Comments 6
KEYS нельзя использовать в продакшене, редис однопоточный и когда у вас будет много данных эта команда может надолго лочить инстанс.
Существуют асинхронные форки, они ещё быстрее
Стоит рассмотреть вариант с zset где score - время сообщения, он будет проще, но больше подойдёт для реализаций где не нужно отмечать факт прочтения сообщения.
Спасибо за zset — сообразил как через него сделать одну нужную мне штуку. Прям в тютельку.
1. да, про KEYS я дополнил, хотел сказать про это но показалось очевидным, так как про это везде пишут в документации.
2. Не совсем понял про форки и как их применять можно. Не могли бы объяснить что имеете ввиду?
3. Про zset интересное замечание. Посмотрел в документации. У него среднее время работы log n (O), то есть выглядит действительно быстро. Только, это решение действительно будет иметь свои ограничения. Например если мы хотим сделать поиск по тексту сообщений или по части сообщения. Тут только индексировать и все также упирается во все тот же кастомный модуль описаный внизу) - https://redis.io/docs/data-types/sorted-sets/
Спасибо за интересное замечание, исправил
Даже не то чтобы форки, не изучал досконально что там под капотом, например: https://www.dragonflydb.io/docs
Основная функция бэкенда чата - пагинация,
1) верх
2) вниз
3) оконная
где и как основная функция всех бэкэнд чатов у вас реализована я так и не понял.
да пагинация есть в redisearch, просто изначально в примере я описал неправильно) Там где я написал про limit следует указывать LIMIT first num, где first - это смещение offset, а num - число записей. Все согласно официальной документации -
https://redis.io/commands/ft.search/. Напомню в примере сортировка делается по полю createdAt. Надеюсь, это помогает ответить на вопрос пагинации.
Спасибо за дельное замечание, исправил
Использование Redis почти как SQL БД: Реализация чата с кешированием сообщений