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

Это база: нюансы работы с Redis. Часть 1

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров41K
Всего голосов 79: ↑79 и ↓0+79
Комментарии5

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

Основательно, как на старом-добром Хабре, спасибо.

Спасибо за пост.

Если ни один ключ не соответствует критериям политики или параметр maxmemory-policy установлен как noeviction, то ни один ключ не будет вытеснен. Вместо этого сервер Redis будет отдавать ошибки на все операции записи, и отвечать только на команды чтения, такие как GET, фактически перейдя в read only.

Не нашел подверждения на официальном сайт. Но нашел здесь:

https://stackoverflow.com/questions/57491620/how-to-block-all-writes-and-allow-only-reads-in-redis-server

Это одновременно как и плюс, так и минус

какой же это плюс в 2023г? это просто несерьезно и говорит о том, что redis в сущности очень простой инструмент. и Pub/Sub тогда просто поиграться

Хотел бы добавить, что все сложные типы данных находятся в зоне риска из-за отсутствия транзакций (да, в Redis есть batch режим, но без (100%) гарантии отката в случае ошибки).

Batch режим - очень важная фича, позволяющая увеличить скорость записи до 5 раз (+-). Её бы стоило упомянуть в статье, хотя возможно это появится во 2/3-ей части статьи :-) (еще раз подчеркну, это не транзакция).

Есть еще интересная фича типа "оптимистических блокировок" (или CAS CompareSwapUpdate), в принципе с ее помощью в простых случаях можно добиться транзакционного/атомарного поведения.

Не используйте ключи с неограниченным TTL, желательно ограничить размер TTL минимально необходимым сроком жизни ключа;
Используйте политику вытеснения чтобы не засорять Redis и подбирайте параметр maxmemory-policy в зависимости от структуры базы и частоты обращения к ключам;

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

Старайтесь снимать RDB дампы с боевой базы как можно реже, если объем
базы более нескольких гигабайт. Для создания RDB используется операция
fork в основном потоке, что может вызвать заметную задержку в работе
инстанса Redis. Лучшее решение —  поднятие мастер - слейв репликации и
снятие бэкапа со слейва.

но если очень хочется и нет слейва, то только через команду `BGSAVE` , чтобы не блокировать работу редиса в момент снятия дампа. Так же сам редис просит включить механизм copy-on-write, для снижения потребления памяти.

RedisInsight - не умирает на больших размерах БД(от 50Гб) и ключах( от 100 млн)?

А так, интересная статья, добавлю в закладки, чтобы кидать тем, кто хочет познать дивный мир редиски

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