Приложение к публикации: "Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL. "(с)

Публикация № 94437

Администрирование - Производительность и оптимизация (HighLoad)

Основная статья находится по адресу: http://infostart.ru/public/94040/

 

В основной статье выдвигается тезис, что свёртка базы данных (БД) делается только из-за размера БД. Позволю себе не согласиться с автором.

 

Но, полностью соглашусь с утверждением автора основной статьи:

"В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С - её объём превышает 50 ГБ"."(с)

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

Схема БД продуктов "1С:Предприятие" ориентирована на решение учетных/отчетных задач (УОЗ).

Для задач такой направленности характерно:

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

2) Цикличность накопления и обработки информации.

Т.е. применимы такие понятия, как: закрыть/открыть период, входящие/исходящие итоги, пересчитать итоги, архивирование "первичной" информации, итоговый (балансовый) отчет за фиксированные периоды, итоги на дату, последовательности документов (пачки) и т.д.

Т.е. в таких ИС моделируется УОЗ и вся схема базы данных "заточена", именно, на решение подобных задач. Т.е. отражается "житейское" представление человека в "кишках" информационной системы практически без изменения.

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

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

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

Возникает "конфликт" между концепцией (архитектурой) платформ "1С:Предприятие" (всех версий) и задачами которые на неё возлагается.

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

И всё было бы хорошо, кроме одного - таблица для хранения регистров имеет суммарное количество записей по всем видам документов "входящих" в регистр.

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

Мне неловко приводить собственное описание способов представления и обработки "индексных структур" в СУБД, т.к. ... Но, к этим описаниям имеет смысл добавить, что любые действия с деревьями требуют использования "технологических" блокировок. Как при записи, так и при чтении записей таблицы в порядке индекса. Т.е. если обрабатывается регистр в порядке индекса с ключом: "Товар+...+....", то будет приостановлена работа (условно говоря) со всеми документами, отчетами и т.д. использующими одинаковое значение "Товар". А время заблокированного состояния зависит от "глубины и ветвистости" дерева. Которое, в свою очередь, зависит от количества записей таблицы и от "характера значений" ключей. Могут возникать, условно говоря, и конфликт блокировок (deadlock).

Но, в области СУБД-строения и ЭВМ-строения с этими "проблемами" борются. Разными способами, и с переменным успехом. Но, думаю, гораздо большего успеха в этой борьбе можно добиться разработкой схемы базы данных отвечающей не только УОЗ проблематике, но и более общим задачам АСУПа.

Возвращаясь к основной статье, приведу из неё цитату:

"Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили."(с)

Похоже на правду. Только причина не указана - почему не приходит в голову свертывать базы данных в этих системах. А причина, думаю, простая. Эти системы не ориентированы только на УОЗ в сути своей архитектуры.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
0. hogik 435 14.10.11 17:25 Сейчас в теме
1. comol 4384 14.10.11 17:25 Сейчас в теме
И всё было бы хорошо, кроме одного - таблица для хранения регистров имеет суммарное количество записей по всем видам документов "входящих" в регистр.
Нужно писать - для 1С 7.7
2. comol 4384 14.10.11 17:29 Сейчас в теме
СУБД-строения и ЭВМ-строени
:cry:
6. Арчибальд 2713 17.10.11 08:17 Сейчас в теме
(2) Противник словесности?
4. kapustinag 14.10.11 22:36 Сейчас в теме
Может быть, можно придраться к отдельным словам или фразам статьи, но с основной мыслью автора полностью согласен. Насколько легче было бы жить, если бы журналы документов и регистры допускали секционирование или вынесение старых данных в архив! Не путем допиливания конфигурации, а как штатная возможность платформы.

