Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД

01.02.23

База данных - HighLoad оптимизация

ORM (Object Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений приводит к мысли, что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущей части статьи были изложены результаты теста, в этой статье ответы на самые часто задаваемые вопросы и новый тест.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?]
Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД:
.epf 9,76Kb
8
8 Скачать бесплатно

В предыдущей части статьи Концепция 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 можно штатной выгрузкой\загрузкой базы.

производительность orm transaction log

См. также

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    8669    Evg-Lylyk    61    

43

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    4851    spyke    28    

49

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    7203    vasilev2015    20    

42

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    11776    225    ZAOSTG    76    

115

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    5229    glassman    17    

40

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    12287    doom2good    49    

71
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. triviumfan 96 07.02.23 09:47 Сейчас в теме
Если DML - это язык манипулирования данными, то что есть "поток мелких DML", "крупные DML" в данном контексте?
2. Cyberhawk 135 07.02.23 15:54 Сейчас в теме
(1) Пишем СМС, подразумеваем СМС-сообщение.
Пишем ДМЛ, подразумеваем ДМЛ-выражение / ДМЛ-оператор.
triviumfan; +1 Ответить
3. 1CUnlimited 320 13.02.23 14:32 Сейчас в теме
(1) Укрупнить dml можно разными способами
не делать 10 insert и Update
Например использовать Table valued параметры
https://www.sqlshack.com/table-valued-parameters-in-sql-server/
Для Oracle есть For all
https://blogs.oracle.com/connect/post/bulk-processing-with-bulk-collect-and-forall

Если хочется быть ближе к стандарту SQL
как вариант insert in to xxx values (1,2,3), (4,5,6), (7,8,9)
либо табличные параметры забросить во временную таблицу #ParTab
И использовать ее в дальнейшем
triviumfan; +1 Ответить
4. triviumfan 96 13.02.23 18:59 Сейчас в теме
(3) Аааа, понял о чём, где-то уже натыкался на такие темы ранее.
Для меня как разработчика сервер 1с - это чёрный ящик к которому нет доступа, можно лишь глянуть трассировку запросов, поинтересоваться а как оно там "под капотом" и как сервер приложений общается с СУБД.Только не за чем (кроме как разбора планов запросов).
Тема скорее для разработчиков платформы, которые сюда вряд ли заходят.
Да и раз они выбрали такой путь реализации (если это реальный пример) вставки 10 записей отдельными insert-ами - значит не спроста :).
ЗЫ: Скорее всего чем больше поддерживаемых СУБД, тем сложнее использовать оптимальные DML в каждом кейсе. Да и 1с - это не про скорость)
5. 1CUnlimited 320 13.02.23 21:36 Сейчас в теме
(4) 1C это всего лишь генератор запросов к СУБД . Причем изначально сделанный неэффективно по производительности.
Эффективная архитектура на 1С при работе с большими объемами получается только при изучении этого черного ящика через MS SQL Profiler или подобные средства. Структуру базы и индексов 1С специально публикует, чтобы было понимание как программирование на языке отражается в СУБД и для обслуживания .
Попробуйте базу в 5 терабайт обслуживать штатными средствами 1С или запросы по большой таблице - там ждут сюрпризы Лучшее соединение враг хорошего

>>Да и раз они выбрали такой путь реализации (если это реальный пример) вставки 10 записей отдельными insert-ами - значит не спроста :)
Да не спроста. Если посмотреть что они делают и как понимают горизонтальное маштабирование - там направление на экстенсивное наращивание функционала, а не эффективную работу платформы с объемами. Собственно тут все изложил Язык мой враг мой

P S Разработчики 1С про поднятые проблемы знают , писал.
6. ILM 241 08.06.23 06:27 Сейчас в теме
- Делать то нам что? Продолжать плакать? Или уже можно начать радоваться?
7. kauksi 217 16.02.24 16:16 Сейчас в теме
очень интересно, но тест не запускается. или это шаблон для ознакомления?
Оставьте свое сообщение