Народ, юзал ли кто sqlite3 + node.js c большим размером

файла базы данных? Ощутимо ли лагает или все печально? Допустим если больше 100 гигов файлик)

Разницы между 3 гигами и 2 мбайтами замечено не было

Спасибо за обратную связь, если у кого ещё опыт на реальных проектах есть напишите, очень интересно.

Это немного странный кейс (сотня Гб в sqlite), поэтому думаю, что подобный опыт мало у кого есть. Но ничто не мешает тебе забить базу данными и постестить её под нагрузкой

Полностью согласен что кейс странный, но тем не менее. Он связан с безсерверной БД. Синтетические тесты это конечно можно, но это все идеальные условия. Хотелось услышать мнение со стороны кто трогал такое в проде так сказать.

у меня использовались бд в 10-ки Гб. Если вы нормаль построите индексы, то проблем нет никаких. При необходимости заливки данных, сноси индексы, заливай порциями через транзакции, потом снова строй индексы.

Благодарю, значит переживаю напрасно.

какая задача, если не секрет?

Хранить строки текста, возможно небольшие по размеру файлы (до 5мб), текст большого объёма с кучей пробелов и отступов, текст с разделителями. Планируется полнотекстовой поиск по бд или по специально подготовленной таблице с данными.

в sqlite есть из коробки fts5 для полнотекстового поиска. Просто необязательно все писать в один файл. можете разбить на несколько файлов бд по какому-то принципу. тут надо пробывать.

а файлы зачем в бд хранить?

ну не в файловой системе же их хранить, это же тупо

Гляну, спасибо. Насчет структуры тоже смотрю разные варианты и да писать в несколько файлов БД действительно рассматриваю (правда поиск в этом случае немного осложняется). Пока думаю как лучше поступить.

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

Видео 1,5г файл наверное в базу лить не стоит, а вот мелочь как по мне самый раз.

Для видео есть отдельные сервисы, позволяющие хранить данные вплоть до стрима.

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

я бы сказал, что в ноде есть такой тип данных, как стрим 😁

Есть. И очень полезный даже. 😉

Сложно согласиться, я минут 10 назад свойства папки открыл чтобы посмотреть сколько там чего по объему и кол-ву. До сих пор пересчитывает файлики размером по 1-20кб пока подсчитало всего 20гб и 200к файлов в 60к папок. Это вот реальная моя практика файловых операций с мелкими файлами. В этой папке около 300гб файлов (может больше), интересно сколько часов потребуется до конечной цифры=) мой кейс наверное связан с тем чтобы соседние вещи на диске не просели от такого "мелкого" соседства.

Полноценно ещё не юзал, так разок.

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

чем будет отличаться чтение файлов напрямую из фс от чтения одного огромного файла из той же фс только с определенного указателя?

zip наложит другие сложности

Какая fs, и какой диск?

а дело не в файлах а в хранении данных. Одно дело писать в мелкие файлы, другое в БД. Скорость чтения и скорость доступа к данным я думаю на одном уровне будет примерно. Дело в самой организации хранения в едином целом. Вы когда-нибудь копировали большую папку мелких файлов? Это может занять и пару суток. Другое дело скопировать файл на терабайт вжух и готово. Специфичная задача, специфичное решение - идеального решения всё равно не существует или оно по другим моментам может не устраивать.

ntfs, sata hdd 10tb