Является ли DynamoDB правильным вариантом для этого варианта использования?

Question

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

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

Потоки DynamoDB изначально представляли собой правильный подход к решению проблемы. Я внедрил потребитель, используя Kinesis Client Library (KCL), как рекомендовано AWS. Однако, внедряя его, я столкнулся с некоторыми проблемами, которые заставляют меня поверить, что я ошибаюсь. В частности:

• Когда я создаю новый потребитель, используя KCL, он создает новую таблицу DynamoDB сделать домашнее хозяйство аренд и контрольно-пропускных пунктов, так что при повторном запуске программы, KCL знает, какие записи были потребляются и которые не имею. Это не то, что мне нужно для этой проблемы. Любые записи потока, созданные во время автономной работы приложения, не имеют значения, так как вся таблица считывается при запуске приложения.

• Несколько экземпляров одного и того же приложения работают одновременно. Каждый из них должен быть уведомлен об обновлениях таблиц. Чтобы реализовать это в KCL, мне нужно назначить уникальное имя приложения для каждого из них. В противном случае они разделит таблицу аренды, и только одно из приложений получит уведомление. Одна таблица для каждого экземпляра приложения кажется неправильной. Также мне понадобится что-то, чтобы удалить неиспользуемые таблицы.

Я также реализовал его, используя API низкого уровня. Это прекрасно работает, когда есть один осколок. Однако моя реализация не обрабатывает перерисовку, как KCL, поэтому она слишком хрупка. Похоже, что вам приходится выполнять обработку повторного очертания для простой проблемы, которую я пытаюсь решить.

Я начинаю рассматривать и другие решения, такие как:

• Исполнительные функции лямбда, который получает срабатывает на обновления в таблице. Функция отправляет уведомление по теме SNS. Потребители создают подписки SQS по этой теме и получают уведомление через это. Это решение имеет слишком много движущихся частей по моему вкусу.

• Заставить приложения периодически перечитывать всю таблицу и сами определять, были ли сделаны изменения. Это решение кажется немного примитивным, но, кажется, самым простым.

Все решения, которые я рассмотрел до сих пор, имеют довольно существенные недостатки. Что мне не хватает?

Answer 1

Это зависит от того, как ваш KCL настаивает на зависимых приложениях, но Я считаю, что путь SQS является правильным выбором.

• Вы можете добавить, предположительно, бесконечное количество потребителей, не подвергаясь дросселю.
• Когда вы добавляете другое зависимое приложение, вам не потребуется менять KCL, чтобы нажать на него, новое приложение просто будет смотреть очередь SQS.
• Вы получаете возможность следить за очередью при возникновении проблем.
• Больше подвижных частей для установки, но как только у вас есть трубка Streams -> SNS -> SQS, она в основном пуленепробиваемая.

Только мои 2 ¢.