Сколько времени я протяну хранить сообщения весом 1кб в файловой системе NTFS, организуя их в дерево каталогов, где один каталог содержит максимально 1000 каталогов или файлов, а индекс - в виде текстового файла в корне, переписываемого заново при добавлении нового сообщения? В день поступает где-то 400 новых сообщений, файл индекса весит 8 МБ.

Например сообщение номер 76123 хранится в файле 0/76/76123.txt - простой алгоритм поиска.

Доступ к хранящимся сообщениям очень редкий, в основном вида "пройтись по всем раз в день".

Это первая реализация, макет. Достаточно переделать класс хранения данных и всё уйдёт в СУБД, но стоит ли? Может пока забить?

AkinaШкола с философским уклоном.Достаточно переделать класс хранения данных и всё уйдёт в СУБД, но стоит ли?Раз сообщения - то текстовые. Думаю, стОит перейти на СУБД, и хранить это дело в каком-нить TEXT(1024).

Всё зависит от того, что разумеется под "пройтись по всем раз в день". Проверить наличие? просуммировать номера? найте те, в которых имеется определённый текст? что-то ещё? В любом случае СУБД выполнит такую задачу ПО МАССИВУ СООБЩЕНИЙ эффективнее, чем программный итеративный код, постоянно дёргающий файловую систему. А ведь на эффективность выполнения этой задачи в рамках СУБД можно влиять, и очень сильно!
Пройтись раз в день означает тупо слить всё содержимое, начиная с индекса, на котором остановились вчера, в один большой файл для выдачи наружу.

Basil A. SidorovmaytonВ Ntfs ты можешь всё сливать в 1 директорию и скорость точечного доступа будет такой-же."Ню-ню".
Нюню - обосновать, все свободны )

Basil A. SidorovШкола с философским уклоном.а индекс - в виде текстового файла в корне, переписываемого заново при добавлении нового сообщенияДумаю, что на этом вы и засыпетесь.
А так, NTFS - вполне надёжная файловая система. Мы пару раз наступали на грабли вида "пользователи не могут сохранять файлы" - на диске оставалось 4Кб свободного места, расчищался мусор и всё ехало дальше.
Второе утверждение без обоснований) У вас осталось одно предупреждение (-; (как в анектоде про тёщу). Пейшыте аргументы к утверждениям, пожалуйста.

miksoftmaytonВ Ntfs ты можешь всё сливать в 1 директорию и скорость
точечного доступа будет такой-же.Увы, при 6-значных количествах файлов все становится грустно и печально, я пробовал. Особенно, если вдруг захочется открыть этот каталог проводником или подобной GUI-программой.
Ну речь про точечный доступ, а не про вариант с "особенно".

maytonКонечно по хорошему ему нужна СУБД. Но это приходит с пониманием dirty reads и с методами
борьбы с этим явлением в файловой системе. А обычно проектировщики БД на файлах
скипают этот пункт или как-то решают что "проскочит само" или "по заданию" такого никогда
не будет. А жисть - сложная штука...
Что за dirty reads? Неблокируемый множественный доступ к одним и тем же данным? Што я, дурак штоле? )

maytonУ него в день поступает 400 сообщений. Для современных систем - это смешные цифры.
Затык 100% будет в другом. Это идеология. Возможность роста и развития и этот загадочный
файл индекса в 8 Мб который там непонятно зачем и что в нем внутри тоже непонятно.
Файл индекса текстовый. В нём на каждой строке содержится идентификатор файла и различная метаинформация для него.

Basil A. SidorovmaytonУ него в день поступает 400 сообщений. Для современных систем - это смешные цифры.Если "смешная цифра" будет приводить к четырём сотням подвисонов в день по десятку-полтора секунд каждый - это перебор.
Отсюда вопрос - если уж выбрана изначально кривая архитектура, то зачем дополнительно усугблять ситуацию?
Балансировка в дереве каталогов по дате/ключу - вполне нормальная практика.
Можно сказать - проверенная временем и освящённая традициями.
И, что характерно, в ней есть здравый смысл.
Мой "здравый смысл" основывался только на том, чтобы не создавать проблем человеку, который решил зачем-то заглянуть в какой-нибудь каталог проводником. Знаний о том, что происходит при открытии конкретного файла функцией open на Python нет было (например читает ли Python зачем-нибудь список записей в каталоге или не читает, если читает - то лучше пусть он будет покороче). Плюс на память пришло устройство кеша squid - папочки, 00, 01, 02, 03..., fe, ff :)

maytonШкола с философским уклоном.Мой "здравый смысл" основывался только на том, чтобы не создавать проблем человеку, который решил зачем-то заглянуть в какой-нибудь каталог проводником.
Если эта разработка будет работать на рабочей станции то человек
должен быть проиструктирован что здесь - хранилище и не стоит туда лазить
просто так из любопытства (dirty reads тоже сюда включим). Короче
это идёт через инструкцию.

Если это сервер то там вобщем-то никто не лазит. И это правильно.
А что за dirty reads? Перевод на русский мне ни о чём не говорит. Какие ёще грязные чтения?