Дискуссия о разных подходах в построении систем 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.
Так что единственный реальный плюс хранения документов (файлов) в СУБД -- это бОльшая простота реализации системы для разработчиков, особенно в части управления правами доступа. (Если хранить документы на файл-серверах, то для каждого типа серверной ОС и файловой системы нужно писать свой модуль защиты данных, что более трудоемко.)
И практика это подтверждает: сейчас фактически практически все лидирующие на мировом рынке системы используют принцип раздельного размещения базы данных и собственно файлов.
И те отечественные разработчики, которые изначально использовали схему хранения документов в базе данных, в дальнейшем (по мере роста объема информации у пользователей их систем) были вынуждены из-за указанных выше проблем перейти на хранение документов на файл-серверах.
Но Вы, разумеется, вправе выбирать ту стратегию при разработке своего ПО, которую считаете наиболее правильной.
Кстати, если Вас не затруднит, передайте, пожалуйста, от меня привет и наилучшие пожелания Илье Лебедеву.
Желаю Вам всяческих успехов!
Выделено из другой темы
[Moderation Mode OFF]
Уважаемый McZag,
насколько я понимаю, Вы представляете фирму CSoft.
Раз уж Вы упомянули Lotsia PDM PLUS, то позвольте сделать небольшое разъяснение (разумеется, абсолютно субъективное, и не претендующее на истину в последней инстанции).
При создании системы Lotsia PDM PLUS мы сознательно не использовали схему хранения документов в базе данных, хоть это и было бы проще с точки зрения программирования.
Мы очень хорошо представляем себе все плюсы и минусы такого решения.
И мы считаем хранение документов в базе неоптимальным по следующим причинам:
- быстрый рост объема базы данных вызывает необходимость использования более мощного (следовательно, -- более дорогого) сервера и катастрофическое снижение производительности при работе с большими объемами документов;
- при сбое базы данных возможна потеря всех документов сразу;
- сложнее организовать хранение компонентных документов;
- ограничение только схемой хранения on-line.
Но, я полагаю, что Вы и сами все это прекрасно знаете.
Упомянутые Вами плюсы хранения файлов в базе данных спорны. (Вообще, как писал выше Alxd, ту же NTFS можно рассматривать в качестве файловой базы данных.)
Безопасность хранения файлов в базе данных ничуть не выше, чем при хранении на защищенном файловом сервере (тут все зависит от конкретной реализации защиты). А в ряде случаев -- даже ниже (например, при работе всех пользователей с базой через одно подключение с административными правами, о чем некоторые наши разработчики умалчивают).
Централизованное резервное копирование применительно к хранению файлов в БД в ряде случаев (но не всегда) также менее удобно (не все средства резервного копирования позволяют работать с открытой базой, а останавливать ее не всегда удобно; не все СУБД хранят всю базу в одном файле; да и сама процедура восстановления базы из бэкапа не всегда легка и прозрачна). А существующие сейчас средства резервного копирования часто позволяют гораздо лучше обеспечить процесс резервного копирования файлов.
Полнотекстовый поиск средствами СУБД -- вещь хорошая, но для нормального мультиформатного поиска по русскоязычным документам все же предпочтительнее использовать специализированные средства полнотекстового поиска типа Verity.
Так что единственный реальный плюс хранения документов (файлов) в СУБД -- это бОльшая простота реализации системы для разработчиков, особенно в части управления правами доступа. (Если хранить документы на файл-серверах, то для каждого типа серверной ОС и файловой системы нужно писать свой модуль защиты данных, что более трудоемко.)
И практика это подтверждает: сейчас фактически практически все лидирующие на мировом рынке системы используют принцип раздельного размещения базы данных и собственно файлов.
И те отечественные разработчики, которые изначально использовали схему хранения документов в базе данных, в дальнейшем (по мере роста объема информации у пользователей их систем) были вынуждены из-за указанных выше проблем перейти на хранение документов на файл-серверах.
Но Вы, разумеется, вправе выбирать ту стратегию при разработке своего ПО, которую считаете наиболее правильной.
Кстати, если Вас не затруднит, передайте, пожалуйста, от меня привет и наилучшие пожелания Илье Лебедеву.
Желаю Вам всяческих успехов!
С уважением, Николай Ширяев
Рад, что Вы, Николай, откликнулись
Я действительно представляю компанию CSoft, но предлагаю рассматривать наше обсуждение как чисто теоретическое, без привязки к TDMS или Lotsia PDM PLUS. Возможно, в таком ключе диспут будет полезен обоим компаниям-разработчикам.
Как Вы верно заметили, при выборе модели хранения больших бинарных и текстовых данных, компания-разработчик информационной системы стоит перед выбором "как это сделать". И если разработчики подходят к этому вопросу достаточно ответственно (а, imo, это один из ключевых вопросов построения системы, оперирующей с файлами), то аргумент "это проще в реализации" не может восприниматься всерьез при постановке ТЗ. Вы утверждаете, что реализация хранения в СУБД проще, хотя немного противоречите сами себе, приводя контраргумент о поддержки связанных документов в разных моделях. За сим, я могу с такой же легкостью перевернуть ситуацию и сказать, что реализация хранения файлов в файловой системе проще, чем реализация любыми другими способами
, особенно, если в качестве отправной точки выбрать конкретную файловую систему конкретной операционной системы.
Поэтому, предлагаю обсудить этот вопрос с позиций "а что действительно удобнее, быстрее, надежнее etc." без привязки к конкретной системе и пути ее развития и "стоимости" того или иного решения.
Скажу сразу, что я являюсь сторонником гибридного хранения файлов. Т.е. модель хранения должна быть выбрана администратором системы в зависимости от ряда параметров: территориальное расположение, типы файлов, их объем, типы используемых накопителей и т.д. Поэтому ниже нижеследующие реплики в защиту хранения файлов в СУБД следует рассматривать как "и так тоже можно", но не более того.
Вы приводите несколько аргументов против модели хранения файловых данных в СУБД. Я дам свои комментарии:
Относительно безопасности и резервного копирования Вы меня никогда не переубедите. Поэтому мы можем "расстаться" по этим вопросам каждый при своем. Основная проблема в безопасности и надежности не железо и не наличие соответствующего сертификата, а человеческий фактор. Чем больше людей задействовано в администрировании, чем более разнообразные задачи они решаю, тем больше потенциальных проблем. Перенеся всю тяжесть проблем на (двух?) администраторов СУБД вы максимально исключаете человеческий фактор.
Полнотекстовый поиск сторонними средствами вещь хорошая. Но не бесплатная
К тому же бОльшая часть этих средств легко встраивается в СУБД
Мы с Вами не затронули вопрос управления физическими устройствами. Хотелось бы узнать Вашу точку зрения на этот счет.
С удовольствием передам привет Илье Лебедеву.
Жду Вашего ответа. С уважением, Сергей Загурский[/quote]
Я действительно представляю компанию CSoft, но предлагаю рассматривать наше обсуждение как чисто теоретическое, без привязки к TDMS или Lotsia PDM PLUS. Возможно, в таком ключе диспут будет полезен обоим компаниям-разработчикам.
Как Вы верно заметили, при выборе модели хранения больших бинарных и текстовых данных, компания-разработчик информационной системы стоит перед выбором "как это сделать". И если разработчики подходят к этому вопросу достаточно ответственно (а, imo, это один из ключевых вопросов построения системы, оперирующей с файлами), то аргумент "это проще в реализации" не может восприниматься всерьез при постановке ТЗ. Вы утверждаете, что реализация хранения в СУБД проще, хотя немного противоречите сами себе, приводя контраргумент о поддержки связанных документов в разных моделях. За сим, я могу с такой же легкостью перевернуть ситуацию и сказать, что реализация хранения файлов в файловой системе проще, чем реализация любыми другими способами

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

