От экспертов «1С-Рарус»: Как и зачем интегрировать Yandex ClickHouse с 1С?

Рост потребности в BI-системах

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

Это приводит к ситуации, когда становится невозможно эффективно управлять компанией без использования современных средств автоматизации бизнес-анализа. Средства, дающие организациям возможность превращать накапливаемые данные в информацию о бизнесе, а затем информацию — в знания для управления бизнесом, объединяются под термином business intelligence или BI решения.

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

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

Быстрое получение отчетов позволит пользователям оперативно изменять выбранный набор данных и получать результат, проверяя различные бизнес-гипотезы.

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

OLTP и OLAP. Два основных подхода к обработке данных

OLTP (OnLine Transaction Processing) — обработка данных транзакционной природы в реальном времени. Типичными примерами задач, решаемых таким способом, являются ввод заказов, розничные продажи, системы финансовых транзакций: банкоматы, оплата покупок банковской картой.

Важнейшими требованиями к реализации такого подхода являются принципы ACID:

• Atomicity (Атомарность) — гарантирует, что транзакция будет зафиксирована полностью. Будут либо выполнены все её подоперации, либо не выполнено ни одной.
• Consistency (Согласованность) — успешная транзакция фиксирует только допустимые результаты, сохраняя согласованность данных.
• Isolation (Изолированность) — Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на ее результат.
• Durability (Устойчивость) — результат работы завершенной транзакции, должен остаться сохраненными после аварийного завершения работы системы.

К системам реализующим такой подход относят реляционные СУБД. Структуры данных хранимые в таких системах, как правило нормализованы для соблюдения принципа согласованности, при чтении данных могут возникать блокировки для соблюдения принципа атомарности и изоляции. Хотя конечно надо понимать, что правила нормализации действуют в определенных границах и могут быть нарушены в ситуациях, когда приоритет производительности выборки данных выше, чем требования к объемам хранения и академическим правилам.

OLAP (OnLine Analytical Processing) — интерактивная аналитическая обработка. Подход к обработке и хранению данных, заключающийся в подготовке агрегированной информации на основе больших массивов данных, структурированных по многомерному принципу. Многомерный принцип подразумевает осознанную денормализацию данных, поскольку основной задачей подобных систем является скорость извлечения данных.

Цель данного подхода — сократить скорость доступа к большим данным. Примеры задач, решаемых таким подходом: годовые финансовые результаты, сравнение выручки розничных магазинов в разрезе различных категорий пользователей.

Сравнение методов

В реальной жизни, как правило, используются оба подхода, поскольку решаются оба класса задач. А между OLTP и OLAP системами выполняется регулярная миграция данных. Степень регулярности определяется требованиями к аналитической отчетности. Важно ясно понимать, что это две совершенно разные архитектуры и они не являются заменой друг друга и не конкурируют друг с другом, а напротив, решая разный класс задач, являются дополнением друг к другу.

Тестируем MS SQL для быстрого построения отчетов на основании больших данных

В «1С-Рарус» разработано решение «Система управления лояльностью», которое представляет собой веб-приложение для организации маркетинговых мероприятий. В качестве хранилища данных, оно использует базы СУБД MS SQL Server.

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

В качестве front-end решения, для управления приложением и его данными используется конфигурация на базе системы «1С:Предприятие», опубликованная в виде веб-интерфейса.

Конечно клиенты нуждаются в построении аналитической отчетности: средний чек по периодам, покупателям, регионам; выручка по магазинам в сети, эффективность маркетинговых акций, пропускная способность торговых точек и многие другие показатели и аналитические разрезы. Данные для построения такой отчетности у нас есть, но база данных, в которой они хранятся, не является базой «1С:Предприятие».

Рассматриваемые варианты решения задачи:

• Запрашивать данные с сервера MS SQL и через программный интерфейс веб-приложения, через http протокол.
• Подключить таблицы как внешний источник данных и выполнять запросы «1С:Предприятие», получая данные напрямую из MS SQL.
• Выполнить репликацию данных MS SQL в какую-то другую систему и осуществлять запросы к ней.

Первые два способа объединяет то, что нагрузка при выборке данных по-прежнему остается на сервере MS SQL. Для решения проблемы можно было бы вынести некоторые таблицы «на чтение» в память, таким образом снизив скорость доступа к ним, но это повлечет за собой ряд проблем:

• Необходимо будет пересматривать схему баз данных и методы модификации данных для сохранения консистентности данных, а это затраты на рефакторинг фактически работающего сервиса. Например, в системе есть две таблицы, на базе которых рассчитывается актуальный баланс карт, запись в них выполняется при каждой продаже, массовое чтение в другой транзакции может оказаться неэффективным, придется создать отдельную таблицу и обновлять её периодически.
• Блокировки на чтение данных остаются, поэтому для быстрого чтения необходимо дублировать данные.
• Увеличение объема памяти с ростом размера базы.

Оба способа были опробованы, но не оправдали ожиданий, как раз за счет нагрузки на MS SQL Server. На относительно небольших объектах, порядка 30–50 тысяч чеков в месяц, т. е. полмиллиона чеков в год, простые годовые агрегирующие отчеты строятся достаточно быстро, около 2–3 секунд.

О каких объемах данных идет речь, когда начинаются сложности со скоростью формирования отчетов. В среднем покупка составляет 2–5 позиций и в год 500 тысяч чеков. То есть верхняя оценка 500 тыс * 5 = 2,5 млн записей. Отчеты агрегирующие данные в разрезе позиций в чеке, выполняются уже порядка 4–5 секунд.

Количество скидок на одну позицию может зависеть от множества факторов, но как правило после соединения с таблицей скидок количество записей увеличивается, то есть со скидками таких записей становится больше 2,5 млн. Отчеты, строящиеся в разрезе скидок на каждую позицию в чеке, могут зависнуть надолго.

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

Основные параметры сервера, на котором выполнялись запросы:

• OS: Windows Server 2012 R2.
• Процессор: Intel® Xeon® Gold 6254.
• RAM: 32 GB.
• СУБД: Microsoft SQL Server Standard (64-bit).

Поэтому было принято решение реплицировать данные в другую систему. Реплицировать нужно асинхронно, чтобы не тормозить работу OLTP системы.

Механизм репликации обычно называют ETL (Extract Transform Load), то есть извлечь, преобразовать, загрузить. Перед выбором системы репликации, нужно было определиться с целевой системой хранения данных реплик.

Основные подходы к реализации OLAP системы:

• Базы данных в памяти (in-memory DB). Такие базы данных позволяют полностью или частично хранить данные в оперативной памяти. Базы данных в памяти работают быстрее, чем базы данных, оптимизированные для диска, потому что доступ к диску медленнее, чем доступ к памяти, внутренние алгоритмы оптимизации проще и выполняют меньше инструкций ЦП.

  Доступ к данным в памяти сокращает время поиска на диске при запросе данных, что обеспечивает более быструю и предсказуемую производительность. Потенциальным техническим препятствием при хранении данных в памяти является ее энергозависимость.

  В частности, в случае отключения питания, преднамеренного или иного, данные, хранящиеся в энергозависимой RAM, теряются. С внедрением технологии энергонезависимой памяти с произвольным доступом базы данных в памяти смогут работать на полной скорости и сохранять данные в случае сбоя питания.
• Традиционные реляционные СУБД. Конечно, современные СУБД можно применять для получения аналитической отчетности. Проблемы, возникающие при их использовании описаны выше.
• Колоночные СУБД. Системы управления базами данных, реализующие хранение данных в виде столбцов, в отличие от строковых (реляционных*) баз данных.

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

Колоночные или столбцовые СУБД

Любая реляционная СУБД обрабатывает данные в виде таблиц, содержащих столбцы и строки. Этот двухмерный формат является абстракцией. В реальности жесткий диск требует, чтобы данные были сериализованы в ту или иную форму.

В обычной, «строковой» СУБД, данные хранятся в таком порядке:

То есть, значения, относящиеся к одной строке, физически хранятся рядом.

В столбцовых СУБД, данные хранятся в таком порядке:

В примерах изображён только порядок расположения данных.

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

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

Хорошо иллюстрируют архитектурную разницу между выборкой данных из строковых и колоночных БД две следующие анимации.

Чтение в строковых СУБД

Чтение в колоночных СУБД

