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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

ОБНОВЛЕНИЕ 1 (06/04/2013)

04/18/2013 Amazon объявила о поддержке локальных вторичных индексов, которые сделали DynamoDB f *** великолепным:

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

Доводы

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

против

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

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