Да, если используем Microsoft SQL-сервер Enterprize Edition, секционирование таблиц можно сделать средствами SQL-сервера. Но это придется делать вручную для каждой такой таблицы, и заботиться, не случится ли что при обновлениях и т.п.
Вспомним, как работал бухгалтер без компьютера: он, в частности, вел журналы документов в специальных тетрадях. А заполненные тетради складывал в папки по годам. У него всегда под рукой был архив журналов за весь период, в течение которого законодательством предписывалось хранить журналы. Но этот архив не мешал ему делать текущую работу.
А разработчики большинства программ, ориентированных на "решение учетно/отчетных задач", положившись на безграничные мощность процессора, объем памяти и диска, решили, что архивы, неотделенные от текущих данных, не будут мешать эти текущие данные обрабатывать. Это ошибка, я считаю.
5. hogik 435 14.10.11 23:42 Сейчас в теме
(4)
Александр (kapustinag).
Если рассуждать от достигнутого, что - есть объект АвтоМехАнизации под название "Документ", то - да. Суть "секционирование таблиц" можно (и желательно) "вставлять" в платформу.
Но, я в своей статейке пытаюсь, еще продвинуть "мысль", что не документами описывается предметная область. Хотя, это и мало отношения имеет к текущей версии 1С-ов.
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную "бухгалтерию" по сбору документов. И жить по правилам "бухгалтерии". Нет в реальной жизни никаких журналов документов и регистров. Для "образования" этих понятий в том месте, где они действительно используются (учет) - уже достаточно технических средств "сбора" информации из тех точек "бизнес процессов" где она возникает. Т.е. не документ имеет движение, а - материальная ценность и деньги двигаются между точками их применения. ;-) Очень хорошо это укладывается в сетевую (иерархическую, объектную) модель баз данных. И многие вопрос уходят на второй план. Например, такие как: блокировки, размеры БД, искусственное преобразование структур данных туды-сюды, модульность подсистем, интеграция данных, постепенное внедрение, "паразитные" структуры данных типа - регистр и т.д.
7. Арчибальд 2713 17.10.11 09:10 Сейчас в теме
Вообще говоря, статья не о СУБД, конечно, а о жизни. Точнее, об отражении жизненных реалий техническими средствами. О том, что техника отображения (моделирования) зависит от текущих потребностей "моделиста". И на самом деле, по модели можно судить не только (и даже не столько) об объекте моделирования, но и о субъекте.
Вспомним, откуда взялась (выросла) 1С. Расплодившимся в конце 80-х мелким лавочникам потребовалось средство, чтобы отбиваться от государственного рэкета, в котором, в отличие от рэкета криминального, размер платежей исчисляется, исходя не из реального финансового состояния, а из документально оформленного. Именно поэтому "Документ" стал "священной коровой" одноэсных продуктов.
Надо сказать, что в этом то ли 1С попала "в струю", то ли тенденции автоматизации бизнеса попали под влияние 1С - так или иначе, за что ни возьмись - вместо реалий упираешься в документооборот. Примеров тому великое множество, приведу один модный термин: бизнес-процесс. Копни его - и увидишь, что это не что иное, как документооборот, сопровождающий некий хозяйственный цикл.
Другой пример "повернутости" на документы в противовес реалиям. При анкетировании в рамках исследования должностей я указал в качестве своей функции "формирование и реализация технической политики предприятия в сфере компьютеризации учета". И сразу же получил вопрос от анкетирующих о существовании документа с нименованием "техническая политика предприятия". А его как раз и не существует - но политика-то есть! Выходит, цель анкетирования - не описание должности, а описание входящих/исходящих документов...
Мое глубокое убеждение - документооборот (и Документооборот в смысле 1С) описывает жизнь не просто некорректно, а извращенно с особым цинизмом. Под чем и подписуюсь.
fzt; CheBurator; vkr; leoner61; Evgen.Ponomarenko; Rustig; AlexO; maxpiter; comol; cool.vlad4; +10 Ответить
8. cool.vlad4 45 17.10.11 10:43 Сейчас в теме
(7) ага, а потом появляются такие статьи http://infostart.ru/public/93587/
12. ildarovich 7146 17.10.11 20:47 Сейчас в теме
(7)(10) Про "Документ": Как всегда, чем короче слово, тем шире понятие и возможности неоднозначной интерпретации. Мне кажется, что понимать "документ" следует так:
Есть предприятие как система. Ее состояние определяется набором параметров. В определенное время состояние меняется (приходят деньги на расчетный счет, отгружается товар, регистрируется выпуск продукции, списываются материалы на выпуск, проходят через проходную сотрудники). Во многих случаях длительность самого изменения невелика или несущественна, поэтому его можно считать "мгновенным". Это изменение регистрируется в системе. Для этого вручную (или автоматически) формируется объект в базе данных с параметрами, характеризующими время изменения и его характеристики. Этот объект "проводится", то есть записывается так, что меняются параметры системы (ресурсы регистров) и определен факт изменения.
Это очень широкая концепция, позволяющая моделировать очень многие процессы. Чем Вы предлагаете заменить документ-событие?
Предложите! Можете назвать сети Петри, конечные автоматы, сетевые графики, блок-схемы, таблицы решений, структурные схемы, иерархические схемы, фреймы и прочее. Что Вам больше нравится, что шире, удобнее, выразительнее? Модель должна иметь стержень, ключевую метафору. А иначе получите "действующую модель паровоза в натуральную величину". ООП + паттерны? Попробуйте пофантазировать! А так получается, что "что-то другое, а не документ", но что именно?
CheBurator; maxpiter; romansun; +3 Ответить
14. hogik 435 17.10.11 21:33 Сейчас в теме
(12)
Сергей.
Ваше сообщение адресовано двум собеседникам.
Я подожду ответа от Другого Вашего собеседника. ;-)
Лады?
16. romansun 191 17.10.11 22:13 Сейчас в теме
(12) согласен, +1

