Work.дыбр - REDIS - просто запишу здесь
Jan. 23rd, 2023 12:56 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dzzRedis в качестве оперативной БД для миддлвари, управляющей отрисовкой электронных ценников и передачей контента в полки, оказался лучшим решением из возможных.
Основные плюсы:
1. Очень разумное использование оперативной памяти. Redis - это in-memory database, но сам сервер занимает в оперативке совершенно смешной объём.
2. Скорость. При правильном подходе к конструированию объектов выборка данных во многих случаях занимает O(1), т.е. практически мгновенно. В нашем проекте это сказалось на общей скорости обработки, получилось офигенно быстро по сравнению с прототипом с другой архитектурой :)
3. Встроенный механизм устаревания объектов. Нет необходимости заботиться об удалении уже ненужной картинки или команды, она умрёт сама по таймауту.
4. Богатый набор типов объектов (по сравнению с тем же memcached) - хэши, сеты, сортированные сеты, стримы. Удобная альтернатива таблицам и индексам в концепции NoSQL.
5. Встроенный месседжинг нескольких типов.
6. Своеобразная, но вполне рабочая система ACL (начиная с версии 6).
Недостатки тоже есть, часть из них вытекает из достоинств:
1. Все конечные значения - строки. Преобразование типов ложится на клиентскую часть
2. Пространство имён объектов - сплошное. Да, есть до 10 БД, но у меня была задача поддержать 100500 клиентов, поэтому при проектировании пришлось начинать с разработки грамотной системы нейминга, включающей идентификаторы назначения. К счастью, не так страшен чёрт, как его малюют, но names.cpp - один из самых больших кусков прикладной библиотеки :)
3. Необходимость следить за объёмом памяти, занимаемым объектами. Решается тоже при проектировании, разделением объектов на постоянные и временные.
4. Месседжинг с использованием стримов и групп приводит в версии 7.0.5 к дикой утечке памяти на стресс-тестах с отправкой сотен тысяч сообщений в короткое время. При удалени объекта из стрима он физически продолжаети занимать хип, хотя должен удаляться в составе блока. Удалось решить переходом на передачу сообщений через zset-ы и временные hash-и.
5. Общая системная проблема - зависимость от сбоев. При экстренной остановке сервиса или перезагрузке сервера даже в режиме AOF данные могут не успеть сброситься на диск, в этом случае информация может теряться. В моей задаче это оказалось неважным, т.к. основной источник команд уровнем выше хранит данные в постгресе, а источник статусов ниже - в SQLite. При рестарте сервера всё критичное приползает в редис за обозримое время. Развёртывать кластер sentinel не понадобилось, хотя изначально такой вариант я рассматривал.
В целом, доволен выбранной архитектурой, и собой немножко :)
КДПВ: Redis database mascot в представлении Midjourney
Основные плюсы:
1. Очень разумное использование оперативной памяти. Redis - это in-memory database, но сам сервер занимает в оперативке совершенно смешной объём.
2. Скорость. При правильном подходе к конструированию объектов выборка данных во многих случаях занимает O(1), т.е. практически мгновенно. В нашем проекте это сказалось на общей скорости обработки, получилось офигенно быстро по сравнению с прототипом с другой архитектурой :)
3. Встроенный механизм устаревания объектов. Нет необходимости заботиться об удалении уже ненужной картинки или команды, она умрёт сама по таймауту.
4. Богатый набор типов объектов (по сравнению с тем же memcached) - хэши, сеты, сортированные сеты, стримы. Удобная альтернатива таблицам и индексам в концепции NoSQL.
5. Встроенный месседжинг нескольких типов.
6. Своеобразная, но вполне рабочая система ACL (начиная с версии 6).
Недостатки тоже есть, часть из них вытекает из достоинств:
1. Все конечные значения - строки. Преобразование типов ложится на клиентскую часть
2. Пространство имён объектов - сплошное. Да, есть до 10 БД, но у меня была задача поддержать 100500 клиентов, поэтому при проектировании пришлось начинать с разработки грамотной системы нейминга, включающей идентификаторы назначения. К счастью, не так страшен чёрт, как его малюют, но names.cpp - один из самых больших кусков прикладной библиотеки :)
3. Необходимость следить за объёмом памяти, занимаемым объектами. Решается тоже при проектировании, разделением объектов на постоянные и временные.
4. Месседжинг с использованием стримов и групп приводит в версии 7.0.5 к дикой утечке памяти на стресс-тестах с отправкой сотен тысяч сообщений в короткое время. При удалени объекта из стрима он физически продолжаети занимать хип, хотя должен удаляться в составе блока. Удалось решить переходом на передачу сообщений через zset-ы и временные hash-и.
5. Общая системная проблема - зависимость от сбоев. При экстренной остановке сервиса или перезагрузке сервера даже в режиме AOF данные могут не успеть сброситься на диск, в этом случае информация может теряться. В моей задаче это оказалось неважным, т.к. основной источник команд уровнем выше хранит данные в постгресе, а источник статусов ниже - в SQLite. При рестарте сервера всё критичное приползает в редис за обозримое время. Развёртывать кластер sentinel не понадобилось, хотя изначально такой вариант я рассматривал.
В целом, доволен выбранной архитектурой, и собой немножко :)
КДПВ: Redis database mascot в представлении Midjourney
