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


172

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

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

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

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


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

Действительно, то, как вы запрашиваете данные, может существенно повлиять на выбор базы данных бэкэнда. Насколько иерархичным был бы мой вопрос №1.
Занлок

3
Я удивлен, что этот вопрос еще не закрыт рейтингом ТАКИХ людей. Обычно вопросы, которые обращаются за советом, закрываются, потому что они не обращаются за помощью по очень конкретной проблеме.
LS

Ответы:


67

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

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

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

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


спасибо за размещение ваших статей здесь, которые помогли мне иметь более ясное видение, и это определенно поможет мне к тому времени, когда я приму решение
jack.the.ripper

1
Изучив три причины, по которым вы должны использовать динамо по сравнению с монго, есть компания, которая предлагает управляемый сервис, который стоит дороже по сравнению с DynamoDB, но это может быть принято во внимание, если у вас нет человека, отвечающего за обслуживание nosql. , название компании - mongoLab
jack.the.ripper

2
@Pedro Большое спасибо за напоминание. Возможно я использую MongoDB неэффективным способом. У меня 1,4 миллиона записей, и я занимал диск 8G, но после переноса в DynamoDB занимал только 300 миллионов. Мне может понадобиться тест и посмотреть, что за хранилище, если я перенесу эти данные в MongoLab :)
Мейсон Чжан

1
Ссылки не работают?
Федорки 'ТАК прекрати вредить'

@MasonZhang Будет очень интересно посмотреть, что такое хранилище, если вы перенесете эти данные в MongoLab.
fuiiii

164

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

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


35
Если нужно сравнить базу данных с базой данных, нужно сравнить только функции базы данных. Размещенное решение не является функцией базы данных. Если вы ищете размещенный MongoDB, перейдите на MongoHQ, и он выполнит всю тяжелую работу, которую вы можете избежать, сосредоточившись на своей основной работе.
Kabeer

12
Это правда, хотя первоначальное сравнение стоимости, которое мы сделали, показало, что динамо является довольно выгодной сделкой. Другая проблема заключается в том, что если вам нужно увеличить / уменьшить динамо, это просто нажатие кнопки. Если вам нужно добавить диск или изменить размер сервера Монго, это может привести к простоям, нужно ли вам это делать или кому-то еще.
CargoMeister

@ Kabeer Я на 100% согласен с вами технически, но в реальном мире весь пакет имеет значение для принятия бизнес-решения. В конечном итоге это бизнес-решение.
poitroae

59

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


да, моя забота мэра о расширении и обслуживании со временем, чтобы быть честным лично, я чувствую, что mongoDB может сделать работу, о которой я только думаю, с точки зрения среднего и долгосрочного обслуживания
jack.the.ripper

10
Дерик, еще один важный фактор масштаба - это использование, а не только количество документов или размер базы данных. @jack не «чувствует», а полагается на тестирование, включая платформу и оборудование окончательного развертывания; неделя, затраченная на заполнение пары вариантов БД данными и бенчмаркинг, должна привести к принятию обоснованных решений, избавляющих от многих проблем.
Занлок

3
Предоставление профессионального продукта / услуги выходит далеко за рамки простого решения «это может сделать это». То, что дешевая машина может работать под управлением Linux, MongoDB и миллионов записей практически без денег, не означает высокую производительность в реальном мире. Записи 500K (с простой схемой), вероятно, были бы хорошим кандидатом для DynamoDB просто потому, что у OP не было бы никаких затрат на обслуживание (по крайней мере, для оборудования), и ежемесячная плата, вероятно, была бы намного меньше, чем стоимость сервера в течение год или два.
cbmeeks


16

Краткий ответ: начните с 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.


Вы действительно должны проверить, насколько легко интегрировать cloudsearch с потоками динамодб и лямбда-выражениями для охвата полнотекстовых или локализованных запросов.
MrTJ

4
Выберите базу данных в соответствии с вашими потребностями. Это не выбор между SQL и noSQL, а между документно-ориентированной БД, графо-ориентированной БД, БД с ключом-значением, RDMBS ... Золотого выбора нет, и SQL, безусловно, нет.
vcarel

14

Мы выбрали комбинацию Монго / Динамо для медицинского продукта. В основном, монго позволяет лучше выполнять поиск, но размещенное «Динамо» великолепно, потому что оно совместимо с 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, чтобы поддерживать и поддерживать свои системы в течение длительного времени.


9

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

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

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

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

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

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

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

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

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

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


1
А сочетание Redis и MongoDB? Это потрясающе, я думаю.
Исмаэстро

Я полагаю, что у меня нет опыта работы с Redis, но наверняка он широко используется из-за своей производительности, в БД памяти почти всегда лучше, чем на дисковых БД. Поэтому я думаю, что данные, к которым нужно обращаться по огромному запросу и с высокой частотой, должны идти в Redis. С другой стороны, для больших летаргических данных следует использовать MongoDB.
Рахул Кумар

7

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.