Является ли NoSQL просто маркетинговой шумихой поверх СУБД с точки зрения дизайна программного обеспечения?

Question

С точки зрения архитектуры: не могли бы вы помочь мне понять, почему NoSQL DynamoDB так популярен.

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

Я пытаюсь критиковать, чтобы понять, ПОЧЕМУ часть вопроса. Мы всегда должны указывать ключ раздела и атрибут ключа при извлечении, чтобы получить миллисекунду производительности.

Если я спроектирую СУБД:

1. где первичный или альтернативный ключ (INDEXED) всегда должен быть указан в запросе
2. Я могу использовать ключ раздела, чтобы узнать, в какой базе данных хранятся мои данные.
3. Никогда не присоединяйтесь

Разве это не то же самое, что архитектура NoSQL без всякой маркетинговой шумихи?

Мы все равно переходим на DynamoDB, но это мое невинное любопытство, должна быть веская причина, по которой RDMBS не может этого сделать. Давайте пропустим преимущества резервного копирования, обслуживания и т. Д.

Answer 1

Вы смешиваете две разные вещи.

Определение NoSQL

Нет ни одного, по крайней мере, ни одного, которое можно было бы применить во всех случаях.

В большинстве случаев базы данных NoSQL не помещают ваши данные в «строки и столбцы» с фиксированной схемой реляционной базы данных. Хотя современные реляционные базы данных, такие как Postgres, поддерживают такие типы данных, как JSONB, которые заставили бы EF Codd крутиться в могиле.

DynamoDB - это база данных документов: она оптимизирована для извлечения и обновления отдельных документов на основе уникального ключа, и она не ограничивает поля, которые эти документы содержат (кроме того, что требует наличия тех, которые используются для ключа).

Распределенные базы данных

Распределенная база данных хранит данные на нескольких узлах и может выполнять параллельные запросы на этих узлах и объединять результаты.

Есть распределенная база данных SQL: Redshift и BigQuery оптимизированы для запросов к большим наборам данных, которые могут включать соединения, а MySQL (и, без сомнения, другие) может запускать несколько движков и распределять запросы между ними. Базы данных SQL могут выполнять соединения, в том числе соединения, пересекающие узлы, но такие соединения обычно работают плохо.

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

Как вы отметили в своем вопросе, вы можете реализовать сегментированную базу данных документов поверх реляционной базы данных (либо с использованием собственных столбцов JSON, либо с сохранением всего в CLOB, который анализируется для каждого доступа). Но достаточно других людей сделали это (включая DynamoDB), что нет смысла (по крайней мере, для меня) реализовывать заново.