Для выполнения аналитического запроса, требуется прочитать небольшое количество столбцов таблицы. В столбцовой БД для этого можно читать только нужные данные. Так как данные читаются «пачками», то их проще сжимать. Данные, лежащие по столбцам также лучше сжимаются. За счет этого, дополнительно уменьшается объём ввода-вывода, и как следствие больше данных влезает в системный кэш.

Как видно, в целом колоночные СУБД не являются заменой традиционным «строковым» СУБД. В то время как «строковые» СУБД прекрасно справляются с OLTP сценарием обработки данных, колоночные СУБД призваны решить проблему неэффективной работы традиционных СУБД в аналитических системах и системах в подавляющим большинством операций типа «чтение», то есть реализуют OLAP сценарий обработки данных.

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

Организация хранения и работы с данными в колоночной базе данных или наконец про ClickHouse

В итоге для «Системы управления лояльностью» качестве платформы хранения и обработки данных для аналитической отчетности была выбрана колоночная СУБД  Yandex ClickHouse.

Причины выбора Yandex ClickHouse

• Сжатие данных.
  Некоторые столбцовые СУБД (InfiniDB CE, MonetDB) не используют сжатие данных. Однако сжатие данных действительно играет одну из ключевых ролей в демонстрации отличной производительности.
  
• Хранение данных на диске.
  Многие столбцовые СУБД (SAP HANA, Google PowerDrill) могут работать только в оперативной памяти. Такой подход стимулирует выделять больший бюджет на оборудование, чем фактически требуется для анализа в реальном времени. ClickHouse спроектирован для работы на обычных жестких дисках, что обеспечивает низкую стоимость хранения на гигабайт данных, но SSD и дополнительная оперативная память тоже полноценно используются, если доступны.
  
• Параллельная обработка запроса на многих процессорных ядрах.
  Большие запросы естественным образом распараллеливаются, используя все необходимые ресурсы из доступных на сервере.
  
• Распределенная обработка запроса на многих серверах.
  Почти все перечисленные ранее столбцовые СУБД не поддерживают распределенную обработку запроса. В ClickHouse данные могут быть расположены на разных шардах. Каждый шард может представлять собой группу полных реплик, которые используются для отказоустойчивости. Запрос будет выполнен на всех шардах параллельно. Это делается прозрачно для пользователя.
  
• Поддержка SQL.
  ClickHouse поддерживает декларативный язык запросов на основе SQL и во многих случаях совпадающий с SQL стандартом. Поддерживаются GROUP BY, ORDER BY, подзапросы в секциях FROM, IN, JOIN, а также скалярные подзапросы. Коррелирующие подзапросы и оконные функции не поддерживаются.
  
• Векторный движок.
  Данные не только хранятся по столбцам, но и обрабатываются по векторам — кусочкам столбцов. За счёт этого достигается высокая эффективность по CPU.
  
• Обновление данных в реальном времени.
  ClickHouse поддерживает таблицы с первичным ключом. Для того, чтобы можно было быстро выполнять запросы по диапазону первичного ключа, данные инкрементально сортируются с помощью merge дерева. За счет этого, поддерживается регулярное добавление данных в таблицу. Блокировки при добавлении данных отсутствуют.
  
• Наличие индекса.
  Физическая сортировка данных по первичному ключу позволяет получать данные для конкретных его значений или их диапазонов с низкими задержками — менее десятков миллисекунд.
  
• Подходит для онлайн запросов.
  Низкие задержки позволяют не откладывать выполнение запроса и не подготавливать ответ заранее, а выполнять его именно в момент загрузки страницы пользовательского интерфейса. То есть, в режиме онлайн.

Читатель вправе усомниться в том, что все так хорошо и нет никаких недостатков. Разумеется, они есть, но важно понимать, что для нашей задачи они практического значения не имели.

Недостатки Yandex ClickHouse

• Отсутствие полноценных транзакций.
• Возможность изменять или удалять ранее записанные данные с низкими задержками и высокой частотой запросов не предоставляется. Есть массовое удаление и изменение данных для очистки устаревших данных.
• Разреженный индекс делает ClickHouse плохо пригодным для точечных чтений одиночных строк по своим ключам.

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

Репликация мастер-данных в ClickHouse

Итак, мы имеем мастер-данные, которые находятся в базе данных клиента на сервере MS SQL, выбрана целевая система хранения данных. Теперь нужно реплицировать данные из одной СУБД в другую. Можно использовать несколько подходов:

• Использовать HTTP-интерфейс, который по-умолчанию предоставляет ClickHouse.
• Использовать ssh-интерфейс, для передачи данных и загрузки уже на стороне сервера ClickHouse.

Был выбран первый вариант, так как программная реализация взаимодействия с системой по протоколу ssh более трудоемка.

В качестве ETLрешения не рассматривались готовые продукты, так как одним из требований была тесная интеграция с нашим Сервисом управления лояльности. Было реализовано собственное приложение, отвечающее за извлечение, преобразование и заливку данных.

Приложение выполняется в фоне, и по расписанию запускает задачу репликации данных. Для определения логики репликации составляется файл правил миграции, которые исполняются последовательно и могут содержать запросы к MSSQL, запросы к ClickHouse и непосредственно миграцию таблиц.

Пример простого файла правил:

Основным узлом, выполняющим операции репликации, является узел operations, он содержит последовательный набор узлов node различного типа:

• tsql — исполнение запроса или пакета запросов в базе MSSQL;
• clickhouse — исполнение запроса или пакета запросов на сервере ClickHouse;
• migration — выполнение миграции таблицы из MSSQL в таблицу ClickHouse.

На базе этих атомарных операций, в общем то и построены правила миграции между базами. Общий шаблон правил выполняет следующие операции:

• создание базы на сервере ClickHouse, если её не существует;
• создание служебных таблиц метаданных, о которых мы поговорим чуть позже;
• создание буферных таблиц репликации;
• создание конечных пользовательских таблиц и представлений, которые послужат источником данных для аналитической отчетности.

Полный пример файла правил миграции

Пример узла миграции

Для примера возьмем таблицы, относящиеся к продажам. Упрощенная ER-диаграмма основных таблиц выглядит так:

bsSales — таблица документов продаж.
bsSalesItems — товары в документах продаж.
bsCalculateHistory — скидки, рассчитанные по каждой позиции товара.

Связи таблиц показаны на рисунке.

Правила миграции таблицы bsSales выглядят следующим образом (для остальных таблиц правила аналогичные):

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

Для таблиц справочной природы, существует специальное поле rowversion, которое увеличивается при модификации записи, что позволяет реплицировать только измененные записи для некоторых таблиц.

Одно правило миграции выполняется итерационно в M потоков. Каждый поток оперирует своей областью данных и выгружает не более fetchSize записей из источника.

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

Данные сериализуются в JSON формат и отправляются на сервер Clickhouse через стандартный http-интерфейс (https://clickhouse.tech/docs/ru/interfaces/http/).

Таким образом выгрузка продаж за 2 года занимает около 2–3 минут.

Количество выгружаемых записей:

Это только записи продаж, не считая товаров по каждой продаже и скидок по каждому товару. В случае однопоточной выгрузки, та же таблица выгружается в течение 15 минут. На данный момент реплицируется 7 таблиц.

После выгрузки данные трансформируются в более «широкие» таблицы, путем денормализации и соединения существующих таблиц. Создаются дополнительные агрегирующие таблицы и представления для получения общих показателей аналитики.

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

Управление метаданными подсистемы отчетности в 1С

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

Для обобщения и удобства представления данных пользователю была разработана подсистема, позднее включенная в личный кабинет веб-приложения «Система управления лояльностью».

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

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

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

Для хранения метаданных используется возможность ClickHouse сохранять прямо в таблице вместе с колонкой строковый комментарий к ней. Таким образом, метаданные в виде JSON объекта сохраняются прямо с таблицей.

Пример запроса сохранения метаданных колонки:

ALTER TABLE TABLE_NAME

  COMMENT COLUMN year '{

      "repr": "Год",

       "tool_tip": "",

       "role": "dimension",

       "default_agg": "any(%1)",

       "default_dim": "year",

       "hidden": false,

       "period_field": false,

       "digits": 0,

       "props_table": "",

       "prop_id": "",

       "type_props_table": "static",

       "dis_change_role": false,

       "dis_filter": false,

       "guid_field": "",

       "formatter_id": ""

  }'

Когда колонок в таблице много, а их обычно много в соответствии с OLAP сценарием, редактировать в текстовом виде такие запросы становится сложно. Редактор метаданных, как раз позволяет редактировать метаданные в графическом интерфейсе и генерировать запрос на помещение метаданных в таблицу:

Далее запрос используется при создании таблиц в правилах репликации, обычно вместе с запросом создания таблицы:

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

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

Шаблон правил хранится в git репозитории, когда стабильные изменения попадут в мастер-ветку, их можно втянуть на сервере и все последующие по расписанию задания репликации будут использовать новый шаблон.

Со стороны 1С подсистема отчетности считывает метаданные таблиц и позволяет бизнес-пользователю работать с данными в терминах предметной области:

Роли полей делятся на группировки и агрегаты (колонки). Роль полям назначается по умолчанию, но её всегда можно изменить.

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

Выборка данных из ClickHouse

Для того чтобы получить набор данных с сервера ClickHouse, подсистема интеграции предоставляет возможности:

• формирования запроса вручную,
• формирования запроса конструктором.

Конструктор — это обработка, позволяющая в «текучем» стиле собрать текст запроса перед отправкой на обработку:

Такой подход разделяет логику формирования запроса и операций с метаданными.

Запросы на сервер Clickhouse отправляются через стандартный http-интерфейс (https://clickhouse.tech/docs/ru/interfaces/http/).

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

Сервер ClickHouse отвечает на запрос в формате, указанном в запросе. Мы используем JSON формат. Файл ответа фактически содержит массив объектов, ключи которых соответствуют именам колонок в базе данных, а значения определяют сериализованные значения из «ячеек» таблицы в строке данных.

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

Вывод данных отчета

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

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

Сначала мы попытались использовать встроенные в платформу «1С:Предприятие» инструменты и выводить отчет в виде табличного документа. Но уже на 50000 записей табличный документ не справлялся с нагрузкой и вывод отчета выполнялся целые минуты, хотя выборка данных и десериализация занимали миллисекунды. Периодически получали ошибки нехватки памяти.

Было принято решение попробовать выполнять вывод через поле HTML-документа, используя JavaScript. Был проведен анализ нескольких готовых библиотек, остановились на Tabulator (http://tabulator.info/).

Она показала лучшие результаты на сравнительно больших выборках за счет использования способа вывода Virtual DOM. Вместо того, чтобы взаимодействовать с DOM напрямую, мы работаем с его легковесной копией. Мы можем вносить изменения в копию, исходя из наших потребностей, а после этого применять изменения к реальному DOM.

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

DOM (Document Object Model) — способ представления структурного документа с помощью объектов. Это кроссплатформенное и языко-независимое соглашение для представления и взаимодействия с данными в HTML, XML и т. д.

В качестве ограничения выборка данных выполняется последовательно при раскрытии каждого уровня дерева:

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

Заключение

В одну телегу впрячь неможно
Коня и трепетную лань.
Забылся я неосторожно:
Теперь плачу безумства дань...
Полтава (А. С. Пушкин)

Статья является в определенном смысле антагонистом строкам великого поэта и протагонистом строкам Александра Сергеевича из другого произведения.

Они сошлись. Волна и камень,
Стихи и проза, лед и пламень
Не столь различны меж собой.
Сперва взаимной разнотой
Евгений Онегин (А. С. Пушкин)

Важно осознанно подходить к работе с данными и понимать, когда различные подходы приведут к «недвижимости телеги», а когда дадут синергетический эффект. Что мы должны учитывать:

• Какие производятся запросы к данным?
• Как часто и в каком соотношении?
• Сколько читается данных на запросы каждого вида: строк, столбцов, байт?
• Как соотносятся чтения и обновления данных?
• Какой рабочий размер данных и насколько локально он используется?
• Используются ли транзакции и с какой изолированностью?
• Какие требования к дублированию данных и логической целостности?
• Требования к задержкам на выполнение и пропускной способности запросов каждого вида?

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

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

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

Еще статьи о производительности и работе с базами данных для 1С:

• Ускоряем в 3 раза открытие сложной формы в 1С 8.3
• Оптимизация перезапуска рабочих процессов на платформе «1С» 8.3.15 и выше
• База 1С растёт и всё тормозит. Что делать?
• Страничные блокировки в MS SQL Server при проведении документа в документе в 1С
• Производительность нового RLS в 1С БСП 3. Переходить или нет?