хоть сети Петри (услышал знакомое институтское слово), хоть графы - всё равно событийная модель на основе таблиц.

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

--------

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

И всё это, опять же, упирается в людей. Стройную и прозрачную схему работы в реале можно и в экселе автоматизировать - работать будет только в путь. В противном случае, никакие системы, методики и теории не помогают, к сожалению.
18. hogik 435 17.10.11 22:23 Сейчас в теме
(16)
Роман (romansun).
Вы написали: "что весь 1С-учет (бухучет, в частности)"(с)
Стоп!
А АвтоМехАнизация - это только учет?
Тогда и разговора нету.
Начинаем перечитывать мою статейку и комментарии темы заново.
20. Арчибальд 2713 18.10.11 11:43 Сейчас в теме
(12)
Это очень широкая концепция, позволяющая моделировать очень многие процессы. Чем Вы предлагаете заменить документ-событие?
Двумя руками за! Если документ = событие - все нормально. Однако во-первых, в 1С время документа не совпадает с временем события - это породило гемор с "восстановлением последовательности". Во-вторых, одним документом могут быть зафиксированы два (и более) событития - скажем, факт выписки (продажи) товара и его отгрузки. В-третьих, при проведении (изменении состояния модели предприятия) зачастую результат зависит от момента проведения. Тут уж сплошные парадоксы времени получаются из научной фантастики. В жизни такого не бывает, т.е. концепция (модель), основанная на 1С-Документе нежизненна. Как мне показалось, статья именно об этом...
CheBurator; hogik; cool.vlad4; +3 Ответить
21. ildarovich 7146 18.10.11 15:48 Сейчас в теме
(20) Во-первых, во-вторых и в-третьих решается простым способом - полным запретом проведения документов задним числом. То есть все, что перечислено - не недостатки модели и концепции, а практики ее применения. То есть Вы говорите - модель "нежизненна". Следует ли понимать так, что жизненная модель должна разрешать помещать в базу данных любые факты, в любом порядке, за любые периоды и сама определять их достоверность и согласованность. Или все же быть своего рода тотальным (видео)регистратором - работать в реальном времени. Я не спорю - я спрашиваю: не встречалось ли Вам удачных идей, концепций, моделей, которые могли бы лечь в основу "хорошей" системы, если 1С такая "плохая" и основанная на порочной концепции система. Что можно в принципе противопоставить подходу 1С? Какой правильный стержень?
Моя мысль в том, что критика бессмысленна в отсутствии более-менее конкретных представлений об идеальной системе. Ведь для управления нужна цель, направление. Здесь, предположим, плохо. Но куда Вы предлагаете двигаться?
CheBurator; ljubasia; +2 Ответить
22. hogik 435 18.10.11 23:05 Сейчас в теме
(21)
Сергей (ildarovich).
Я подписываюсь под (20) сообщением.
1) А вот Ваше: "Во-первых, во-вторых и в-третьих решается простым способом - полным запретом проведения документов задним числом."(с) вызывает у меня удивление.
Возможно, приведу не очень удачный пример, но... Просто, очень много таких примеров. Я, даже, теряюсь приводить совсем уж конкретные примеры.
Например, существуют документы от даты которого исчисляется время возможности его использования. А момент конкретного его использования (совершения ХО) фиксируется другой датой. Например, подписями с датой, сторон совершающих ХО. Т.е. одна дата на документе это очень "большое" допущение в вопросе отражения реальных ХО. И если подобный документ заносится в БД, то либо надо иметь возможность изменять его задним числом, либо вносить задним числом сам документ. А по какой дате...? Или подобные документы не надо заносить в БД?
2) "которые могли бы лечь в основу "хорошей" системы"(с)
На данный момент моего понимания, мне представляется "идеальной" моделью системы, где существует возможность "называть" объектами реальные объекты нашей жизни. Т.е. например, товар (объект) осуществляет собственное "движение" между объектами хозяйственной деятельности. А не объект-документ порождает своё движение на регистрах учета ;-)
Из реально существующей системы для АСУПа (не в области СУБД - там одна, всем известная) - это "ABACUS Financial (AF7)" в сути её "ABACUS Builder (AB7)". Тут: http://www.omega.ru/ab.html есть, разбросанные по тексту, файлы PDF. Гляньте их содержание. Обратите внимание на год создания этого продукта. ;-)
У меня есть много критики в адрес этого продукта. Но, так красиво уложиться в "SQL-ную" СУБД - это достойно изучения. И запросы там, почти, по делу...
3) "Ведь для управления нужна цель, направление."(с)
Для управления нужен объект управления. И полные, достоверные, точные данные (информация) о состоянии этого объекта. Этим, в первую очередь, и должна заниматься АСУП-ина. ;-)
4) Сергей. Я ужо обмолвился, выше по тексту, про "Графины". Вас не заинтересовала тема - "раздолбать" модель (архитектуру) 1С-продукта "графинами"?
23. ildarovich 7146 19.10.11 17:36 Сейчас в теме
(22)
1) В "тяжелых" случаях документов может быть несколько. Они будут объединены структурой подчиненности. То есть одному печатному документу будет соответствовать несколько модельных документов. А еще есть "стадии" (УТ11), бизнес-процессы. В 8-ке очень много и других готовых объектов.
2) Посмотрю ссылки, спасибо. Идея с объектами, осуществляющими "движения", наверное, правильная. Кажется, разработчики WMS на базе 1С идут по этому пути.
3) Под целью я понимал описание идеальной системы. Вы его дали в п.2.
4) Про "графины" ничего не понял. Наверное, что-то пропустил.
24. hogik 435 19.10.11 18:47 Сейчас в теме
(23)
Сергей (ildarovich).
1) Можно углубиться (вернуться) к теме "первичный документ". ;-)
Уже обсуждали на данном ресурсе.
Но, например:
"Документ есть закодированное определенным образом и зафиксированное на специальном носителе информационное сообщение (свидетельство), удостоверяющее, что факт хозяйственной жизни или существует, или совершен, или должен быть совершен.
...
Первичные бухгалтерские документы — письменное свидетельство о совершенной хозяйственной операции или дающее право на ее совершение."(с)
[ http://www.r-ooo.ru/byx_obsluzyvanie.php?pid=31 ]

В описании "Управление производственным предприятием"(УПП) от 1С есть текст:
"Средством регистрации хозяйственной операции является документ, причем для ускорения работы широко используются механизмы подстановки данных "по умолчанию", ввод новых документов на основании ранее введенных. "(с)
[ http://v8.1c.ru/enterprise/ ]

Я, из этих определений, делаю однозначный вывод: "В УПП АвтоМехАнизируется учет документов.". И в 1С-продуктах всё сделано хорошо для ЭТОЙ задачи. Гораздо лучше чем полвека назад. Но суть не изменилась. :-( Изменилась только "внешняя" форма. :-(

2) Интересно, сколько "готовых объектов"(с) будет использоваться в подобных задачах? :-)

3) Я - молодец. :-)

