Подходит ли DynamoDB в качестве индекса метаданных S3?

Я хотел бы хранить и запрашивать большое количество необработанных данных о событиях. Я хотел бы использовать архитектуру «озера данных», в которой S3 содержит фактические данные о событиях, а DynamoDB используется для их индексации и предоставления метаданных. Это архитектура, о которой говорят и рекомендуют во многих местах:

Однако я изо всех сил пытаюсь понять, как использовать DynamoDB для запроса данных о событиях в S3. В приведенной выше ссылке на блог AWS они используют пример хранения клиентских событий, созданных несколькими разными серверами:

Формат пути S3: [4-digit hash]/[server id]/[year]-[month]-[day]-[hour]-[minute]/[customer id]-[epoch timestamp].data

Eg: a5b2/i-31cc02/2015-07-05-00-25/87423-1436055953839.data

И схема для записи этого события в DynamoDB выглядит так:

Customer ID (Partition Key), Timestamp-Server (Sort Key), S3-Key, Size
87423, 1436055953839-i-31cc02, a5b2/i-31cc02/2015-07-05-00-25/87423-1436055953839.data, 1234

Я хотел бы выполнить запрос, например: «Получить мне все события клиентов, созданные всеми серверами за последние 24 часа», но, насколько я понимаю, невозможно эффективно запрашивать DynamoDB без использования ключа раздела. Я не могу указать ключ раздела для такого запроса.

Учитывая это требование, должен ли я использовать базу данных, отличную от DynamoDB, для записи того, где мои события находятся в S3? Или мне просто нужно использовать другой тип схемы DynamoDB?


amazon-s3 amazon-dynamodb data-lake
person Alex Spurling    schedule 10.11.2016    source источник
comment
Архитектура выглядит нормально. Однако вы не можете запросить базу данных DynamoDB без ключа раздела. Вы должны сканировать всю DynamoDB, если ключ раздела недоступен. Альтернативой может быть создание глобального вторичного индекса в поле даты и времени.   -  person notionquest    schedule 10.11.2016
comment
@notionquest спасибо. Не могли бы вы подробнее рассказать о том, что вы подразумеваете под глобальным вторичным индексом и как он поможет здесь?   -  person Alex Spurling    schedule 10.11.2016
comment
как насчет использования elasticsearch для индексации метаданных? Взгляните на ссылку ниже: индексирование-метаданных-в-амазонке-эластик-сервис-использование-авс-лямбда-и-питон   -  person Payman    schedule 24.01.2017

Ответы (2)


arrow_upward
2
arrow_downward

Архитектура выглядит прекрасно и реализуема при использовании базы данных DynamoDB. Класс DynamoDBMapper (присутствует в AWS SDK Java) можно использовать для создания модели с полезными методами для получения данных из S3.

DynamoDBMapper

getS3ClientCache() Возвращает базовый S3ClientCache для доступа к S3.

База данных DynamoDB не может быть запрошена без ключа раздела. Вы должны сканировать всю базу данных DynamoDB, если ключ раздела недоступен. Однако вы можете создать глобальный вторичный индекс (GSI) в поле даты/времени и запросить данные для своего варианта использования.

Проще говоря, GSI похож на индекс, присутствующий в любой СУБД. Разница в том, что вы можете напрямую запрашивать GSI, а не основную таблицу. Обычно GSI требуется, если вы хотите запросить DynamoDB для какого-либо варианта использования, когда ключ раздела недоступен. Существуют варианты включения ВСЕХ (или) выбранных полей, присутствующих в основной таблице GSI.

Глобальный вторичный индекс (GSI)

Разница между сканированием и запросом в DynamoDB

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

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

