Я вже досить довго використовую MySQL і мені комфортно його структура та SQL запити тощо.
В даний час будується нова система в AWS, і я дивився на DynamoDB. В даний час я лише трохи про це знаю.
Чи один кращий, ніж інший?
У чому перевага DynamoDB?
що таке перехід від запитів MySQL тощо на цю плоску БД?
Відповіді:
Ви можете прочитати пояснення AWS про це тут .
Якщо коротко, якщо ви маєте в основному запити пошуку (а не запити приєднання), DynamoDB (та інші БД NoSQL) краще. Якщо вам потрібно обробити велику кількість даних , ви будете обмежені під час використання MySQL (та інших RDBMS).
Ви не можете повторно використовувати свої запити MySQL, а також схему даних, але якщо ви витратите зусилля на вивчення NoSQL, ви додасте важливий інструмент до свого інструментального вікна. Є багато випадків, коли DynamoDB дає найпростіше рішення.
Дійсно DynamoDB і MySQL - це яблука та апельсини. DynamoDB є шаром зберігання NoSQL, тоді як MySQL використовується для реляційного зберігання. Ви повинні вибрати, що використовувати, виходячи з реальних потреб вашої програми. Насправді, деякі програми можуть бути добре обслуговані, використовуючи обидва.
Наприклад, якщо ви зберігаєте дані, які не піддаються належній реляційній схемі (структури дерева, представлення JSON без схем тощо), які можна шукати проти однієї клавіші або комбінації клавіш / діапазону, тоді DynamoDB ( або якийсь інший магазин NoSQL), швидше за все, буде вашою найкращою ставкою.
Якщо у вас є чітко визначена схема для ваших даних, яка може добре вписуватися у реляційну структуру, і вам потрібна можливість запиту даних різними способами (додаючи індекси, якщо потрібно, звичайно), то RDS може бути кращим рішенням .
Основна перевага для використання DynamoDB як магазину NoSQL полягає в тому, що ви отримуєте гарантовану пропускну здатність для читання / запису на будь-якому рівні, який вам потрібен, не турбуючись про управління кластерним сховищем даних. Отже, якщо вашій програмі потрібно 1000 читання / запису в секунду, ви можете просто надати свою таблицю DynamoDB для цього рівня пропускної здатності, і не потрібно переживати за базову інфраструктуру.
RDS має таку саму перевагу, що не потрібно турбуватися про саму інфраструктуру, однак якщо вам знадобиться зробити значну кількість записів до того моменту, коли найбільший розмір екземпляра більше не буде тримати, ви залишаєтесь без параметри (ви можете горизонтально масштабувати для читання за допомогою реплік читання).
Оновлена примітка: DynamoDb тепер підтримує глобальну вторинну індексацію, тому тепер у вас є можливість виконувати оптимізовані пошуки в полях даних, окрім хеша чи комбінації хеш-клавіш і діапазонів ключів.
Ми щойно перенесли всі наші таблиці DynamoDB в RDS MySQL.
Хоча використання DynamoDB для конкретних завдань може мати сенс, побудова нової системи на базі DynamoDB - це справді погана ідея. Кращі закладені плани тощо, вам завжди потрібна додаткова гнучкість у вашому БД.
Ось наші причини, з яких ми перейшли з DynamoDB:
Зараз ми використовуємо DynamoDB як резервну копію для деяких систем, і я впевнений, що ми будемо використовувати його в майбутньому для конкретних, чітко визначених завдань. Це не погано БД, це просто не БД, щоб обслуговувати 100% вашої базової системи.
Що стосується переваг, я б сказав, масштабованість та довговічність. Він масштабує неймовірно та прозоро, і це (начебто) завжди вгору. Це дійсно чудові функції, але вони жодним чином не компенсують недоліків.
Під час використання DynamoDB ви також повинні знати, що елементи / записи в DynamoDB обмежені 400KB (Див. Обмеження DynamoDB ). Для багатьох випадків використання це не допоможе. Тож DynamoDB буде корисний для кількох речей, але не для всіх. Те саме стосується багатьох інших баз даних NoSQL.