Дискуссия о разных подходах в построении систем PDM

Дискуссии о других системах
Ответить
Николай Ширяев
Участник
Сообщения: 40
Зарегистрирован: 25 июн 2004, 14:06
Откуда: Лоция

Дискуссия о разных подходах в построении систем PDM

Сообщение Николай Ширяев »

[Moderation Mode ON]
Выделено из другой темы
[Moderation Mode OFF]


Уважаемый McZag,
насколько я понимаю, Вы представляете фирму CSoft.

Раз уж Вы упомянули Lotsia PDM PLUS, то позвольте сделать небольшое разъяснение (разумеется, абсолютно субъективное, и не претендующее на истину в последней инстанции).

При создании системы Lotsia PDM PLUS мы сознательно не использовали схему хранения документов в базе данных, хоть это и было бы проще с точки зрения программирования.

Мы очень хорошо представляем себе все плюсы и минусы такого решения.

И мы считаем хранение документов в базе неоптимальным по следующим причинам:
- быстрый рост объема базы данных вызывает необходимость использования более мощного (следовательно, -- более дорогого) сервера и катастрофическое снижение производительности при работе с большими объемами документов;
- при сбое базы данных возможна потеря всех документов сразу;
- сложнее организовать хранение компонентных документов;
- ограничение только схемой хранения on-line.

Но, я полагаю, что Вы и сами все это прекрасно знаете.

Упомянутые Вами плюсы хранения файлов в базе данных спорны. (Вообще, как писал выше Alxd, ту же NTFS можно рассматривать в качестве файловой базы данных.)

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

Централизованное резервное копирование применительно к хранению файлов в БД в ряде случаев (но не всегда) также менее удобно (не все средства резервного копирования позволяют работать с открытой базой, а останавливать ее не всегда удобно; не все СУБД хранят всю базу в одном файле; да и сама процедура восстановления базы из бэкапа не всегда легка и прозрачна). А существующие сейчас средства резервного копирования часто позволяют гораздо лучше обеспечить процесс резервного копирования файлов.

Полнотекстовый поиск средствами СУБД -- вещь хорошая, но для нормального мультиформатного поиска по русскоязычным документам все же предпочтительнее использовать специализированные средства полнотекстового поиска типа Verity.

Так что единственный реальный плюс хранения документов (файлов) в СУБД -- это бОльшая простота реализации системы для разработчиков, особенно в части управления правами доступа. (Если хранить документы на файл-серверах, то для каждого типа серверной ОС и файловой системы нужно писать свой модуль защиты данных, что более трудоемко.)

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

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

Но Вы, разумеется, вправе выбирать ту стратегию при разработке своего ПО, которую считаете наиболее правильной.

Кстати, если Вас не затруднит, передайте, пожалуйста, от меня привет и наилучшие пожелания Илье Лебедеву.

Желаю Вам всяческих успехов!
С уважением, Николай Ширяев
McZag
Новый участник
Сообщения: 6
Зарегистрирован: 02 авг 2005, 13:12

Сообщение McZag »

Рад, что Вы, Николай, откликнулись

Я действительно представляю компанию CSoft, но предлагаю рассматривать наше обсуждение как чисто теоретическое, без привязки к TDMS или Lotsia PDM PLUS. Возможно, в таком ключе диспут будет полезен обоим компаниям-разработчикам.

Как Вы верно заметили, при выборе модели хранения больших бинарных и текстовых данных, компания-разработчик информационной системы стоит перед выбором "как это сделать". И если разработчики подходят к этому вопросу достаточно ответственно (а, imo, это один из ключевых вопросов построения системы, оперирующей с файлами), то аргумент "это проще в реализации" не может восприниматься всерьез при постановке ТЗ. Вы утверждаете, что реализация хранения в СУБД проще, хотя немного противоречите сами себе, приводя контраргумент о поддержки связанных документов в разных моделях. За сим, я могу с такой же легкостью перевернуть ситуацию и сказать, что реализация хранения файлов в файловой системе проще, чем реализация любыми другими способами ;), особенно, если в качестве отправной точки выбрать конкретную файловую систему конкретной операционной системы.

Поэтому, предлагаю обсудить этот вопрос с позиций "а что действительно удобнее, быстрее, надежнее etc." без привязки к конкретной системе и пути ее развития и "стоимости" того или иного решения.

Скажу сразу, что я являюсь сторонником гибридного хранения файлов. Т.е. модель хранения должна быть выбрана администратором системы в зависимости от ряда параметров: территориальное расположение, типы файлов, их объем, типы используемых накопителей и т.д. Поэтому ниже нижеследующие реплики в защиту хранения файлов в СУБД следует рассматривать как "и так тоже можно", но не более того.

Вы приводите несколько аргументов против модели хранения файловых данных в СУБД. Я дам свои комментарии:
- быстрый рост объема базы данных вызывает необходимость использования более мощного (следовательно, -- более дорогого) сервера и катастрофическое снижение производительности при работе с большими объемами документов;
Быстрый рост объема данных не зависит от выбранной модели хранения файлов. Затраты на прокачку файлов по сети и скорость работы дисковых (или любых других) накопителей не сопоставимы с затратной частью потока сервера, обслуживающего операцию ввода/вывода. Поэтому дополнительные требования, предъявляемые к модели хранения файлов непосредственно в СУБД относятся скорее к расширению сетевых каналов и бОльшему расслоению дисковых массивов, нежели увеличению производительности самого сервера (количества процессоров, объема памяти). Поэтому между затратами при выборе "один более быстрый сервер или два (несколько) попроще" я бы поставил знак равенства. Хотя (а я вроде бы этого и не утверждал) управление файлами средствами СУБД никогда при прочих равных не будет быстрее, чем средствами нативной файловой системы.
- при сбое базы данных возможна потеря всех документов сразу;
Это, извините, не аргумент. Если произойдет извержение супервулкана, то ваши данные никому вообще не будут нужны. Резервное копирование никто не отменял. К тому же, при "сбое базы данных" будут ОЧЕНЬ БОЛЬШИЕ проблемы при любом способе хранения файлов.
- сложнее организовать хранение компонентных документов;
Я придерживаюсь перпендикулярной точки зрения. Если говорить о хранении файлов в_отдельно_взятой_организации, то бесспорно это значительно проще. Но если ваша модель исходно исключает операции по абсолютным путям, переносимость любого файлового контента осуществляется "как есть". Операции передачи объектно-файловой информации между подразделениями компании и к заказчику выполняется без привязки к модели хранения файлов. Где бы вы не разместили файлы в дальнейшем, связи между ними будут корректно обработаны.
- ограничение только схемой хранения on-line.
Хранение файлов в СУБД действительно не предлагает их физическое отсутствие. Но так ли это актуально?

Относительно безопасности и резервного копирования Вы меня никогда не переубедите. Поэтому мы можем "расстаться" по этим вопросам каждый при своем. Основная проблема в безопасности и надежности не железо и не наличие соответствующего сертификата, а человеческий фактор. Чем больше людей задействовано в администрировании, чем более разнообразные задачи они решаю, тем больше потенциальных проблем. Перенеся всю тяжесть проблем на (двух?) администраторов СУБД вы максимально исключаете человеческий фактор.

