Я уже довольно давно использую MySQL, и мне удобна его структура, SQL-запросы и т. Д.
В настоящее время создаю новую систему в AWS, и я смотрел на DynamoDB. В настоящее время я знаю об этом очень мало.
Одно лучше другого?
В чем преимущество DynamoDB?
как происходит переход от запросов MySQL и т. д. к этой БД в плоском стиле?
Вы можете прочитать объяснение AWS об этом здесь .
Короче говоря, если у вас в основном запросы Lookup (а не запросы соединения), DynamoDB (и другие базы данных NoSQL) лучше. Если вам нужно обрабатывать много данных , вы будете ограничены при использовании MySQL (и других СУБД).
Вы не можете повторно использовать свои запросы 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 ограничены 400 КБ (см. Ограничения DynamoDB ). Во многих случаях это не сработает. Так что DynamoDB хорош для некоторых вещей, но не для всех. То же самое и со многими другими базами данных NoSQL.
источник