AWS MySQL RDS против AWS DynamoDB [закрыто]


109

Я уже довольно давно использую MySQL, и мне удобна его структура, SQL-запросы и т. Д.

В настоящее время создаю новую систему в AWS, и я смотрел на DynamoDB. В настоящее время я знаю об этом очень мало.

Одно лучше другого?

В чем преимущество DynamoDB?

как происходит переход от запросов MySQL и т. д. к этой БД в плоском стиле?

Ответы:


66

Вы можете прочитать объяснение AWS об этом здесь .

Короче говоря, если у вас в основном запросы Lookup (а не запросы соединения), DynamoDB (и другие базы данных NoSQL) лучше. Если вам нужно обрабатывать много данных , вы будете ограничены при использовании MySQL (и других СУБД).

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


262

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

Если, например, вы храните данные, которые не подходят для реляционной схемы (древовидные структуры, представления JSON без схемы и т. Д.), Которые можно искать по одному ключу или комбинации ключ / диапазон, то DynamoDB ( или какой-нибудь другой магазин NoSQL), вероятно, будет вашим лучшим выбором.

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

Основное преимущество использования DynamoDB в качестве хранилища NoSQL заключается в том, что вы получаете гарантированную пропускную способность чтения / записи на любом требуемом уровне, не беспокоясь об управлении хранилищем кластеризованных данных. Поэтому, если вашему приложению требуется 1000 операций чтения / записи в секунду, вы можете просто подготовить свою таблицу DynamoDB для этого уровня пропускной способности и не беспокоиться о базовой инфраструктуре.

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

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


10
Если бы я мог проголосовать за ваш ответ на 100, я бы это сделал.
Салил

Некоторые проблемы в информационной модели хорошо подходят для реализации NoSQL. Когда вы сталкиваетесь с такими проблемами, задайте себе вопрос, имеет ли смысл иметь NoSQL Db. Вот некоторые из этих сущностей: журналы, данные временных рядов, социальные сети, управление контентом, каталог продуктов и т. Д.
user398039

150

Мы только что перенесли все наши таблицы DynamoDB в RDS MySQL.

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

Вот причины, по которым мы перешли из DynamoDB:

  1. Индексирование - изменение или добавление ключей на лету невозможно без создания новой таблицы.
  2. Запросы - Запросы данных крайне ограничены. Особенно, если вы хотите запрашивать неиндексированные данные. Соединения, конечно, невозможны, поэтому вам нужно управлять сложными отношениями данных на уровне кода / кеша.
  3. Резервное копирование - такая утомительная процедура резервного копирования является разочаровывающим сюрпризом по сравнению с гладким резервным копированием RDS.
  4. GUI - плохой UX, ограниченный поиск, никакого удовольствия.
  5. Скорость - время отклика проблематично по сравнению с RDS. Вы обнаруживаете, что создаете сложный механизм кэширования, чтобы компенсировать это в тех местах, где вы бы устроились для внутреннего кэширования RDS.
  6. Целостность данных. Хотя концепция гибкой структуры данных для начала звучит неплохо, некоторые из ваших данных лучше «высечены в камне». Строгая типизация - это благословение, когда небольшая ошибка пытается уничтожить вашу базу данных. С DynamoDB возможно все, и действительно все, что может пойти не так, как надо.

Сейчас мы используем DynamoDB в качестве резервной копии для некоторых систем, и я уверен, что мы будем использовать его в будущем для конкретных, четко определенных задач. Это неплохая БД, это просто не БД для 100% обслуживания вашей базовой системы.

Что касается преимуществ, я бы сказал, что это масштабируемость и долговечность. Он невероятно и прозрачно масштабируется и (как бы) всегда работает. Это действительно отличные функции, но они никоим образом не компенсируют недостатки.


11
Очень конкретные плюсы / минусы. Отличный ответ
stevendesu

10
Некоторые из них устарели. Например, 1 больше не соответствует действительности.
mbroshi

2
Очень хорошо задокументированный ответ. Однако некоторые из этих проблем могут быть специфичны для редких случаев использования. Номер 2 - «Соединения, конечно, невозможны» - структуры данных DynamoDB не должны иметь никаких отношений - точка. Таблица должна быть полностью денормализована. Это означает, что некоторые атрибуты дублируются. В таких случаях используйте динамо-триггер или условную запись. Если пользователи не могут справиться с задержкой при условной записи, поместите очередь SQS между приложением и динамо-машиной. Кроме того, пункт № 6 к неверно названы точки , что ставит под сомнение «целостность» DynamoDB в - это не может быть намерение ...
скупо

1
Dynamo по-прежнему не хватает гибкости при выполнении запросов. Хотя GSI - огромная помощь, мы все же можем лучше моделировать наши данные с помощью схемы RDBMS.
Паван

1
Я бы добавил, что возможности запросов в DynamoDB имеют несколько "подводных камней". Например, если ваш первичный ключ состоит только из хэша, запрос Dynamo может возвращать только 1 запись, вы не можете предоставить диапазон для ключа, содержащего только хэш, во время запроса, а также вы не можете запросить, не зная конкретного хеша для предмет, который вы ищете. BatchGet принимает только 100 запросов в запросе, общий размер ответа 1 МБ или общий размер запроса 1 МБ, в зависимости от того, что наступит раньше. Сканирование дает вам гибкий поиск, но он крайне неэффективен и дорог, поскольку возвращает всю таблицу перед фильтрацией.
Brooks

12

При использовании DynamoDB вы также должны знать, что элементы / записи в DynamoDB ограничены 400 КБ (см. Ограничения DynamoDB ). Во многих случаях это не сработает. Так что DynamoDB хорош для некоторых вещей, но не для всех. То же самое и со многими другими базами данных NoSQL.

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