Полнотекстовый поиск сторонними средствами вещь хорошая. Но не бесплатная :( К тому же бОльшая часть этих средств легко встраивается в СУБД
сейчас фактически практически все лидирующие на мировом рынке системы используют принцип раздельного размещения базы данных и собственно файлов.
Я не располагаю такой информацией. Если у Вас есть реальные примеры отказа хранения файлов в СУБД в системах с мировым именем, буду рад услышать "их имена". Впрочем, ничего удивительного в этом нет. Файловый сервер, работающий как отдельный сетевой сервис, не привязанный к ОС и обладающий сопряженными с информационной системой средствами администрирования, всегда будет эффективнее чем СУБД.

Мы с Вами не затронули вопрос управления физическими устройствами. Хотелось бы узнать Вашу точку зрения на этот счет.

С удовольствием передам привет Илье Лебедеву.
Жду Вашего ответа. С уважением, Сергей Загурский[/quote]
Аватара пользователя
Alxd
Активный участник
Сообщения: 50
Зарегистрирован: 15 июл 2004, 12:42
Откуда: Тюмень
Контактная информация:

Сообщение Alxd »

Как человек наглый :D я таки вклинюсь в диалог.
Затраты на прокачку файлов по сети и скорость работы дисковых (или любых других) накопителей не сопоставимы с затратной частью потока сервера, обслуживающего операцию ввода/вывода.
Если файлы хранятся в БД, то соответственно файл базы данных растет непомерно. Могу привести пример. За два года эксплуатации Lotsia PDM Plus у нас размер базы данных 700Мб + размер каталога с файлами 9500Мб. База и файлы хранятся на разных серверах. Причем база данных на работает под Windows, а файловый под Novell (самый быстрый файловый сервер)!!!
Представьте себе, что все эти файлы оказались бы в базе данных!!! Мало того, что файловая система NTFS уступает NFS в скорости, так еще и размер базы был бы гигантским, что мешало поиску данных на диске! А так, при размере RAM в 2Гб можно смело предположить, что данные по базе данных ищутся именно в памяти, а не на диске. Дисковые операции самые медленные!!!
Если произойдет извержение супервулкана, то ваши данные никому вообще не будут нужны
Вот именно это не аргумент! Извержение тут ни при чем. И резервное копирование пользователи (админы) делают.
Вопрос в процедуре восстановления данных и возврата пользователей к работе. В случае с хранением данных в файловой системе достаточно открыть пользователям доступ к файлам и выдать имена файлов из базы. Это реально сделать в течении часа!
А если файлы в базе, их надо будет еще извлечь до момента восстановления самой информации к ним!!! Простите, но это намного сложнее.
Где бы вы не разместили файлы в дальнейшем, связи между ними будут корректно обработаны.
Просто представьте себе количество операций при обработке компонентных документов хранимых в базе и при хранении на диске. Это опять все вытекает из способа хранения.
Тот же AutoCAD должен подключить внешнюю ссылку информация о которой хранится в базе данных. Ему нужен конкретный файл. Значит его надо предоставить. Как?
В Lotsia PDM Plus - просто открыть права. В TDMS файл придется извлечь и корректно сохранить!!! (Отходя в сторону, отпадает даже операция захвата файлов.)
Перенеся всю тяжесть проблем на (двух?) администраторов СУБД вы максимально исключаете человеческий фактор.
Нас было двое. Теперь я один. Какая разница? Резервное копирование - это процедура которая настраивается единожды и должна доходить до автоматизма. Просто смена ленточек. Какая разница сколько админов?
Файловый сервер, работающий как отдельный сетевой сервис, не привязанный к ОС и обладающий сопряженными с информационной системой средствами администрирования, всегда будет эффективнее чем СУБД.
Именно. Именно поэтому Microsoft поменяла файловую систему с FAT32 на NTFS (одна из причин).
Николай Ширяев
Участник
Сообщения: 40
Зарегистрирован: 25 июн 2004, 14:06
Откуда: Лоция

Сообщение Николай Ширяев »

Уважаемый Сергей!
Мне очень приятно, что такие серьезные представители компании CSoft читают этот форум. Я пишу это без иронии.
McZag писал(а):предлагаю рассматривать наше обсуждение как чисто теоретическое, без привязки к TDMS или Lotsia PDM PLUS. Возможно, в таком ключе диспут будет полезен обоим компаниям-разработчикам.
Давайте попробуем, но активного диалога не обещаю (банально не хватает времени). :(
А если скатимся совсем в оф-топик, или появится скрытая реклама, то Злобный Модератор форума нас быстро приструнит. :)
McZag писал(а):аргумент "это проще в реализации" не может восприниматься всерьез при постановке ТЗ.
К сожалению, я неоднократно видел, как различные компании-разработчики принимали решение, которое было не лучше для пользователя, а именно проще им в реализации. Но я не могу их за это винить. Они, к примеру, могли решать тактические задачи создания системы под конкретного клиента; а потом их детище неожиданно переросло изначальные задумки.
McZag писал(а):Вы утверждаете, что реализация хранения в СУБД проще, хотя немного противоречите сами себе, приводя контраргумент о поддержки связанных документов в разных моделях.
Уважаемый Сергей, я писал, что этот путь проще, особенно в части управления правами доступа, но не говорил, что он лучше. Поскольку именно эта простота реализации начальных требований может в дальнейшем привести к серьезным проблемам.
McZag писал(а):За сим, я могу с такой же легкостью перевернуть ситуацию и сказать, что реализация хранения файлов в файловой системе проще, чем реализация любыми другими способами ;), особенно, если в качестве отправной точки выбрать конкретную файловую систему конкретной операционной системы.
Для файловой системы конкретной ОС- возможно; но мы же не рассматриваем совсем уж частные случаи, не так ли?
А в общем случае реализовать защиту при хранении документов в файловой системе сложнее, чем при хранении в БД.
McZag писал(а):Поэтому, предлагаю обсудить этот вопрос с позиций "а что действительно удобнее, быстрее, надежнее etc." без привязки к конкретной системе и пути ее развития и "стоимости" того или иного решения.
Я не знаю, получится ли найти "единственно верное решение". Не верю я в панацею. :)
McZag писал(а):Скажу сразу, что я являюсь сторонником гибридного хранения файлов. Т.е. модель хранения должна быть выбрана администратором системы в зависимости от ряда параметров: территориальное расположение, типы файлов, их объем, типы используемых накопителей и т.д. Поэтому ниже нижеследующие реплики в защиту хранения файлов в СУБД следует рассматривать как "и так тоже можно", но не более того.
Я также полагаю, что система должна быть гибкой, но при этом максимально использовать принцип единообразия организации работы с данными (чем больше разных схем используется, тем больше вероятность появления разного рода проблем и дырок в защите).
В моем идеале система должна быть простой и безотказной как автомат Калашникова. :)
McZag писал(а):Вы приводите несколько аргументов против модели хранения файловых данных в СУБД. Я дам свои комментарии:
- быстрый рост объема базы данных вызывает необходимость использования более мощного (следовательно, -- более дорогого) сервера и катастрофическое снижение производительности при работе с большими объемами документов;
Быстрый рост объема данных не зависит от выбранной модели хранения файлов.
Извините, но Вы не совсем точно меня цитируете. :)
Я писал именно про быстрый рост объема базы данных, а не просто данных.
McZag писал(а):Затраты на прокачку файлов по сети и скорость работы дисковых (или любых других) накопителей не сопоставимы с затратной частью потока сервера, обслуживающего операцию ввода/вывода.
В этой части я согласен.
Но, как Вы понимаете, что чем больше размер базы данных, тем больше вероятность работы именно с использованием дисковых накопителей, а не ОЗУ. Так что я выступаю за максимально компактную базу данных. ;)

