Какую БД выбрать для маленького файлового сервиса?
Я хочу сделать приложение на python(на Fastapi), которое будет работать примерно так:
Пользователи запускают задание, которое выгружает тяжелый отчет в файловую систему на сервере, после чего получают уведомление на почту с уникальной ссылкой. При переходе по ссылке автоматически скачивается файл.
Мне необходимо хранить информацию:
1. Связь ссылки с файлом в файловой системе
2. Историю скачиваний
Возможно, иногда мне надо будет чистить старые файлы(и соотвественно ссылки) массово(например старше 30 или 7 дней).
Ожидаю до выгрузки нескольких десятков тысяч файлов в месяц.
Посоветуйте, какую БД стоит использовать для таких целей? И почему именно ее?
FastAPI предполагает работу с БД через ORM в частности SQLAlchemy
Который предоставляет слой абстракции.
поэтому не так важно какая база будет использоваться.
Начните с SQLite а потом, если не хватит, легко смигрируете на мускуль или постгрес
Роман Мирр, нет, но у них есть сервер, который обрабатывает одновременные подключения, у sqlite нет сервера, это просто файл, который блокируется на момент обращения к нему.
Ivan Yakushenko, с другой стороны, запросы могут быть обработаны очень быстро.
И если использовать её при обработке очереди отчетов, то она отлично подойдет.
Роман Мирр, а, я чет упустил тот момент, что файлы будут загружаться на сервер, думал через этот-же апи. Ну тогда да, плевать по большому счету. Хотя в любом случае при любой повышенной нагрузке вероятнее всего именно sqlite будет узким горлом.
да какая там нагрузка?
каждый юзер запускает джоб
джоб регистрируется в редис и ставится в очередь
запускаешь всего одного RQ воркера, который берет задачи из редиса,
делает всю работу и монопольно обращается в базу.
и пофигу на синхронность. (смайлик)
iddqda, у меня нет опыта работы с не реляционынми БД. С реляционными мне все понятно, а с монгой не очевидно, как я буду удалять тысячи лишних отчетов и что будет в этот момент с монгой. Возможно следует и монгу рассмотреть
Любую реляционную: MySQL, Postgresql, Firebird. Первую точно можно настроить на малое потребление памяти, если необходимо.
При использовании их легко вырасти, не меняя СУБД.
В долгосрочной перспективе SQLite не подходит.
Кажется, что перебирать пол сотни тысяч записей в файлах не очень то удобно. Если не реализовывать свою систему индексов, то для поиска файла по ссылке мне придется перебирать кучу лишнего, а пользователю придется ждать. Как то не хорошо
Пол сотни тысяч записей - это ерунда, не заметно будет. Те же многие базы используют диск и Вы не замечаете этого. Для вашей задачи точне не проблема, хоть 100 тыс записей. Тут скорее надо смотреть на ресурсы сервера (память, например) и на Ваше знание одной из баз данных. Если ресурсы сервера позволяют и знаете хорошо одну из баз данных, то смело используйте ее.
системный администратор, программист... все дела..
Такая задача идеально решается при помощи s3 или любого объектного хранилища. Оно имеет в себе функции ограничения доступа, удаления старых файлов, и, самое главное, - не нужно самому эти отчёты прокачивать через свой хттп сервер - можно давать ссылку напрямую на хранилище прямо на конкретный отчет.
Для хранения каких-либо метаданных приложения отлично подходит универсальная СУБД PostgreSQL
Вопрос в перспективе тянет на экспертную систему по выбору БД.
При данной постановке - можно брать любую документно-ориентированную. Все одинаково подходят.
Но если основной контент (80% берем по Паретто) это файлы - то можно брать Amazon S3, в дальнейшем с перспективой трансформировать это в DynamoDb если понадобятся транзакции или в Amazon Document Db (он же Mongo) если понадобится тонкая работа с атрибутами документов (или файлов).
Автор должен понять что в это вопросе нет единого правильного решения. Есть просто некая сравнительная табличка где есть набор фичей с одной стороны и набор DBMS с другой и нет такого покрытия которое бы закрыло ВСЕ фичи.
А зачем вообще файлы и база данных? Эту задачу можно решить гораздо проще. Юзер запускает тяжелую задачу, которая строит отчет. Отчет кладется в кеш с временем жизни 30 дней (ну или сколько нужно). Ключом в кеше является уникальное значение, которое юзер получает в ссылке в письме. То есть задача сильно упрощается:
Нет базы
Не нужно писать логику удаления отчетов, потому что они будут удалятся автоматически при протуханиии кеша
У меня тут два вопроса, которые я не понимаю как решать:
1. А как мне хранить историю запросов/скачиваний для разбора инцидентов
2. Это сколько надо оперативы, чтобы держать такой кэш. Кажется, что сервер понадобится не слабенький
