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

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

А>>Вы пробовали подобным разношёрстными BLOBами наполнить БД примерно на десяток миллионов объектов на стандартном железе — хорошо ей жилось после этого?
G>Десяти миллионов — нет, а несколько тысяч — вполне, и у каждого еще по несколько десятков версий.
Ради интереса просканил свою шару на сторэдже — за 2.5 года работы получилось 315 тысяч документов разного рода и объёма общим размером 34 ГБ. То есть даже у одного "владельца" (который кстати любит удалять дуюбликаты и устаревшие документы, а также пользуется внесторэджевым буффером для текущих документов и отправляет на сторэдж действительно нужные доки) получается гораздо больше нескольких тысяч.
Но это так — инфа к размышлению на основе реально существующего use-case.

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

G>Вставка конечно работает не быстро, но редко встречается задача вставки огромного количества документов.
Это Вы напрасно так считаете, что вставка большого количества документов — вымысел. Как живой пример могу привести ситуацию, когда мне человек принёс практически полный ДВД с каталогами и даташитами по радиодеталям разных производителей. Объем — под 4 ГБ, количество документов думаю, тысяч за 50 перевалило.

А>>Я не спец по БД, поэтому не могу отвергнуть и это решение, но отношусь к нему всё же с подозрением.
G>С этго надо было начинать.
То, что я допускаю идею построения этого хранилища на основе БД, не говорит о том, что я признаю её оптимальной. Тот подход, который предлагаю я, уже реально работает много лет, надёжен, быстр на неспециализированном железе и имеет очень низкий процент потери данных. Хотя с учётом того, что БД прогрессируют, я не могу сказать, что отвергание BLOBов в БД тоже оптимально.

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

А>>К тому же предвижу проблемы с расширением функционала, если всё завязано на одну БД.
G>Какие?
Сейчас думать некогда, так что прошу моё последнее замечание считать недействительным. Один только вопрос — как БД хранить блобы? Внутри файла(ов) с БД или в виде внешних файлов, а внутри только ссылка? Как повлияет повреждение БД в одном секторе на работу с остальной частью БД?

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

A>Ну, например:

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

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

А>Ради интереса просканил свою шару на сторэдже — за 2.5 года работы получилось 315 тысяч документов разного рода и объёма общим размером 34 ГБ. То есть даже у одного "владельца" (который кстати любит удалять дуюбликаты и устаревшие документы, а также пользуется внесторэджевым буффером для текущих документов и отправляет на сторэдж действительно нужные доки) получается гораздо больше нескольких тысяч.
А>Но это так — инфа к размышлению на основе реально существующего use-case.

Хм. Интересно. Ещё один повод в моём решении отказаться от хранения файлов. Конечно, при этом, я потеряю часть функционала. Надо подумать, насколько он мне критичен.

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

А>>>Вы пробовали подобным разношёрстными BLOBами наполнить БД примерно на десяток миллионов объектов на стандартном железе — хорошо ей жилось после этого?
G>>Десяти миллионов — нет, а несколько тысяч — вполне, и у каждого еще по несколько десятков версий.
А>Ради интереса просканил свою шару на сторэдже — за 2.5 года работы получилось 315 тысяч документов разного рода и объёма общим размером 34 ГБ. То есть даже у одного "владельца" (который кстати любит удалять дуюбликаты и устаревшие документы, а также пользуется внесторэджевым буффером для текущих документов и отправляет на сторэдж действительно нужные доки) получается гораздо больше нескольких тысяч.
А>Но это так — инфа к размышлению на основе реально существующего use-case.
Порядком цифры не ошиблись?
315000 за 2,5 годы = 126000 в год = 345 в день = 14 в час. Один документ в 4 минуты, при этом надо ни есть, ни спать, только вносить документы.
Для среднестатистического офисного работника это очень дофига.
Средний объем — 113 кб. Для текста это очень много, за 4 минуты не набъешь столько.

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

