Здравствуйте, trophim, Вы писали:

T>Здравствуйте, pansa, Вы писали:

P>>Здравствуйте, trophim, Вы писали:

T>>>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

P>>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?

T>Эх, не сыпьте соль... Заказчики они такие заказчики... =(

T>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап),

Вот тут странный вывод. Удаление файла — операция должна быть весьма быстрой. Во всяком случае, не в нее всё упереться должно. Даже с учетом XP.

T> и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

Ну если по теме.
Учитывая , видимо, печальный опыт с файлами на WinXP... Не надо сразу его отбрасывать.

1) Поднимаете хороший сервер на Solaris + zfs, либо что-то близкое. По возможности — с хорошей дисковой подсистемой.
2) Файлы храните в ФС, именуя их по их md5/sha и раскладывая на несколько уровней подкаталогов, равномерно, чтобы не создавать подкаталоги с сотнями тыщ файлов. Это важно.
3) mongodb в качестве хранилища метаданных. Храните там оригинальное имя файла и его хэш, по которому именуете файлы в ФС. Плюс еще можете хранить кучу всего, это уже не важно.

Для доступа к файлу — сначала выполняете поиск его в mongo. Это будет очень быстро.
Найдя запись, вы знаете его абсолютный путь, он однозначно вычисляется по sha — это залог более быстрых операций в ФС.

В общих чертах всё. Это рабочая , продакшн, схема. Несколько десятков млн файлов держит пока абсолютно спокойно.