2

Я использую Titan/DynamoDB library для использования AWS DynamoDB в качестве backend для моих графиков Titan DB. Мое приложение очень сильно загружено, и я заметил, что Titan чаще всего выполняет запросы запросов от DynamoDB. Я использую transaction- and instance-local caches и indexes, чтобы уменьшить количество читаемых модулей DynamoDB и общую задержку. Я хотел бы представить уровень кэша, который будет соответствовать всем моим EC2 экземплярам: кеш чтения/записи между DynamoDB и моим приложением для хранения результатов, вершин и ребер.Как добавить кеширование уровня хранилища между DynamoDB и Titan?

Caching between Titan API and DynamoDB

Я вижу два решения этого:

  1. неявного кэширование сделано непосредственно библиотека Titan/DynamoDB. Такие классы, как ParallelScannercould be changed, чтобы читать от AWS ElastiCache. Это изменение должно быть применено для чтения операций записи & для обеспечения согласованности.
  2. Явное кэширование, выполненное приложением даже после вызова API Titan/Gremlin.

Первый вариант, по-видимому, более мелкозернистый, поперечный и общий.

  • Что-то вроде этого уже существует? Может быть, для других хранилищ?
  • Есть ли причина, по которой это уже не существует? Приложения графического DB кажутся очень читабельными, поэтому кэширование с несколькими экземплярами кажется довольно значительной функцией для ускорения запросов.
+0

Предполагаете, вы пытались просто сделать кеши Титана намного больше? Какой вариант использования предполагает введение другого уровня косвенности и латентности? –

+0

Это решает проблему только для одного экземпляра сервера Gremlin, а не для обеспечения согласованности кеша нескольких экземпляров. –

+0

@Sebastian: Чтение из ElastiCache примерно в десять раз быстрее, чем чтение из DynamoDB. Мое приложение чрезвычайно читается тяжелым (читайте: скорость записи около 100: 1). Если данных в локальном кеше экземпляра Titan не существует, я хочу получить его из ElastiCache вместо DynamoDB. Уровень ElastiCache, который я предлагаю, относится ко всем экземплярам EC2/Titan. Если экземпляр A обновляет вершину, это приведет к аннулированию/обновлению записей ElastiCache. Последующие данные из экземпляра B, связанные с этой вершиной, будут обновлять кеш. – Ingo

ответ

1

Во-первых, ParallelScanner - это не единственное, что вам нужно будет изменить. Самое главное, все изменения, которые вам нужно внести, находятся в DynamoDBDelegate (это единственный класс, который вызывает вызовы API DynamoDB на низком уровне).

Что касается неявного кэширования, вы можете добавить слой кеширования поверх DynamoDB. Например, вы можете реализовать кеш с помощью API Gateway поверх DynamoDB, или вы можете использовать Elasticache. В любом случае вам нужно выяснить способ аннулирования страниц Query/Scan. Вставка/удаление элементов приведет к изменению границ страниц, поэтому требуется некоторое размышление.

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

Возможно, что-то между ними возможно (но требует некоторой работы). Вы могли бы продолжать использовать кеши для вершин/баз данных, как указано в Titan, и использовать низкое значение для TTL, которое согласуется с тем, как часто вы пишете столбцы. Или вы можете сделать свой подход к кешированию еще одним шагом и сделать следующее.

  1. Включить поток DynamoDB на edgestore.
  2. Используйте функцию лямбда для передачи обновлений edgestore в поток Kinesis.
  3. Поглотите поток Kinesis с обновлениями edgestore в той же JVM, что и сервер Gremlin, на каждом из экземпляров сервера Gremlin.Вам нужно будет измерить кеш уровня базы данных в Titan, чтобы потреблять поток Kinesis и, в случае необходимости, аннулировать кешированные столбцы в каждом экземпляре Titan.