G>>Вставка конечно работает не быстро, но редко встречается задача вставки огромного количества документов.
А>Это Вы напрасно так считаете, что вставка большого количества документов — вымысел. Как живой пример могу привести ситуацию, когда мне человек принёс практически полный ДВД с каталогами и даташитами по радиодеталям разных производителей. Объем — под 4 ГБ, количество документов думаю, тысяч за 50 перевалило.
И зачем их все пихать в БД?
Смысл хранения в БД:
1)Нетривиальные метаданные (+интеграция с бизнес-системой)
2)Контроль доступа
3)Версионирование
4)Транзакционность
Если хотябы 2 пункта не нужны, то не факт что использование БД вам поможет в каких-то задачах.

Системы документооборота как раз занимаются тем что приведено выше, в том числе Documentum, который по непонятной мне причине не хранит файлы в БД.
Хотя при наличии filestream лучше использовать его, и вообще не работать с ФС напрямую.

А>>>Я не спец по БД, поэтому не могу отвергнуть и это решение, но отношусь к нему всё же с подозрением.
G>>С этго надо было начинать.
А>То, что я допускаю идею построения этого хранилища на основе БД, не говорит о том, что я признаю её оптимальной. Тот подход, который предлагаю я, уже реально работает много лет, надёжен, быстр на неспециализированном железе и имеет очень низкий процент потери данных. Хотя с учётом того, что БД прогрессируют, я не могу сказать, что отвергание BLOBов в БД тоже оптимально.
Ну и пусть работает. Для ваших задач он может быть даже оптимальна. Только франение в ФС не является универсальным рецептом. Более того, при нынешнем развитии БД хранение документов в ФС может быть только оптимизацией.

G>>Когда ФС получит встроенные функции версионирования и транзакционности тогда поговорим.
А>На мой взгляд к разговору стоит вернуться при воникновении именно проблемы, а не путей решения потенциальных проблем. С желанием версионированием для меня всё понятно, но что Вы имеете ввиду под транзакционностью ФС?
Ну как обычно, в основном инетресуют свойства атомарности и консистентности.
Можно ли при хранении файов в ФС гарантировать что при измении файла если произойдет ошибка записи метаданных, то изменения содержимого файла не будет и наоборот, при ошибки записи в файл не произойдет изменения метаданных?
Про вопросы ссылочной целостности даже не говорю.

А>Сейчас думать некогда, так что прошу моё последнее замечание считать недействительным. Один только вопрос — как БД хранить блобы? Внутри файла(ов) с БД или в виде внешних файлов, а внутри только ссылка? Как повлияет повреждение БД в одном секторе на работу с остальной частью БД?
Обычно блобы в отдельных страницах БД хранятся.

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

G>Системы документооборота как раз занимаются тем что приведено выше, в том числе Documentum, который по непонятной мне причине не хранит файлы в БД.

Базы данных не всегда успешно справлялись с хранением файлов.

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

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

G>>Системы документооборота как раз занимаются тем что приведено выше, в том числе Documentum, который по непонятной мне причине не хранит файлы в БД.

R3>Базы данных не всегда успешно справлялись с хранением файлов.

Это не означает что предрассудки надо тянуть за собой и еще верить предрассудкам других людей.

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

R3>>Базы данных не всегда успешно справлялись с хранением файлов.
G>Это не означает что предрассудки надо тянуть за собой и еще верить предрассудкам других людей.

В какой версии SQL Server сделали нормальную поддержку работы с файлами?
Все ли версии БД, которые поддерживает Documentum, имеют нормальную поддержку работы с файлами?

Так что ещё не известно, тянет ли тут кто-нибудь, или кто-то тормозит.

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

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

G>315000 за 2,5 годы = 126000 в год = 345 в день = 14 в час. Один документ в 4 минуты, при этом надо ни есть, ни спать, только вносить документы.
G>Для среднестатистического офисного работника это очень дофига.
G>Средний объем — 113 кб. Для текста это очень много, за 4 минуты не набъешь столько.
Я явно не среднестатистический офисный работник, составляющий один документ с отчётностью в конце дня и отправляющий её куда-нить.
Вы, очевидно, забываете что не plain-text'ом единым жив человек. А графика? А растры? А видео? А архивы — аттачи к мылу? А само мыло, которое сыплется на корпоративную почту по 100 в день? Голубчик, пожалуйста, изучите современные мерки ingest'а в системы хранения данных в разных отраслях, привязанных к хранению информации в сторэджах, а затем уже разрабатывайте нормативы — сколько байт должен производить среднечтатистический работник за единицу времени. И порите его, если он не укладывается.

