Amazon SimpleDB
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 ]
Ограничения
[ редактировать ] | Этот раздел может чрезмерно полагаться на источники, слишком тесно связанные с предметом , что может помешать статье стать проверяемой и нейтральной . ( Май 2016 г. ) |
SimpleDB обеспечивает итоговую согласованность , которая является более слабой формой согласованности по сравнению с другими системами управления базами данных . Это часто считают ограничением, поскольку об этом труднее рассуждать, что затрудняет написание правильных программ, использующих SimpleDB. Это ограничение является результатом фундаментального компромисса при проектировании. Благодаря вышеуказанной последовательности система способна достичь двух других весьма желательных свойств:
- доступность – компоненты системы могут выйти из строя, но сервис продолжит работать корректно.
- толерантность к разделению – компоненты системы соединены друг с другом компьютерной сетью . Если компоненты не могут связаться друг с другом по сети (состояние, известное как сетевой раздел ), работа системы продолжится.
Предполагается, что отказы компонентов неизбежны; таким образом, оба этих свойства были сочтены необходимыми для обеспечения надежного веб-сервиса . Теорема CAP утверждает, что система не может проявлять эти свойства вместе с согласованностью; таким образом, дизайнерам пришлось согласиться на более слабую форму согласованности.
Опубликованные ограничения: [ 4 ]
Ограничения магазина
[ редактировать ] | Этот раздел может чрезмерно полагаться на источники, слишком тесно связанные с предметом , что может помешать статье стать проверяемой и нейтральной . ( Май 2016 г. ) |
| Атрибут | Максимум |
|---|---|
| домены | 250 активных доменов на аккаунт. Дополнительную информацию можно запросить, заполнив форму. [ 5 ] |
| размер каждого домена | 10 ГБ |
| атрибуты для каждого домена | 1,000,000,000 |
| атрибуты для каждого элемента | 256 атрибутов |
| размер на атрибут | 1024 байта |
Ограничения запроса
[ редактировать ]| Атрибут | Максимум |
|---|---|
| элементы, возвращаемые в ответе на запрос | 2500 предметов |
| секунд, в которых может выполняться запрос | 5 с |
| имена атрибутов для каждого предиката запроса | 1 имя атрибута |
| сравнения по предикату | 22 оператора |
| предикаты для каждого выражения запроса | 20 предикатов |
Функции
[ редактировать ]Условное размещение и удаление
[ редактировать ]Условное размещение и условное удаление — это новые операции, добавленные в феврале 2010 года. Они решают проблему, возникающую при одновременном доступе к SimpleDB. Рассмотрим простую программу, использующую SimpleDB для хранения счетчика, т. е. числа, которое можно увеличивать. Программа должна делать три вещи:
- Получите текущее значение счетчика из SimpleDB.
- Добавьте единицу к значению.
- Сохраните новое значение в том же месте, что и старое значение в SimpleDB.
Если эта программа запускается, когда другие программы не имеют доступа к SimpleDB, она будет работать правильно; однако часто желательно, чтобы программные приложения (особенно веб-приложения ) имели одновременный доступ к одним и тем же данным. Когда к одним и тем же данным осуществляется одновременный доступ, возникает состояние гонки , которое может привести к необнаружимой потере данных.
Продолжая предыдущий пример, рассмотрим два процесса A и B, выполняющие одну и ту же программу. Предположим, что сервисы SimpleDB запрашивают данные, как описано в шаге 1, как от A, так и от B. A и B видят одно и то же значение. Допустим, текущее значение счетчика равно 0. Из-за шагов 2 и 3 A попытается сохранить 1. B попытается сделать то же самое; таким образом, окончательное значение счетчика будет равно 1, хотя ожидаемое окончательное значение счетчика равно 2, поскольку система предприняла две операции увеличения: одну на A, а другую на B.
Эту проблему можно решить, используя условный пут. Предположим, мы изменили шаг 3 следующим образом: вместо безусловного сохранения нового значения программа просит SimpleDB сохранить новое значение только в том случае, если значение, которое она хранит в данный момент, совпадает со значением, полученным на шаге 1. Тогда мы можем убедитесь, что значение счетчика действительно увеличивается. Это вносит некоторую дополнительную сложность; если SimpleDB не удалось сохранить новое значение, поскольку текущее значение не соответствует ожидаемому, программа должна повторять шаги 1–3 до тех пор, пока операция условного размещения фактически не изменит сохраненное значение.
Постоянное чтение
[ редактировать ]Согласованное чтение было новой функцией, выпущенной одновременно с условным размещением и условным удалением. Как следует из названия, согласованное чтение решает проблемы, возникающие из-за модели конечной согласованности SimpleDB (см. раздел «Ограничения» ). Рассмотрим следующую последовательность действий:
- Программа А хранит некоторые данные в SimpleDB.
- Сразу после этого A запрашивает только что сохраненные данные.
Гарантия конечной согласованности SimpleDB не позволяет нам сказать, что данные, полученные на шаге 2, отражают обновления, сделанные на шаге 1. Окончательная согласованность гарантирует только то, что шаг 2 отражает полный набор обновлений на шаге 1 или ни одно из этих обновлений. Согласованное чтение можно использовать, чтобы гарантировать, что данные, полученные на шаге 2, отражают изменения на шаге 1.
Причина, по которой могут возникнуть противоречивые результаты, когда не используется операция согласованного чтения, заключается в том, что SimpleDB хранит данные в нескольких местах (для доступности), а новые данные на шаге 1 могут быть записаны не во всех местах, когда SimpleDB получает запрос данных на шаге 2. В этом случае возможно, что запрос данных на шаге 2 обслуживается в одном из мест, где новые данные не были записаны.
Amazon не рекомендует использовать последовательное чтение, если только оно не требуется для корректности. Причина этой рекомендации заключается в том, что скорость обслуживания операций последовательного чтения ниже, чем при обычном чтении.
Связь с DynamoDB
[ редактировать ] | Этот раздел может чрезмерно полагаться на источники, слишком тесно связанные с предметом , что может помешать статье стать проверяемой и нейтральной . ( Май 2016 г. ) |
Были некоторые разговоры о замене SimpleDB DynamoDB (он больше не «повторяется», [ 6 ] хотя Amazon не планирует его удалять). DynamoDB кажется его преемником. [ 7 ] [ 8 ]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Что нужно знать об Amazon SimpleDB
- ^ Перейти обратно: а б «AWS | Amazon SimpleDB — простая служба баз данных» . Amazon Веб-сервисы, Inc.
- ^ SimpleDB — Уровень бесплатного пользования — Изменение цен на AWS. Архивировано 25 декабря 2008 г. на Wayback Machine.
- ^ «Ограничения», Руководство разработчика SimpleDB , Amazon (последняя версия API).
- ^ Запрос на увеличение распределения доменов Amazon SimpleDB . Aws.amazon.com. Проверено 9 августа 2013 г.
- ^ «Форумы разработчиков AWS: будущее SimpleDB? ...» forums.aws.amazon.com .
- ^ http://aws.amazon.com/dynamodb/faqs/#How_does_Amazon_DynamoDB_differ_from_Amazon_SimpleDB_Which_should_I_use Dynamo, созданная «для устранения ограничений SimpleDB».
- ^ «Amazon DynamoDB — быстрая и масштабируемая служба баз данных NoSQL, разработанная для приложений масштаба Интернета — все распределено» . www.allthingsdistributed.com . 18 января 2012 г.
Внешние ссылки
[ редактировать ]
| Базы данных органов управления : Национальные |
|---|
