Метаданные в потоке событий DynamoDB для операции удаления? - PullRequest
0 голосов
/ 10 декабря 2018

Я намерен использовать потоки DynamoDB для реализации журнала, который отслеживает изменения в ряде таблиц (и записывает это в файлы журналов на S3).Всякий раз, когда в таблицу вносятся изменения, из события потока будет вызываться лямбда-функция.Теперь мне нужно записать пользователя, который внес изменения.Для put и update я могу решить эту проблему путем включения фактического атрибута таблицы, содержащего идентификатор вызывающего абонента.Теперь запись, хранящаяся в таблице, будет включать этот идентификатор, что не очень желательно, так как это больше метаданные об операции, чем часть самой записи, но я могу с этим смириться.

Так, например:

put({
  TableName: 'fruits',
  Item: {
    id: 7,
    name: 'Apple',
    flavor: 'Delicious',
    __modifiedBy: 'USER_42'
  })

Это приведет к вызову лямбда-функции, где я могу написать что-то вроде следующего в мой файл журнала S3:

table: 'fruits',
operation: 'put',
time: '2018-12-10T13:35:00Z',
user: 'USER_42',
data: {
    id: 7,
    name: 'Apple',
    flavor: 'Delicious',
}

Однако при удалении возникает проблема - как я могу зарегистрировать вызывающего пользователя операции удаления?Конечно, я могу сделать два запроса: один обновляет __modifiedBy, а другой удаляет элемент, и поток просто извлекает значение __modifiedBy из OLD_IMAGE, включенного в событие потока.Однако это действительно нежелательно, тратить 2 записи на одно удаление элемента.

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

1 Ответ

0 голосов
/ 10 декабря 2018

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

Опция 1

Если вы используете AWS IAM на достаточно детальном уровне, то вы можете получить идентификатор пользователя из Потоковой записи .

Опция 2

Если вы можете обрабатывать небольшие накладные расходы при записи в DynamoDB, вы можете настроить лямбда-функцию (или службу на основе ec2), которая действует какзапись прокси в ваши таблицы DynamodB.Сконфигурируйте ваши разрешения так, чтобы только Lambda могла записывать в таблицу, а затем вы можете принимать любые метаданные и записывать их по своему усмотрению.Если все, что вам нужно, это регистрация событий, вам не нужно писать в S3, поскольку AWS может обрабатывать лямбда-журналы за вас.

Вот пример псевдокода для лямбда-функции, использующей запись в журнал вместо записи в S3.

handle_event(operation, item, user)
    log(operation, item, user)
    switch operation
        case put:
             dynamodb.put(item)
        case update:
             dynamodb.update(item)
        case delete:
             dynamodb.delete(item)

log(operation, item, user)
    logEntry.time = now
    logEntry.user = user
    ...
    print(logEntry)

Вы, конечно, можете свободно регистрироваться непосредственно на S3, но если вы это сделаете, вы можете обнаружить, что добавленная задержка достаточно значительна, чтобы повлиять на ваше приложение.

Опция 3

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

Это позволит вам регистрировать «добавить TTL» как удаление и иметь пользователя last modified by для этого удаления.Вы можете безопасно игнорировать фактическое удаление, которое происходит, когда DynamodB очищает просроченные элементы.

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

...