DynamoDB против MongoDB NoSQL

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

Короткий ответ: начните с 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 года Бретт Холлман (Brett Hollman), менеджер по архитектуре решений, AWS в своем разговоре о том, что ваши первые 10 миллионов пользователей выступают за поддержку базы данных SQL, а затем используя NoSQL только тогда, когда и если имеет смысл. Потому что рано или поздно вам, вероятно, понадобится SQL-сервер в вашем стеке. Его слайды здесь: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users См. Слайд 28.

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

Я работал над обоими и любителями обоих.

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

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

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

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

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

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

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

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

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