Комментарии 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'
Для примера redis.multi().incr(key).sadd('keys:changed', key).exec(). С версии 1.2.0 поддерживается.
Выборка последних изменившихся данных это уже бизнес логика, так же через multi/exec или LUA реализуется, при каждом изменении сохраняем дату в сортированном списке.
ну вот, разрабы редиса были с видением как у вас, и послали гугл… веселый тикет был помню.
Их уже 100 лет просят создать 2 системных поля (entrydate, lastupdate) с выборкой по ним, а они всё носом вертят....
когда нужно колоссальное горизонтальное масштабирование, тактика с надстройками\хаками\каком то lua \ или через подобие транзакций multi не подходит
Насчёт метки "по ключу были изменения": в Redis имеются keyspace и keyevent pub/sub каналы.
keyspace говорит "на ключе А была применена операция Б"
keyevent говорит "операция Б была применена на ключе А"
Т.е. можно отслеживать все операции над конкретным ключом через keyspace и все ключи, к которым была применена конкретная операция через keyevent
Также имеется система "кеширования на стороне клиента", когда Redis через pubsub отсылает уведомления о том, что "этот ключ был изменён". Подписался, и будет тебе счастье.
Redis Best Practices, часть 3