Я не располагаю такой информацией. Если у Вас есть реальные примеры отказа хранения файлов в СУБД в системах с мировым именем, буду рад услышать "их имена". Впрочем, ничего удивительного в этом нет. Файловый сервер, работающий как отдельный сетевой сервис, не привязанный к ОС и обладающий сопряженными с информационной системой средствами администрирования, всегда будет эффективнее чем СУБД.сейчас фактически практически все лидирующие на мировом рынке системы используют принцип раздельного размещения базы данных и собственно файлов.
Мы с Вами не затронули вопрос управления физическими устройствами. Хотелось бы узнать Вашу точку зрения на этот счет.
С удовольствием передам привет Илье Лебедеву.
Жду Вашего ответа. С уважением, Сергей Загурский[/quote]
- Alxd
- Активный участник
- Сообщения: 50
- Зарегистрирован: 15 июл 2004, 12:42
- Откуда: Тюмень
- Контактная информация:
Как человек наглый
я таки вклинюсь в диалог.
Представьте себе, что все эти файлы оказались бы в базе данных!!! Мало того, что файловая система NTFS уступает NFS в скорости, так еще и размер базы был бы гигантским, что мешало поиску данных на диске! А так, при размере RAM в 2Гб можно смело предположить, что данные по базе данных ищутся именно в памяти, а не на диске. Дисковые операции самые медленные!!!
Вопрос в процедуре восстановления данных и возврата пользователей к работе. В случае с хранением данных в файловой системе достаточно открыть пользователям доступ к файлам и выдать имена файлов из базы. Это реально сделать в течении часа!
А если файлы в базе, их надо будет еще извлечь до момента восстановления самой информации к ним!!! Простите, но это намного сложнее.
Тот же AutoCAD должен подключить внешнюю ссылку информация о которой хранится в базе данных. Ему нужен конкретный файл. Значит его надо предоставить. Как?
В Lotsia PDM Plus - просто открыть права. В TDMS файл придется извлечь и корректно сохранить!!! (Отходя в сторону, отпадает даже операция захвата файлов.)

Если файлы хранятся в БД, то соответственно файл базы данных растет непомерно. Могу привести пример. За два года эксплуатации 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 читают этот форум. Я пишу это без иронии.

