Как стать автором
Обновить

Комментарии 8

Самое что не хватает и почему ютуб отказался от редиса это отсутствие выборки последних изменившихся данных начиная с чекпоинта и отсутствие автоматической метки что по ключу были изменения или аналогичного атомарного incrementAndSet


Кто не в курсе что нужно было им напомню:
1) hashIncrement key:videoid field:up
2) hashIncrement key:videoid field:watch
2) hashIncrement key:videoid field:otherfield
3) select hashes where lastchange > 'datetime'

Метку об изменениях или недостающую атомарную функцию можно реализовать через multi/exec или на LUA, если нужна условная логика.
Для примера redis.multi().incr(key).sadd('keys:changed', key).exec(). С версии 1.2.0 поддерживается.

Выборка последних изменившихся данных это уже бизнес логика, так же через multi/exec или LUA реализуется, при каждом изменении сохраняем дату в сортированном списке.

ну вот, разрабы редиса были с видением как у вас, и послали гугл… веселый тикет был помню.
Их уже 100 лет просят создать 2 системных поля (entrydate, lastupdate) с выборкой по ним, а они всё носом вертят....

Эти поля же не бесплатные, они тратят память и процессорное время для обновления индекса. Нужна такая функциональность не всем, тогда зачем понижать производительность для всех. Могла бы быть дискуссия, если бы это сложно было бы самому реализовать, но это добавляется буквально в пару строк. Сделал раз свою обертку перед драйвером, которая проставляет эти поля в сортированные списки при записи в БД, и все, никого просить не надо 100 лет.
А почему они на Lua не дописали такого, есть информация?

когда нужно колоссальное горизонтальное масштабирование, тактика с надстройками\хаками\каком то lua \ или через подобие транзакций multi не подходит

(Знаю, капец, как вовремя), но почему, собственно, не подходит?
Сейчас в Redis можно загружать хранимые функции (не скрипты, а именно функции, которые являются объектами Redis, и будут сохраняться и реплицироваться). Так что такой мизер логики спокойно можно написать, добавив всего одну функцию.

Насчёт метки "по ключу были изменения": в Redis имеются keyspace и keyevent pub/sub каналы.
keyspace говорит "на ключе А была применена операция Б"
keyevent говорит "операция Б была применена на ключе А"

Т.е. можно отслеживать все операции над конкретным ключом через keyspace и все ключи, к которым была применена конкретная операция через keyevent


Также имеется система "кеширования на стороне клиента", когда Redis через pubsub отсылает уведомления о том, что "этот ключ был изменён". Подписался, и будет тебе счастье.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории