it-swarm.com.ru

DynamoDB против MongoDB NoSQL

Я пытаюсь выяснить, что я могу использовать для будущего проекта, мы планируем хранить от 500 тыс. Записей в месяц в первый год и, возможно, еще больше в течение следующих лет, это вертикальное приложение, поэтому нет необходимости использовать Для этого я решил выбрать хранилище данных noSQL.

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

Мое главное беспокойство связано со структурой запросов, я еще не рассматривал возможности запросов DynamoDB, но так как это хранилище данных K/V, я чувствую, что это может быть более ограниченным, чем Mongo DB.

Если кто-то имел опыт переноса проекта из mongoDB в DynamoDB, любой совет будет полностью оценен.

157
jack.the.ripper

Недавно я перенес свою MongoDB в DynamoDB и написал 3 блога, чтобы поделиться опытом и данными о производительности и стоимости.

Миграция из MongoDB в AWS DynamoDB + SimpleDB

7 причин, по которым вы должны использовать MongoDB вместо DynamoDB

причины, по которым вы должны использовать DynamoDB вместо MongoDB

54
Mason Zhang

Я знаю, что это старый, но он все еще появляется, когда вы ищете для сравнения. Мы использовали Mongo, почти полностью перешли в "Динамо", что является нашим первым выбором. Не потому, что у него больше возможностей, это не так. Mongo имеет лучший язык запросов, вы можете индексировать в структуре, есть много мелочей. Преимущество "Динамо" заключается в том, что ОП заявило в своем комментарии: это легко. Вам не нужно заботиться о каких-либо серверах. Когда вы начинаете настраивать монго-решение, оно становится сложным. Вы можете пойти в одну из хостинговых компаний, но это тоже не дешево. С Динамо, если вам нужна большая пропускная способность, вы просто нажимаете кнопку. Вы можете написать сценарии для автоматического масштабирования. Когда пришло время обновить Динамо, это сделано для вас. Это все много драгоценного стресса и не потраченного времени. Если у вас нет преданных сотрудников, то Динамо отлично.

Так что теперь мы едем на "Динамо" по умолчанию. Монго, может быть, если структура данных достаточно сложна, чтобы это оправдать, но тогда мы, вероятно, вернемся к базе данных SQL. Динамо тупое, вам действительно нужно подумать о том, как вы собираетесь его построить, и, вероятно, вы будете использовать Redis в Elasticcache, чтобы заставить его работать для сложных вещей. Но это конечно хорошо, что не нужно заботиться об этом. Вы код. Вот и все.

159
CargoMeister

С 500 тыс. Документов нет оснований для масштабирования. Типичный ноутбук с твердотельным накопителем и 8 ГБ оперативной памяти может легко сделать десятки миллионов записей, поэтому, если вы пытаетесь выбрать из-за масштабирования, ваш выбор не имеет значения. Я бы посоветовал вам выбрать то, что вам больше всего нравится, и, возможно, там, где вы сможете найти больше всего поддержки онлайн.

55
Derick

Для быстрых сравнительных обзоров мне очень нравится этот веб-сайт, на котором есть много страниц сравнения, например, AWS DynamoDB против MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

21
AnneTheAgile

Краткий ответ: начните с SQL и добавляйте NoSQL только тогда, когда это необходимо. (если вам не нужно ничего кроме очень простых запросов)

Мой личный опыт: я не использовал MongoDB для запросов, но по состоянию на апрель 2015 года DynamoDB все еще очень ограничен, когда речь идет о чем-то помимо самых простых запросов ключ/значение. Мне нравится это для базовых вещей, но если вы хотите язык запросов, то посмотрите на реальное решение для базы данных SQL.

В DynamoDB вы можете запрашивать хеш или ключ хеша и диапазона, и вы можете иметь несколько вторичных глобальных индексов. Я делаю запросы к одной таблице с 4-мя возможными параметрами фильтра и сортирую результаты, это поддерживается (почти) за счет использования глобальных вторичных индексов с выражениями фильтра. Проблема возникает, когда вы пытаетесь получить итоговые результаты, соответствующие фильтру, вы не можете просто искать первые 10 элементов, соответствующих фильтру, вместо этого он проверяет 10 элементов, и вы можете получить 0 действительных результатов, заставляя вас продолжать Сканирование с помощью клавиши "Продолжить" - боль в шее и слишком большая квота чтения таблицы для простого сценария.