А если скатимся совсем в оф-топик, или появится скрытая реклама, то Злобный Модератор форума нас быстро приструнит.
А в общем случае реализовать защиту при хранении документов в файловой системе сложнее, чем при хранении в БД.

В моем идеале система должна быть простой и безотказной как автомат Калашникова.
Я писал именно про быстрый рост объема базы данных, а не просто данных.
Но, как Вы понимаете, что чем больше размер базы данных, тем больше вероятность работы именно с использованием дисковых накопителей, а не ОЗУ. Так что я выступаю за максимально компактную базу данных.

Я просто пытался обосновать логику нашего подхода.
сбой базы случается все же значительно чаще, чем извержение супервулкана.
Но Вы же знаете, в какой стране мы живем...
Помимо тех резонов, что привел выше уважаемый Alxd, есть еще и другие.
Например, ряд приложений любят хранить полные абсолютные пути. А другие приложения любят "молча" сбрасывать дополнительные файлы (типа сечений и т.п.) в текущий каталог. И этот перечень "особенностей отдельных приложений" можно продолжать.
Также есть другая интересная задача: попробуйте импортировать в БД файлы со ссылками друг на друга, ранее хранившиеся на пусть даже сетевом ресурсе, и открыть их после импорта. "Поднимутся" ли ссылки?
А если ссылки вдруг
все же поднимутся, то экспортируйте эти файлы опять из системы, и снова проверьте, работают ли внешние ссылки в экспортированных файлах. В большинстве случаев (за исключением совсем простых) ситуация бывает крайне забавной.


Но обычно даже двумя администраторами обойтись не получается (для крупных проектов): кто-то же еще должен вести справочники, классификаторы и т.п.
Так что если хочется нормальный полнотекстовый индексатор - за него все равно нужно платить.
Схема "Database - Vault" сейчас стала практически стандартной.
Я писал:
Да и Ваша компания наверняка не просто так свой файловый сервер разрабатывала.
Но что касается отсутствия привязки сервиса защиты документов к ОС, есть у меня все же некие сомнения.
Уж больно разные механизмы используются, к примеру, в сетях под Windows и Novell NetWare. Так что есть сомнения в "полном счастье, для всех и сразу".
Тем более, сейчас многие системы массового хранения имеют свое собственное ПО для миграции документов.
Чаще все же встречается случай, когда нужно переместить целый проект (например, по его завершении). И это решается легко.
Все что нужно практически любой нормальной системе - это чтобы ресурс (устройство хранения) был виден.
Мой личный подход предельно прагматичен: если есть стандартное решение, которое работает, то не нужно изобретать велосипед.
Так что наличие средств миграции - это хорошо, но IMHO, не главное.
Вот примерно так; извиняюсь что коротко.
Прошу прощения, если мои высказывания не очень "научны" или расходятся с Вашими представлениями об идеальной системе - мой подход "не шашечки, а ехать", и от высокой теории я очень далек. Для этого у нас специально обученные люди есть.
Желаю удачи!
Мне очень приятно, что такие серьезные представители компании CSoft читают этот форум. Я пишу это без иронии.
Давайте попробуем, но активного диалога не обещаю (банально не хватает времени).McZag писал(а):предлагаю рассматривать наше обсуждение как чисто теоретическое, без привязки к TDMS или Lotsia PDM PLUS. Возможно, в таком ключе диспут будет полезен обоим компаниям-разработчикам.

А если скатимся совсем в оф-топик, или появится скрытая реклама, то Злобный Модератор форума нас быстро приструнит.

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

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

Извините, но Вы не совсем точно меня цитируете.McZag писал(а):Вы приводите несколько аргументов против модели хранения файловых данных в СУБД. Я дам свои комментарии:
Быстрый рост объема данных не зависит от выбранной модели хранения файлов.- быстрый рост объема базы данных вызывает необходимость использования более мощного (следовательно, -- более дорогого) сервера и катастрофическое снижение производительности при работе с большими объемами документов;

Я писал именно про быстрый рост объема базы данных, а не просто данных.
В этой части я согласен.McZag писал(а):Затраты на прокачку файлов по сети и скорость работы дисковых (или любых других) накопителей не сопоставимы с затратной частью потока сервера, обслуживающего операцию ввода/вывода.
Но, как Вы понимаете, что чем больше размер базы данных, тем больше вероятность работы именно с использованием дисковых накопителей, а не ОЗУ. Так что я выступаю за максимально компактную базу данных.

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

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

Опять же, как показывает практика,McZag писал(а):Если произойдет извержение супервулкана, то ваши данные никому вообще не будут нужны.

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

Для кого-то это может быть актуально.McZag писал(а):Хранение файлов в СУБД действительно не предлагает их физическое отсутствие. Но так ли это актуально?
Воля Ваша.McZag писал(а):Относительно безопасности и резервного копирования Вы меня никогда не переубедите.

Здесь я с Вами опять соглашусь.McZag писал(а):Основная проблема в безопасности и надежности не железо и не наличие соответствующего сертификата, а человеческий фактор.

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

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

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

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

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


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

Я не сказал, что это много. Наоборот, хорошо, что мало. Но сложите объем файлов с объемом базы и становится ясно, что размер базы данных стал "неслабым". И я напираю именно на то, что такой объем данных в память серверу не пихнуть (воздержитесь от upgrade сервера, платить за это начальство не любит), значит операции с данными будут _дисковыми_. Они самые медленные. HDD до сих пор как "бутылочное горлышко" в системе.Если бы вы к каждой цифре приписали бы 0, я бы сказал "Прилично!"
И еще, раз уж коснулись размера базы данных. Не знаю как в TDMS (возможно, Вы осветите), но в Lotsia PDM Plus удачно продумана система хранения значений атрибутов. Они не дублируются!!! А следовательно, размер базы данных плавно будет стремиться к горизонтальной линии (если чертить график). Удачно!
Lotsia PDM Plus не обладает, но файловый сервер позволит админу открыть права на файлы. А пользователи уже "насабачились" и знают файлы по именам.Я с трудом представляю себе, как [временно] потеряв объектную информацию (включая права доступа), вы восстановите доступ к файлам (по сути, раздадите пользователям права на них "в течение часа"). Возможно, Lotsia PDM Plus и обладает такой возможностью.
Вы указали на возможность кэширования файлов на рабочих станциях пользователей, но забыли одну особенность. При работе в команде, по крайней мере у нас, используется "параллельное проектирование". Т.е. специалисты "видят" и используют файлы смежных отделов, которые храняться на сервере. И при попытке работать с кэшированными данными (в терминах Lotsia PDM Plus - захваченные файлы) возникнут проблемы.
У нас в организации ВООБЩЕ не используется захват (кэширование). Все файлы открыты прямо с сервера.
Позиция все время "ждать у моря погоды". Надеяться и ждать можно, но лучше уже сейчас иметь использовать то, что так необходимо. Работаем ведь мы уже сейчас, а не когда-то в будущем.SQL Server работает с офисными документами, Oracle поддерживает весьма внушительное число текстовых форматов.
У нас, например, контекстный поиск уже сделан собственными силами. Просто и элегантно. А так и не дождемся...
-
- Новый участник
- Сообщения: 4
- Зарегистрирован: 15 авг 2005, 17:07
Я являюсь разработчиком конкурирующей PDM системы (не будем уточнять, чтобы избежать обвинений в рекламе), потому поделюсь некоторыми техническими соображениями:
Аргумент "так проще разработчикам" - достаточно серъезен. Ибо если разработчикам проще, то у них остается время на другую, более полезную функциональность. Кроме того, в простой системе проще тестирование и меньше глюков.
Я пришел к выводу, что есть 3 архитектуры:
1. Хранение файлов в самой СУБД в виде BLOB.
2. Хранение файлов на расшаренном сетевом ресурсе средствами файловой системы.
3. Хранение файлов средствами файловой системы, но под
управлением отдельного специализированного файлового сервиса.
Аргумент "что, если СУБД грохнется и в варианте 1 потеряются все файлы" уравновешивается аргументом "что, если файловый сервер грохнется и в вариантах 2 и 3 тоже все файлы потеряются". Понятно, что данные надо резервировать в любом случае.
Аргумент "так проще разработчикам" - достаточно серъезен. Ибо если разработчикам проще, то у них остается время на другую, более полезную функциональность. Кроме того, в простой системе проще тестирование и меньше глюков.
Я пришел к выводу, что есть 3 архитектуры:
1. Хранение файлов в самой СУБД в виде BLOB.
2. Хранение файлов на расшаренном сетевом ресурсе средствами файловой системы.
3. Хранение файлов средствами файловой системы, но под
управлением отдельного специализированного файлового сервиса.
Аргумент "что, если СУБД грохнется и в варианте 1 потеряются все файлы" уравновешивается аргументом "что, если файловый сервер грохнется и в вариантах 2 и 3 тоже все файлы потеряются". Понятно, что данные надо резервировать в любом случае.
Практика показывает, что это в большинстве случаев не так. Даже в варианте 1, когда файлы храняться в BLOB и "прокачиваются" через журналы транзакций, "бутылочным горлышком" оказывается сеть. Да и поставить на сервер быстрые диски сильно дешевле, чем всю сетевую инфраструктуру заапгрейдить. Ситуация усугубляется тем, что очень часто отделы территориально разделены и их подсетки связаны с центральными серверами по выделенной линии далеко не 100 мегабитной полосы пропускания. Вариант 2 тут вообще неработоспособен. Варианты 1 и 3 могут хоть кешировать файлы на клиенте. Вариант 3 допускает установку своего файлового сервера для каждой рабочей группы, что сильно рулит, если пользователи преимущественно обращаются к файлам своего локального сервера. А по ночам можно пускать взаимную репликацию между файловыми серверами.Alxd писал(а):У моих заказчиков типична такая ситуация: размер метаданных 500Мб, размер сжатых (примерно вдвое) файлов 100Гб, всего примерно 200 тыс. файлов. Одновременно с системой работают 50 человек. Понятно, что при таких объемах резервное копирование уже может стать проблемой по причине пропускной способности этих устройств. У нас резервирование выполняется без остановки сервера. Восстановление сотни гигов из бекапа - это многие часы. Для варианта 1 есть стандартное решение - резервный сервер, который читает журналы транзакций основного сервера и имеет копию всей базы. Сервера связаны собственной сетью и своими сетевыми картами, потому такой трафик не нагружает основную сеть. Если основной сервер падает, нужно только переконфигурировать сервера приложений, чтобы они работали с резервным сервером. Это всего несколько минут. Для варианта 2 такого простого решения нет. Для варианта 3 репликацию в принципе можно реализовать. Например, писать на DVD в фоновом режиме. Тогда восстановление из бекапа заключается только в том, чтобы вставить этот DVD в устройство на другом файловом сервере. Но в любом случае (для вариантов 2 и 3) _синхронное_ резервирование сервера СУБД и файлового сервера (особенно, если их несколько) требует разработки отдельной софтины и дополнительных напрягов от администратора. Так что вариант 1 "все в одном" сильно проще с точки зрения резервирования.у нас размер базы данных 700Мб + размер каталога с файлами 9500Мб
Понятно, что когда метаданные составляют всего полпроцента общих размеров базы, хранить файлы под управлением СУБД (вариант 1) не имеет смысла. Файлы не нужно кэшировать, строить по ним индексы, им не нужны полноценные транзакции. То есть ресурсы сервера СУБД для файлов просто не нужны. Если предположить, что файлы никогда не меняются, а только создаются целиком или удаляются целиком (нет UPDATE, есть только INSERT и DELETE), то достаточно сначала поместить один или несколько файлов на сервер (не запуская транзакцию), а затем стартовать транзакцию в СУБД и сообщить, что файлы с такими идентификаторами уже помещены, потом ее зафиксировать. Если транзакция откатилась, то СУБД просто не будет знать, что файл физически существует на сервере. Будет "потерянное" тело файла, впустую занимающее место. При удалении файла также сообщаем серверу СУБД (в транзакции), что файлы с такими идентификаторами удаляем. Само тело файла не трогаем. Оно станет "потерянным". В итоге получим короткие транзакции, которые работают только с метаданными, не "проворачивая" мегабайты контента. Остается только создать некий низкоприоритетный фоновый процесс, который будет физически удалять "потерянные" тела файлов. Эту "оптимизацию транзакций" (по сравнению с вариантом 1) можно полноценно реализовать в варианте 3. В варианте 2 о транзакциях вообще речь не идет.
Alxd писал(а):Соответственно, я так понимаю, используется вариант 2. То есть ни о "полноценных" ни об "оптимизированных" транзакциях речь не идет. Представим, что при попытке сохранения (обновления) файла прямо на сервера приложение упало. Не останется ни старого файла, ни нового. А это гораздо более вероятная (я бы сказал ежедневная) ситуация, чем "упал сервер СУБД". Кроме того, даже если файл успешно перезаписан, рано или поздно кому-то понадобится предыдущая версия этого файла. Как с этим дела в Вашей организации? Ведь "захват" - это не только кэширование, это еще и процедура check-in/check-out, которая обычно предусматривает сохранение еще и предыдущих версий изменяемого файла.У нас в организации ВООБЩЕ не используется захват (кэширование). Все файлы открыты прямо с сервера.
Теперь о сетевом трафике. Если в вариантах 1 и 3 можно сжимать файлы на клиенте и передавать их по сети (и хранить на сервере) в сжатом виде (в среднем вдвое). То это вдвое быстрее варианта 2, когда приложения напрямую лезут за файлами на шареный ресурс. Мы этот эффект сразу демонстрируем заказчикам, когда они не верят, что загрузить в САПР сложную сборку из сотен файлов в нашей системе они смогут сильно быстрее, чем просто с сетевого диска.
Alxd писал(а):
- Alxd
- Активный участник
- Сообщения: 50
- Зарегистрирован: 15 июл 2004, 12:42
- Откуда: Тюмень
- Контактная информация:
Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов. А в случае с "падением", Novell NetWare обладает стековым механизмом хранения удаленных файлов. Поэтому перед открытием файла сохраняется его копия. В отношении Windows 2003 есть теневые копии. Тоже отличная вещица, но я ее пока не использую.Представим, что при попытке сохранения (обновления) файла прямо на сервера приложение упало. Не останется ни старого файла, ни нового. А это гораздо более вероятная (я бы сказал ежедневная) ситуация, чем "упал сервер СУБД". Кроме того, даже если файл успешно перезаписан, рано или поздно кому-то понадобится предыдущая версия этого файла. Как с этим дела в Вашей организации?
полностью согласен. Это даже первое бутылочное горлышко!"бутылочным горлышком" оказывается сеть
Пока я странствовал по просторам нашей необъястной Родины, пришел дядька Лисеев, и расстрелял почти все аргументы, которые были "за пазухой" 
Самый главный из них - загрузка сети файловым траффиком. Если удается снизить его хотя бы вдвое, то производительность системы вырастает примерно на 50-90 процентов. Достигается такой эффект, как правильно указал Дмитрий, двумя способами - сжатие данных (файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты), и кэширование (либо только на чтение, если файл хранится в СУБД, либо и на чтение/запись, если файл размещается на локальном файловом сервере).

