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

G>Вот в мире есть компания на букву M, у которой есть продукт начинающийся на Share и заканчивающийся на Point, так вот в нем все файлы хранятся в БД и никто пока от этого не умер.

+1.

Ещё могу припомнить Team Foundation Server, где вообще все объекты хранятся в БД. Также проблем не наблюдается...

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

G>>Вот в мире есть компания на букву M, у которой есть продукт начинающийся на Share и заканчивающийся на Point, так вот в нем все файлы хранятся в БД и никто пока от этого не умер.
K>+1.
K>Ещё могу припомнить Team Foundation Server, где вообще все объекты хранятся в БД. Также проблем не наблюдается...

Да хоть +1000 за БД. Я тоже за БД. Но только в той области, где её "вотчина".
Уважаемые собеседники — для каждой задачи должен применяться свой инструментарий.
Я не сомневаюсь, что есть узкозаточенные БД, которые могут качественно, быстро и оптимально пережёвывать миллионы объектов на одном нераспределённом сервере. Но сколько стоит использование такого инструмента и создание на нём своего решения? Имхо это аналогично "ассигнациями печь топить".
Вы пробовали подобным разношёрстными BLOBами наполнить БД примерно на десяток миллионов объектов на стандартном железе — хорошо ей жилось после этого? а как обстояло дело со вставкой новых и выборкой по старым объектов? А каков стал размер БД? Я не спец по БД, поэтому не могу отвергнуть и это решение, но отношусь к нему всё же с подозрением. Хранение больших бинарных объектов — это всё же удел ФС — на то она и сделана, возможно над выбором самой ФС нужно поработать. А БД — это всё же метаданные. К тому же предвижу проблемы с расширением функционала, если всё завязано на одну БД.

А про EMC добавлю вот что — это у нас эту компнаию знают, как владельца Documentum. Ещё у неё очень сильная Storage'воя линейка — Symmetrix, Celerra, Centera, Clariion — можно почитать на досуге про них.

С уважением,
Константин

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

R3>На входе имеем поступление большого (на практике — бесконечного) количества всевозможных файлов. Я могу точно определить только кто текущий владелец файла (это string) и получить информацию о самом файле. Остальная информация, как например, версия файла или автор файла, определяется не всегда, поэтому не рассматриваю.
R3>Примечание1: файл может быть один, а владельцев — несколько.
R3>Примечание2: хоть я и не рассматриваю версию файла, тем не менее, от одного владельца может поступить файл с тем же именем, который можно рассматривать как следующая версия. И было бы не плохо, если бы старые версии тоже сохранялись.

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

Предположим, что имя владельца и имя файла состоит из допустимых для ФС символов. Тогда напрашивается простая структура хранилища: \storage\YYYY\MM\DD\OWNER\V, где YYYY — год, MM — месяц и DD — день поступления файла в хранилище, OWNER — владелец, V — монотонно возрастающая версия начиная с 0 в пределах одной даты поступления. Имя файла при этом не меняется. Если файл существует в папке версии 0, то он ложится в папку версии 1, если существует в папке 1, то в 2 и т.д.
Если владельцев несколько и их важно различать, то можно использовать некие символы-разделители в имени папки, например, "ivanov-petrov-sidorov" и "ivanov".
Если в сутки поступает небольшое количество файлов, можно попробовать обойтись без DD.
Иногда для удобства версию стоит указывать с несколькими ведущими нулями: 00000, 00001, и т.д.

Достоинствами такой организации считаю её человеко-ориентированность и возможность восстановления атрибутов в случае какой-либо аварии.

Ещё один, более обобщённый, вариант стуктуры: \storage\YYYY\MM\DD\N, где N — монотонно возрастающая последовательность чисел от 0 на каждый файл. При этом в каждой папке хранится только один файл, атрибуты не хранятся вообще.

Здравствуйте, Аноним, Вы писали:

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

G>>>Вот в мире есть компания на букву M, у которой есть продукт начинающийся на Share и заканчивающийся на Point, так вот в нем все файлы хранятся в БД и никто пока от этого не умер.
K>>+1.
K>>Ещё могу припомнить Team Foundation Server, где вообще все объекты хранятся в БД. Также проблем не наблюдается...

А>Да хоть +1000 за БД. Я тоже за БД. Но только в той области, где её "вотчина".
А>Уважаемые собеседники — для каждой задачи должен применяться свой инструментарий.
А>Я не сомневаюсь, что есть узкозаточенные БД, которые могут качественно, быстро и оптимально пережёвывать миллионы объектов на одном нераспределённом сервере. Но сколько стоит использование такого инструмента и создание на нём своего решения? Имхо это аналогично "ассигнациями печь топить".
Самый обычный MS SQL нормально работает в таком режиме.

А>Вы пробовали подобным разношёрстными BLOBами наполнить БД примерно на десяток миллионов объектов на стандартном железе — хорошо ей жилось после этого?
Десяти миллионов — нет, а несколько тысяч — вполне, и у каждого еще по несколько десятков версий.

А>а как обстояло дело со вставкой новых и выборкой по старым объектов?
Нормально, блобы не хранятся в страницах с записями, поэтому выборки метаданных работают быстро, а выборка контента — чуть медленнее, чем ФС (главное буферизацию на клиенте не включать).
Вставка конечно работает не быстро, но редко встречается задача вставки огромного количества документов.

А>А каков стал размер БД?
Блобы не создают оверхеда, как раз обычные записи имеют значительный оверхед в БД по объему.

А>Я не спец по БД, поэтому не могу отвергнуть и это решение, но отношусь к нему всё же с подозрением.
С этго надо было начинать.

А>Хранение больших бинарных объектов — это всё же удел ФС — на то она и сделана, возможно над выбором самой ФС нужно поработать.
Когда ФС получит встроенные функции версионирования и транзакционности тогда поговорим.

А>А БД — это всё же метаданные.
Это предрассудки от незнания.

А>К тому же предвижу проблемы с расширением функционала, если всё завязано на одну БД.
Какие?

ЗЫ. Это я не упомянул еще про FILESTREAM в MS SQL 2008.

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

R3>Так в связи с этим тема и поднята — как постоить ФС?
А чем своя собственная идея не понравилась? Оцени максимальное количество хранимых на ФС объектов, определи необходимую вложенность директорий из этого и пиши на здоровье исходя из имени объекта, как сам и предложил. Только нужно проверить, что уникальный индентификатор даёт достаточно равномерное распределение по всему спектру значений, которые используются для определения целевой директории.

Z>>Можешь ещё подумать как можно обеспечить удаление дубликатов бинарников, но это так — на десерт.
R3>Ну тут можно тупо в фоновом режим запустить какой-нибудь сравнитель файлов. Скорость тут не важна, т.к. сама эта функция не важна.
Это когда все пользователи твоего хранилища запишут Ледниковый период-3 да по несколько раз и место начнёт кончаться, тогда поймёшь что дубликаты — это плохо.

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

A>Теоретически файловая система может хранить атрибуты самостоятельно, при условии, что их строковое представление состоит из допустимых для ФС символов.

Из допустимых. Вообще, все используемые символы в данной задаче — допустимы для использования в ФС.

A>Предположим, что имя владельца и имя файла состоит из допустимых для ФС символов. Тогда напрашивается простая структура хранилища: \storage\YYYY\MM\DD\OWNER\V, где YYYY — год, MM — месяц и DD — день поступления файла в хранилище,

DD- день первого поступления файла в хранилище?

A> OWNER — владелец,

Т.е. получается, что все файлы одного владельца будут раскиданы по всему хранилищу. Теоретически, конечно, при наличии БД, на это можно не обращать внимание. Но человекочитаемость пострадает. Хотя она мне не важна.

A>Если владельцев несколько и их важно различать, то можно использовать некие символы-разделители в имени папки, например, "ivanov-petrov-sidorov" и "ivanov".

Владельцев не нескольно. Их также — бесконечно много. Извиняюсь, что не заострил на этом внимание.

