Как присоединиться к таблицам в AWS DynamoDB?

Я знаю, что весь дизайн должен основываться на естественных агрегатах (документах), однако я собираюсь реализовать отдельную таблицу для локализации (lang, key, text), а затем использовать ключи в других таблицах. Тем не менее, я не смог найти ни одного примера для этого.

Любые указатели могут быть полезны!

Ответ 1

Вы правы, DynamoDB не предназначен как реляционная база данных и не поддерживает операции объединения. Вы можете думать о DynamoDB как о простом наборе пар ключ-значение.

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

DynamoDB - это другой способ мышления о базах данных, и вы можете захотеть использовать управляемую реляционную базу данных, такую ​​как Amazon Aurora: https://aws.amazon.com/rds/aurora/

Одно замечание: Amazon EMR позволяет добавлять таблицы DynamoDB, но я не уверен, что вы ищете: http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/EMRforDynamoDB.html

Ответ 2

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

Если вы обнаружите, что вам требуются сложные запросы на чтение, вы, возможно, попали в ловушку, ожидая, что DynamoDB будет вести себя как РСУБД, чего нет. Преобразуйте и сформируйте данные, которые вы пишете, сохраните чтение простым.

Диск намного дешевле, чем вычислять в эти дни - не бойтесь денормализовать.

Ответ 3

Вы должны запросить первую таблицу, а затем перебрать каждый элемент с запросом на получение в следующей таблице.

Другие ответы неудовлетворительны, поскольку 1) не отвечают на вопрос, и, что более важно, 2) как вы можете заранее подготовить свои таблицы к знанию своего будущего приложения? Технический долг слишком высок, чтобы разумно покрывать неограниченные будущие возможности.

Мой ответ ужасно неэффективен, но это единственное текущее решение поставленного вопроса.

Я с нетерпением жду ответа.

Ответ 4

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

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

DynamoDB вторичные индексы

Что хорошего?

  1. Быстро и никаких других систем не требуется!
  2. Подходит для очень конкретной аналитической функции, которую вы создаете (например, таблица лидеров)

Соображения

  1. Ограниченное количество вторичных индексов, ограниченная точность запросов
  2. Дорого, если вы зависите от сканирования
  3. Проблемы безопасности и производительности при использовании производственной базы данных непосредственно для аналитики

DynamoDB + Клей + S3 + Афина

Architecture

Что хорошего?

  1. Все компоненты "без сервера" и не требуют никакой инфраструктуры.
  2. Легко автоматизировать ETL-конвейер

Соображения

  1. Высокая сквозная задержка данных в несколько часов, что означает устаревшие данные
  2. Задержка запроса варьируется от десятков секунд до минут
  3. Схема применения может потерять информацию со смешанными типами
  4. Процесс ETL может время от времени требовать обслуживания, если структура данных в источнике изменяется

DynamoDB + Hive/Spark

Architecture

Что хорошего?

  1. Запросы по последним данным в DynamoDB
  2. Не требует ETL/предварительной обработки, кроме указания схемы

Соображения

  1. Применение схемы может привести к потере информации, если поля имеют смешанные типы
  2. EMR кластер требует некоторого администрирования и управления инфраструктурой
  3. Запросы по последним данным включают в себя сканирование и являются дорогостоящими
  4. Задержка запроса варьируется от десятков секунд до минут непосредственно в Hive/Spark.
  5. Влияние безопасности и производительности на выполнение аналитических запросов в оперативной базе данных

DynamoDB + AWS Lambda + Elasticsearch

Что хорошего?

  1. Поддержка полнотекстового поиска
  2. Поддержка нескольких типов аналитических запросов
  3. Может работать над последними данными в DynamoDB

Соображения

  1. Требуется управление и мониторинг инфраструктуры для приема, индексирования, репликации и разделения.
  2. Требуется отдельная система для обеспечения целостности и согласованности данных между DynamoDB и Elasticsearch
  3. Масштабирование выполняется вручную и требует предоставления дополнительной инфраструктуры и операций.
  4. Нет поддержки объединений между разными индексами

DynamoDB + Rockset

Architecture

Что хорошего?

  1. Полностью без сервера. Никаких операций или предоставления инфраструктуры или базы данных не требуется
  2. Синхронизация в реальном времени между DynamoDB и коллекцией Rockset, так что они никогда не превышают нескольких секунд
  3. Мониторинг для обеспечения согласованности между DynamoDB и Rockset
  4. Автоматические индексы, построенные на данных, позволяющие выполнять запросы с низкой задержкой
  5. Служба запросов SQL, которая может масштабироваться до высокого QPS
  6. Объединяет данные из других источников, таких как Amazon Kinesis, Apache Kafka, Amazon S3 и т.д.
  7. Интеграция с такими инструментами, как Tableau, Redash, Superset и SQL API через REST и использование клиентских библиотек.
  8. Функции, включающие полнотекстовый поиск, преобразование загрузки, сохранение, шифрование и детальное управление доступом

Соображения

  1. Не подходит для хранения редко запрашиваемых данных (например, журналов машин)
  2. Не транзакционное хранилище данных

(Полное раскрытие: я работаю в команде разработчиков продукта @Rockset). Посетите блог, чтобы узнать больше об отдельных подходах.

Ответ 5

Я знаю, что мой ответ немного запоздал, на пару лет. Тем не менее, мне удалось найти некоторую дополнительную информацию, касающуюся Amazon DynamoDB & Joins, которая может принести вам пользу (или, возможно, другому человеку, который может наткнуться на это обсуждение при изучении этой информации в будущем).

Чтобы добраться до сути, мне удалось найти некоторую документацию на веб-сайте Amazon DynamoDB, в которой говорится, что можно использовать язык запросов Apache HiveQL для выполнения объединений с таблицами Amazon DynamoDB, столбцами и данными и т.д.

Запрос данных в DynamoDB (с HiveQL): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EMRforDynamoDB.Querying.html

Работа с Amazon DynamoDB и Apache Hive: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EMRforDynamoDB.Tutorial.html

Обработка данных Amazon DynamoDB с помощью Apache Hive в Amazon EMR: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EMRforDynamoDB.html

Я надеюсь, что эта информация поможет кому-то, если не оригинальному постеру.

Ответ 6

Недавно у меня появилось такое же требование использовать функции соединения и агрегирования, такие как avg и sum, с DynamoDb, чтобы решить эту проблему, я использовал драйвер Cdata JDBC, и он работал отлично. Он поддерживает объединение, а также агрегатные функции. Хотя я также ищу решение, чтобы избежать использования cdata из-за стоимости лицензии Cdata.