Самый главный из них - загрузка сети файловым траффиком. Если удается снизить его хотя бы вдвое, то производительность системы вырастает примерно на 50-90 процентов. Достигается такой эффект, как правильно указал Дмитрий, двумя способами - сжатие данных (файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты), и кэширование (либо только на чтение, если файл хранится в СУБД, либо и на чтение/запись, если файл размещается на локальном файловом сервере).
-
- Новый участник
- Сообщения: 4
- Зарегистрирован: 15 авг 2005, 17:07
Это какие организационные процедуры? Вот загружает человек в САПР из PDM сложную конструкцию из сотен файлов. Вносит изменения в несколько файлов. Сохраняет в PDM. Тут кому-то нужна прежняя редакция _всей конструкции_, поскольку по этой документации уже была выпущена продукция. Я так понимаю, человек видит на экране список версий головной сборки. Ткнул в любую, сказал "открыть", и получил всю конструкцию из сотен файлов в первоначальном виде (до внесения изменений). Или вдруг выяснил, что в одну из деталей этой конструкции были неудачно внесены изменения, тогда он просто указывает, что в конструкции должна быть использована не последняя версия этой детали, а одна из предыдущих. Кроме того, есть на практике такая штука (не регламентированная ГОСТами), как альтернативные варианты конструкции. Когда независимыми проектировщиками делаются несколько вариантов одного документа с одним обозначением, а потом выбирают лучший. Далеко не каждая PDM система поддерживает такое ветвление (branches) для документа. Как показывает практика, очень часто человек даже не задумывается, в какой именно файл он вносит изменения. Он видит на экране конструкцию, решает изменить размер некого кронштейна, поскольку САПР полностью ассоциативная, автоматически пересчитываются сотни размеров других деталей, выскакивает сообщение, что нужно взять на редактирование (check-out) следующие документы (и вываливается список на полторы сотни), человек просто щелкает по кнопке OK, автоматом делается захват и внесение изменений в сотни документы, на которые повлияло изменение размера этого кронштейна.Alxd писал(а):Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов.
Этим отличается инженерный документооборот от обычного офисного. В современной САПР одним поворотом мышки можно внести изменения в сотни различных взаимосвязанных файлов. И при просмотре прежних редакций любого файла нужны прежние редакции соответствующих взаимосвязанных файлов.
Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска. Если файл в основном состоит из текста и содержит мало нетекстовых данных (крайний вариант - TXT, который состоит только из текста), то действительно, сжатие тут бесполезно, ибо для поиска нужны сложные индексы, а индекс по данным обычно сильно больше самих данных. Но в PDM обычно используются файлы САПР, которые содержат очень мало текста по сравнению с бинарной информацией. Тогда текст (основная надпись чертежа и другие атрибуты) извлекается из файла, отправляется в СУБД, где индексируется, а сам файл сжимается и отправляется в файловое хранилище. Больше он системе не нужен. Пользователь может выполнять поиск по этим атрибутам и даже менять их (в СУБД, но не в файле). Например, часто удобнее сначала занести в PDM сложную сборку, а уже потом задавать обозначения и заполнять основные надписи. При извлечении файла из PDM все происходит в обратном порядке: файл вытаскивается, расжимается, из СУБД извлекается вся его текстовая часть и помещается обратно в файл. То есть работает и сжатие и поиск.McZag писал(а):файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты
Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег, а выхлоп от нее нулевой если 95% хранящихся документов (CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС) этой системой не поддерживаются.
-
- Новый участник
- Сообщения: 4
- Зарегистрирован: 15 авг 2005, 17:07
Это какие организационные процедуры? Вот загружает человек в САПР из PDM сложную конструкцию из сотен файлов. Вносит изменения в несколько файлов. Сохраняет в PDM. Тут кому-то нужна прежняя редакция _всей конструкции_, поскольку по этой документации уже была выпущена продукция. Я так понимаю, человек видит на экране список версий головной сборки. Ткнул в любую, сказал "открыть", и получил всю конструкцию из сотен файлов в первоначальном виде (до внесения изменений). Или вдруг выяснил, что в одну из деталей этой конструкции были неудачно внесены изменения, тогда он просто указывает, что в конструкции должна быть использована не последняя версия этой детали, а одна из предыдущих. Кроме того, есть на практике такая штука (не регламентированная ГОСТами), как альтернативные варианты конструкции. Когда независимыми проектировщиками делаются несколько вариантов одного документа с одним обозначением, а потом выбирают лучший. Далеко не каждая PDM система поддерживает такое ветвление (branches) для документа. Как показывает практика, очень часто человек даже не задумывается, в какой именно файл он вносит изменения. Он видит на экране конструкцию, решает изменить размер некого кронштейна, поскольку САПР полностью ассоциативная, автоматически пересчитываются сотни размеров других деталей, выскакивает сообщение, что нужно взять на редактирование (check-out) следующие документы (и вываливается список на полторы сотни), человек просто щелкает по кнопке OK, автоматом делается захват и внесение изменений в сотни документы, на которые повлияло изменение размера этого кронштейна.Alxd писал(а):Для сохранения предыдущих редакций документа существуют организационные процедуры хранения этих самых файлов.
Этим отличается инженерный документооборот от обычного офисного. В современной САПР одним поворотом мышки можно внести изменения в сотни различных взаимосвязанных файлов. И при просмотре прежних редакций любого файла нужны прежние редакции соответствующих взаимосвязанных файлов.
Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска. Если файл в основном состоит из текста и содержит мало нетекстовых данных (крайний вариант - TXT, который состоит только из текста), то действительно, сжатие тут бесполезно, ибо для поиска нужны сложные индексы, а индекс по данным обычно сильно больше самих данных. Но в PDM обычно используются файлы САПР, которые содержат очень мало текста по сравнению с бинарной информацией. Тогда текст (основная надпись чертежа и другие атрибуты) извлекается из файла, отправляется в СУБД, где индексируется, а сам файл сжимается и отправляется в файловое хранилище. Больше он системе не нужен. Пользователь может выполнять поиск по этим атрибутам и даже менять их (в СУБД, но не в файле). Например, часто удобнее сначала занести в PDM сложную сборку, а уже потом задавать обозначения и заполнять основные надписи. При извлечении файла из PDM все происходит в обратном порядке: файл вытаскивается, расжимается, из СУБД извлекается вся его текстовая часть и помещается обратно в файл. То есть работает и сжатие и поиск.McZag писал(а):файлы САПР не используются для полнотекстового поиска и могут быть неплохо сжаты
Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег, а выхлоп от нее нулевой если 95% хранящихся документов (CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС) этой системой не поддерживаются.
Dmitry V. Liseev
То о чем вы говорите относится к средствам автоматизации конкретного приложения (и не всегда, кстати, возможно). И вырезаете вы не текстовые данные для полнотекстового поиска, а отдельные атрибуты, которые помещаются на "карточку" информационного объекта. Поиск по значениям атрибутов идет стандартными средствами СУБД, через операторы инструкции WHERE. А поиск по подстроке в строковых типах данных с использованием оператора LIKE вообще не индексирован.
Полнотекстовый поиск производится по контенту файлов определенного формата и требует включения соответсвующей службы СУБД. БОльшая часть типов файлов, используемая приложениями САПР, не входит в число индексируемых. Т.е. попросту кладется в хранилище как есть, без создания индексов. Но утверждать, что выхлоп от системы полнотекстового поиска нулевой, я бы не стал. Любое изделие (объект проектирования) содержит большие объемы текстовых документов. Для них и предназначен полнотекстовый поиск.
Alxd
Если вы имеете ввиду что-то уникальное и свойственное только Lotsia PDM, поделитесь, будет очень интересно.
Размер всех баз данных стремится к какой-то горизонтальной линии. Вопрос только под каким углом
Что-то вы страсти какие-то рассказываете. Кто (какая программа) должна заниматься экстрагированием текста из документа? Исполняемые файлы тоже содержат много текста. Их тоже будем индексировать?Тут нет прямой связи с возможностью поиска. Все текстовые данные должны извлекаться из тела файла и храниться в СУБД с целью построения индексов для поиска.
То о чем вы говорите относится к средствам автоматизации конкретного приложения (и не всегда, кстати, возможно). И вырезаете вы не текстовые данные для полнотекстового поиска, а отдельные атрибуты, которые помещаются на "карточку" информационного объекта. Поиск по значениям атрибутов идет стандартными средствами СУБД, через операторы инструкции WHERE. А поиск по подстроке в строковых типах данных с использованием оператора LIKE вообще не индексирован.
Полнотекстовый поиск производится по контенту файлов определенного формата и требует включения соответсвующей службы СУБД. БОльшая часть типов файлов, используемая приложениями САПР, не входит в число индексируемых. Т.е. попросту кладется в хранилище как есть, без создания индексов. Но утверждать, что выхлоп от системы полнотекстового поиска нулевой, я бы не стал. Любое изделие (объект проектирования) содержит большие объемы текстовых документов. Для них и предназначен полнотекстовый поиск.
Не совсем так. Конретных денег стоят сами системы. А средства полнотекствого поиска в них "бесплатны". Например, SQL Server Standard Ed уже содержит средства полнотекстового поиска. За деньги нужно приобретать встраиваемые в СУБД модули сторонних производителей, которые обладают бОльшими возможностями по сравнению с базовыми средствами.Хотя SQL Server и Oracle имеют встроенную систему полнотекстового поиска, но она стоит конкретных денег
Alxd
Честно говоря, я не понял вашей мысли. Если вы о наследовании (т.е. о некоторых особенностях реализации отношений часть-целое), то это базовый функционал многих PDM систем. Если о том, что PDM системы легко обращаются со ссылочной информацией (т.н. "заимствование"), то это тоже базовый функционалИ еще, раз уж коснулись размера базы данных. Не знаю как в TDMS (возможно, Вы осветите), но в Lotsia PDM Plus удачно продумана система хранения значений атрибутов. Они не дублируются!!! А следовательно, размер базы данных плавно будет стремиться к горизонтальной линии (если чертить график). Удачно!