McZag писал(а):Поэтому дополнительные требования, предъявляемые к модели хранения файлов непосредственно в СУБД относятся скорее к расширению сетевых каналов и бОльшему расслоению дисковых массивов, нежели увеличению производительности самого сервера (количества процессоров, объема памяти).
Производительность сервера зависит от многих параметров, но обращение, - при прочих равных условиях, - не к ОЗУ, а к дисковым накопителям ее (производительность) обычно не повышает. ;)
McZag писал(а):Поэтому между затратами при выборе "один более быстрый сервер или два (несколько) попроще" я бы поставил знак равенства.
Как показывает практика, увеличение производительности сервера в два раза удорожает его в существенно большее число раз (мы же говорим об отказоустойчивом сервере).
McZag писал(а):Хотя (а я вроде бы этого и не утверждал) управление файлами средствами СУБД никогда при прочих равных не будет быстрее, чем средствами нативной файловой системы.
Вот и славно. Но я и не говорю, что Вы это утверждали.
Я просто пытался обосновать логику нашего подхода. :)
McZag писал(а):Если произойдет извержение супервулкана, то ваши данные никому вообще не будут нужны.
Опять же, как показывает практика, :) сбой базы случается все же значительно чаще, чем извержение супервулкана.
McZag писал(а):Резервное копирование никто не отменял.
Готов подписаться под этими Вашими словами.
Но Вы же знаете, в какой стране мы живем...
McZag писал(а):К тому же, при "сбое базы данных" будут ОЧЕНЬ БОЛЬШИЕ проблемы при любом способе хранения файлов.
Выше уважаемый Alxd довольно ясно написал о решении проблем в случае раздельного хранения файлов и базы. Спасти данные будет проще, чем при хранении в БД.
McZag писал(а):
- сложнее организовать хранение компонентных документов;
Я придерживаюсь перпендикулярной точки зрения. Если говорить о хранении файлов в_отдельно_взятой_организации, то бесспорно это значительно проще. Но если ваша модель исходно исключает операции по абсолютным путям, переносимость любого файлового контента осуществляется "как есть". Операции передачи объектно-файловой информации между подразделениями компании и к заказчику выполняется без привязки к модели хранения файлов. Где бы вы не разместили файлы в дальнейшем, связи между ними будут корректно обработаны.
Извините, но все-таки я с Вами не соглашусь.
Помимо тех резонов, что привел выше уважаемый Alxd, есть еще и другие.
Например, ряд приложений любят хранить полные абсолютные пути. А другие приложения любят "молча" сбрасывать дополнительные файлы (типа сечений и т.п.) в текущий каталог. И этот перечень "особенностей отдельных приложений" можно продолжать.
Также есть другая интересная задача: попробуйте импортировать в БД файлы со ссылками друг на друга, ранее хранившиеся на пусть даже сетевом ресурсе, и открыть их после импорта. "Поднимутся" ли ссылки?
А если ссылки вдруг ;) все же поднимутся, то экспортируйте эти файлы опять из системы, и снова проверьте, работают ли внешние ссылки в экспортированных файлах. В большинстве случаев (за исключением совсем простых) ситуация бывает крайне забавной.
McZag писал(а):Хранение файлов в СУБД действительно не предлагает их физическое отсутствие. Но так ли это актуально?
Для кого-то это может быть актуально.
McZag писал(а):Относительно безопасности и резервного копирования Вы меня никогда не переубедите.
Воля Ваша. :)
McZag писал(а):Основная проблема в безопасности и надежности не железо и не наличие соответствующего сертификата, а человеческий фактор.
Здесь я с Вами опять соглашусь. :)
McZag писал(а):Чем больше людей задействовано в администрировании, чем более разнообразные задачи они решаю, тем больше потенциальных проблем. Перенеся всю тяжесть проблем на (двух?) администраторов СУБД вы максимально исключаете человеческий фактор.
Количество администраторов никак не связано (IMHO) ни со схемой хранения, ни со схемой резервного копирования.
Но обычно даже двумя администраторами обойтись не получается (для крупных проектов): кто-то же еще должен вести справочники, классификаторы и т.п.
McZag писал(а):Полнотекстовый поиск сторонними средствами вещь хорошая. Но не бесплатная :( К тому же бОльшая часть этих средств легко встраивается в СУБД
К сожалению, чтобы полнотекстовый поиск в БД также работал хорошо (а именно, поддерживал корректный поиск документов на русском языке в форматах файлов более сложных чем TXT и HTML), тоже приходится докупать опциональные расширения.
Так что если хочется нормальный полнотекстовый индексатор - за него все равно нужно платить.
McZag писал(а):
сейчас фактически практически все лидирующие на мировом рынке системы используют принцип раздельного размещения базы данных и собственно файлов.
Я не располагаю такой информацией.
Пожалуйста, например, Hummigbird DM, TeamCenter и другие.
Схема "Database - Vault" сейчас стала практически стандартной.
McZag писал(а):Если у Вас есть реальные примеры отказа хранения файлов в СУБД в системах с мировым именем, буду рад услышать "их имена".
Извините, но Вы опять неточно меня цитируете (то ли я так косноязычно пишу...).

Я писал:
И те отечественные разработчики, которые изначально использовали схему хранения документов в базе данных, в дальнейшем (по мере роста объема информации у пользователей их систем) были вынуждены из-за указанных выше проблем перейти на хранение документов на файл-серверах.
То есть, изменяли стратегию хранения именно отечественные разработчики. Я думаю, Вы знаете, в частности о каком продукте идет речь. Да, возможность хранения документов в базе у них осталась, но им пришлось для крупных проектов решать задачи и файлового хранения.
Да и Ваша компания наверняка не просто так свой файловый сервер разрабатывала. ;)
McZag писал(а):Впрочем, ничего удивительного в этом нет. Файловый сервер, работающий как отдельный сетевой сервис, не привязанный к ОС и обладающий сопряженными с информационной системой средствами администрирования, всегда будет эффективнее чем СУБД.
Собственно, о лучшей производительности системы при раздельном хранении файлов и базы я и говорил.
Но что касается отсутствия привязки сервиса защиты документов к ОС, есть у меня все же некие сомнения.
Уж больно разные механизмы используются, к примеру, в сетях под Windows и Novell NetWare. Так что есть сомнения в "полном счастье, для всех и сразу".
McZag писал(а):Мы с Вами не затронули вопрос управления физическими устройствами. Хотелось бы узнать Вашу точку зрения на этот счет.
Миграция для отдельных документов - вещь хорошая. Но вот реально она мало где используется (по моему опыту работы еще в середине 90-х годов прошлого века с DOCS Open, имевшим этот сервис, заказчики им практически не пользовались).
Тем более, сейчас многие системы массового хранения имеют свое собственное ПО для миграции документов.
Чаще все же встречается случай, когда нужно переместить целый проект (например, по его завершении). И это решается легко.
Все что нужно практически любой нормальной системе - это чтобы ресурс (устройство хранения) был виден.
Мой личный подход предельно прагматичен: если есть стандартное решение, которое работает, то не нужно изобретать велосипед.
Так что наличие средств миграции - это хорошо, но IMHO, не главное.


