Что выбрать в качестве промежуточного хранилища в проекте?

Question

[UsmanovTim]

Добрый день! Есть проект на FastApi он обращается к БД. Есть желание снизить нагрузку на БД и уменьшить время отклика приложения. Какие варианты для себя нашел.
1) Кэширование. Из плюсов: Снижение нагрузки, но часть запросов все равно будут проходить из-за непопадания в кэш.
2) Промежуточное хранилище. Идея выгрузить все в Redis провалилась, так как на более 120К записей поиск начал тормозить сильнее прямого запроса к БД.
3) ELK или Hadoop. Больше заточены под аналитические запросы(могу ошибаться).
Есть ли еще какие либо варианты для промежуточного хранения большого объема данных?

Comments

[Everything_is_bad]

что за данные? что за поиск по ним?

[UsmanovTim]

Сущности из БД- устройства. Поиск по двум ключам id и mac адрес. В кеше лежат как device_id_1_mac_ff-ff-ff-ff-ff-ff. Поиск по паттерну в зависимости от переданных фильтров.

[Ярослав]

А что значит "поиск начал тормозить", какие цифры? Просто у меня есть проект на python (то есть, относительно "медленный") и я тестировал на базе из 1 млн записей (все в памяти, с диска не подргружается ничего), при этом фильтрация идет по пайтоновскому выражению в запросе (скорее ближе к SELECT ... WHERE в SQL, а не быстрый-эффективный поиск по дереву, как в редисе на С).

Так вот, при всех этих замедляющих факторах, поиск всех продуктов, где "price<20" из миллиона:

Products: 1000000 items
evalidate_raw_eval(): 0.266s

https://github.com/yaroslaff/evalidate

четверть секунды. Это слишком много? И это на пайтоне и это фильтрация каждого из миллиона (а не поиск по ключу). Если у вас поиск по ключу, да еще и redis'ом больше занимает - что-то где-то как-то криво.

И еще вопрос - а как часто обновляются данные у вас? Потому что есть еще такая веселая идея (если обновления редки) - сделать все на статике (например, hugo) и раздавать HTMLки (или JSONки) просто как файлы с диска. Nginx найдет выплюнет статический файл с диска просто моментально. Но это уместно только если обновления редки.

Answer 1

[Everything_is_not_so_bad]

Что выбрать в качестве промежуточного хранилища в проекте?

Redis таковое и есть.

Смысл в кешировании не в том, чтобы сканировать в Redis всё подряд, а чтобы взять данные по заранее известному ключу или двух-трёх максимум, но не более, ключей.
Кеширование имеет смысл тогда, когда количество попаданий в кеш него большое. Если для возврата ответа сервером необходимо совершить запросов по 120К записям, то у вас что-то не так.

Comments

[UsmanovTim]

Пожалуй соглашусь. Буду пересматривать стратегию кэширования. Спасибо за помощь!

[Everything_is_not_so_bad]

UsmanovTim,
кэш не должен быть большим для хранения всех данных (ибо всё хранится в ОЗУ), что и в основной СУБД, а только для частоиспользуемых элементов. Если hit rate менее 60%, то надо взвесить стратегию кеширования.

Answer 2

[mayton2019]

Идея выгрузить все в Redis провалилась, так как на более 120К записей поиск начал тормозить сильнее прямого запроса к БД.

Нужно более подробно изучить этот кейс. В момент "торможения" что происходило? Шла выгрузка?
Redis упал в swap? Дело в том что структуры данных Redis спроектированы так что дают
постоянный отклик почти на любом объеме данных лишь бы хватало памяти. Этот эффект
который вы поймали говорит скорее всего о неверном использовании.

Попробуйте value хранить в разных форматах. В JSON. В бинарном (protobuf). В gzip. Оптимизируйте
бизнес данные. Я всегда находил способы не хранить длинные url. И заменить их на что-то.

В качестве промежуточного хранилища можно использовать много чего. Apache Ignite, Hazelcast,
LevelDb, RocksDb, CouchDb, Riak. Но мне кажется что проблема ваша не в том какую
dbms взять а как грамотно реплицировать бизнес-данные в слой кеширования.

Поговорите с бизнесом какое отставание кеша от данных является приемлемым и исходите из этого.
В некоторых случаях отставанее в сутки является норм. А иногда даже милисекунда - уже нельзя.

Answer 3

[Александр Негашев]

Keydb, умеет в мульти мастер