Amazon SimpleDB — это распределенная база данных , написанная на Erlang [1] компанией Amazon.com . Она используется как веб-сервис совместно с Amazon Elastic Compute Cloud (EC2) и Amazon S3 и является частью Amazon Web Services . Она была анонсирована 13 декабря 2007 года. [2]
Как и в случае с EC2 и S3, Amazon взимает плату за хранение SimpleDB, передачу и пропускную способность через Интернет. 1 декабря 2008 года Amazon ввел новые цены с бесплатным уровнем [3] за 1 ГБ данных и 25 машинных часов. Передача на другие веб-сервисы Amazon бесплатна. [2]
SimpleDB обеспечивает конечную согласованность , которая является более слабой формой согласованности по сравнению с другими системами управления базами данных . Это часто считается ограничением, поскольку его сложнее рассуждать, что затрудняет написание корректных программ, использующих SimpleDB. Это ограничение является результатом фундаментального компромисса в дизайне. Отказавшись от согласованности, система может достичь двух других весьма желательных свойств:
Предполагается, что отказы компонентов неизбежны; таким образом, оба эти свойства были признаны необходимыми для обеспечения надежного веб-сервиса . Теорема CAP утверждает, что система не может демонстрировать эти свойства вместе с согласованностью; таким образом, проектировщикам пришлось довольствоваться более слабой формой согласованности.
Опубликованные ограничения: [4]
Условный put и условное delete — новые операции, добавленные в феврале 2010 года. Они решают проблему, которая возникает при одновременном доступе к SimpleDB. Рассмотрим простую программу, которая использует SimpleDB для хранения счетчика, т. е. числа, которое можно увеличивать. Программа должна выполнять три действия:
Если эта программа выполняется, пока никакие другие программы не обращаются к SimpleDB, она будет работать правильно; однако часто бывает желательно, чтобы программные приложения (особенно веб-приложения ) обращались к тем же данным одновременно. Когда к тем же данным обращаются одновременно, возникает состояние гонки , что может привести к необнаружимой потере данных.
Продолжая предыдущий пример, рассмотрим два процесса, A и B, запускающие одну и ту же программу. Предположим, что SimpleDB обслуживает запросы данных, как описано в шаге 1, от A и B. A и B видят одно и то же значение. Предположим, что текущее значение счетчика равно 0. Из-за шагов 2 и 3 A попытается сохранить 1. B попытается сделать то же самое; таким образом, конечное значение счетчика будет равно 1, хотя ожидаемое конечное значение счетчика равно 2, потому что система попыталась выполнить две операции приращения, одну по A, а другую по B.
Эту проблему можно решить с помощью условного put. Предположим, мы изменим шаг 3 следующим образом: вместо безусловного сохранения нового значения программа просит SimpleDB сохранить новое значение только в том случае, если текущее значение совпадает со значением, полученным на шаге 1. Тогда мы можем быть уверены, что значение счетчика действительно увеличивается. Это вносит некоторую дополнительную сложность; если SimpleDB не смогла сохранить новое значение, поскольку текущее значение не соответствовало ожидаемому, программа должна повторять шаги 1–3 до тех пор, пока операция условного put фактически не изменит сохраненное значение.
Consistent read — это новая функция, которая была выпущена одновременно с conditional put и conditional delete. Как следует из названия, consistent read решает проблемы, возникающие из-за модели согласованности SimpleDB в конечном счете (см. раздел Ограничения). Рассмотрим следующую последовательность операций:
Гарантия согласованности SimpleDB в конечном итоге не позволяет нам утверждать, что данные, полученные на шаге 2, отражают обновления, сделанные на шаге 1. Согласованность в конечном итоге гарантирует только то, что шаг 2 отражает полный набор обновлений на шаге 1 или ни одно из этих обновлений. Согласованное чтение может использоваться для того, чтобы гарантировать, что данные, полученные на шаге 2, отражают изменения на шаге 1.
Причина, по которой могут возникать несогласованные результаты, когда не используется операция согласованного чтения, заключается в том, что SimpleDB хранит данные в нескольких местах (для обеспечения доступности), а новые данные на шаге 1 могут быть записаны не во все места, когда SimpleDB получает запрос данных на шаге 2. В этом случае возможно, что запрос данных на шаге 2 обслуживается в одном из мест, куда новые данные не были записаны.
Amazon не рекомендует использовать согласованное чтение, если только это не требуется для корректности. Причина этой рекомендации в том, что скорость обслуживания операций согласованного чтения ниже, чем для обычных чтений.
Ходили разговоры о том, что SimpleDB будет заменена DynamoDB (она больше не «повторяется», [6] хотя Amazon не планирует ее удалять). DynamoDB, по всей видимости, является ее преемником. [7] [8]