Чем вызваны тормоза в PDM, PLM, ERP?

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

Тут сам по себе важен принцип этих баз, на которых построены программы.

Большинство современных систем построено на не самой шустрой MSSQL и ее аналогах — впрочем, некоторые из них в какой-то мере могут работать лучше, а в чем-то могут быть и хуже, да и развитие самой MSSQL не стоит на месте: что-то улучшается, что-то «оптимизируется». Некоторые пользователи уже давно считают, что имеет место заговор IT-гигантов с производителями электроники, и некоторые «оптимизации» сделаны специально для замедления работы. Впрочем, такие заговоры уже не раз вскрывались, и никто с этим так ничего и не сделал, а все подобные дела просто спускались на тормозах.

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

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

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

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

Для изделия главной будет СПЕЦИФИКАЦИЯ (СП), а вложенными данными, как правило, выступают сопроводительные документы, непосредственно влияющие на нее. К примеру, стандарты, расчеты, и пр. документы, на основе которых оно выполнено.

Для документа существуют другие документы, на которые он ссылается или от которых зависит. Для файлов в отношении вложенных данных нет разницы с документом.

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

Одна из основных возможностей PDM (без которой он уже не PDM вовсе) — проверка зависимости и вложенности. Из схемы понятно, для чего это нужно.

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

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

Так вот, к чему все ЭТО.

Вам кажется, что при запросе какого-нибудь документика из PDM система (по сути сервер) жутко тормозит. На деле там есть из-за чего тормозить. Ведь, по сути, запросив один файл, вы тащите за ним еще много данных из базы, которые системе еще нужно найти (к слову, данные в базе находятся сами по себе, а не лежат рядышком с файлом, чтобы их можно было захватить «по пути»), проверить их актуальность и передать вам (даже если вы работаете через удаленный рабочий стол). А ведь со временем даже просто поиск их среди огромного количества таких же будет занимать немалое количество времени, не думайте, что количество тут не имеет значения — еще как имеет.

К тому же, вы наверняка запросили не один «файлик», а сразу состав изделия, т.е. сразу все, что к нему относится; да и где гарантия, что запросили только вы. Представьте, что за вашим компьютером работает 10 человек. Или 50. Или 100.

Вы можете подумать: «там же сервер». К сожалению, это не так работает — по ту сторону экрана находится компьютер ненамного мощнее вашего (уж точно не мощнее в 50 раз). Сервер в первую очередь призван не обеспечить высокую производительность, а сохранить все, что на нем есть, под напором большого количества пользователей.

Особо умные скажут: «а как же серверные кластеры» (набор серверов, распределяющих между собой нагрузку), и все равно будут правы не во всем. К примеру, если уж так получилось, и вы работаете с PDM один, то одинокий сервер будет работать быстрее, чем серверный кластер (им ведь еще между собой нужно общаться, чтобы распределять нагрузку да и данные зачастую тоже — даже если вы там один).

И кстати, а почему вы думаете, что на той стороне компьютер мощнее? В лучшем случае там оперативной памяти в 10 раз больше, чем у вас, во всем же остальном сервер мало чем будет отличаться от компьютера инженера-конструктора в лучшую сторону.

Вместо одного процессора — два, но зато, скорее всего, с тактовой частотой значительно ниже (что более критично, чем их количество).

SSD? Способа сделать их быстрее, чем у вас в компьютере, нет, а вот замедлить из-за систем защиты от выхода из строя — это есть. А еще, может, вы помните, что SSD имеют очень ограниченный ресурс? На серверах SSD-диски используют только совсем отчаявшиеся люди, ну или нереально богатые компании. При 100 пользователях 5 лет службы диска (а это очень хорошие диски должны быть) превращаются в 1 месяц в лучшем случае. А про дефрагментацию помните? А как ее на сервере делать или в составе серверного кластера?

Правильно — никак...