DynamoDB против MongoDB NoSQL [закрыто]

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

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

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

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

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

Миграция с MongoDB на AWS DynamoDB + SimpleDB

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

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

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

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

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

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

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

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

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

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

В ответ DynamoDB возвращает все совпадающие результаты в
область действия предельного значения. Например, если вы выполните запрос
или запрос на сканирование с предельным значением 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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