Привествую!
Представим, что у нас есть база данных документов в формате HTML. У каждого документа есть ряд характеристик, которые я храню в базе данных: название, дата создания. справочники повторяющихся элементов,...
Стоит ли хранить HTML документ в среднем размеров 1-2 страниц формата А4, приблизительно? Ну убьет ли это скорость базы данных? Думаю, что фильтрация по по атрибутам для выборки листа документов более важно, и не стоит отегащать огромными объемами текста базу данных?
Возможно стоит хранить в базе ссылки на файлы в которых храниться сам HTML? Как лучше поступить. Таблица документов сейчас примерно около 1,000,000, но конечная цифра будет примерно 30 млн.
Как лучше поступить?
Вопрос с производительностью в первую очередь решается не размером поля, а репликацией, партиционирование, шардингом и индексацией.
Стоит провести тестирование на 30 млн записей со средним размером А4, если результаты устроют, то ОК, если подумайте над партиционированием/шардированием.
Ну а уже после тестирования если результаты неудовлетворительные(в чем сомневаюсь 30 млн записей, это не очень много) можете попробовать Postgres + S3/mongo
Когда говорят о базе данных, то 99% имеется в виду классическая реляционная БД типа Postgres/MySQL e.t.c.
Такие базы данных создавались для эффективного соединения кортежей и сортировок. Длина DataRow
при этом обычно не больашя (до 8К целый блок таких строк). Эта цифра имеет корни еще в 20м веке.
И если заставить их хранить html (обычно 5-100К) то такая деятельность может быть не очень
удобная для БД. Это как микроскопом гвозди забивать. Очень умная система будет использоваться как
файловое хранилище. Возникает идея - просто взять что-то ориентированное на файлы. Например S3,
BlobStorage, GoogleDrive. Это было-бы дешевле с точки зрения стоимости владения и бэкап делать
проще.
Я понимаю что мы живем в странное время, когда вместо расчета в калькуляторе - запускают гугл или вместо
расчета в MathCad спрашивают ChatGpt, но все-таки программист должен быть немного хозяйственник
и должен брать простые и дешевые решения там где они достаточны.
Валентин Бируля, дьявол как всегда кроется в деталях. Говоря о "многих функциях" мы можем овер-инжинерить любую задачу. Я-бы предпочел идти от простого к сложному. Так - проще обсуждать задачу. Иначе мы запутаемся.
mayton2019, Валентин Бируля, для мускуля неприятно, а постгресу по барабану — он жирные значения хранит отдельно.
В постгресе есть какое-то сжатие данных из коробки, есть форки типа PostgrePro где сжатие куда более эффективное, можно класть в базу уже пожатые данные. Ну и в зависимости о того, могут ли они дублироваться, стоит ещё глянуть в Clickhouse.
batyrmastyr, я-бы не стал писать через запятую MySQL и Clickhouse. Это уж слишком разные системы по своим целям и по задачам. Все равно что корабль и самолет.
Базу это естественно не убьет.
Вопрос как хранить влияет на то, как часто и кто будет запрашивать документы, как часто добавлять новые.
Но даже сейчас мне кажется, что 1-2 страницы А4 в HTML будет занимать меньше место в базе, чем отдельными файлами.
Можно посмотреть в сторону монги, и то не факт что имеет смысл.
Средний