Размер всех баз данных стремится к какой-то горизонтальной линии. Вопрос только под каким углом

-
- Новый участник
- Сообщения: 4
- Зарегистрирован: 15 авг 2005, 17:07
Этим должен заниматься модуль интеграции PDM системы с конкретной САПР или другим приложением. Например, модуль интеграции с MS Office работает с файлами ворда, экселя и т.д.McZag писал(а):Что-то вы страсти какие-то рассказываете. Кто (какая программа) должна заниматься экстрагированием текста из документа? Исполняемые файлы тоже содержат много текста. Их тоже будем индексировать?
Зависит от реализации. Текстовые данные представляем в виде XML и кладем в СУБД, где они прекрасно индексируются.McZag писал(а):И вырезаете вы не текстовые данные для полнотекстового поиска, а отдельные атрибуты, которые помещаются на "карточку" информационного объекта.
Вообще-то СУБД сильно разные бывают. Если ваша СУБД чего-то не умеет, то это не говорит о том, что СУБД конкурентов этого тоже не умеет. Поиск по подстрокам бывает индексированным. Правда, индекс достаточно большой размер имеет.McZag писал(а):Поиск по значениям атрибутов идет стандартными средствами СУБД, через операторы инструкции WHERE. А поиск по подстроке в строковых типах данных с использованием оператора LIKE вообще не индексирован.
СУБД сильно разные бывают. У меня алгоритмов полнотекстового поиска - как грязи. В исходниках для моей СУБД. Нашел в Интернете. Конечно, без учета семантики и морфологии, но найти документы со словами "завальцевать" и "ТУ 88???-76*" на поле чертежа оно может.McZag писал(а):Полнотекстовый поиск производится по контенту файлов определенного формата и требует включения соответсвующей службы СУБД.
И нахрена такое заказчику?McZag писал(а):БОльшая часть типов файлов, используемая приложениями САПР, не входит в число индексируемых.
Статистика по некоторым головным предприятиям минобороны (моим заказчикам), как я говорил, показывает: 95% хранящихся документов имеют формат CATIA, PCAD, SolidWorks, Pro/ENGINEER, КОМПАС. Текстовые данные там на полях чертежей и в моделях. Впрочем, заказчики у всех разные.McZag писал(а):Любое изделие (объект проектирования) содержит большие объемы текстовых документов. Для них и предназначен полнотекстовый поиск.
Не достаточно большими возможностями, чтобы это устраивало моих заказчиков. Все равно пришлось самому делать.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 (если абстрагироваться от цены)?
Еще раз прошу прощения, скорее всего, оперативно отвечать в ближайшие пару недель не смогу.
Не сочтите за неуважение.
я очень рад, что обсуждение пошло так активно.

