В предыдущей части статьи Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? было живое обсуждение и как я понял из вопросов, не все осознают глубину проблемы низкой производительности ORM. Я верю, что можно написать ORM, где потери производительности минимальны, но на практике не смотрят как это будет работать в СУБД. Результат — низкая производительность ORM. Да проблема находится на границе программирования и тонкой настройки СУБД и для понимания последствий нужно иметь хороший опыт на этих уровнях. Поэтому я решил сделать FAQ и добавил еще один тест с увеличенной длинной транзакции. Поскольку у нас здесь запись по непересекающимся ключевым полям, и уровень изоляции read committed проблем с блокировками не будет. Статья была готова еще в прошлом году, но я предпочел опубликовать необычный прогноз на 2023 год, который отлично зашел на Smart Lab, но на хабре он не прошел в разделе научпоп — видимо работы ученого Чижевского А забыты.
Далее изложен FAQ, в данном случае для MS SQL и Oracle, но только для того чтобы в будущем проверить Postgres тем же методом. Вот и увидим является ли Postgres импортозамещением для 1С или нет.
Часто задаваемые вопросы
Вопрос: А о чём статья? О том, что ещё один слой абстракции ORM над данными замедляет работу? Так это как бы очевидно.
Ответ: ORM ускоряет разработку и делает ее удобной, но это не значит что он должен замедлять работу. Если ORM изначально проектировать на запись наборами сущностей (операций, документов и т. д.), а внутри формировать ORM крупные DML, то никаких существенных замедлений не будет. Наоборот за счет горизонтального маштабирования (смотрите ниже ) можно ускорить обработку достаточно существенно.
Вопрос: Если не устраивает поток мелких DML создаваемых ORM, почему бы не использовать более низкий уровень работы с СУБД (ODBC, JDBC)?
Ответ: ORM позволяет делать более крупные DML, но если она изначально спроектирована для записи множества операций\записей одним крупным DML. Улучшения типа Batching, например, в JDBC эту проблему не решают. ORM позволяет ускорить разработку, проблема в том, что текущие известные мне библиотеки ORM на оптимальную работу с СУБД не рассчитаны. Это же не повод отказываться от концепции ORM для Highload приложений?
Вопрос: Статье утверждается что SSD не является узким местом из за наличия запаса по IOPS. Используемая конфигурация с SSD это не доказывает, только лог на RAM диске покажет истинную картину.
Ответ: Тесты показывают, что сам RAM диск сам может быть узким местом см тут Тестирование скорости работы 1C в режиме файловой версии, MS SQL и POSTGRES на HDD, SSD и RAMDisk и проигрывает SSD. Скорее всего диспетчер RAM диска не поддерживает многопоточность и висит на одном ядре. Если найдете RAM диск с многопоточным диспетчером проверю.
Вопрос:В статье утверждается что Transaction log узкое место. Если Transaction log узкое место, а запись в transaction лог идет в определенной последовательности‑ какая разница писать одним крупным DML или множеством мелких DML?
Ответ: Это не так, производители СУБД постоянно работают над ликвидацией узких мест. Например в MS SQL запись в Transaction Log sql сервер сделали многопоточной см тут Troubleshoot slow SQL Server performance caused by I/O issues
“Prior to SQL Server 2016, a single Log Writer thread performed all log writes. If there were issues with thread scheduling (for example, high CPU), both the Log Writer thread and log flushes could get delayed. In SQL Server 2016, up to four Log Writer threads were added to increase the log-writing throughput. See SQL 2016 - It Just Runs Faster: Multiple Log Writer Workers. In SQL Server 2019, up to eight Log Writer threads were added, which improves throughput even more. Also, in SQL Server 2019, each regular worker thread can do log writes directly instead of posting to the Log writer thread. With these improvements, WRITELOG waits would rarely be triggered by scheduling issues.”
Вопрос. Если сделать транзакцию более крупной, поместив в нее больше мелких DML, данные в transaction log будут сбрасываться более крупными партиями? Разве это не решит проблему мелких DML?
Ответ:
Если посмотрите на трейс который порождает одна операция.Записать() то там минимум 7 DML в одной транзакции. т. е. у нас и так транзакция не на каждый DML, а на группу DML и результаты в предыдущей части показывают, что Transaction log это бутылочное горлышко. Но все таки есть осторожные рекомендации Tuning writelog:
“Too many small transactions: While large transactions can lead to blocking, too many small transactions can lead to another set of issues. If you don't explicitly begin a transaction, any insert, delete, or update will result in a transaction (we call this auto transaction). If you do 1,000 inserts in a loop, there will be 1,000 transactions generated. Each transaction in this example needs to commit, which results in a transaction log flush and 1,000 transaction flushes. When possible, group individual update, delete, or insert into a bigger transaction to reduce transaction log flushes and increase performance. This operation can lead to fewer WRITELOG waits.”
У других производителей СУБД можно тоже найти рекомендации группировать мелкие DML в крупные транзакции. В нашем тесте мы можем себе это позволить поскольку он ориентирован на запись, чтение идет в самом начале, а полное разделение данных по регистраторам, и структура регистра исключает deadlocks. Это несколько идеальная ситуация, ведь при реальной задаче перепроведения документов мы делаем чтения наборов записей (возможно из других регистров\ структур данных), блокировки записываемых наборов. Все это в крупной транзации заставит вспомнить про уровни изоляции ( MS SQL Isolation levels) про блокировки, дедлоки которые может повлечь укрупнение транзакции. Поэтому и рекомендации такие осторожные.
Тест с удлиненной транзакцией
Итак, модифицируем программный код обработки на возможность делать крупные транзации:
Запускаем и смотрим результаты: Waits на write log ушли в низ, но правда среднее время ожидания на запись (AvgWait_s) для writelog все‑равно плохое (запомним это). В топе теперь ожидания на запись в файлы данных:
Далее смотрим — стал ли Writelog писать более интенсивно?
Log Bytes Flushed (голубой) — практически не поменялся по уровню, это и объяснимо DML те же но просто транзакция в 20 раз больше. Но вот Сброс Flushes\sec (песочный) резко упало с 60 до 30.
А почему не на большую величину? Потому что Commit, это не единственное событие, которое инициирует сброс данных в transaction log. Есть еще такое понятие как Checkpoint, о но присутствует не только в MS SQL, Oracle. Его можно вызывать явно, либо оно срабатывает по условия — см подробности тут Database checkpoints.
Ко всему прочему запись в Transaction log идет асинхронно. Я думаю, те кто делал реструктуризации конфигурации в 1С помнят, как может вырасти Transaction log при добавлении реквизита в объект, ведь все реструктуризацию 1С делает в одной! транзации. Если думаете, что все зависит от commit, просто задайдесь вопросом — куда будут деваться измененные данные при транзакции на десятки миллионов и Вы поймете как функционирует запись в Transaction log. Примечание — в Oracle Redo log имеет структуру циклической записи, там еще все интересней ????
Смотрим дальше — может у нас изменилось количество обрабатываемых DML в секунду? Можем обратить внимание на BatchRequest\sec.
Есть небольшое увеличение — раньше было ниже 10 тыс\сек, сейчас уже стабильно 10 тыс\сек.
Ну и наконец давайте проверим — повлияло ли это на скорость в самой обработке? Напомню она написана с учетом горизонтального маштабирования (50 потоков) и даже небольшое увеличение в каждом потоке может дать мультипликативный эффект.
В целом да повлияла 1803 против 1374 в предыдущем тесте, т. е. рост 31% процент. т. е. меньше чем 1% на поток. Это не заметно для одного потока, но при горизонтальном маштабировании очень заметно.
Но есть и хорошая новость, Waits стали гораздо меньше значит можно увеличить нагрузку например до 75 потоков.
Как протиснуться в бутылочное горлышко?
Собственно рекомендации были даны в исходной статье Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД?, и я сторонник использовать более крупные операторы DML на пакет из Х записей, нежели псевдо оптимизации типа Batching или глубокий тюнинг Transaction log. Но конечно доказательство этого факта требует отдельной статьи. То что проблема актуальна в разных языках — достаточно сделать поиск по словам » orm low performance «, » jpa low performance «. Можно найти
Почему следует избегать использования JPA/Hibernate в продакшене / Хабр (habr.com)
Откуда тормоза в ORM? / Хабр (habr.com)
Node.js ORMs: Why you shouldn”t use them — LogRocket Blog
The two top performance problems caused by ORM tools: programming (reddit.com)
SivaLabs — Improve JPA application performance using HypersistenceOptimizer
Несмотря на поверья — увеличение длины транзакции существенного увеличения пропускной способности Transaction log не дает, но к проблемам в реальной системе с блокировками приведет с большой вероятностью. А пока эту методику можно использовать для оценки производительности Postgres в реальных системах, тем более что в 1С перевести базу из MS SQL в Postgres можно штатной выгрузкой\загрузкой базы. До новых встреч на нашем телеграмм канале t.me/Chat1CUnlimited
Комментарии (27)
edo1h
31.01.2023 04:06В целом да повлияла 1803 против 1374 в предыдущем тесте, т.е. рост 31% процент. Т.е. меньше чем 1% на поток
непонятно, как вы этот 1% насчитали
1CUnlimited Автор
31.01.2023 07:4231% / 50 фоновых заданий =0,62 % т.е. Меньше 1% на поток. Округлил для удобства восприятия
starik-2005
31.01.2023 09:58Как говорил кто-то: М - Математика!
Т.е. сначала 1803 / 50 -> 1374 / 50 -> ~ 31%. Не?
По поводу ОРМ, то она, помнится, не в языках программирования встроена, обычно, а в фреймворках. 1С тут - скорее исключение, как предметно-ориентированный язык. У всяковских там питонов, пых и прочих есть масса фреймворков, которые содержат массы реализаций ОРМ, на которые ты, при необходимости, можешь повлиять. В 1С так нельзя. Более того, там нельзя прямком в базу писать, ибо это нарушает лицензионное соглашение и может привести к отказу в обслуживании (ага, как будто они кого-то без этих нарушений "обслужат", ежели у них что накроется медным тазом). Ну писать - ладно, так и читать-то нельзя прямиком из базы.
1CUnlimited Автор
31.01.2023 15:32Как говорил кто-то: М - Математика!
Т.е. сначала 1803 / 50 -> 1374 / 50 -> ~ 31%. Не?
1803 и 1374 записей в секунду, это суммарный показатель который дают 50 параллельных потоков (Скор1+Скор2...+Скор50)=ОбщаяСкорость
Процент прироста
ОбщийПрирост/(Скор1+Скор2...+Скор50)=ОбщийПрирост/ОбщаяСкорость=31%
Мы же смотрим какой % вкладывает один поток в общий прирост, поэтому 31 делим на 50
У всяковских там питонов, пых и прочих есть масса фреймворков, которые содержат массы реализаций ОРМ, на которые ты, при необходимости, можешь повлиять. В 1С так нельзя.
За питон не скажу, но например в Java JPA базовые библиотеки ориентированы на работу либо с одной записью либо с набором но по одному ключу , что исключает обработку нескольких документов с разными номерами одним методом. Изменить это конечно можно написав собственный набор объектов даже базируясь на JPA , но по сути у Вас получится отдельный собственный ORM
Ну писать - ладно, так и читать-то нельзя прямиком из базы.
Дав программисту 1С ORM 1С тем самым позвляет ему владеть меньшим объемом знаний - логика понятна. Свобода работы с базой в "нормальных языках программировани" с ORM это иллюзия . ORM загоняет программиста в определенную версию стандарта SQL причем не самую новую . Просто попробуйте использовать чтото подобное table of records в SQL запросе для JPA
edo1h
31.01.2023 16:31+1Мы же смотрим какой % вкладывает один поток в общий прирост, поэтому 31 делим на 50
то есть если машина удвоила скорость (+100%), то каждое из 4 колёс стало крутиться на 25% (100%/4) быстрее? )))
1CUnlimited Автор
31.01.2023 16:56Если каждый поток обрабатывает в среднем 27 записей в секунду, а 50 потоков работают параллельно какая тогда общая скорость приложения из 50 потоков? Посчитайте и аналогия с колесами отпадет
edo1h
31.01.2023 17:24один обрабатывает
nзапросов в секунду, 50 —50⋅n.если у нас появился новый поток
n', который на 30% быстрее, то он обрабатываетn'=n⋅1.3запросов в секунду, а 50 таких потоков50⋅n'=50⋅(n⋅1.3)=(50⋅n)⋅1.3
ровно на 30% больше, чем первый вариант.аналогия с колёсами не отпадает )
1CUnlimited Автор
31.01.2023 18:52Наверное долго формулой отвечать - просто на цифрах
1803-1374=429 записей \ сек это общий прирост на 50 потоков, на каждый поток приходится в среднем 8.58 записей \ сек прироста . 429 записей\сек прироста это 30% от общей скорости 1374 зап \сек. Как оценить вклад\долю одного потока (прирост 8.58 записей\сек) в общий прирост ? 8.58 / 1374 =0.62% . В своих выкладках за 100% я принимаю 1374 запись в сек общей скорости. Почему? Просто скорость фоновых заданий разная по техническим причинам получается
edo1h
31.01.2023 22:02извините, но вы пишете бред.
обозначим:
v₁=1374, v₂=1803, v₂-v₁=429, единица измерения — запись/сек
N=50, единица измерения — потокдальше вы считаете:
(v₂-v₁)/N
и делите на v₁
получается ((v₂-v₁)/N)/v₁=((v₂-v₁)/v₁)/N=((v₂/v₁)-1)/Nвнутри скобок безразмерная величина, 30%, которую вы делите на число потоков, получается 0.006 поток⁻¹ (процент мы уже не можем использовать, проценты применимы только к безразмерным величинам). и что это может означать?
starik-2005
31.01.2023 16:33Т.е. 1374 - это не 50 потоков, а 1803 - это 50?
Один поток в новом варианте = 1803/50 = 36,6, один поток в старом варианте = 1374 / 50 = 27,48 => 36,6 / 27,48 = 1,33 = +33%. ЧЯДНТ?
По поводу ОРМ, то разработчик на 1С ограничен ОРМ от 1С для записи данных в базу. Объясняется это тем, что нужно соблюдать ACID. Вне зависимости от того, на сколько этим ACID в данной конкретной ситуации можно пренебречь в угоду производительности. Но этим пренебрегают даже банки. А в 1С этого сделать нельзя вот никак вообще. В то время как во всех фреймворках, код которых в части ОРМ открыт, никто не мешает при необходимости эту ОРМ чуть-чуть подкрутить (шардирование, например, воткнуть).
Ну и полное отсутствие обновления данных через UPDATE в угоду все тому же ACID делает механизмы обновления крайне проблемными с точки зрения производительности. Напрмер, чтобы перепровести все документы (а это зачастую единственный путь получить "правильный" срез учета), необходимо их всех перезаписать с признаком проведения, в итоге в СУБД для каждого объекта запустится последовательная транзакция, в ходе которой сначала все данные объекта удалятся из базы, удалятся связанные с ним движения во всех регистрах, потом объект, даже если он не изменился, запишется в базу (даже если в нем сто таблиц по сто строк - они все были удалены), потом запустится код, который сформирует набор записей в регистрах накопления и сведений, после чего они будут записаны, потом будут записаны изменения в таблицах изменений объектов (по количеству планов обмена, требующих регистрации изменений). И все удивляются, почему это все так сильно тормозит. Ну а фиг ли...
edo1h
31.01.2023 17:27Напрмер, чтобы перепровести все документы (а это зачастую единственный путь получить "правильный" срез учета)
???
срезы на любой момент 1с с помощью своих регистров отлично умеет делать как раз. массовое перепроведение обычно требуется для исправления накопившихся по каким-то причинам в регистрах данных.starik-2005
31.01.2023 17:40???
Ну вот Вы в 1С оформили документ покупки барахла, которое хотите продать. Потом продали. А потом оказалось, что нужно бы транспортные расходы отразить, ну или оказалось, что количество не совсем то, или еще что-то. Вы документ поступления корректируете, добавляете затраты, но Вы уже продали барахло, т.е. оформили документ продажи, который списал партии по старой
ценесебестоимости. И если Вы документ поступления скорректируете, то списанная себестоимость документа продажи сама себя не скорректирует.То же самое с оплатами, которые 1С автоматически раздербанивает по исторически сложившейся последовательности документов отгрузки/поступления, и если они вдруг были скорректированы, то у вас будет что-то недосписано. Т.е. образуется некая кредиторская/дебиторская задолженность в разрезе отдельных аналитических признаков учета (договор, документ, контрагент даже). И чтобы все стало красиво, 1С-неги не придумали ничего лучше (нет, придумали - РАУЗ, но это не помогает с "бабочками" по ДЗ/КЗ), чем перпровести документы. Вот такая вот интересная штука эта 1С. И для всего этого есть даже специальный механизм - последовательность учета. При том эти последовательности могут быть не в одном экземпляре, например, по ДЗ/КЗ и по партиям, по кадровым документами, по производственному учету и по всему тому, что еще было напихано в конкретное решение.
edo1h
31.01.2023 17:50так это вам не срезы нужны, а требуется исправить цепочку ошибочных документов.
да, для общего случая решения лучше «отменить всё и создать документы заново» нет. не вижу тут никакой специфики 1с.
1CUnlimited Автор
31.01.2023 18:06-1Т.е. 1374 - это не 50 потоков, а 1803 - это 50?
50 потоков в обеих тестах. Просто потоки работают параллельно и 1374 записей\сек или 1803 записей\сек это скорость посчитанная суммированием скоростей потоков. Поэтому когда Вы считаете среднюю скорость потока то по Вашей логике - если у каждого она увеличилась на 33% то общая увеличится 33%*50=1650% а в тесте не так. Лучше я Excel полный выложу.
По поводу ОРМ, то разработчик на 1С ограничен ОРМ от 1С для записи данных в базу. Объясняется это тем, что нужно соблюдать ACID
Ихмо это всего лишь одна из причин, там же еще guid кластеру нужно генерить и еще много чего
В то время как во всех фреймворках, код которых в части ОРМ открыт, никто не мешает при необходимости эту ОРМ чуть-чуть подкрутить (шардирование, например, воткнуть).
Как при шардировании сделать эффективный Join таблиц? Я думаю что не каждый программист может Map Reduce прикрутить. Мне кажется шардирование это уже другая лига
Ну и полное отсутствие обновления данных через UPDATE в угоду все тому же ACID делает механизмы обновления крайне проблемными с точки зрения производительности. Напрмер, чтобы перепровести все документы (а это зачастую единственный путь получить "правильный" срез учета), необходимо их всех перезаписать с признаком проведения, в итоге в СУБД для каждого объекта запустится последовательная транзакция
Вообще лучше бы MERGE тем более он входит в свежие стандарты SQL . Вообще как сделать эффективным запись в банальный регистр накопления с итогами, это очень интересная тема. С одной стороны использование средств специфичных для СУБД (tables of records, или forall из Oracle) 100% сделают код Orm закрытым, с другой стороны можно и стандартом SQL свежим обойтись если делать по одному DML на 1000 записей.
Кстати 1С догадывается что тотальный delete insert пагубен для производительности и как показано в Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? / Хабр (habr.com) контролирует измененность записи на сервере приложений. Т.е. распределение логики между сервером приложений и СУБД тоже хорошая тема для ORM но опять же при запси сущностей группой по 100-1000 записей
starik-2005
31.01.2023 23:51Т.е. распределение логики между сервером приложений и СУБД тоже хорошая тема для ORM но опять же при запси сущностей группой по 100-1000 записей
Основная проблема тут - это то, что при проведении документов (по крайней мере реализации) нужны "исторические данные", ведь таблицы проводок формируются программно. А для "исторических данных" нужны записанные таблицы остатков, которые могут быть прочитаны. Нам нужны партии, взаиморасчеты, остатки, резервы, ... И если писать пачками, то на что ваять селекты на эти самые остатки всего на свете? Тот же подход с контролем регистров накопления при записи в модуле их менеджера как бы намекает, что пачками вряд ли что получится - это ж не справочники обменами гонять между базами - там в этом был бы смысл, но клятый ACID...
1CUnlimited Автор
01.02.2023 13:21.. И если писать пачками, то на что ваять селекты на эти самые остатки всего на свете?
Если конечно логику проведения документа закладывать в процедуру ОбработкаПроведения документа , да проблем такого рода не избежать поскольку уже единицей обработки является документ а не пакет документов. Такой подход оправдан если нужно автоматизировать отдел продаж где менеджеры обрабатывают заявки.
Но если у Вас Озон-Амазон или сделки по ценным бумагам в крупном брокере у Вас и архитектура приложения будет строится иначе
Интеграция с фронтом (поскольку на 1С фронт не напишешь хорошо хотябы по линцензионным причинам, только бэкофис)
Оперативное проведение (с упрощенным контролем\фиксацией остатков оперативного учета, но без проводок)
Перепроведение (как часть процедуры закрытия дня, недели)
И вот для задач перепроведния, работа с пакетами документов будет строится не из модуля документа (ОбработкаПроведения) а отдельной обработкой которая будет создавать проводки сразу для 1000 документов в памяти кластера и потом уже постить.
При этом ACID тут не мешает совершенно
Во первых все зависит от ключей по которым делятся сущности это может сделать обработка, и пакеты \ группы документов будут постится независимо
Во вторых процедура закрытия дня\недели может делатся в технологические окна роботами если не хочется усложнять архитектуру
Даже если у Вас алгоритм, который трудно параллелится напр FIFO его можно параллелить в разрезе (товаров\ценных бумаг и т.д.) , фиксировать остатки только на конец дня, а день считать в памяти.
Приемы крупным планом представлены тут
Язык мой – враг мой / Хабр (habr.com)
Главное не считать типовые конфигурации за правильный паттерн, это скорее всего антипаттерн с точки зрения маштабируемого решения. Даже 1С ЗУП на 5000 человек в типовом варианте это показывает, а там параллелить обработку легко. Нагруженный процесс к типовым конфигурацям лучше делать свой как отдельную подсистему, а учет муторных но небольших объемов оставить на механизмах типовой. Большая проблема кроется именно в регистрах с итогами, там прямо архитектурно место для deadlock
Tzimie
01.02.2023 22:54Если речь зашла о записи в лог, то для MSSQL важнейший параметр Delayed Durability
1CUnlimited Автор
01.02.2023 23:08Думаю это просто еще один способ оттянуть неизбежное . В первой части ссылка на статью хабра есть. Но когда читаешь раздел data loss https://learn.microsoft.com/en-us/sql/relational-databases/logs/control-transaction-durability?view=sql-server-ver16#bkmk_DataLoss есть подозрение что это не для prod . Но как нибудь проверю и этот параметр
Tzimie
02.02.2023 12:36Для prod. Он не нарушает порядок записи в Wal. Почты теоретически вы можете потерять доли секунды работы
1CUnlimited Автор
02.02.2023 13:59Мне только не понятно , Delayed Durability он может потерять завершенную транзакцию или незавершенную. Поскольку незавершенные и так откатываются в обычном режиме. Нет ли тут каких то подводных камней типа разрушеных условий primary key, нумерации Identity?
Tzimie
02.02.2023 14:57Разрушенных условий быть не может. А вот закомиченую транзакцию вы потерять можете (как и в асинхронном always on и при ресторан из бэкапа плюс транзакшн логи). Но как правило речь идёт о доляжх секунды.
Так что базы для импорта данных вы точно можете в этот решим перевести (и одинокие инсерты ускорятся в десятки раз), переводы денег между счетами в банке вероятно нет, но есть куча не такой критичной деятельности.
edo1h
02.02.2023 20:47А он что-то делает помимо снижения частоты сброса буферов?
На dc ssd штраф на синхронную запись фактически нулевой, то на боевом сервере прироста производительности может и не быть (а вот на машине разработчика он может быть очень существенным).
Kwisatz
Статья понравилась, но столько отсылок к 1с? ЕЕ крутить замучаешься чтобы она базу хотя бы приблизительно нормально использовала. И даже тогда, откройте мониторинг запросов и посмотрите что именно она делает. Я несколько раз в разных режимах проводил такие набеги, страшнее не видел ничего.
1CUnlimited Автор
Просто 1с хороший пример как разработчики делая orm удобным для программиста 1с (а он реально удобен) совершенно не заботятся о производительности. Хотя у них и devops и хорошая обратная связь от франчайзи есть. А ведь им еще захватывать сданный без боя рынок финансовых систем западных вендоров. Да под капотом там "миниган" из dml . Если еще им воспользуется программист 1с который статьи о оптимальном программировании на языке 1с на its.1c.ru не читал , тут и оборудование не спасет
Kwisatz
Он удобен? Мире Hibername/Doctrine - да, в мире 1с - на три (ну ок, на два) порядка хуже. А вообще проблема не в том что там "миниган" (хотя еслиб он стрелял только когда его просят это еще было бы переживаемо), а в том что там "тупой миниган".
Мой личный рекорд - отчет, который формировался 40 минут, уложить в запрос со временем выполнения 0.9 сек без изменения данных/реконфигурации базы/добавления индексов. Это совершенно за гранью добра и зла.
Про программистов я согласен, но у них даже в стандартных конфигурация полно дурдома и вычислений на стадии запроса.
1CUnlimited Автор
Хуже чего?
А так да удобен - скажите где при создании экземпляра объекта (напр документ с собственными табличными частями и реквизитами) вы сразу получите готовый интерфейс, и отображение в СУБД с индексами ? И это без отладки и СМС. Причем эту конфигурацю Вы можете портировать на любую и 4х поддерживаемых СУБД просто импортом \ экспортом. Это реальный Rapid Application Development где можно реально быстро получить результат
Мы ворочаем у себя 5 терабайтной базой, при грамотном подходе к реализации причем только средствами 1С без прямых запросов к MS SQL . Принципы и приемы изложены тут Язык мой – враг мой / Хабр (habr.com) . Это возможно если рассматривать платформу как инструмент для генерации запросов, то подогнать запрос\инструкцию 1С под хороший план вполне можно. Это своего рода создание оптимального паттерна программирования
Типовые конфигурации 1С проектировались без оглядки на обработку больших объемов, хотя можно было бы делать по другому. Видимо политика "Лучше 10 маленьких клиентов чем один большой" еще действует. Но времена меняются когда читаешь это Фирма «1С» открывает новую компанию с бывшим менеджментом российского офиса SAP (infostart.ru)
Тупость "минигана" в 1С проявляется прежде всего на операциях записи поскольку там вариантов оптимизации почти нет. С обычными запросами к базе все проблемы решаемы хотя с общими разделителями они промахнулись Лучшее соединение враг хорошего? / Хабр (habr.com)
Кстати никто не запрещается создать свою внешнюю компоненту в 1С со своим отображением на СУБД - Api полностью открыт. Правда есть один нюанс, механизм отчетов тоже придется делать внутри компоненты