person notionquest    schedule 10.11.2016
comment
В документах GSI говорится: каждый глобальный вторичный индекс должен иметь ключ раздела и может иметь необязательный ключ сортировки. Я думаю, это означает, что это не решит проблему эффективного поиска записей с использованием временного диапазона? - person Alex Spurling; 10.11.2016
comment
В приведенном выше случае использования Timestamp-Server должен быть ключом раздела GSI. - person notionquest; 10.11.2016
comment
Если я использую временную метку в качестве ключа раздела, мне также нужно указать для нее значение при запросе индекса. Опять же, из документов: вам нужно указать имя индекса, критерии запроса для ключа раздела индекса и ключа сортировки (если он есть). Опять же, означает ли это, что я не могу выполнять эффективные запросы диапазона? - person Alex Spurling; 10.11.2016
comment
Согласен, GSI тут не поможет. Обновил мой ответ. - person notionquest; 10.11.2016

arrow_upward
1
arrow_downward

Во-первых, я прочитал ту же страницу блога AWS: https://aws.amazon.com/blogs/big-data/building-and-maintaining-an-amazon-s3-metadata-index-without-servers/

Единственный способ заставить это работать с DynamoDB:

  • добавьте еще один атрибут с именем «foo» и установите одинаковое значение 1 для всех элементов
  • добавьте еще один атрибут под названием «отметка времени» и поместите туда временную метку эпохи
  • создайте GSI с ключом раздела "foo" и ключом диапазона "timestamp" и спроецируйте все остальные атрибуты

Выглядит немного грязно, да? Затем вы можете запросить элементы за последние 24 часа с ключом раздела 1 (все элементы имеют 1) и использовать этот ключ диапазона меток времени. Теперь проблемы:

  1. GSI имеет все элементы с одним и тем же ключом раздела? Производительность будет отстойной, если данные будут слишком большими
  2. Стоит дороже с GSI

Следует подумать и о затратах. Подумайте о скорости приема данных. Помещение 1000 объектов в секунду в корзину будет стоить вам около 600 долларов в месяц и еще 600 долларов с GSI. Только из-за потребности в этом запросе (последние 24 часа) вам придется потратить еще 600 долларов.

Я сталкиваюсь с теми же проблемами при разработке этого индекса метаданных. DynamoDB выглядит неправильно. Это всегда то, что вы получаете, когда пытаетесь использовать DynamoDB так, как вы используете СУБД. Потому что у меня мало таких запросов, как у вас. Я думал об ElasticSearch и плагине s3 listing river, и он тоже не выглядит хорошо, так как мне приходится управлять кластерами ES и хранилищем. Как насчет CloudSearch? Учитывая его ограничения, CloudSearch тоже не подходит.

Мои требования:

  1. иметь доступ к самому последнему объекту с заданным префиксом
  2. иметь доступ к объектам в пределах определенного диапазона времени
  3. получить максимальную производительность от S3 с помощью строк хэшей в ключевом пространстве для AWS EMR, Athena или Redshift Spectrum

Я весь потерян здесь. Я даже подумал о функции управления версиями S3, так как я могу естественным образом получить самый последний объект. Все кажется не совсем правильным, и документы AWS и статьи в блогах полны путаницы.

Вот тут я застрял на всю неделю :(

Люди в AWS просто обожают рисовать диаграммы. Когда они представляют какую-то новую архитектурную схему или концепцию, они просто помещают туда кучу значков продуктов AWS и говорят, что они прекрасно интегрированы.

person gini09    schedule 11.05.2017
comment
Я даже подумал о том, чтобы поместить временную метку эпохи в ключи объекта, как в двоичном формате. например 4238429332 будет выглядеть как 111011010101010101010101. Тогда вы можете получить СПИСОК с определенным префиксом, который даст вам определенный диапазон времени. Угадай, что? Запросы S3 на получение LIST намного дороже, чем стоимость подготовки DynamoDB для чтения. если вы можете каким-то образом использовать результат до предела в 1000 объектов, это может иметь смысл, но это не мой случай. - person gini09; 11.05.2017
comment
похоже, что AWS делает новую функцию для S3. есть команда индексации S3, и они нанимают... amazon.jobs/en/ рабочие места/468608 - person gini09; 11.05.2017