A>Ещё один, более обобщённый, вариант стуктуры: \storage\YYYY\MM\DD\N, где N — монотонно возрастающая последовательность чисел от 0 на каждый файл. При этом в каждой папке хранится только один файл, атрибуты не хранятся вообще.

Я думаю об аналогичном решении, но со следующими изменениями:
\storage\i1\...\iN\filename\v
, где
— i1-iN — директории, названия которых соответствует номерам счётчиков от нуля до бесконечности;
— filename — директория, название которой совпадает с названием хранимого файла;
— v — сам файл, название которого соответствует версии файла.

Поиск — с помощью БД.
Таким образом, остаётся определить количество счётчиков и моменты, когда надо инкрементировать каждый счётчик.

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

R3>Может быть, но у меня вопрос: зачем мне подключать дополнительную систему с кучей дополнительных возможностей, если мне надо всего-лишь сохранить файл, а через некоторое время найти его и прочитать?
R3>Может вы что-то знаете, что мне понадобится, а я этого не знаю?

1. Версионность файла, свн это уже умеет, много версий одного и того же файла в репозитарии займут мало места.
2. Аплоад/даунлоад контента. На нагруженном сайте и больших файлах это не совсем тривиальная задача (обрывы связи при аплоаде, докачки при даунлоаде), у сабвершена есть модуль для апача.
3. Hot backup, слабое место связки БД+файлы на диске.

Обычно все что можно получить из коробки дешевле получить из коробки.

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

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

K>А чем они это мотивируют? Меня громкие имена не убеждают — мне факты нужны...

А что будет, если размер каждого файла — 4ГБ? И мне их через интернет передать надо?

K> А пока мой опыт говорит о том, что в хранении файлов в БД нет ничего плохого, более того, есть некоторые преимущества (например отмеченные мной в посте выше)...

Преимущества есть, не спорю.

Пообщался с народом, говорят, что Oracle научился хранить файлы в БД ничем не хуже, чем в ФС. Есть над чем подумать.

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

G>Вот в мире есть компания на букву M, у которой есть продукт начинающийся на Share и заканчивающийся на Point, так вот в нем все файлы хранятся в БД и никто пока от этого не умер.

И не умрут. Потому что как только у них возникают проблемы — они отдают контент на хранение в EMC Documentum.

Здравствуйте, Аноним, Вы писали:

А>А чем своя собственная идея не понравилась? Оцени максимальное количество хранимых на ФС объектов, определи необходимую вложенность директорий из этого и пиши на здоровье исходя из имени объекта, как сам и предложил. Только нужно проверить, что уникальный индентификатор даёт достаточно равномерное распределение по всему спектру значений, которые используются для определения целевой директории.

Это была не моя идея. Я её подглядел.
Плюс ещё у меня нет уникального идентификатора, дающего равномерное распределение.
Ищу его там

Автор: Real 3L0
Дата: 27.07.09

.

А>Это когда все пользователи твоего хранилища запишут Ледниковый период-3 да по несколько раз и место начнёт кончаться, тогда поймёшь что дубликаты — это плохо.

+1.

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

Z>Обычно все что можно получить из коробки дешевле получить из коробки.

Хорошо. Спасибо.

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

Нагрузку, да, не представляю. А требование про бесконечное количество файлов — это, например, все файлы какой-либо компании, генерируемые в процессе своей жизнедеятельности.

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

R3>DD- день первого поступления файла в хранилище?

Нет. День текущей даты, когда получен запрос на сохранение файла в хранилище.

R3>Т.е. получается, что все файлы одного владельца будут раскиданы по всему хранилищу. Теоретически, конечно, при наличии БД, на это можно не обращать внимание. Но человекочитаемость пострадает. Хотя она мне не важна.

Почему пострадает? Я тебе привёл рабочий пример организации документооборота, немного упрощённый для демонстрации. Пусть, к примеру, это будут письма от организации. Смотри. Модель \storage\YYYY\MM\DD\OWNER\V.

Хранилище изначально велось людьми в ручном режиме. Файлы в него поступают в определённый день. Люди довольно хорошо ориентируются в датах, уж если не в днях, то год и месяц запоминают. Элемент owner у меня обычно представлен конкретной фамилией с инициалами, когда файл определяется в хранилище, у него один единственный конкретный owner, тот, который его помещает.

