Cassandra: установка TTL для суперстолбца

Я разработал плагин для Tomcat, который позволяет сохранять данные сеанса и распределять их по кольцу Cassandra. Я хочу, чтобы Cassandra обрабатывала истечение сеанса, используя настройки TTL для различных столбцов. Проблема, с которой я столкнулся сейчас, заключается в том, что срок действия различных объектов в сеансе истекает в разное время, поэтому сеанс со временем теряет неиспользуемые объекты, даже если к сеансу (и другим объектам сеанса) осуществляется постоянный доступ.

Есть ли способ, которым я могу установить TTL для суперстолбца, и все данные, хранящиеся под ключом в этом суперстолбце, истекают, когда истечет срок действия ключа?

Я не хочу просматривать все данные, хранящиеся в веб-сеансе, каждый раз, когда возвращается ответ HTTP, так как это приведет к ненужному вводу-выводу между плагином tomcat и Cassandra. Я также не хочу хранить что-либо в кеше памяти в плагине Tomcat, так как я хочу, чтобы Tomcat был полностью безгражданским и поддерживал все состояние сеанса пользователя исключительно в Cassandra.

Этот подключаемый модуль Tomcat довольно удобен, так как он позволяет веб-приложениям, ранее созданным поэтапно, становиться безстоящими, что позволяет горизонтальное масштабирование. Было бы здорово решить эту проблему с TTL...

https://code.google.com/a/apache-extras.org/p/tomcat-cassandra/


person Morten Jorgensen    schedule 11.07.2014    source источник


Ответы (1)


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

  1. При создании сеанса создайте дополнительный столбец expiration_timestamp и задайте для него разумное значение, например, отметку времени, которая истекает через 60 минут.

session_key, value1, value2, expiration_timestamp=60 минут

  1. При вставке столбца (значение1, значение2 и т. д.) установите ttl на 60 минут. (Столбцы могут добавляться динамически во время http-запроса, поэтому изначально они истекают в разное время)

  2. Когда пользователь выполняет http-запрос, прочитайте строку сеанса (оптимизированную с помощью кеша строк, кеша ключей и т. д.), но пока не обновляйте ttl или expire_timestamp.

  3. Когда запрос пользователя близок к expire_timestamp, скажем, 50 минут, обновите expire_timestamp (добавьте еще 60 минут) и повторно вставьте всю строку сеанса с новым ttl (все столбцы ttl будут обновляться одновременно и синхронно).

Решение гарантирует, что мы будем выполнять чтение большую часть времени (надеюсь, из кеша) и выполнять ввод-вывод записи (чтобы поддерживать сеанс, обновить ttl) только до истечения срока действия сеанса. А "когда" выполнять обновление ttl произвольно, можно ставить 30 минут, 50 минут, но только не при каждом доступе.

person user2659443    schedule 19.01.2015