DynamoDB vs MongoDB NoSQL

Question

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

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

Моя основная забота о структуре запроса, я еще не рассматривал возможности dynamoDB-запросов, но поскольку это хранилище данных k/v, я чувствую, что это может быть более ограниченным, чем mongo db.

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

 
In a response, DynamoDB returns all the matching results within 
the scope of the Limit value. For example, if you issue a Query 
or a Scan request with a Limit value of 6 and without a filter 
expression, the operation returns the first six items in the 
table that match the request parameters. If you also supply a 
FilterExpression, the operation returns the items within the 
first six items in the table that match the filter requirements. 

Мой вывод заключается в том, что запросы с 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.

Answer 6

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

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

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

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

Answer 7

Я работал над обоими и для своего поклонника.

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

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

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

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

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

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

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

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

Это мое мнение.