Вот примерно так; извиняюсь что коротко.
Прошу прощения, если мои высказывания не очень "научны" или расходятся с Вашими представлениями об идеальной системе - мой подход "не шашечки, а ехать", и от высокой теории я очень далек. Для этого у нас специально обученные люди есть. :)

Желаю удачи!
С уважением, Николай Ширяев
McZag
Новый участник
Сообщения: 6
Зарегистрирован: 02 авг 2005, 13:12

Сообщение McZag »

Уважаемый Alxd

Вы чрезвычайно эмоциональный человек. В вашем постинге штук 20 восклицательных знаков. В ветке A vs B это было бы вполне допустимо. Но я предложил абстрагироваться на сколько это возможно от конкретных продуктов, и обсудить плюсы и минусы разных подходов управления файлами в информационных системах.
За два года эксплуатации Lotsia PDM Plus у нас размер базы данных 700Мб + размер каталога с файлами 9500Мб.
Если бы вы к каждой цифре приписали бы 0, я бы сказал "Прилично!" По мне так вы указали достаточно скромный объем. 10ГБ это 10,000 файлов в 1 МБ.
Представьте себе, что все эти файлы оказались бы в базе данных!!! Мало того, что файловая система NTFS уступает NFS в скорости, так еще и размер базы был бы гигантским, что мешало поиску данных на диске! А так, при размере RAM в 2Гб можно смело предположить, что данные по базе данных ищутся именно в памяти, а не на диске. Дисковые операции самые медленные!!!
Не понимаю о чем это вы. Вопросы хранения, поиска и извлечения больших бинарных данных в современных СУБД (если не сложно, далее под СУБД понимать только представителей РСУБД, лидирующих на этом рынке: Oracle, SQL Server, DB2. Я просто не могу поручиться за остальные системы) решены достаточно эффективно. Умный (хотя бы обученный [нами]) администратор СУБД не будет класть яйца в одно лукошко, и файлы (системные области) с файлами будет размещать отдельно. Совсем замечательно, если будут выполнены требования по конфигурации железа, и файлы будут размещаться на отдельном дисковом массиве. Заметьте, это не требования TDMS, это общие требования по конфигурированию СУБД. По нашим тестам, извлечение файлов из СУБД происходит с сопоставимой скоростью по сравнению с NTFS. Другое дело запись файлов. При отключенном полнотекстовом поиске потери уже заметны, но по прежнему не критичны, при включенном полнотекстовом поиске на однопроцессорном сервере потери составляют до 100%. Хотя это "фоновый" сервис, его работа достаточно сильно нагружает ресурсы сервера. Но ситуация относительно легко выправляется наращиванием производительности сервера: увеличение числа процессоров и объема памяти.

И еще раз. Увеличение объемов хранения файлов в СУБД никак не влияет на производительность системы и не предъявляет дополнительных требований к серверу! Файлы размещаются в СУБД отдельно.

Более того, я считаю, что СУБД в состоянии более эффективно управлять файлами, чем современные файловые системы. Если вам знакомо слово Longhorn, изучите как собирается эта система работать с файлами.
Вопрос в процедуре восстановления данных и возврата пользователей к работе. В случае с хранением данных в файловой системе достаточно открыть пользователям доступ к файлам и выдать имена файлов из базы. Это реально сделать в течении часа!
А если файлы в базе, их надо будет еще извлечь до момента восстановления самой информации к ним!!! Простите, но это намного сложнее.
Я с трудом представляю себе, как [временно] потеряв объектную информацию (включая права доступа), вы восстановите доступ к файлам (по сути, раздадите пользователям права на них "в течение часа"). Возможно, Lotsia PDM Plus и обладает такой возможностью. Но даже это не переубедит меня в том, что работа в системе должна начаться до того, как она полностью восстановлена. К тому же, если уж сравнивать A vs B, то если политикой безопасности организации разрешено пользователям оставлять файлы на рабочих местах, они смогут продолжить работу со своими файлами и без TDMS. Без остановки! У них не будут работать прямые интерфейсы, не будет доступа к системе, но редактировать файлы и впоследствие восстановить их в системе не составит никакого труда. Надеюсь, Николай простит меня за эту "скрытую рекламу".
Просто представьте себе количество операций при обработке компонентных документов хранимых в базе и при хранении на диске. Это опять все вытекает из способа хранения.
Тот же AutoCAD должен подключить внешнюю ссылку информация о которой хранится в базе данных. Ему нужен конкретный файл. Значит его надо предоставить. Как?
В Lotsia PDM Plus - просто открыть права. В TDMS файл придется извлечь и корректно сохранить!!! (Отходя в сторону, отпадает даже операция захвата файлов.)
Не вижу принципиальной разницы. Точнее она есть, причем, ИМХО, не в пользу файлового хранилища ;) Вставка ссылки на файл делается для того чтобы увидеть его содержимое у себя в документе. Соответственно, будет произведена сетевая операция по загрузке содержимого ссылочного документа. Это основная потеря скорости. Переместив файл на диск пользователя, мы избежим повторной сетевой операции для всех ссылочных файлов, которые не изменялись. Это называется кэширование. Вообще, я сторонник редактирования содержимого составных документов исключительно средствами нативных редакторов и прямых, встроенных в них, интерфейсов. Т.е. последовательность действий примерно следующая: а) пользователь открывает "свой" документ, б) пользователь, используя прямой интерфейс, встроенный в САПР, осуществляет вставку/редактирование/удаление связанных документов. Избежать выгрузки копии связанного документа при этом нельзя. Но это не недостаток. Это издержки (а в некоторых случаях плюсы) такого подхода.

Николай, теперь к Вам ;)