Если говорить конкретно о проблеме ограничения с фильтрами в запросе, то это из документации ( http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ) :

 В ответе DynamoDB возвращает все результаты сопоставления в пределах 
 Области действия значения Limit. Например, если вы отправляете запрос 
 Или запрос сканирования со значением предела 6 и без выражения фильтра 
, Операция возвращает первые шесть элементов в таблице 
, Которые сопоставьте параметры запроса. Если вы также предоставите 
 FilterExpression, операция вернет элементы в пределах первых 
 Шести элементов таблицы, которые соответствуют требованиям фильтра. 

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

Мнение эксперта. На саммите AWS 9 апреля 2015 года Бретт Холлман, менеджер по архитектуре решений, AWS в своем выступлении по вопросу о привлечении ваших первых 10 миллионов пользователей выступает за то, чтобы начать с базы данных SQL и затем использовать NoSQL только тогда и тогда, когда это имеет смысл. Потому что рано или поздно вам, вероятно, понадобится SQL-сервер где-нибудь в вашем стеке. Его слайды находятся здесь: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users См. Слайд 28.

16
Deemoe

Мы выбрали комбинацию Монго/Динамо для медицинского продукта. В основном, монго позволяет лучше искать, но размещенное "Динамо" великолепно, потому что оно совместимо с HIPAA без дополнительной работы. Таким образом, мы размещаем часть монго без личных данных в стандартной настройке и позволяем Amazon работать с частью HIPAA с точки зрения инфраструктуры. Мы можем запросить определенные элементы из Монго, которые вызывают документы с указателями (идентификаторами) соответствующего документа "Динамо".

Основная причина, по которой мы решили сделать это, используя mongo вместо размещения всего приложения на динамо, была по двум причинам. Во-первых, нам нужно было предварительно выполнить поиск на основе определения местоположения, что хорошо для Монго, и в то время Динамо не было, но у них теперь есть возможность.

Во-вторых, некоторые документы были неструктурированными, и мы заранее не знали, какими будут данные, поэтому, например, скажем, пользователь вводит документ в коллекцию "form", например: {"username": "user1", " электронная почта ":" [email protected] "}. А другой пользователь помещает это в ту же коллекцию {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. С помощью mongo мы можем искать любое из этих динамических и неизвестных полей в любое время, с помощью Dynamo вы можете сделать это, но вам придется создавать индекс каждый раз, когда добавляется новое поле, которое вы хотели найти. Так что, если у вас никогда не было телефонного поля в документе "Динамо", а потом вдруг, кто-то добавляет его, его совершенно невозможно найти.

Теперь это поднимает еще один момент, в котором вы упомянули. Иногда выбор правильного решения для работы не всегда означает выбор лучшего продукта для работы. Например, у вас может быть клиент, который нуждается и будет использовать созданную вами систему в течение 10+ лет. Использование решения SaaS/IaaS, которое является достаточно хорошим для выполнения работы, может быть лучшим вариантом, поскольку вы можете положиться на Amazon, чтобы поддерживать и поддерживать свои системы в течение длительного времени.

14
Steffan Perry

Я работал над обоими и как фанат обоих.

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

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

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

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

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

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

DynamoDB следует использовать там, где скорость критична, с другой стороны, у MongoDB слишком много рук и возможностей, чего нет у DynamoDB.

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

Это мое мнение, хотя.

8
Rahul Kumar

Имейте в виду, я только экспериментировал с MongoDB ...

Из того, что я прочитал, DynamoDB прошел долгий путь с точки зрения возможностей. Раньше это было суперосновное хранилище значений ключей с крайне ограниченными возможностями хранения и запросов. С тех пор он вырос, теперь поддерживает большие размеры документов + поддержка JSON и глобальные вторичные индексы . Разрыв между возможностями DynamoDB и MongoDB с точки зрения возможностей с каждым месяцем уменьшается. Новые возможности DynamoDB расширены на здесь .

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

Мой вывод: если вы делаете серьезные запросы к базе данных или работаете на языках, не поддерживаемых DynamoDB, используйте MongoDB. В противном случае, придерживайтесь DynamoDB.

7
AndrewSouthpaw