Я использую MySQL на справедливое время, и мне нравится его структура и SQL-запросы и т.д.
В настоящее время строит новую систему в AWS, и я смотрю на DynamoDB. В настоящее время я немного об этом знаю.
Лучше ли другое?
В чем преимущество DynamoDB?
что такое переход, например, от запросов MySQL и т.д. к этому плоскому стилю DB?
Вы можете прочитать объяснение 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.