Если не возражаете, я не буду отвечать на бОльшую часть Вашего постинга, тем более, что мы более-менее ясно выразили свои точки зрения. Выделю лишь основные (проблемные) моменты.
Извините, но все-таки я с Вами не соглашусь.
Помимо тех резонов, что привел выше уважаемый Alxd, есть еще и другие.
Например, ряд приложений любят хранить полные абсолютные пути. А другие приложения любят "молча" сбрасывать дополнительные файлы (типа сечений и т.п.) в текущий каталог. И этот перечень "особенностей отдельных приложений" можно продолжать.
Также есть другая интересная задача: попробуйте импортировать в БД файлы со ссылками друг на друга, ранее хранившиеся на пусть даже сетевом ресурсе, и открыть их после импорта. "Поднимутся" ли ссылки?
А если ссылки вдруг Wink все же поднимутся, то экспортируйте эти файлы опять из системы, и снова проверьте, работают ли внешние ссылки в экспортированных файлах. В большинстве случаев (за исключением совсем простых) ситуация бывает крайне забавной.
Ух. Попали в точку. Давайте разберем "по косточкам".
С абсолютными путями бороться можно только одним способом - предоставлять их ;) К счастью, "плохих" приложений все же существенно меньше, чем "правильных", которые корректно работают с относительными путями. Есть, конечно, и "клинические" случаи. Например, одна из версий Solid Edge просто падала, когда ей через API резали пути до относительных :x

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

Подъем готовых сцепленных документов не получится. Любо их нужно будет "присоединить", сохранив пути выгрузки (или просто сославшись на них), либо руками переприцепить. Но сделать это придется только один раз. Далее, при выгрузке, если приложение корректно разруливает относительные пути никаких проблем быть не должно. Хотя, конечно, это все лежит на совести разработчиков конкретных приложений.
К сожалению, чтобы полнотекстовый поиск в БД также работал хорошо (а именно, поддерживал корректный поиск документов на русском языке в форматах файлов более сложных чем TXT и HTML), тоже приходится докупать опциональные расширения.
Так что если хочется нормальный полнотекстовый индексатор - за него все равно нужно платить.
SQL Server работает с офисными документами, Oracle поддерживает весьма внушительное число текстовых форматов. Недостаток встроенных средств в отсутствии разбора национальных словоформ и семантики. Но зная эти компании, рискну предположить, что очень скоро появятся подобные встроенные средства.
Миграция для отдельных документов - вещь хорошая. Но вот реально она мало где используется (по моему опыту работы еще в середине 90-х годов прошлого века с DOCS Open, имевшим этот сервис, заказчики им практически не пользовались).
Тем более, сейчас многие системы массового хранения имеют свое собственное ПО для миграции документов.
Чаще все же встречается случай, когда нужно переместить целый проект (например, по его завершении). И это решается легко.
Все что нужно практически любой нормальной системе - это чтобы ресурс (устройство хранения) был виден.
Мой личный подход предельно прагматичен: если есть стандартное решение, которое работает, то не нужно изобретать велосипед.
Так что наличие средств миграции - это хорошо, но IMHO, не главное.
Я придерживаюсь практически такой же точки зрения. Кесарю кесарево. Хотя вопросы расширенной поддержки миграции обсуждаются постоянно.
Аватара пользователя
Alxd
Активный участник
Сообщения: 50
Зарегистрирован: 15 июл 2004, 12:42
Откуда: Тюмень
Контактная информация:

Сообщение Alxd »

Вы чрезвычайно эмоциональный человек
Есть немного. Точнее, просто настроение такое было :)
Если бы вы к каждой цифре приписали бы 0, я бы сказал "Прилично!"
Я не сказал, что это много. Наоборот, хорошо, что мало. Но сложите объем файлов с объемом базы и становится ясно, что размер базы данных стал "неслабым". И я напираю именно на то, что такой объем данных в память серверу не пихнуть (воздержитесь от upgrade сервера, платить за это начальство не любит), значит операции с данными будут _дисковыми_. Они самые медленные. HDD до сих пор как "бутылочное горлышко" в системе.

И еще, раз уж коснулись размера базы данных. Не знаю как в TDMS (возможно, Вы осветите), но в Lotsia PDM Plus удачно продумана система хранения значений атрибутов. Они не дублируются!!! А следовательно, размер базы данных плавно будет стремиться к горизонтальной линии (если чертить график). Удачно!
Я с трудом представляю себе, как [временно] потеряв объектную информацию (включая права доступа), вы восстановите доступ к файлам (по сути, раздадите пользователям права на них "в течение часа"). Возможно, Lotsia PDM Plus и обладает такой возможностью.
Lotsia PDM Plus не обладает, но файловый сервер позволит админу открыть права на файлы. А пользователи уже "насабачились" и знают файлы по именам.
Вы указали на возможность кэширования файлов на рабочих станциях пользователей, но забыли одну особенность. При работе в команде, по крайней мере у нас, используется "параллельное проектирование". Т.е. специалисты "видят" и используют файлы смежных отделов, которые храняться на сервере. И при попытке работать с кэшированными данными (в терминах Lotsia PDM Plus - захваченные файлы) возникнут проблемы.
У нас в организации ВООБЩЕ не используется захват (кэширование). Все файлы открыты прямо с сервера.
SQL Server работает с офисными документами, Oracle поддерживает весьма внушительное число текстовых форматов.
Позиция все время "ждать у моря погоды". Надеяться и ждать можно, но лучше уже сейчас иметь использовать то, что так необходимо. Работаем ведь мы уже сейчас, а не когда-то в будущем.
У нас, например, контекстный поиск уже сделан собственными силами. Просто и элегантно. А так и не дождемся...
Dmitry V. Liseev
Новый участник
Сообщения: 4
Зарегистрирован: 15 авг 2005, 17:07

Сообщение Dmitry V. Liseev »

Я являюсь разработчиком конкурирующей PDM системы (не будем уточнять, чтобы избежать обвинений в рекламе), потому поделюсь некоторыми техническими соображениями:

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

Я пришел к выводу, что есть 3 архитектуры:
1. Хранение файлов в самой СУБД в виде BLOB.
2. Хранение файлов на расшаренном сетевом ресурсе средствами файловой системы.
3. Хранение файлов средствами файловой системы, но под
управлением отдельного специализированного файлового сервиса.

Аргумент "что, если СУБД грохнется и в варианте 1 потеряются все файлы" уравновешивается аргументом "что, если файловый сервер грохнется и в вариантах 2 и 3 тоже все файлы потеряются". Понятно, что данные надо резервировать в любом случае.
Alxd писал(а):
у нас размер базы данных 700Мб + размер каталога с файлами 9500Мб
У моих заказчиков типична такая ситуация: размер метаданных 500Мб, размер сжатых (примерно вдвое) файлов 100Гб, всего примерно 200 тыс. файлов. Одновременно с системой работают 50 человек. Понятно, что при таких объемах резервное копирование уже может стать проблемой по причине пропускной способности этих устройств. У нас резервирование выполняется без остановки сервера. Восстановление сотни гигов из бекапа - это многие часы. Для варианта 1 есть стандартное решение - резервный сервер, который читает журналы транзакций основного сервера и имеет копию всей базы. Сервера связаны собственной сетью и своими сетевыми картами, потому такой трафик не нагружает основную сеть. Если основной сервер падает, нужно только переконфигурировать сервера приложений, чтобы они работали с резервным сервером. Это всего несколько минут. Для варианта 2 такого простого решения нет. Для варианта 3 репликацию в принципе можно реализовать. Например, писать на DVD в фоновом режиме. Тогда восстановление из бекапа заключается только в том, чтобы вставить этот DVD в устройство на другом файловом сервере. Но в любом случае (для вариантов 2 и 3) _синхронное_ резервирование сервера СУБД и файлового сервера (особенно, если их несколько) требует разработки отдельной софтины и дополнительных напрягов от администратора. Так что вариант 1 "все в одном" сильно проще с точки зрения резервирования.

