Здравствуйте, trophim, Вы писали:
P>>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"? T>Эх, не сыпьте соль... Заказчики они такие заказчики... =(
Здравствуйте, trophim, Вы писали:
T>Здравствуйте, pansa, Вы писали:
P>>Здравствуйте, trophim, Вы писали:
T>>>ОС — WinXP. Какую ФС там можно кроме НТФС применить?
P>>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?
T>Эх, не сыпьте соль... Заказчики они такие заказчики... =(
T>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап),
Вот тут странный вывод. Удаление файла — операция должна быть весьма быстрой. Во всяком случае, не в нее всё упереться должно. Даже с учетом XP.
T> и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?
Ну если по теме.
Учитывая , видимо, печальный опыт с файлами на WinXP... Не надо сразу его отбрасывать.
1) Поднимаете хороший сервер на Solaris + zfs, либо что-то близкое. По возможности — с хорошей дисковой подсистемой.
2) Файлы храните в ФС, именуя их по их md5/sha и раскладывая на несколько уровней подкаталогов, равномерно, чтобы не создавать подкаталоги с сотнями тыщ файлов. Это важно.
3) mongodb в качестве хранилища метаданных. Храните там оригинальное имя файла и его хэш, по которому именуете файлы в ФС. Плюс еще можете хранить кучу всего, это уже не важно.
Для доступа к файлу — сначала выполняете поиск его в mongo. Это будет очень быстро.
Найдя запись, вы знаете его абсолютный путь, он однозначно вычисляется по sha — это залог более быстрых операций в ФС.
В общих чертах всё. Это рабочая , продакшн, схема. Несколько десятков млн файлов держит пока абсолютно спокойно.
Здравствуйте, pansa, Вы писали:
T>>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап),
P>Вот тут странный вывод. Удаление файла — операция должна быть весьма быстрой. Во всяком случае, не в нее всё упереться должно. Даже с учетом XP.
А между тем все вот так плохо... Например в каталоге лежало 340000 файлов HTM (разбиты по 4000 файлов по подкаталогам). Так вот простой обход всех файлов (можно просто в обычном Total Commander проверить) это какая-то дичайше тормознутая операция (имеется ввиду суммарно затраченное время).
Ну а про то, как сервер два дня удалял зарегистрированные сообщения с диска — даже вспоминать не хочется.