А>>Это Вы напрасно так считаете, что вставка большого количества документов — вымысел. Как живой пример могу привести ситуацию, когда мне человек принёс практически полный ДВД с каталогами и даташитами по радиодеталям разных производителей. Объем — под 4 ГБ, количество документов думаю, тысяч за 50 перевалило.
G>И зачем их все пихать в БД?
Заметьте — я пихаю всё на сторэдж, а не в БД. Это Ваше предложение, как разработчика (нет, архитектора — простите) — пихать всё в БД (смотрите первый пост про цель постановленной задачи).

G>Ну и пусть работает. Для ваших задач он может быть даже оптимальна. Только франение в ФС не является универсальным рецептом. Более того, при нынешнем развитии БД хранение документов в ФС может быть только оптимизацией.
Простите — посмотрите, пожалуйста, первый пост топика — где просьба выработать универсальное решение? Безусловно — ФС — не панацея в хранении данных, равно как и БД. Всё зависит от специфики.

G>Можно ли при хранении файов в ФС гарантировать что при измении файла если произойдет ошибка записи метаданных, то изменения содержимого файла не будет и наоборот, при ошибки записи в файл не произойдет изменения метаданных?
Это зависит от радиуса кривизны рук разработчика (в том числе). Но мой ответ — можно.

А>>Сейчас думать некогда, так что прошу моё последнее замечание считать недействительным. Один только вопрос — как БД хранить блобы? Внутри файла(ов) с БД или в виде внешних файлов, а внутри только ссылка? Как повлияет повреждение БД в одном секторе на работу с остальной частью БД?
G>Обычно блобы в отдельных страницах БД хранятся.
К сожалению, я не узрел ответа на свой последний вопрос.

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

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

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

G>>315000 за 2,5 годы = 126000 в год = 345 в день = 14 в час. Один документ в 4 минуты, при этом надо ни есть, ни спать, только вносить документы.
G>>Для среднестатистического офисного работника это очень дофига.
G>>Средний объем — 113 кб. Для текста это очень много, за 4 минуты не набъешь столько.
А>Я явно не среднестатистический офисный работник, составляющий один документ с отчётностью в конце дня и отправляющий её куда-нить.
А>Вы, очевидно, забываете что не plain-text'ом единым жив человек. А графика? А растры? А видео? А архивы — аттачи к мылу? А само мыло, которое сыплется на корпоративную почту по 100 в день? Голубчик, пожалуйста, изучите современные мерки ingest'а в системы хранения данных в разных отраслях, привязанных к хранению информации в сторэджах, а затем уже разрабатывайте нормативы — сколько байт должен производить среднечтатистический работник за единицу времени. И порите его, если он не укладывается.

А>>>Это Вы напрасно так считаете, что вставка большого количества документов — вымысел. Как живой пример могу привести ситуацию, когда мне человек принёс практически полный ДВД с каталогами и даташитами по радиодеталям разных производителей. Объем — под 4 ГБ, количество документов думаю, тысяч за 50 перевалило.
G>>И зачем их все пихать в БД?
А>Заметьте — я пихаю всё на сторэдж, а не в БД. Это Ваше предложение, как разработчика (нет, архитектора — простите) — пихать всё в БД (смотрите первый пост про цель постановленной задачи).

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

Тем не менее БД видится сейчас более универсальным решением в отличие ФС.

А>>>Сейчас думать некогда, так что прошу моё последнее замечание считать недействительным. Один только вопрос — как БД хранить блобы? Внутри файла(ов) с БД или в виде внешних файлов, а внутри только ссылка? Как повлияет повреждение БД в одном секторе на работу с остальной частью БД?
G>>Обычно блобы в отдельных страницах БД хранятся.
А>К сожалению, я не узрел ответа на свой последний вопрос.
Это зависит от того как хранятся страницы данных. В MS SQL все хранится в одном файле (в случае filestream блобы лежат отдельно).