Понятно, что когда метаданные составляют всего полпроцента общих размеров базы, хранить файлы под управлением СУБД (вариант 1) не имеет смысла. Файлы не нужно кэшировать, строить по ним индексы, им не нужны полноценные транзакции. То есть ресурсы сервера СУБД для файлов просто не нужны. Если предположить, что файлы никогда не меняются, а только создаются целиком или удаляются целиком (нет UPDATE, есть только INSERT и DELETE), то достаточно сначала поместить один или несколько файлов на сервер (не запуская транзакцию), а затем стартовать транзакцию в СУБД и сообщить, что файлы с такими идентификаторами уже помещены, потом ее зафиксировать. Если транзакция откатилась, то СУБД просто не будет знать, что файл физически существует на сервере. Будет "потерянное" тело файла, впустую занимающее место. При удалении файла также сообщаем серверу СУБД (в транзакции), что файлы с такими идентификаторами удаляем. Само тело файла не трогаем. Оно станет "потерянным". В итоге получим короткие транзакции, которые работают только с метаданными, не "проворачивая" мегабайты контента. Остается только создать некий низкоприоритетный фоновый процесс, который будет физически удалять "потерянные" тела файлов. Эту "оптимизацию транзакций" (по сравнению с вариантом 1) можно полноценно реализовать в варианте 3. В варианте 2 о транзакциях вообще речь не идет.
Alxd писал(а):
У нас в организации ВООБЩЕ не используется захват (кэширование). Все файлы открыты прямо с сервера.
Соответственно, я так понимаю, используется вариант 2. То есть ни о "полноценных" ни об "оптимизированных" транзакциях речь не идет. Представим, что при попытке сохранения (обновления) файла прямо на сервера приложение упало. Не останется ни старого файла, ни нового. А это гораздо более вероятная (я бы сказал ежедневная) ситуация, чем "упал сервер СУБД". Кроме того, даже если файл успешно перезаписан, рано или поздно кому-то понадобится предыдущая версия этого файла. Как с этим дела в Вашей организации? Ведь "захват" - это не только кэширование, это еще и процедура check-in/check-out, которая обычно предусматривает сохранение еще и предыдущих версий изменяемого файла.

Теперь о сетевом трафике. Если в вариантах 1 и 3 можно сжимать файлы на клиенте и передавать их по сети (и хранить на сервере) в сжатом виде (в среднем вдвое). То это вдвое быстрее варианта 2, когда приложения напрямую лезут за файлами на шареный ресурс. Мы этот эффект сразу демонстрируем заказчикам, когда они не верят, что загрузить в САПР сложную сборку из сотен файлов в нашей системе они смогут сильно быстрее, чем просто с сетевого диска.
Alxd писал(а):
Практика показывает, что это в большинстве случаев не так. Даже в варианте 1, когда файлы храняться в BLOB и "прокачиваются" через журналы транзакций, "бутылочным горлышком" оказывается сеть. Да и поставить на сервер быстрые диски сильно дешевле, чем всю сетевую инфраструктуру заапгрейдить. Ситуация усугубляется тем, что очень часто отделы территориально разделены и их подсетки связаны с центральными серверами по выделенной линии далеко не 100 мегабитной полосы пропускания. Вариант 2 тут вообще неработоспособен. Варианты 1 и 3 могут хоть кешировать файлы на клиенте. Вариант 3 допускает установку своего файлового сервера для каждой рабочей группы, что сильно рулит, если пользователи преимущественно обращаются к файлам своего локального сервера. А по ночам можно пускать взаимную репликацию между файловыми серверами.
Аватара пользователя
Alxd
Активный участник
Сообщения: 50
Зарегистрирован: 15 июл 2004, 12:42
Откуда: Тюмень
Контактная информация:

Сообщение Alxd »

Представим, что при попытке сохранения (обновления) файла прямо на сервера приложение упало. Не останется ни старого файла, ни нового. А это гораздо более вероятная (я бы сказал ежедневная) ситуация, чем "упал сервер СУБД". Кроме того, даже если файл успешно перезаписан, рано или поздно кому-то понадобится предыдущая версия этого файла. Как с этим дела в Вашей организации?
Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов. А в случае с "падением", Novell NetWare обладает стековым механизмом хранения удаленных файлов. Поэтому перед открытием файла сохраняется его копия. В отношении Windows 2003 есть теневые копии. Тоже отличная вещица, но я ее пока не использую.
"бутылочным горлышком" оказывается сеть
полностью согласен. Это даже первое бутылочное горлышко!
McZag
Новый участник
Сообщения: 6
Зарегистрирован: 02 авг 2005, 13:12

Сообщение McZag »

Пока я странствовал по просторам нашей необъястной Родины, пришел дядька Лисеев, и расстрелял почти все аргументы, которые были "за пазухой" :D

Самый главный из них - загрузка сети файловым траффиком. Если удается снизить его хотя бы вдвое, то производительность системы вырастает примерно на 50-90 процентов. Достигается такой эффект, как правильно указал Дмитрий, двумя способами - сжатие данных (файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты), и кэширование (либо только на чтение, если файл хранится в СУБД, либо и на чтение/запись, если файл размещается на локальном файловом сервере).
Dmitry V. Liseev
Новый участник
Сообщения: 4
Зарегистрирован: 15 авг 2005, 17:07

Сообщение Dmitry V. Liseev »

Alxd писал(а):Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов.
Это какие организационные процедуры? Вот загружает человек в САПР из PDM сложную конструкцию из сотен файлов. Вносит изменения в несколько файлов. Сохраняет в PDM. Тут кому-то нужна прежняя редакция _всей конструкции_, поскольку по этой документации уже была выпущена продукция. Я так понимаю, человек видит на экране список версий головной сборки. Ткнул в любую, сказал "открыть", и получил всю конструкцию из сотен файлов в первоначальном виде (до внесения изменений). Или вдруг выяснил, что в одну из деталей этой конструкции были неудачно внесены изменения, тогда он просто указывает, что в конструкции должна быть использована не последняя версия этой детали, а одна из предыдущих. Кроме того, есть на практике такая штука (не регламентированная ГОСТами), как альтернативные варианты конструкции. Когда независимыми проектировщиками делаются несколько вариантов одного документа с одним обозначением, а потом выбирают лучший. Далеко не каждая PDM система поддерживает такое ветвление (branches) для документа. Как показывает практика, очень часто человек даже не задумывается, в какой именно файл он вносит изменения. Он видит на экране конструкцию, решает изменить размер некого кронштейна, поскольку САПР полностью ассоциативная, автоматически пересчитываются сотни размеров других деталей, выскакивает сообщение, что нужно взять на редактирование (check-out) следующие документы (и вываливается список на полторы сотни), человек просто щелкает по кнопке OK, автоматом делается захват и внесение изменений в сотни документы, на которые повлияло изменение размера этого кронштейна.