4) Тогда - забудем :-(
9. ildarovich 7146 17.10.11 17:14 Сейчас в теме
Интересная тема:
1) Кажется, не стоит противопоставлять концепции построения АСУП и конкретные технические решения для конкретной СУБД. - Это совершенно разный уровень проблем. О чем тут спорить? Практикам интересны конкретные технические решения, применимые здесь и сейчас, для конкретной версии 1С. Есть плюсы (быстродействие) и минусы (надежность), - прием не бесспорный, это очевидно. Зато читатели узнали о спектре возможностей настройки СУБД. За это знание и плюсы в статье;
2) Теперь о концепции построения АСУП. - Сколько их уже было! СУБД - это инструмент хранения. Сетевая, иерархическая, реляционная - какая разница? У АСУП должна быть более глубокая парадигма. 1С доказала устойчивость своей парадигмы и менять ее не собирается. А зачем? В чем проблемы? Не нравится слово "документ"?
Кстати, у западных систем, по-моему, вообще еще меньше стройности и концептуальности. Там нет крупных кирпичиков - почти что одни таблицы. Гибкости при разработке больше, а трудность и цена кастомизации выше.
В общем, предлагайте парадигму вместо "документ". Иначе критика выглядит неконструктивной.
user1456023; Dolly_EV; Rustig; +3 Ответить
10. hogik 435 17.10.11 19:08 Сейчас в теме
(9)
Сергей (ildarovich).
1) "не стоит противопоставлять концепции построения АСУП и конкретные технические решения для конкретной СУБД"(с)
Согласен. Но между СУБД и АСУП существует мАААА-аленькая "прослойка" - схема базы данных. ;-) И эта "прослойка" разрабатывается с учетом потребностей АСУПа и технических возможностей СУБД.
2) "Это совершенно разный уровень проблем."(с)
Ошибаетесь. Уровень, то - разный. Но, работать ОНО должно совместно.
3) "Практикам интересны конкретные технические решения, применимые здесь и сейчас, для конкретной версии 1С."(с)
Согласен.
4) "Есть плюсы (быстродействие) и минусы (надежность),"(с)
Т.е. можно складывать килограммы и метры? ;-)
5) "прием не бесспорный, это очевидно"(с)
В "основной" статье рассматриваются (противопоставляются) "объемы" и "надежность", а используется средство для повышения скорости. Хотя, с самого начала указывается, что в современном мире с расширением "объемов" нет проблем. Главное отвертку вовремя наточить... ;-)
6) "За это знание и плюсы в статье;"(с)
Допускаю. Но, знания имеет смысл применять по назначению. И, лично я, долго пытался призвать автора "основной" статьи к осознанию этого. Не получилось... :-(
7) "Сколько их уже было! СУБД - это инструмент хранения. Сетевая, иерархическая, реляционная - какая разница?"(с)
Их было очень мало. Сами, же перечислили почти все. ;-) Но, не осознавать их разницу и влияние на "прослойку"... Не ожидал такого вывода... :-(
8) "У АСУП должна быть более глубокая парадигма."(с)
Согласен.
9) "1С доказала устойчивость своей парадигмы и менять ее не собирается."(с)
В смысле сбыта своего продукта - да. А в смысле постоянного (постепенного) понимания той самой "парадигмы" - нет. Одной фразой, развитие 1С-продуктов можно охарактеризовать, как: "попытка уложить иерархическую модель в реляционную".
10) "А зачем? В чем проблемы? Не нравится слово "документ"?"(с)
Это точно. :-) На грани с цинизмом. :-(
11) "Кстати, у западных систем, по-моему, вообще еще меньше стройности и концептуальности."(с)
В ИХ системах проведена четкая грань (уровень) где, далее (выше/ближе к предметной области), "стройность и концептуальность" - НЕВОЗМОЖНА.
12) "Там нет крупных кирпичиков - почти что одни таблицы."(с)
Да - нет крупных кирпичиков. Т.е. как и при строительстве зданий. Из больших блоков можно построить только Хрущебу. ;-)
13) "Гибкости при разработке больше, а трудность и цена кастомизации выше"(с)
Естественно.
14) "В общем, предлагайте парадигму вместо "документ". Иначе критика выглядит неконструктивной."(с)
Нет, с моей стороны, никакой критики. Печаль одна... :-( Какая может быть парадигма вместо "документа", если ставится задача (цель) - сбор документов. Поменяется "задача" - поменяется и "парадигма". А пока, системы ориентированные не на "пАчкование документов" умирают. А "парадигма от документа" живет уже, почти полвека... :-( :-( :-( Но, с точки зрения реляционной модели БД и предметной области (пусть, даже ставится задача - собирать документы в пачки) - хранить документ как "монолитную" структуру - не разумно. Вспомните про "Графины"... ;-)
11. romansun 191 17.10.11 19:43 Сейчас в теме
появилось много статей на темы всяких ERP-APS, но не пойму в целом, а чего все спорят, поэтому не могу корректно "влезть" в перепалку :)

но тем не менее

hogik пишет:
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную "бухгалтерию" по сбору документов.


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

Проблемы начинаются, когда:

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

- и из всего этого вытекает еще более глобальная проблема - высшему руководству часто тупо наплевать на всё это, ему не нужна эта 1С в компьютере, оно не готово заниматься каким-то планированием, анализом, смотреть какие-то графики и пр. Там всё распилено, цены на продукцию уже обозначены заранее и строго секретны, там мерседесы и порше и т.д. и т.п.

Ей богу, проще сравнять бульдозерами, пригласить иносранцев и тупо построить завод заново с информационной системой в комплекте.

P.S. после n лет разработки и внедрения была как-то презентация отчета, считающего себестоимость изделия, финдиректору. Слушал молча, внимательно, нахмурившись. После подробного рассказа и показа общего листа отчета тыкает в цифры стоимостей и спрашивает:
- всё ок, но кто вот бьёт эти цифры?
- ээээ... никто не бьёт... программа сама посчитала, мы же вот тут вам рассказали..
- не, это я понял, но вот тут, например, литье - столько-то рублей, материалы - столько-то. Вот кто забивает эти цифры в систему?
- да никто не забивает, программа сама считает, начиная с каждого болтика, шайбочки и детальки..
- как так?? Не морочте мне голову!! Как так у вас всё считается?? Этим цифрам нельзя доверять..

и т.д.
Rustig; e.kogan; +2 Ответить
13. hogik 435 17.10.11 21:25 Сейчас в теме
(11)
Роман (romansun).
Всё верно Вы написали.
Только:
1) Не "ERP-APS",а "ERP+APS" мы пытаемся делать.
2) И кода "необходимо влить в общий информационный поток", то это не означает "серьёзные изменения бизнес-процессов"(с).
Системы (задачи, функции, алгоритмы т.д.) не складываются. Они могут лишь "встраиваться" (интегрироваться) и базироваться на нечто общем. Это общее - исходные данные общие для всех задач. Для успешного встраивания должна проводится четкая систематизации информации без привязки (но с учетом) к алгоритмам последующего их использования. И чем больше в исходных данных присутствует элементов направленных на решение конкретной (частной) задачи тем меньше шансов (и сложнее) обобщить другие задачи.
Для такого подхода в построении ИС и придуманы "БнД=БД+СУБД+Администрирование".(очень давно придумали!!!). С очень важным дополнением - описание схемы базы данных должна быть открытой и общей для всех задач имеющих отношение к хранимой (и собираемой) информации в базе данных.
Ну и лозунг должен быть, примерно, таким: ;-)
"Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.
Разместить бизнес-решение там, где вам удобно: внутри компании или у хостинг-партнера.
Выбрать модель внедрения, оптимальную по сочетанию рисков, затрат, сроков и ресурсов."(с) http://www.microsoft.com/rus/dynamics/about/overview.mspx

Продукты от 1С не соответствуют принципам построения БнД и не могут служит платформой для АСУПа. Вот, так грубо скажу...
15. romansun 191 17.10.11 21:55 Сейчас в теме
hogik пишет:
Ну и лозунг должен быть, примерно, таким: ;-)
"Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.


Круто конечно и, наверное, правильно... Только нереально )) Почему? Потому как часто на предприятиях, схему работы которых придумывали и внедряли в 70-80гг всякие НИИ - за прошедшее время часто 2+2=5, а 2*3=7, а операция деления вообще отменена еще при старом режиме директоре.

Там почти что априори приходится выправлять и 2+2 и 2*3, иначе просто код не пишется.

Может и не на всех так, но где я имел возможность работать - было и есть так.

А вот изначальные схемы и бизнес-процессы были круты, да! Но изменились с тех пор до неузнаваемости, как в кривых зеркалах.
17. hogik 435 17.10.11 22:16 Сейчас в теме
(15)
Роман (romansun).
Согласен. И лозунг привел специально. ;-)
Я же не первый десяток лет в АСУПе. :-(
Но 2+2=5 это не бизнес процесс. Это его отсутствие.
Ну, а дальше классика...
Надо научить людей пользоваться пипкми компьютера и обеспечить ему продвинутую пишущую машинку с калькулятором. И это уже очень много! А если бумажные документы не будут теряться пачками - отлично. Только, тогда давайте не будем говорить о всяких названиях из трех букв.
Помню, как много лет назад делили машинное время между пользователями при использовании нашего аналога IBM/370. Все бегали с собственными дисками с персональной операционной системой и в каждой лаборатории занимались разработкой собственно банка данных под управлением личной СУБД.
Потом появились персональные ЭВМ. Рассосалось. Разбежались по углам. Машинное время перестали делить со скандалами. И тут от НИХ приползла зараза - сети... И опять, по кругу...
Ну чего сказать? Да, 2+2=5... :-)
19. hogik 435 18.10.11 01:50 Сейчас в теме
(15)
Роман (romansun).
Эх. Понесло меня на примитивные тексты... :-)
Извините.
Химия. НИИ. Все проводят исследования, анализы, утилизацию реактивов и т.д.
Ну, сделайте сначала, чтобы потребитель реактива мог на "компьютере" выбрать, набрать, заказать необходимые ему реактивы (материалы) для своей работы. Наращивайте описание реактивов, для более качественного выбора. Он же после проведения этапа своей работы делает отчет по затратам этих реактивов по отношению к заказчику (другой лаборатории). Пусть забьёт это в "компьютер". И не в виде "требование на" (и др. т.н. документов), а в понятной ему форме. Его не волнует ни склад, ни НДС. Может в другой лаборатории есть эти реактивы. И покупать не надо. И ждать не надо. Для этого - что? Бизнес процессы ломать придется. Или там есть корпоративные секреты. Воровство спирта - есть. Но это ни для кого, не секрет...
И надо обеспечить достоверность информации (пусть - малой), и доступ к этому компьютеру в режиме 24/7. Без всяких сверток БД и регламентных работ. Иначе, отвратите, изначально, человека от использования эТТого устройства. Компьютер должен помогать пользователю, а не добавлять ему лишнюю работу. Только тогда пользователь будет на Вашей (ИТ-шной) стороне.
Нет, блин, нам сразу подавай систему с названием из трех букв. Покупную, готовую обязательно. И чтобы всё делала сама. Прибыль считала и графики строила. А цифирь мы возьмем из бухгалтерии, т.к. только там достоверная информация. А чтобы она была полная и оперативная - наладим "УУ". Рядышком, чтобы пачки документов далеко не носить от одного компьютера к другому. Типа, механизация труда бухгалтера в вопросе перенося тяжестей...
Ну, сделайте чтобы на складе не наклеивали "собственные" штрих-коды, если "внешние" нормальные (уникальные). Сделайте базу данных разных наименований одного товара для быстрого приема. Или чтобы продавец не мог пробить один товар (дешевый), а выдать (своему другу-покупателю) дорогой. Чтобы остатки на складе сходились не по б.учету на конец прошлого квартала, а на сейчас, когда за товаром приходит оптовый покупатель. И сделайте это не бесконечными обменами между системами с названием из трех букв, а "автоматически" - в одной базе данных. В реальном масштабе времени жизни, а не бухгалтерии.
Может тогда и прибыль будет не только посчитана, но и, просто - будет.
А если Ваш начальник этого не понимает (а Вы - понимаете), то надо сменить начальника.
Для этого есть два способа...
25. pvase 364 08.08.12 11:07 Сейчас в теме
Есть несколько нерешенных проблем:
1 - Если база 7.7 - то все немного не так, Большой обьъем данных может быть не в таблицах RG а в RA, и если не включена бістрая обработка движений (нет поля DATE_TIME_IDDOC), то разделить на группы по полю - нет возможности.
2 - Если база растет, то любые изменения в структуре вызывает пересчет данных по измененным таблицам, что при росте БД может вырости в разы. Так добавление новой графы отбора может привести к серьезным пересчетам. Или же удаление реквизита и поиск ссылок (это в 7.7).
3 - Бекапы базы, их ведь надо хранить и если размер не 10 ГБ а 100, то даже при зжатии бекапа надо очень большое хранилище чтобы каждый день хранить полный бекап, хотя бы за пару месяцев.

