Как присоединиться к таблицам в 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 вторичные индексы
Что хорошего?
- Быстро и никаких других систем не требуется!
- Подходит для очень конкретной аналитической функции, которую вы создаете (например, таблица лидеров)
Соображения
- Ограниченное количество вторичных индексов, ограниченная точность запросов
- Дорого, если вы зависите от сканирования
- Проблемы безопасности и производительности при использовании производственной базы данных непосредственно для аналитики
DynamoDB + Клей + S3 + Афина
![Architecture]()
Что хорошего?
- Все компоненты "без сервера" и не требуют никакой инфраструктуры.
- Легко автоматизировать ETL-конвейер
Соображения
- Высокая сквозная задержка данных в несколько часов, что означает устаревшие данные
- Задержка запроса варьируется от десятков секунд до минут
- Схема применения может потерять информацию со смешанными типами
- Процесс ETL может время от времени требовать обслуживания, если структура данных в источнике изменяется
DynamoDB + Hive/Spark
![Architecture]()
Что хорошего?
- Запросы по последним данным в DynamoDB
- Не требует ETL/предварительной обработки, кроме указания схемы
Соображения
- Применение схемы может привести к потере информации, если поля имеют смешанные типы
- EMR кластер требует некоторого администрирования и управления инфраструктурой
- Запросы по последним данным включают в себя сканирование и являются дорогостоящими
- Задержка запроса варьируется от десятков секунд до минут непосредственно в Hive/Spark.
- Влияние безопасности и производительности на выполнение аналитических запросов в оперативной базе данных
DynamoDB + AWS Lambda + Elasticsearch
Что хорошего?
- Поддержка полнотекстового поиска
- Поддержка нескольких типов аналитических запросов
- Может работать над последними данными в DynamoDB
Соображения
- Требуется управление и мониторинг инфраструктуры для приема, индексирования, репликации и разделения.
- Требуется отдельная система для обеспечения целостности и согласованности данных между DynamoDB и Elasticsearch
- Масштабирование выполняется вручную и требует предоставления дополнительной инфраструктуры и операций.
- Нет поддержки объединений между разными индексами
![Architecture]()
Что хорошего?
- Полностью без сервера. Никаких операций или предоставления инфраструктуры или базы данных не требуется
- Синхронизация в реальном времени между DynamoDB и коллекцией Rockset, так что они никогда не превышают нескольких секунд
- Мониторинг для обеспечения согласованности между DynamoDB и Rockset
- Автоматические индексы, построенные на данных, позволяющие выполнять запросы с низкой задержкой
- Служба запросов SQL, которая может масштабироваться до высокого QPS
- Объединяет данные из других источников, таких как Amazon Kinesis, Apache Kafka, Amazon S3 и т.д.
- Интеграция с такими инструментами, как Tableau, Redash, Superset и SQL API через REST и использование клиентских библиотек.
- Функции, включающие полнотекстовый поиск, преобразование загрузки, сохранение, шифрование и детальное управление доступом
Соображения
- Не подходит для хранения редко запрашиваемых данных (например, журналов машин)
- Не транзакционное хранилище данных
(Полное раскрытие: я работаю в команде разработчиков продукта @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.