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

Я намагаюся розібратися, що я можу використовувати для майбутнього проекту, ми плануємо зберігати приблизно 500 000 записів на місяць в перший рік, а може бути, і більше наступних років. Це вертикальне додаток, тому немає необхідності використовувати База даних для цього, ось чому я вирішив вибрати сховище 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, це ускладнюється. Ви можете зайти до однієї з компаній-хостингів, але це теж не дешево. Якщо "Динамо" вам потрібно більше пропускної здатності, ви просто натисніть кнопку. Ви можете писати сценарії для масштабування автоматично. Коли настає час модернізувати Динамо, це зроблено за вас. Це все велика кількість дорогоцінного стресу і витраченого часу. Якщо ви не '

Отже, ми зараз переходимо до "Динамо" за замовчуванням. Монго, може, якщо структура даних є досить складною для того, щоб її вимагати, але тоді ми, мабуть, повернемося до бази даних SQL. "Динамо" тупіше, вам справді потрібно подумати про те, як ви збираєтеся його будувати, і, ймовірно, ви будете використовувати Redis в Elasticcache, щоб він працював на складні речі. Але це впевнено приємно, що про це не треба дбати. Ви кодуєте. Це воно.

Маючи 500 тис. Документів, немає жодної причини масштабувати. Типовий ноутбук з SSD та 8 ГБ оперативної пам’яті може легко зробити 10 мільйонів записів, тому якщо ви намагаєтеся вибрати через масштабування, ваш вибір насправді не має значення. Я б запропонував вам вибрати те, що вам найбільше подобається, і, можливо, там, де ви можете знайти найбільш онлайн-підтримку.

Для швидкого порівняння оглядів, мені дуже подобається цей веб-сайт, який містить багато сторінок порівняння, наприклад AWS DynamoDB vs 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 з точки зору інфраструктури. Ми можемо запитувати певні предмети у монго, які містять документи з покажчиками (ідентифікаторами) відповідного документа "Динамо".

Основна причина, яку ми вирішили зробити це, використовуючи монго, а не розміщення всієї програми щодо динамо, було з 2 причин. По-перше, нам потрібно було заздалегідь здійснити пошук на місцях, де монго було чудовим і в той час, як у «Динамо», не було, але зараз вони мають можливість.

По-друге, це те, що деякі документи були неструктуровані, і ми не знали заздалегідь, якими будуть дані, наприклад, скажемо, що користувач вводить документ у колекцію "форм" на зразок цього: {"username": "user1", " електронна пошта ":" me@me.com "}. І інший користувач поміщає це в цю ж колекцію {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Завдяки монго ми можемо шукати будь-яке з цих динамічних і невідомих полів у будь-який час, з "Динамо" ви можете це зробити, але доведеться робити індекс кожного разу, коли додається нове поле, яке потрібно шукати. Тож якщо ви ніколи раніше не мали в своєму документі "Динамо" телефонного поля, а потім раптом, хтось додав його, його абсолютно не можна знайти.

Тепер це означає ще один момент, про який ви згадали. Іноді вибір правильного рішення для роботи не завжди означає вибір найкращого продукту для роботи. Наприклад, у вас може бути клієнт, який потребує і буде використовувати систему, яку ви створили протягом 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.