Сразу прошу меня извинить, но принимать в нем участие в ближайшие две недели, скорее всего, не смогу.
Для начала позвольте сделать несколько предложений.
1. Если нет возражений, то я попрошу администратора выделить это обсуждение в отдельную тему.
2. Я попросил бы все же воздержаться от скрытой рекламы, иначе администратор форума нас всех разгонит (он у нас товариСЧ резкий, может и "молча" эккаутны наши поудалять). Рекламировать свои системы давайте на собственных ресурсах.

К тому же, не знаю как других, но лично меня от рекламы во всех ее проявлениях уже просто тошнит. Поэтому, пожалуйста, давайте не будем сравнивать, чья СУБД круче.
3. Есть давняя задумка создать отдельный ресурс для обсуждения систем PDM (PLM или называйте еще как угодно), где можно было бы всласть поругаться на конкурентов.

Задумка это абсолютно частная, но реализация ("на коленке") уже почти готова. Через пару недель, надеюсь, можно будет ее запустить. Если у Вас будет желание, то я бы предложил все обсуждения такого рода перенести на этот ресурс. Уж там-то я сам смогу всласть поругаться, без всякой "политкорректности".

Вот, вроде бы все по общей части.
=======================================================
А теперь разрешите сделать несколько комментариев по теме обсуждения (все IMHO).
Относительно схемы хранения файлов.
Еще один плюс хранения файлов на файл-серверах -- это как раз возможность создавать сколько нужно хранилищ на разных серверах в сети с целью минимизации трафика. Разумеется, при этом нужно учитывать организацию конкретной сети.
Ну, как я понял, по вопросу производительности мы остались каждый при своем мнении.

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

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

Не сочтите за неуважение.
С уважением, Николай Ширяев