Comments

Самое что не хватает и почему ютуб отказался от редиса это отсутствие выборки последних изменившихся данных начиная с чекпоинта и отсутствие автоматической метки что по ключу были изменения или аналогичного атомарного 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 \ или через подобие транзакций multi не подходит

Only those users with full accounts are able to leave comments. Log in, please.