|
Свободные IT публикации
|
Немного о временных таблицах или кто на кухне хозяин? [1134][8] AdminITD - 2019-02-05 21:13:39 |
|
|
V81, V82, V83
| |
Вступление
Из сочинений Михаила Жванецкого: Паровоз для машиниста
"Смешно подходить к театру с точки зрения зрителя. На спектакли не ходят – от скуки челюсть выскакивает. А то, что режиссер непрерывно ищет и ставит, ставит и ищет? Театр первым отрапортовал о подготовке к зиме, ни одного актера, не занятого в спектакле. При чем тут пустой зал? Тогда получается, что театр – для зрителя, поезд – для пассажиров, а завод – для покупателя?! Такой огромный завод – для покупателя? Нет! Это для всеобщей занятости. Пароход – для команды, паровоз – для машиниста, столовая – для поваров, театр – для актеров, магазин – для продавцов, литература – для писателей! Нет и не может быть выхода из этих предприятий – настолько увлекательный процесс внутри. Смешно ждать снаружи чего-либо интересного. Схватил у самого передового коллектива пылесос – он не работает, потому что не он главный. При чем тут борщ, когда такие дела на кухне?!"
Лирика
Начну с того, что каждая используемая программистом 1С команда "Поместить", это не волшебное заклинание, отправленное в чудесный космос, а самая обыкновенная команда физического создания таблицы на жестком диске с последующей записью в нее указанных в команде данных. Впрочем, в механизмах работы любых программ нет эзотерики и особой магии - все основано исключительно на элементарных законах физики и математики, как и весь окружающий нас мир. Поэтому мы всегда можем сопоставить правила и алгоритмы, используемые при разработке программных продуктов с правилами и алгоритмами построения процессов, окружающих нас в реальном мире.
Так как служба ИТ любого предприятия, является исключительно сервисной структурой по оказанию услуг пользователям информационной системы, давайте спроецируем активно пропагандируемые и широко используемые программистами 1С методы получения и обработки данных в программных продуктах 1С, на что-то понятное всем. Спроецируем их, к примеру, на обслуживание клиентов в ресторанном бизнесе.
Итак, наш отдел информационных технологий - ресторан.
Посетители этого ресторана - сотрудники, запросившие в виде порции "блюд" необходимую им информацию из 1С.
Кухня - информационная система 1С, за кулисье, где по особым рецептам и правилам, описанным в огромном количестве поваренных книг желтого цвета, готовятся запрошенные посетителями блюда.
Вот в это за кулисье мы и заглянем, заострив внимание на процессе приготовления запрошенных блюд.
Заправляет на кухне конечно же шеф-повар (программист 1С). Это сертифицированный и дорогой специалист, владеющий навыками построения процессов приготовления любых блюд. Так как наш шеф-повар изучил множество кулинарных книг известных и уважаемых мастеров, он не подвергает описанные рецепты ни малейшему сомнению. Поэтому основные правила и алгоритмы приготовления блюд на нашей кухне такие:
- Множество рядовых работников кухни безоговорочно и точно выполняют команды шеф-повара (в информационной системе это внутренние сервисы, предоставленные используемой СУБД, и выполняющие запросы, написанные программистом, а чаще всего даже не им, а программой 1С с помощью построителя или СКД).
- Основная часть продуктов, которые работники берут в кладовой (информация в базе хранения данных), перед попаданием в блюдо должна обязательно помещаться в зону временного хранения (в таблицы системной базы tempdb). Такова методика 1С для приготовления лучших и самых вкусных блюд. Объяснение простое - только так наш шеф-повар может удобно контролировать, оценивать и улучшать процесс. И действительно, ведь гораздо проще контролировать компоновку блюд из небольшого стеллажа, где в зоне обозрения удобно расположены все необходимые ингредиенты. В противном случае необходимо изучать устройство кладовой, выстраивать маршруты работников, придумывать новые способы извлечения и компоновки продуктов - зачем изобретать велосипед? Ведь все давно придумано и описано умными и уважаемыми мастерами с безупречной репутацией. Лично я предполагаю еще одно возможное обоснование, из области виноделия: хороший коньяк - выдержанный коньяк, это же всем известно.
Есть, конечно, и некоторые минусы – работникам нашей кухни слишком часто приходится бегать в кладовую, ведь, хотя в основном они готовят для временного хранилища сразу смесь ингредиентов, иногда, ради удобства шеф-повара им приходится бегать на склад за каждым продуктом отдельно. Но не стоит о них тревожится - они у нас очень быстрые, натренированные, прекрасно знают, что и как хранится в основной кладовой, а также то, каким образом лучше всего это достать. Они бы могли даже готовить блюда быстрее, собирая и компонуя все необходимые ингредиенты сразу в кладовой, не посещая зону временного хранения. Но разве полученная выгода может сравнится с неудобствами, с которыми придётся столкнуться нашему шеф-повару?
В общем, работа на нашей кухне кипит. Шеф-повар раздает команды, работники шуршат и наши немногочисленные утренние посетители получают заказанные блюда в ожидаемые сроки. Все довольны и счастливы.
Но вот подходит время обеда (допустим, период сдачи отчетности). Количество посетителей растет лавинообразно, а вместе с ним растет и количество заказов на нашу кухню. И все эти заказы посетителей нужно выполнить как можно быстрее, ведь время обеда ограничено и посетители не могут и не хотят ждать вечно.
А на кухне коллапс. Потому, что исполнительные работники продолжают четко выполнять распоряжения шеф-повара, перетаскивая требуемые для заказанных блюд ингредиенты из кладовой в зону временного хранения. Вот только в этой зоне сейчас полный хаос, сотни работников всех мастей пытаются пробиться к стеллажам хранения. Кто-то для того, чтобы поместить в заветную ячейку хранения очередную порцию продуктов из главной кладовой, кто-то, чтобы забрать помещенные ранее продукты и приготовить, наконец, заказанное блюдо. По головам, орудуя локтями и рассыпая ругательства. Ну, тут я немного приукрасил. Молча они ломятся и очень целеустремленно. Вот какому-то счастливцу, наконец, удалось вырваться из общей толчеи. Он мгновенно приготовил заказанное блюдо и передал заказ официанту, тот ринулся в зал, но заказчика в гудящем недовольством зале он не нашел. Не дождался заказчик, и, наивно полагая, что в следующий раз повезет больше, заказал желанную порцию заново...
А теперь давайте вспомним, а ради чего весь этот кипишь? А все ради одного: только для удобства нашего шеф-повара. Поэтому наш шеф-повар удовлетворенно отмечает полное соответствие процесса технологическим картам и срочно готовит управляющему служебную записку примерно такого содержания: "Во избежание повторения сбоев, произошедших тогда-то и тогда-то, прошу срочно разместить зону временного хранения в более доступном месте, увеличив количество стеллажей и мест доступа к этим стеллажам. Кроме этого следует увеличить количество работников кухни, расширить ее рабочее пространство, а еще ..." и т.д. и т.п. Переместив направленный в него кол в сторону технической службы, наш шеф-повар удовлетворенно вздыхает и приступает к раздаче новых команд, и конечно же главная и самая любимая из них - ПОМЕСТИТЬ во временное хранилище. Потому, что он так привык. Потому, что он просто так хочет. Потому, что окружающие, включая и владельцев бизнеса, оплачивающих это его желание, и многострадальных пользователей, сидящих перед зависшими экранами и печально наблюдающих колесико курсора ожидания, не разбираются в магическом мире ЕГО КУХНИ и не знают, что все заказанные ими блюда можно приготовить существенно быстрее и с гораздо меньшими затратами просто исключив из процессов его любимую ЗОНУ ВРЕМЕННОГО ХРАНЕНИЯ. А самое печальное, что и сам шеф-повар этого не знает и не понимает - ну нет этого в авторитетных книгах, на которых он становился сертифицированным МАСТЕРОМ 1С.
Но я-то знаю! Поэтому я не люблю временные таблицы. Сам использую их только в крайних случаях, а чаще всего мне приходится удалять технически необоснованные команды "Поместить" из модулей программ, которые поддерживаю.
Мир, в котором живу я
В силу специфики российского рынка ERP-систем, где 1С является безусловным лидером и монополистом, программисты 1С вынуждено разделились на два лагеря.
С одной стороны, это специалисты, нанятые вендором для производства программных продуктов. Основной целью, которую обозначил им бизнес, является быстрая сборка ПО с минимальными трудозатратами. И в данном процессе, безусловно, удобство и комфорт программиста, автоматизация формирования программного кода и его читаемость имеет несравнимо более высокий приоритет, чем оптимальный результат работы программ. Потому что в условиях отсутствия конкуренции эти программы будут реализованы в любом случае, а смена позиции на клиентоориентированность принесет только дополнительные, притом существенные расходы. Мне не очень это нравится, но, если быть честным, наверное, потому, что я не работаю в этом бизнесе и нахожусь по противоположную сторону баррикад.
А по другую сторону находятся специалисты отделов и служб ИТ в компаниях, чья деятельность не связана с производством ПО 1С. Я вхожу именно в эту группу специалистов и нам поставлены абсолютно другие задачи и цели, в рамках которых первое место отводится уже результату работы программы и удобству ее конечных пользователей. И в моем мире бизнес не интересуется порядком слов в модуле или удобством читаемости запросов. Его интересует уровень автоматизации, отсутствие отказов и простоев по вине программных сбоев, оптимизация затрат на оборудование и его обслуживание. В моем мире бизнес интересуется чем угодно, но только не удобством читаемости запросов в программном коде 1С. Я просто представить себе не могу, чтобы топ менеджер любой из компаний, в которых мне приходилось работать, выдал, к примеру, такое распоряжение:
«В течение месяца привести тексты программ в максимальное соответствие канонам 1С, с целью быстрой и комфортной адаптации новых ИТ специалистов, если они у нас вдруг появятся. На выполнение бросить все средства отдела, после выполнения отчитаться лично.»
В моем мире программист 1С не является ключевой фигурой, здесь он - сотрудник сервиса, подстраивающий программы под нужды бизнеса, а не подстраивающий бизнес под свои нужды.
Практика
В этой публикации я пытаюсь обозначить одну из основных причин очень серьезной проблемы, с которой, к сожалению, приходится сталкиваться очень часто – проблемы зависаний и отказов типовых программных продуктов, код которых чрезмерно насыщен использованием временных таблиц. И это не мои догадки или предположения, это результат многолетнего изучения причин возникновения сбоев при работе многих типовых конфигураций (Торговля, УПП, Бухгалтерия, ЗУП, УНФ) в самых разных технических условиях. Причина негативного влияния использования временных таблиц не кроется в том, что они делают запросы более или менее оптимальными, проблема вообще не связана с алгоритмами программных модулей 1С. Проблема в том, что при каждом запросе данных из БД выполняются десятки, а порой сотни дополнительных операций записи/чтения в/из системной базы TEMPDB и в моменты более активной работы очередь чтения записи диска, на котором расположена темповая база вырастает настолько, что нормальная работа с ним становится невозможной. Результат – 1С «висит». В этом может убедиться любой специалист, открыв во время зависания 1С «Монитор ресурсов» на сервере SQL. На вкладке "Диск->Работа диска" с очень высокой степенью вероятности Вы обнаружите в топе на чтение-запись файл темповой базы и «заваленный» диск его хранения с длиной очереди в сотни раз превышающей нормальное значение. Это и есть та кутерьма вокруг «временных стеллажей», описанная мной в истории про ресторан 1С.
Вот так это выглядит в информационной системе кампании, в которой я работаю сейчас, и это не самая печальная картина:
Или так:
К сожалению, это факт. Факт, который можно "потрогать", в существовании которого может убедится любой желающий собственными глазами. По монитору видно, что количество информации, проходящей через темповую базу за единицу времени почти в 100 раз превышает количество данных полученных и записанных в реальную базу 1С. Количество данных записи в tempdb - почти в 200 раз! Это ЗАПИСЬ НА ДИСК - самая ресурсозатратная операция с данными! И представленная картинка с диким количеством записи и чтения времяков - не самая печальная из тех, что мне приходится наблюдать.
Т.к. первопричина происходящего – временные таблицы, то и лечится это исключением, на сколько это возможно, команды «ПОМЕСТИТЬ» из запросов с наиболее частым ее использованием. Процедура крайне нудная, занимает много времени, но решает проблему на 100%. Ну а какие варианты? Ведь у нас же на первом месте - ПОЛЬЗОВАТЕЛЬ.
На самом деле проблема «заваливания» темповой базы еще шире. Т.к. каждый экземпляр SQL-сервера имеет 1 общую для всех темповую базу TEMPDB, то проблемы работы с ней сказываются одновременно на работе всех баз, подключенных к этому серверу.
К примеру, если разместить, на сервере, с которого сняты скриншоты предыдущего примера, базу любой другой конфигурации 1С, то количество сбоев и зависаний при работе этой конфигурации возрастет на порядок и более. Вот снимок работы диска с базой нашего документооборота:
По загрузке tempdb мы видим, что в ней так же активно используются ВТ, но используются гораздо менее интенсивно и база работает. Конечно, есть свои проблемы, но они не вызваны исключительно временными таблицами, делающими код запросов более читаемым и понятным. Если же перенести базу этой конфигурации на сервер с базой ЗУП, мы получим 100% нерабочую систему и согласовывать документы будет гораздо проще и быстрее через почту России.
Я думаю, с подобной ситуацией сталкивались очень многие, когда раздраженный пользователь, к примеру, торговли, высказывал вам, что буквально недавно выполнил отчет за секунды, а сейчас не может дождаться результата уже более 10 мин, и перезагружался, и даже попросил коллег выйти из программы –руководство требует, вопрос жизни и смерти – и все бесполезно. А причина может быть простой: в бухгалтерии (в другой программе, на другой платформе, но с базой на этом же сервере) месяц перепроводят, регламенты формируют или запустили еще какую-нибудь обработку, сделанную строго по учебнику. Вот только обработка эта гоняет по таблицам темповой базы десятки Гб, а в мониторе ресурсов мы опять наблюдаем очередь к диску до горизонта. В результате в торговой базе действительно не выполняется очень простой отчет. И только потому, что в коде этого отчета всего лишь 1 команда «Поместить», причем в этом случае как раз необходимая и в тему. Но диск темповой базы слишком занят другими очень важными задачами, ему уже столько этих «Поместить» накидали, что и за 10 минут не разгрести. Так что «ждите, Шура, ждите» В итоге топ менеджер кампании не получает необходимую для принятия важного решения информацию. Вы как хотите, но лично меня объяснение про «правильный код для людей» в данной ситуации никак не устраивает.
Хотя что это я? Ведь если бы разработчики типовых программных продуктов писали бы их для других людей, для тех которые будут эти программы использовать, то мы, специалисты по адаптации и оптимизации 1С остались бы без работы. Ведь тогда бы программы 1С работали сразу и БЕЗ КОСТЫЛЕЙ – ужас! Нет уж, забудьте все что я тут понаписал, не в себе был, каюсь. Пишите, пишите красивые и правильные коды во благо своего и нашего процветания!
Заключение
Если кому то показалось, что я испытываю какой то негатив к программистам 1С, то они абсолютно не правы. Все программисты, с которыми мне приходилось сталкиваться, в большинстве своем очень умные, талантливые и ответственные специалисты, к которым я испытываю искреннее уважение - и сейчас я серьезно и без всякого сарказма. Я негативно отношусь не к людям , а к пропаганде некоторых принципов разработки в среде 1С, и на мой взгляд, вполне обосновано.
Основные факторы, определяющие мое отношение к этой проблеме таковы:
- Реально наблюдаемое огромное количество трудоемких физических операций с жестким диском, в разы превышающих число операций с БД хранения и вызванных обработкой временных данных.
- В немалой степени причина возникновения зтих трудоемких операций - и это подтверждает большинство программистов 1С - связана с использованием временных таблиц с целью более удобной работы с программным кодом.
- В результате выполнения этих трудоемких операций, что вполне логично при их критическом увеличении, "зависает" 1С и пользователи программы ощущают существенное неудобство.
- Я, как специалист, отвечающий за отсутствие этого неудобства, недоволен источником этих неудобств, и был бы рад, если бы использование этого инструмента было всегда технически обоснованным.
Несколько лет назад я прочитал замечательный бестселлер Алана Купера "Психбольница в руках пациентов". Эта книга полностью перевернула мое отношение к программной разработке и к сфере информационных технологий в целом. И хотя с того времени минуло много лет, данная статья написана, в немалой степени, под влиянием этой книги. Кто не читал, прочтите - очень советую.
| Нет комментариев |