Этим отличается инженерный документооборот от обычного офисного. В современной САПР одним поворотом мышки можно внести изменения в сотни различных взаимосвязанных файлов. И при просмотре прежних редакций любого файла нужны прежние редакции соответствующих взаимосвязанных файлов.
McZag писал(а):файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты
Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска. Если файл в основном состоит из текста и содержит мало нетекстовых данных (крайний вариант - TXT, который состоит только из текста), то действительно, сжатие тут бесполезно, ибо для поиска нужны сложные индексы, а индекс по данным обычно сильно больше самих данных. Но в PDM обычно используются файлы САПР, которые содержат очень мало текста по сравнению с бинарной информацией. Тогда текст (основная надпись чертежа и другие атрибуты) извлекается из файла, отправляется в СУБД, где индексируется, а сам файл сжимается и отправляется в файловое хранилище. Больше он системе не нужен. Пользователь может выполнять поиск по этим атрибутам и даже менять их (в СУБД, но не в файле). Например, часто удобнее сначала занести в PDM сложную сборку, а уже потом задавать обозначения и заполнять основные надписи. При извлечении файла из PDM все происходит в обратном порядке: файл вытаскивается, расжимается, из СУБД извлекается вся его текстовая часть и помещается обратно в файл. То есть работает и сжатие и поиск.

Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег, а выхлоп от нее нулевой если 95% хранящихся документов (CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС) этой системой не поддерживаются.
Dmitry V. Liseev
Новый участник
Сообщения: 4
Зарегистрирован: 15 авг 2005, 17:07

Сообщение Dmitry V. Liseev »

Alxd писал(а):Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов.
Это какие организационные процедуры? Вот загружает человек в САПР из PDM сложную конструкцию из сотен файлов. Вносит изменения в несколько файлов. Сохраняет в PDM. Тут кому-то нужна прежняя редакция _всей конструкции_, поскольку по этой документации уже была выпущена продукция. Я так понимаю, человек видит на экране список версий головной сборки. Ткнул в любую, сказал "открыть", и получил всю конструкцию из сотен файлов в первоначальном виде (до внесения изменений). Или вдруг выяснил, что в одну из деталей этой конструкции были неудачно внесены изменения, тогда он просто указывает, что в конструкции должна быть использована не последняя версия этой детали, а одна из предыдущих. Кроме того, есть на практике такая штука (не регламентированная ГОСТами), как альтернативные варианты конструкции. Когда независимыми проектировщиками делаются несколько вариантов одного документа с одним обозначением, а потом выбирают лучший. Далеко не каждая PDM система поддерживает такое ветвление (branches) для документа. Как показывает практика, очень часто человек даже не задумывается, в какой именно файл он вносит изменения. Он видит на экране конструкцию, решает изменить размер некого кронштейна, поскольку САПР полностью ассоциативная, автоматически пересчитываются сотни размеров других деталей, выскакивает сообщение, что нужно взять на редактирование (check-out) следующие документы (и вываливается список на полторы сотни), человек просто щелкает по кнопке OK, автоматом делается захват и внесение изменений в сотни документы, на которые повлияло изменение размера этого кронштейна.

Этим отличается инженерный документооборот от обычного офисного. В современной САПР одним поворотом мышки можно внести изменения в сотни различных взаимосвязанных файлов. И при просмотре прежних редакций любого файла нужны прежние редакции соответствующих взаимосвязанных файлов.
McZag писал(а):файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты
Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска. Если файл в основном состоит из текста и содержит мало нетекстовых данных (крайний вариант - TXT, который состоит только из текста), то действительно, сжатие тут бесполезно, ибо для поиска нужны сложные индексы, а индекс по данным обычно сильно больше самих данных. Но в PDM обычно используются файлы САПР, которые содержат очень мало текста по сравнению с бинарной информацией. Тогда текст (основная надпись чертежа и другие атрибуты) извлекается из файла, отправляется в СУБД, где индексируется, а сам файл сжимается и отправляется в файловое хранилище. Больше он системе не нужен. Пользователь может выполнять поиск по этим атрибутам и даже менять их (в СУБД, но не в файле). Например, часто удобнее сначала занести в PDM сложную сборку, а уже потом задавать обозначения и заполнять основные надписи. При извлечении файла из PDM все происходит в обратном порядке: файл вытаскивается, расжимается, из СУБД извлекается вся его текстовая часть и помещается обратно в файл. То есть работает и сжатие и поиск.

Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег, а выхлоп от нее нулевой если 95% хранящихся документов (CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС) этой системой не поддерживаются.
McZag
Новый участник
Сообщения: 6
Зарегистрирован: 02 авг 2005, 13:12

Сообщение McZag »

Dmitry V. Liseev
Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска.
Что-то вы страсти какие-то рассказываете. Кто (какая программа) должна заниматься экстрагированием текста из документа? Исполняемые файлы тоже содержат много текста. Их тоже будем индексировать?

То о чем вы говорите относится к средствам автоматизации конкретного приложения (и не всегда, кстати, возможно). И вырезаете вы не текстовые данные для полнотекстового поиска, а отдельные атрибуты, которые помещаются на "карточку" информационного объекта. Поиск по значениям атрибутов идет стандартными средствами СУБД, через операторы инструкции WHERE. А поиск по подстроке в строковых типах данных с использованием оператора LIKE вообще не индексирован.

Полнотекстовый поиск производится по контенту файлов определенного формата и требует включения соответсвующей службы СУБД. БОльшая часть типов файлов, используемая приложениями САПР, не входит в число индексируемых. Т.е. попросту кладется в хранилище как есть, без создания индексов. Но утверждать, что выхлоп от системы полнотекстового поиска нулевой, я бы не стал. Любое изделие (объект проектирования) содержит большие объемы текстовых документов. Для них и предназначен полнотекстовый поиск.
Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег
Не совсем так. Конретных денег стоят сами системы. А средства полнотекствого поиска в них "бесплатны". Например, SQL Server Standard Ed уже содержит средства полнотекстового поиска. За деньги нужно приобретать встраиваемые в СУБД модули сторонних производителей, которые обладают бОльшими возможностями по сравнению с базовыми средствами.

Alxd
И еще, раз уж коснулись размера базы данных. Не знаю как в TDMS (возможно, Вы осветите), но в Lotsia PDM Plus удачно продумана система хранения значений атрибутов. Они не дублируются!!! А следовательно, размер базы данных плавно будет стремиться к горизонтальной линии (если чертить график). Удачно!
Честно говоря, я не понял вашей мысли. Если вы о наследовании (т.е. о некоторых особенностях реализации отношений часть-целое), то это базовый функционал многих PDM систем. Если о том, что PDM системы легко обращаются со ссылочной информацией (т.н. "заимствование"), то это тоже базовый функционал :) Если вы имеете ввиду что-то уникальное и свойственное только Lotsia PDM, поделитесь, будет очень интересно.

