Что выбрать в качестве промежуточного хранилища в проекте?
Добрый день! Есть проект на FastApi он обращается к БД. Есть желание снизить нагрузку на БД и уменьшить время отклика приложения. Какие варианты для себя нашел.
1) Кэширование. Из плюсов: Снижение нагрузки, но часть запросов все равно будут проходить из-за непопадания в кэш.
2) Промежуточное хранилище. Идея выгрузить все в Redis провалилась, так как на более 120К записей поиск начал тормозить сильнее прямого запроса к БД.
3) ELK или Hadoop. Больше заточены под аналитические запросы(могу ошибаться).
Есть ли еще какие либо варианты для промежуточного хранения большого объема данных?
Сущности из БД- устройства. Поиск по двум ключам id и mac адрес. В кеше лежат как device_id_1_mac_ff-ff-ff-ff-ff-ff. Поиск по паттерну в зависимости от переданных фильтров.
А что значит "поиск начал тормозить", какие цифры? Просто у меня есть проект на python (то есть, относительно "медленный") и я тестировал на базе из 1 млн записей (все в памяти, с диска не подргружается ничего), при этом фильтрация идет по пайтоновскому выражению в запросе (скорее ближе к SELECT ... WHERE в SQL, а не быстрый-эффективный поиск по дереву, как в редисе на С).
Так вот, при всех этих замедляющих факторах, поиск всех продуктов, где "price<20" из миллиона:
четверть секунды. Это слишком много? И это на пайтоне и это фильтрация каждого из миллиона (а не поиск по ключу). Если у вас поиск по ключу, да еще и redis'ом больше занимает - что-то где-то как-то криво.
И еще вопрос - а как часто обновляются данные у вас? Потому что есть еще такая веселая идея (если обновления редки) - сделать все на статике (например, hugo) и раздавать HTMLки (или JSONки) просто как файлы с диска. Nginx найдет выплюнет статический файл с диска просто моментально. Но это уместно только если обновления редки.
