Каковы плюсы и минусы DynamoDB по сравнению с другими базами данных NoSQL?

Question

Мы используем дополнение базы данных MongoDB на Heroku для нашего продукта SaaS.Теперь, когда Amazon запустил DynamoDB, службу облачных баз данных, мне стало интересно, как это меняет ландшафт предложений NoSQL?

Специально для облачных сервисов или поставщиков SaaS, как будет использование DynamoDB лучше или хуже по сравнению с MongoDB??Есть ли какие-либо преимущества в стоимости, производительности, масштабируемости, надежности, драйверах, сообществе и т. Д. При использовании одного из них?

Answer 1

Для начала, он будет полностью управляться командой экспертов Amazon, так что вы можете поспорить, что он будет очень хорошо масштабироваться без участия конечного пользователя (разработчика).

Кроме того, поскольку он создан и управляется Amazon, вы можете предположить, что они разработали его так, чтобы он очень хорошо работал со своей инфраструктурой, поэтому можно предположить, что производительность будет на высшем уровне. Помимо того, что они специально созданы для их инфраструктуры, они решили использовать SSD в качестве хранилища, поэтому с самого начала пропускная способность диска будет значительно выше, чем в других хранилищах данных на AWS с поддержкой жесткого диска.

Я еще не видел никаких драйверов, и я думаю, что еще слишком рано говорить о том, как сообщество отреагирует на это, но я подозреваю, что у Amazon будут драйверы для всех самых популярных языков, и сообщество, вероятно, получит это хорошо - и в свою очередь создайте дополнительные драйверы и инструменты.

Answer 2

Я думаю, что ключевым отличием является то, что MongoDB - это программное обеспечение, которое вы можете установить где угодно (в том числе в AWS или в другой облачной службе или внутри компании), поскольку DynamoDB - это SaaS, доступный исключительно в качестве хост-сервиса от Amazon (AWS).,Если вы хотите сохранить возможность размещения своего приложения внутри компании, DynamoDB не подходит.Если хостинг вне AWS не рассматривается, то DynamoDB должен быть вашим выбором по умолчанию, если только особые функции не являются более важными.

Answer 3

В следующей ссылке есть таблица, в которой обобщены атрибуты DynamoDB и Cassandra:

http://www.datastax.com/dev/blog/amazon-dynamodb

Что-то, что нуждается в улучшении DynamoDB, чтобы стать более удобным для использования, - это возможность индексировать столбцы, отличные от первичного ключа.

ОБНОВЛЕНИЕ 1 (04.06.2013)

18.04.2013 Amazon объявила о поддержке локальных вторичных индексов, что сделало DynamoDB великолепным:

http://aws.amazon.com/about-aws/whats-new/2013/04/18/amazon-dynamodb-announces-local-secondary-indexes/

Answer 4

Использование MongoDB через надстройку для Heroku эффективно превращает MongoDB в продукт SaaS.

В действительности можно сравнить любую услугу, выбранную выбранным поставщиком, с тем, что может предложить Amazon, вместо сравнения одного решения для обеспечения устойчивости с другим.

Это очень сложно сделать. Каждый провайдер будет иметь разные уровни обслуживания в разных ценовых категориях, и можно рассмотреть вариант запуска его на своем собственном оборудовании локально для целей разработки. Добро пожаловать.

Answer 5

Я думаю, что одно из ключевых отличий между DynamoDB и другими предложениями NoSQL заключается в обеспечиваемой пропускной способности - вы платите за определенный уровень пропускной способности в таблице и, при условии, что ваши данные хорошо разделены, всегда можно ожидать, что пропускная способность будет достигнута.Таким образом, по мере увеличения нагрузки на ваше приложение вы можете увеличивать и поддерживать производительность более или менее постоянной.

Answer 6

Я должен быть честным;Я был очень взволнован, когда узнал о новом DynamoDB и вчера посетил вебинар.Однако сейчас так сложно принять решение, потому что все, что они сказали, было еще очень расплывчато;Я понятия не имею, какие функции будут разрешены / использованы через их службу.

Единственное, что я знаю, это то, что масштабирование выполняется автоматически;это довольно круто, но все еще так много неизвестных, что трудно действительно провести хороший анализ, пока все факты не будут собраны, и мы не сможем его использовать.

До сих пор я все еще вижу, что монго работает намного лучшедля меня (лично) в проекте, над которым я работаю.

Как и большинство решений по БД, на самом деле все сводится к проекту, исходя из проектного решения, которое лучше всего подходит для ваших нужд.

Я с нетерпением жду дополнительной информации о продукте, хотя покаЯ нахожусь в бета-версии, и я бы не стал прыгать с корабля, чтобы принять самый последний и лучший тестер:)

Answer 7

Amazon DynamoDB выглядит довольно неплохим решением для NoSQL.Это быстро и довольно просто в использовании.Помимо наличия учетной записи AWS, на самом деле не требуется никакой настройки или обслуживания.Набор функций и API в настоящее время довольно мал по сравнению с MongoDB / CouchDB / Cassandra, но я, вероятно, ожидал бы, что со временем он будет расти по мере получения отзывов от сообщества разработчиков.В настоящий момент все официальные пакеты AWS SDK включают в себя клиент DynamoDB.

Answer 8

Pros

1. Lightning Fast (использует твердотельные накопители внутри)
2. Действительно (действительно) надежно.(вероятность сбоев при записи ниже)
3. Бесшовное масштабирование (нет необходимости в ручном разделении)
4. Работает как веб-сервисы (без сервера, без настройки, без установки)
5. Легкоинтегрирован с другими функциями AWS (может хранить всю таблицу в S3 или использовать EMR и т. д.)
6. Управление репликацией осуществляется изнутри, поэтому вероятность случайной потери данных незначительна.

Минусы

1. Очень (очень) ограниченные запросы.
2. Сканирование является болезненным (я помню, однажды сканирование через Java выполнялось в течение 6 часов)
3. предопределенная пропускная способность, что означаетвнезапное увеличение сверх установленной пропускной способности будет подавлено. Пропускная способность
4. разделена, так как таблица будет внутренне обработана.(это означает, что если у вас была пропускная способность 1000 и ее разделение на две части, и если вы читаете только самые последние данные (из одной части), то ваша пропускная способность чтения составляет только 500)
5. Нет объединений, разрешена ограниченная индексация(в основном 2).
6. Нет представлений, триггеров, сценариев или хранимых процедур.

Это действительно хорошая альтернатива хранилищу сеансов в масштабируемом приложении.Другим хорошим использованием будет регистрация / аудит в обширной системе.НЕ предпочтительна для многофункциональных приложений с частыми улучшениями или изменениями.