Так что в предложенном автором механизме реализации есть как плюсы так и минусы, и каждый должен принимать решение исходя из своих соображений и свой ситуации, потому что не может быть здесь одного универсального решения.
26. AlexO 129 08.08.12 11:45 Сейчас в теме
(25) pvase,
Причем тут 7.7? Тут речь идет об основах построения БД 1С8 - концепции и насколько она оправдана.
А не хранения таблиц документов в SQL в 7.7.
27. pvase 364 08.08.12 12:02 Сейчас в теме
(26) AlexO, Извините, из статьи не видно что речь идет исключительно об 8-ке. Напротив речь идет об свертке базы 1С и зачем это делать.
А концепция построения БД в 1С 8 - это немного другая тема, и в заголовке статьи и в самой статье об этом не нашел упоминания.
И поскольку все манипуляции производятся на SQL Server минуя 1С то эта технология применима к любым базам на MS SQL 2005 и выше.
28. AlexO 129 14.08.12 15:12 Сейчас в теме
(27) pvase,
Извините, из статьи не видно что речь идет исключительно об 8-ке

это вы просто невнимательно читали :)
Большая часть, прочитав название темы, к которой мы сейчас пишем комменты "Приложение к публикации: "Давайте забудем о свертке БД?", сразу заинтересуется - а что это за исходная тема такая? Я че - буду читать какое-то "приложение" к непонятно чему, а на "исходную" статью даже и не взгляну?! И перейдет по ссылке Основная статья находится по адресу.
А там, в статье "Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL", ниже заголовка написано, что "Алгоритм для 1С: Предприятие 8.0; 1С: Предприятие 8.1; 1С: Предприятие 8.2; Windows".
Т.е., четко и ясно :)
Никаких 7.7 и прочих "прямых доступов к SQL".
29. bayce 40 08.01.14 01:05 Сейчас в теме
Мне кажется автор не затронул другую проблему.
А именно проблему работы "задним числом".
Во многих западных системах работать задним числом просто запрещено. Для этого у них есть документы корректировки. 1С бухгалтера любят в основном за это, за возможность работать задним числом. Но на базу в целом это влияет негативно. От сюда и вытекает основная идея свертки базы от айтишников. Если оставить только итоги,а прошлые документы убрать, то вероятность того, что бухгалтерия опять, что то поменяет задним числом, приближается к 0.


Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    11736    Aleksey.Bochkov    7    

