Что выбрать: sqlite или redis?

Question

[zven_bpe]

Пишу бота на aiogram. Нужно сделать фичу - рассылку уведомлений пользователям.
Для реализации нужно где-то хранить telegram_user_id юзеров, которые когда-либо нажимали кнопку "Начать"
Не хочу для этого использовать БД, даже sqlite. Вдруг будет слишком долго? Хочется redis
Но до конца не уверен в том, что использовать
Нужен просто совет)

Answer 1

[Алексей Уколов]

Вдруг будет слишком долго?

Не будет. Забудьте вообще на данном этапе своего обучения про существование такого понятия как "скорость", пока не столкнётесь с тормозами в реальности.

Хочется redis

Его сложнее администрировать, чем sqlite. Но если хотите - развлекайтесь.

Comments

[zven_bpe]

спасибо

Answer 2

[mayton2019]

Можно попробовать вот эту фичу (Redis Queue)
https://redis.io/glossary/redis-queue/

Не должно быть "слишком долго". Как раз как хочет автор. :)

Answer 3

[Everything_is_bad]

1. Для более менее загруженного бота, который пишет в базу, sqlite может вызвать проблемы, тогда уж лучше postgresql или mysql
2. Для нормальной работы aiogram, в любом случае нужен Redis.

Comments

[Алексей Уколов]

Для нормальной работы aiogram, в любом случае нужен Redis

Для общего развития - aiogram персистит на диск что-то или там только эфемерные данные?

[Everything_is_bad]

Алексей Уколов, стейты FSM он хранит, по умолчанию просто в памяти, любой перезапуск их теряет, для разработки ок, на для прода уже проблемы. Так же часто нужен менять уровень изоляции events_isolation, его можно делать через редис лок, очень помогает когда у тебя нагруженный бот и инстансев более чем один.

[zven_bpe]

Everything_is_bad
Спасибо. Можно еще вопрос? Наверное, глупый...
У меня в боте уже реализован полноценный класс для работы с Redis. Он кэширует ответы на тест, чтобы его можно было пройти только один раз за определенный период времени, но это не суть важно.
Вопрос в том, если ли смысл делать методы этого класса асинхронными? И можно ли обойтись без этого?

[Everything_is_bad]

zven_bpe, в aiogram уже есть коннекты к редису, можно их использовать, ну и конечно же раз aiogram асинхронный, то и все задачи надо выполнять асинхронно

[zven_bpe]

Everything_is_bad, хорошо, понял, спасибо большое

[zven_bpe]

Everything_is_bad, еще один вопрос : можно ли использовать обычный redis, а не aioredis? Просто для aioredis надо писать на пайтон 3.10: в Python 3.11 имя asyncio.TimeoutError сделано псевдонимом builtins.TimeoutError, и поэтому библиотека не работает. Хотелось бы использовать обычный redis и к методам моего кастомного класса добавить async. Так же тоже можно?

[Everything_is_bad]

zven_bpe, ну так открой доку на "обычный" redis и почитай есть так что про async.

[zven_bpe]

Everything_is_bad, ок, спасибо еще раз, гляну

[Zettabyte]

Everything_is_bad,

Для нормальной работы aiogram, в любом случае нужен Redis

А разрешите поинтересоваться, раз уж разговор зашёл:

Чем я занимаюсь - кратко есть в профиле, aiogram никогда не пользовался, но наслышан.
В моём (возможно, outdated) представлении Redis - это специализированное подобие Memcached.

Увидел упоминание конечных автоматов, стало интересно: это айограм сейчас разросся до такой монструозности, что без достаточно серьёзного кэширования в памяти ему принципиально не обойтись, или когда вы это пишете, вы держите в голове боты на тысячи и десятки тысяч пользователей (которые не факт, что у автора есть)?

[Everything_is_bad]

Zettabyte, так я отвечал же уже, без проблем сохраняет в памяти состояния FSM, но если бота перезапустили, он упал и т.п., все они потеряны. Конечно можно их хранить в БД, но часто стейты, это не данные пользователя, а состояние меню в боте и прочая куча мелкой служебной инфы.

[mayton2019]

zven_bpe, асинхронизм как техническое задание возникает, когда у нас есть много
вычислительных потоков и они ожидают ответа от одной медленной I/O подсистемы.
Это так называемая I/O bounded нагрузка.

Но Redis обычно работает очень быстро и делать асинхронизм для него нет особого
смысла. Простой синхронный код - всегдя прямее и дебажить его проще. И принцип
структурного программирования соблюдается. Читаете глазами код сверху вниз.

[Everything_is_bad]

mayton2019, удачи тебе redis lock синхронно поставить в async коде или как ты где-то там предлагал с редис очередью поработать и воткнуть ее синхронное ожидание

[shurshur]

Zettabyte, redis - изначально тот же memcached (kv-хранилище) с его же интерфейсом, который хранил копию данных в памяти также и на диске. Но вроде с тех пор умеет всякие очереди, кластерность итд. Я его кроме как замены memcached сто лет назад и то в тестовых целях не пользовал, так что не знаю.

Конечные автоматы тут это просто про то, что для упрощения разработки не программист куда-то у себя в боте складирует, какой user_id в каком состоянии, а библиотека это делает сама, вызывая разные обработчики в зависимости от предыстории обмена сообщениями с пользоватлем. Это хорошо, когда делаешь пошаговые взаимодействия (например, когда надо задать серию вопросов и выдать результат обработки), и довольно плохо, когда надо хранить персистентно информацию о пользователе, потому что все данные являются свойствами текущего состояния, а не пользователя (например, бот знакомств в начале регистрации в сервисе спрашивает у пользователя его город/возраст/предпочтения). Но это можно совмещать (например, с помощью FSM зададим серию вопросов, а итог запишем уже в свою базу).

Формально это действительно конечный автомат (граф состояний, между которыми перемещается пользователь в процессе взаимодействия), но с практической точки зрения это то же самое, что можно было бы написать на if-then-else и глобальном словаре с id пользователя с id в качестве ключа. Просто так разрабатывать сильно неудобно. FSM намного удобнее даже для тривиальных взаимодействий, позволяя делать короткие функции, обслуживающие отдельные шаги.

Что касается сохранения данных, то aiogram позволяет в качестве хранилища состояний использовать не только Memory storage, но и файл на диске либо базу данных.

[Zettabyte]

shurshur, Спасибо и за подробный ответ и вдвойне, что нашли время на него в выходной день.

Досадно, что комментарием, по мне так вполне тянет и на ответ и на объяснение для тех, кто активно не следит за развитием этой части технологий.