Кроме даты события (примерной даты) обычно бывает нужно знать кто и что положил. Кто -- это владелец, что -- это имя файла. Чтобы имена файлов не пересекались и не приходилось их менять на суррогат -- используется дополнительная папка версии.

Для поиска информации использовался обычный проводник и файловый поиск в нём. Задавались критерии, и пользователь получал список файлов со значащими именами плюс путь к файлу давал дополнительную информацию, сортировка по имени (поскольку соответсвовала дате поступления) позволяла проследить историю файла от начала до конца, было видно кто и когда менял файл.

Проводник штука тормозная, поэтому выделение YYYY\MM\DD решало 2 задачи поиск по дате и разненсение файлов по нескольким папкам, чтоы не было тормозов при открытии списка. Ну, помимо собственно иерархии рубрикатора.

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

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

Конечно, есть и недостатки, как же без них. К примеру, нельзя было просто сослаться на один файл по его адресу. Было только совпадающее имя, и приходилось выполнять поиск "снизу", чтобы получить актуальную версию. Поскольку не использовались симлинки. А иначе бы пришлось позволить перемещать файлы, что могло привести к ошибкам и путанице.

R3>Владельцев не нескольно. Их также — бесконечно много. Извиняюсь, что не заострил на этом внимание.

На один помещаемый файл единовременно? У меня был один владелец, помещающий файл в конкретный момент времени. Само собой, что за историю изменений файлом могло перевладеть куча народа, начиная с первого владельца, создателя, и заканчивая последним изменившим.
В моём случае эта информация была довольно востребована.

R3>Я думаю об аналогичном решении, но со следующими изменениями:
R3>\storage\i1\...\iN\filename\v
R3>, где
R3>- i1-iN — директории, названия которых соответствует номерам счётчиков от нуля до бесконечности;
R3>- filename — директория, название которой совпадает с названием хранимого файла;
R3>- v — сам файл, название которого соответствует версии файла.

Если я правильно понимаю, ты хочешь избавиться от поиска для построения списка версий файлов. А вот эти цифропапки на пути к полезным атрибутам (как, к примеру, в кеше сквида) мне всегда не нравились. Предпочитал использовать значащие атрибуты (имена папок). По этой же причине не нравится смена имени файла. К тому же, в NTFS есть "глупое" ограничение на размер пути к файлу. Люди иногда дают такие значащие имена шопипец, и если их переносить в названия папок, можно здорово обломиться с навигацией. Так что, я бы очень хорошо подумал, прежде чем вытаскивать имена файлов в названия папок. И, скорее всего, передумал.

R3>Поиск — с помощью БД.

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

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

A>Почему пострадает? Я тебе привёл рабочий пример организации документооборота, немного упрощённый для демонстрации.

Если рабочий, то хорошо, буду иметь в виду.

R3>>Владельцев не нескольно. Их также — бесконечно много. Извиняюсь, что не заострил на этом внимание.

A>Если я правильно понимаю, ты хочешь избавиться от поиска для построения списка версий файлов.

У меня один фик уже есть БД. Почему бы функцию поиска не отдать ей?

A> ... К тому же, в NTFS есть "глупое" ограничение на размер пути к файлу. Люди иногда дают такие значащие имена шопипец, и если их переносить в названия папок, можно здорово обломиться с навигацией. Так что, я бы очень хорошо подумал, прежде чем вытаскивать имена файлов в названия папок. И, скорее всего, передумал.

Отлично, значит и для названия папки будет генерируемая системой метка.

P.S. Для тех, кому интересно, я решил iN делать не больше 256.

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

R3>P.S. Для тех, кому интересно, я решил iN делать не больше 256.

В сквиде используется двухуровневая иерархия, на первом 16 папок, на втором 256. Якобы позволяет равномерно распределять файлы.

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

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

Вот, если взять пример TTH:

"O2FSDVSH7DTVWS5NESYHQTUWBDHH5QEYN5GMDDA"
"DWU3E7Z77HWM34TTCQP542N5Q4KEOIGTUIH6NHA"

Размер — постоянный, 39 символов, алфавит — буквы и цифры. Регистр одинаков. Можно использовать одно- или двухуровневую структуру папок для распределения файлов, например, по первым символам.

Одинаковое имя файла при разных TTH расценивать как новую версию.

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

A>А вот скажи, не думал об использовании алгоритма хеширования из всяких клиентов файлообменных сетей, типа flylinkdc++ ?

Что за сеть, не знаю, но хеш использую.

A>Насколько тот хеш уникален и в случае изменения одного и того же документа, типа версий, будет получаться разный хеш?

Разный, если не случится коллизия.

A> А в случае одного и того же -- одинаковый?

Одинаковый.

A>... А вот хеширование пока не пробовал -- не нашёл, где почитать про сей алгоритм попонятней с примерами на шарпе.

Пример

byte[] MD5hash (byte[] data)
 {
    // This is one implementation of the abstract class MD5.
    MD5 md5 = new MD5CryptoServiceProvider();

    byte[] result = md5.ComputeHash(data);

    return result;
 }

Чтобы уменьшить колличество коллизий, я использую несколько хеш-провайдеров, предоставляемых .NET'ом.

A>Вот, если взять пример TTH:

Что такое ТТН?

A>Размер — постоянный, 39 символов, алфавит — буквы и цифры. Регистр одинаков. Можно использовать одно- или двухуровневую структуру папок для распределения файлов, например, по первым символам.

Я решил не заморачиваться с хэшами для папок.
Как писал ранее, буду использовать счётчики, по 256 папок в одном счётчике. Но папки наполнять буду не подряд, а равномерно по всем папкам.

A>Одинаковое имя файла при разных TTH расценивать как новую версию.

Да, если это не коллизия.

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

R3>Что за сеть, не знаю, но хеш использую.

P2P, flylinkdc++.

R3>Пример

Не, ну так нечестно. md5 приходилось использовать, но вот как-то больше доверял CRC32.

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

R3>Что такое ТТН?

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

Алгоритм и надёжность этой функции хотелось бы понять.

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

A>P2P, flylinkdc++.

Ясно.

A>Я, наверное, не так выразился: меня не просто хеш интересует, меня интересует хеш, используемый конкретно в flylink для вычисления TTH и возможность его использования в системах управления документооборотом.

Я думаю, у них просто выбран другой алгоритм для формирования этого хэша и не более. Ведь для отслеживания уникальности необходимо как минимум глобальную БД, которой у них нет.

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

Дык, MD5 считается аналогично. Только, что MD5, что в хеш в flylink, не застрахован от коллизий.

A>Алгоритм и надёжность этой функции хотелось бы понять.

У них на форуме надо спросить.

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

R3>Плюс ещё у меня нет уникального идентификатора, дающего равномерное распределение.
R3>Ищу его там

Автор: Real 3L0
Дата: 27.07.09

.

А чем Guid не подходит?

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

A>А чем Guid не подходит?

И какова тогда должна быть структура папок?

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

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

A>>А чем Guid не подходит?

R3>И какова тогда должна быть структура папок?

Ну, например:
Генеришь новый Guid (он же будет ключем в таблице Files), делаешь ему ToString("N"), потом сплитишь в массив, например, по одному символу, делаешь String.Join(@"\", theArray) — это будет путем к подкаталогу, куда нужно поместить файл. Создаешь этот путь в ФС, складываешь туда файл (можно переименовать в file.bin и т.п. или не периименовывать — всеравно он будет один в этой подпапке), записываешь в базу вместе с инфой о пользователе и т.п. Позже по ID-у можно сразу определить путь. Глубина вложенность каталогов будет 32, в каждом каталоге максимум 16 подкаталогов. В самом глубоком — один файл.

Можно сгруппировать по 2 символа, например, тогда глубина будет 16, а в каждом каталога максимум 256 подкаталогов. Можно последние символы Guid-а использовать как имя файла и т.п.