Контекст всегда важен. История проблем производительности

Производительность и оптимизация (HighLoad) Бесплатно (free)

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    1764    YPermitin    9    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    3088    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3711    Nykyanen    16    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11634    Aleksey.Bochkov    9    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    8378    YPermitin    30    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    10018    dmurk    30    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2005    Филин    7    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    30102    MrWonder    42    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    2880    ivanov660    12    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    12546    starik-2005    232    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    7748    DataReducer    22    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    61661    Sergey.Noskov    119    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    5860    SergeyN    2    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    4248    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    3010    vasilev2015    7    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    41273    Gilev.Vyacheslav    1    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    3652    ivanov660    3    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    12206    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13446    informa1555    31    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

15.03.2015    40746    gallam99    17    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    3205    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    5341    vasilev2015    26    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7416    kaliuzhnyi    43    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67613    yuraos    112    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    5586    ildarovich    7    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    55409    Антон Ширяев    117    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2904    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    4619    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    10179    Evil Beaver    13    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54914    Gilev.Vyacheslav    46    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    11725    a.doroshkevich    20    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    6556    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    8138    Kaval88    26    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30175    gallam99    19    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    6108    nixel    22    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    12083    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7785    user826155    11    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42880    madmpro    32    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    18254    YPermitin    28    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    22573    YPermitin    15    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9203    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    19001    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    9267    jf2000    8    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7675    w.r.    2    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    11121    w.r.    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    4096    w.r.    35    

Тюнинг производительности запросов в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    8400    w.r.    5    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    9086    Филин    12