Где хранить данные, в БД или файлах?

Question

[Aragorn]

Пишу веб-приложение по типу блог-платформы и возник такой вопрос: где лучше хранить посты (а именно их текст) в БД или в отдельных файлах?

Погуглил, и нашёл что все единодушно говорят, что лучше БД. ОК. Понятно. Доводы убедительны. Но возникает такой вопрос.

Предположим, что у меня 5000 пользователей, у каждого по 100 постов, в каждом посте по 10000 символов. Размер всех постов получается 5 ГБ. Но это же огромная сумма! Хранить такое количество данных в БД как-то не очень. БД будет тормозить, всё это скажется на производительности и в конечном счёте это отразится на клиентах.

Какой же тип хранения мне всё-таки выбрать? БД или простые файлы?

P. S. Пишу на Python (Flask) и SQLite.

Comments

[Сергей delphinpro]

Тупой вопрос, извините меня.

Что такое БД? Правильно! База, мать ее, данных!
Она специально предназначена для хранения данных.

Размер всех постов получается 5 ГБ. Но это же огромная сумма! Хранить такое количество данных в БД как-то не очень. БД будет тормозить, всё это скажется на производительности и в конечном счёте это отразится на клиентах.

Это фигня для любой современной БД. Даже не поперхнется.

Answer 1

[rPman]

забудем про адекватность

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

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

Да, база данных на чтение медленнее правильно составленного файлового хранилища с индексами, особенно если под задачу, но не значительно (в кратное количество раз, если смотреть например обслуживание на backup/restore, что не фатально и есть способы этого избежать в принципе) , но усилий на это создание кода по работе с файлами будут огромны, гораздо выше профита от скорости.

Answer 2

[d-stream]

Человеки в большинстве своём не умеют учиться на чужих ошибках. Поэтому настоятельно рекомендую сделать на файлах. Могу даже подкинуть адресочки пары групп сектантов, не осиливших бд, и рьяно топящих за файлы)

Впрочем я могу подкинуть и гибридные промышленные дорогие решения где есть и орландо и редис и файлы)

Answer 3

[101-s]

большинство бд умеет кэшировать запросы, и еще я знаю язык sql -)) , поэтому выбираю бд

Answer 4

[mayton2019]

Погуглил, и нашёл что все единодушно говорят, что лучше БД. ОК. Понятно. Доводы убедительны. Но возникает такой вопрос.

Предположим, что у меня 5000 пользователей, у каждого по 100 постов, в каждом посте по 10000 символов. Размер всех постов получается 5 ГБ. Но это же огромная сумма! Хранить такое количество данных в БД как-то не очень. БД будет тормозить, всё это скажется на производительности и в конечном счёте это отразится на клиентах.

Какой же тип хранения мне всё-таки выбрать? БД или простые файлы?

Тут - мало входных данных. Во первых нужно собрать все кейсы работы с информацией.
Например: Пользователь создал пост. Пользователь отредактировал пост. Другие пользователи - проголосовали.
Пользователь удалил пост.

Далее - исходя из этого нужно создать модель постов. Определить какие режимы изоляции или блокировок нужны.

Откровенно говоря в наше время дизайн системы на 80% идет от хостинга и от того какие цены выставляет
хост провайдер на RDBMS и на Storage. Само хранилище может быть десятков видов. S3, Microsoft BLOB, GoogleCloud storage. И вот исходя из цен и из того какая формула биллинга - обычно и берут архитектуру.

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

В вашем случае с постами я-бы сказал что S3 вполне себе справится. Я-бы хранил тело поста в S3 а прочую
информацию о статусе редактирования и голосованиях - в любой реляционной БД.

Comments

[mayton2019]

Dr. Bacon, да я не против. Пускай берет что угодно. Может на данном этапе ему вообще безразличен выбор типа БД. А раздличия появятся под нагрузкой. Что-то будет медленно отдаваться. Или при расчете биллинга в конце месяца.

Короче я на самом деле ОК с любым решением просто потому что здесь - сферическая задача в вакууме.