Собственно сабж.
Файлы от килобайтов до 4-5Гб. Планируемый суммарный объем — 100...1000Гб. Основная нагрузка на чтение/запись — на файлы условно текущего года.
Пока используется NTFS и структура папок и файлов вида data/01/02/03/04/01020304.dat с метаинформацией (по id=01020304) в таблице на SQLServer.
Re: Как правильно хранить пользовательские файлы для портала?
Здравствуйте, B7_Ruslan, Вы писали:
B_R>Собственно сабж. B_R>Файлы от килобайтов до 4-5Гб. Планируемый суммарный объем — 100...1000Гб. Основная нагрузка на чтение/запись — на файлы условно текущего года. B_R>Пока используется NTFS и структура папок и файлов вида data/01/02/03/04/01020304.dat с метаинформацией (по id=01020304) в таблице на SQLServer.
Все в одном большом файле, в таблице sqlServer индекс начала файла, его длинна и другая нужная информация.
Программа – это мысли спрессованные в код
Re[2]: Как правильно хранить пользовательские файлы для портала?
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, B7_Ruslan, Вы писали:
B_R>>Собственно сабж. B_R>>Файлы от килобайтов до 4-5Гб. Планируемый суммарный объем — 100...1000Гб. Основная нагрузка на чтение/запись — на файлы условно текущего года. B_R>>Пока используется NTFS и структура папок и файлов вида data/01/02/03/04/01020304.dat с метаинформацией (по id=01020304) в таблице на SQLServer.
Q>Все в одном большом файле, в таблице sqlServer индекс начала файла, его длинна и другая нужная информация.
Это же практически создание своей ФС. И время backup-a будет линейно увеличиваться со временем.
Re: Как правильно хранить пользовательские файлы для портала?
Здравствуйте, B7_Ruslan, Вы писали:
B_R>Собственно сабж. B_R>Файлы от килобайтов до 4-5Гб. Планируемый суммарный объем — 100...1000Гб. Основная нагрузка на чтение/запись — на файлы условно текущего года. B_R>Пока используется NTFS и структура папок и файлов вида data/01/02/03/04/01020304.dat с метаинформацией (по id=01020304) в таблице на SQLServer.
Да вполне нормальное решение. А чем не устраивает-то?
А я бы в исследовательских целях попробовал запилить хранилище на основе git-репозитория... Там и атомарность, и быстрое добавление, и дубликаты схлопываются, и дельта-компрессия, и простота бэкапов... вполне идейка для небольшой опен-сорс библиотечки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Как правильно хранить пользовательские файлы для порт
Здравствуйте, B7_Ruslan, Вы писали:
B_R>Здравствуйте, Qulac, Вы писали:
Q>>Здравствуйте, B7_Ruslan, Вы писали:
B_R>>>Собственно сабж. B_R>>>Файлы от килобайтов до 4-5Гб. Планируемый суммарный объем — 100...1000Гб. Основная нагрузка на чтение/запись — на файлы условно текущего года. B_R>>>Пока используется NTFS и структура папок и файлов вида data/01/02/03/04/01020304.dat с метаинформацией (по id=01020304) в таблице на SQLServer.
Q>>Все в одном большом файле, в таблице sqlServer индекс начала файла, его длинна и другая нужная информация.
B_R>Это же практически создание своей ФС. И время backup-a будет линейно увеличиваться со временем.
А ntfs резко начнет тормозить при определенном количестве папок. Сложного тут ни чего нет, это стандартный прием и очень быстрый в работе. Исключение если только вам нужно будет хранить файлы в виде иерархической структуры, тут возможны другие варианты.
·>А я бы в исследовательских целях попробовал запилить хранилище на основе git-репозитория... Там и атомарность, и быстрое добавление, и дубликаты схлопываются, и дельта-компрессия, и простота бэкапов... вполне идейка для небольшой опен-сорс библиотечки.
Git — это SOURCE version control. Не нужно использовать git для хранение бинарных файлов. Не будет никакой дельта копрессии, будет только огромный размер хранилища.
Re[3]: Как правильно хранить пользовательские файлы для портала?
Здравствуйте, xednay89, Вы писали:
X>Git — это SOURCE version control. Не нужно использовать git для хранение бинарных файлов. Не будет никакой дельта копрессии, будет только огромный размер хранилища.
Я это прекрасно знаю. git работает внутрях на довольно интересной структуре данных. Вот её и можно заюзать. Естественно не на уровне высокоуровневых комманд типа git commit, а на низком уровне типа git hash-object и т.д.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Как правильно хранить пользовательские файлы для портала?
Спасибо всем за участие.
Тем не менее я пока решил подумать за ReFS и Storage Spaces от MS, ибо имеет требуемые заявляемые характеристики.
Кто-нибудь пользовался этим? Реально работает хорошо, как декларируется?