Размер всех баз данных стремится к какой-то горизонтальной линии. Вопрос только под каким углом ;)
Dmitry V. Liseev
Новый участник
Сообщения: 4
Зарегистрирован: 15 авг 2005, 17:07

Сообщение Dmitry V. Liseev »

McZag писал(а):Что-то вы страсти какие-то рассказываете. Кто (какая программа) должна заниматься экстрагированием текста из документа? Исполняемые файлы тоже содержат много текста. Их тоже будем индексировать?
Этим должен заниматься модуль интеграции PDM системы с конкретной САПР или другим приложением. Например, модуль интеграции с MS Office работает с файлами ворда, экселя и т.д.
McZag писал(а):И вырезаете вы не текстовые данные для полнотекстового поиска, а отдельные атрибуты, которые помещаются на "карточку" информационного объекта.
Зависит от реализации. Текстовые данные представляем в виде XML и кладем в СУБД, где они прекрасно индексируются.
McZag писал(а):Поиск по значениям атрибутов идет стандартными средствами СУБД, через операторы инструкции WHERE. А поиск по подстроке в строковых типах данных с использованием оператора LIKE вообще не индексирован.
Вообще-то СУБД сильно разные бывают. Если ваша СУБД чего-то не умеет, то это не говорит о том, что СУБД конкурентов этого тоже не умеет. Поиск по подстрокам бывает индексированным. Правда, индекс достаточно большой размер имеет.
McZag писал(а):Полнотекстовый поиск производится по контенту файлов определенного формата и требует включения соответсвующей службы СУБД.
СУБД сильно разные бывают. У меня алгоритмов полнотекстового поиска - как грязи. В исходниках для моей СУБД. Нашел в Интернете. Конечно, без учета семантики и морфологии, но найти документы со словами "завальцевать" и "ТУ 88???-76*" на поле чертежа оно может.
McZag писал(а):БОльшая часть типов файлов, используемая приложениями САПР, не входит в число индексируемых.
И нахрена такое заказчику?
McZag писал(а):Любое изделие (объект проектирования) содержит большие объемы текстовых документов. Для них и предназначен полнотекстовый поиск.
Статистика по некоторым головным предприятиям минобороны (моим заказчикам), как я говорил, показывает: 95% хранящихся документов имеют формат CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС. Текстовые данные там на полях чертежей и в моделях. Впрочем, заказчики у всех разные.
McZag писал(а):За деньги нужно приобретать встраиваемые в СУБД модули сторонних производителей, которые обладают бОльшими возможностями по сравнению с базовыми средствами.
Не достаточно большими возможностями, чтобы это устраивало моих заказчиков. Все равно пришлось самому делать.
Последний раз редактировалось Dmitry V. Liseev 25 авг 2005, 21:26, всего редактировалось 1 раз.
Николай Ширяев
Участник
Сообщения: 40
Зарегистрирован: 25 июн 2004, 14:06
Откуда: Лоция

Сообщение Николай Ширяев »

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

Для начала позвольте сделать несколько предложений.
1. Если нет возражений, то я попрошу администратора выделить это обсуждение в отдельную тему.
2. Я попросил бы все же воздержаться от скрытой рекламы, иначе администратор форума нас всех разгонит (он у нас товариСЧ резкий, может и "молча" эккаутны наши поудалять). Рекламировать свои системы давайте на собственных ресурсах. ;)
К тому же, не знаю как других, но лично меня от рекламы во всех ее проявлениях уже просто тошнит. Поэтому, пожалуйста, давайте не будем сравнивать, чья СУБД круче.
3. Есть давняя задумка создать отдельный ресурс для обсуждения систем PDM (PLM или называйте еще как угодно), где можно было бы всласть поругаться на конкурентов. :)
Задумка это абсолютно частная, но реализация ("на коленке") уже почти готова. Через пару недель, надеюсь, можно будет ее запустить. Если у Вас будет желание, то я бы предложил все обсуждения такого рода перенести на этот ресурс. Уж там-то я сам смогу всласть поругаться, без всякой "политкорректности". :)

Вот, вроде бы все по общей части.
=======================================================
А теперь разрешите сделать несколько комментариев по теме обсуждения (все IMHO).

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

Ну, как я понял, по вопросу производительности мы остались каждый при своем мнении. :) Но это не страшно, практика все поставит на свои места. (Кстати, если уж мы говорим об объемах баз и количестве пользователей, то у нас довольно много клиентов, имеющих от нескольких сотен до нескольких тысяч одновременно работающих пользователей; а базы по >10 миллионов записей уже давно не редкость.)
Только хотел бы обратить Ваше внимание, что много говорилось о времени чтения, но почти ничего о времени записи при изменении данных. Наверное, правильнее все же оценивать интегральную производительность.

По поддержке разных конфигураций.
Разумеется, необходимо, чтобы система поддерживала как исполнения по ЕСКД, так варианты, и версии документов. Без этого невозможно управлять конфигурациями. И такой функционал есть практически во всех нормальных системах (отличия только в реализации).
И точно так же поддерживаются ссылки на разные версии объектов (Item Revision), документов и т.п. Но вот с утверждением уважаемого Дмитрия о том, что "автоматом делается захват и внесение изменений в сотни документы" я бы все же не согласился. Автоматический захват (блокировка) -- это да, но вот автоматическое изменение далеко не всегда есть хорошо (кстати, я плохо себе представляю, как это можно реализовать для проекта, в котором используются несколько разных САПР). Другое дело, если права на изменение есть -- пользователь может изменять файл, но не "автоматически".

По поводу полнотекстового поиска.
Вещь это хорошая, но, как показывает мой опыт, используется пользователями далеко не всегда (причем, что для меня удивительно, если даже соответствующий модуль куплен!). И для нормального полнотекстового поиска все же нужно покупать специализированные модули.

Уважаемый Сергей,
на рынке действительно есть решения, позволяющие дергать текстовые поля из файлов популярных форматов САПР (AutoCAD, etc.) для последующего их индексирования.
Но вот форматы отечественных САПР эти средства не понимают. :(

Уважаемый Дмитрий,
относительно использования модулей полнотекстового поиска собственной разработки: мне этот путь все же представляется тупиковым.
Меняется формат файлов приложения, -- значит, каждый раз нужно дорабатывать модуль. Конкурировать со специализированными системами будет очень тяжело.
Кстати, не сочтите за подколку, но чего именно не хватило Вашим клиентам, к примеру, в продуктах Verity, Hummingbird или Convera (если абстрагироваться от цены)?

Еще раз прошу прощения, скорее всего, оперативно отвечать в ближайшие пару недель не смогу. :(
Не сочтите за неуважение.
С уважением, Николай Ширяев
Ответить