Как мы боролись за масштабируемость Docsvision (Эпизод 3 — масштабирование Базы данных)
У большинства тех, кто глубоко не знаком с технологиями современных СЭД/ECM-систем, имеется не совсем правильное представление о том, что основная функция этого класса платформ — работа с неструктурированным контентом и управление файлами. На практике это не совсем — или даже совсем не — так.
Развитые функции работы с неструктурированными данными действительно являются отличием СЭД/ECM-систем, но это далеко не самая сложная и критичная функциональность. Сложность и разнообразие функций обработки структурированных данных СЭД/ECM ничуть не меньше, чем в тех же ERP-системах, и они имеют свои особенности, которые делают эту работу порой очень интенсивной и сложной в реализации. Именно поэтому в основе всех крупных промышленных СЭД/ECM-платформ лежит та или иная промышленная СУБД, средствами которой в значительной мере и реализуются функции работы со структурированными данными СЭД/ECM.
Работа со структурированными данными в СЭД/ECM связана прежде всего с метаданными документов — так принято называть различные атрибуты и свойства документов, которые отображают структурированную его часть. Не будем тут вдаваться в обсуждение корректности использования термина метаданных в данном контексте (на самом деле в Docsvision есть слой описания структуры документов различных типов и логики их обработки, которые больше соответствуют понятию метаданные (данные, описывающие данные)). Отметим только, что структурированная часть документа фиксирует не только статические атрибуты документа, но и самые разнообразные динамические данные, которые порождаются в ходе обработки документов (текущее состояние, журналы обработки, текущие права доступа и пр.). Этих данных много и логика работы с ними весьма нетривиальна.
Вторая, достаточно сложная с точки зрения работы со структурированными данными, задача — это поиск документов. В системе Docsvision поддерживаются достаточно сложные структурированные поисковые запросы, включающие не только простые совпадения, но и работу с ключевыми словами, поиск по связанным данным, разрешение справочных данных и пр.
Третья, еще более сложная задача работы со структурированными данными, — это управление навигацией и представлениями. Система должна обеспечивать возможность отображения самых разнообразных реестров документов, причем отображать не только значения из отдельных атрибутов, но и данные связанных объектов, рассчитывать различные их агрегаты (например, считать количество времени, затраченного на обработку всех связанных с документом заданий и пр.). А если учесть, что в один реестр могут попадать документы различных типов, имеющих различную логическую структуру, то иногда необходимо осуществить не только отображение, но и преобразование типов данных на лету. Если вспомнить, что представления могут содержать документы различного типа, — можно понять, насколько существенную работу должен выполнять SQL-сервер при построении подобных представлений.
Ну и, наконец, работа ролевой модели. Описание всех тонкостей ее работы заняло бы не одну статью! Достаточно сказать, что прежде, чем отобразить документ в представлении, ролевая модель должна:
· определить все доступные роли для каждого вида отображаемого документа;
· прочитать данные, используемые для расчета роли, для каждой возможной роли из всех экземпляров карточек и, возможно, связанных с ними карточек;
· произвести расчет доступности каждой возможной роли для пользователя;
· определить доступность данных карточки для пользователя, учитывая доступные ему роли в текущем состоянии документа.
И только после этого определить — можно ли отобразить карточку в представлении. А если ролей много, и они рассчитываются сложным образом? А если карточек в представлении много? И отображение карточки в представлении — далеко не единственная функция ролевой модели.
В общем, можете себе представить, какое количество нагрузки ложится на плечи SQL-сервера.
Исходя из этого, становится очевидным, что в сложном функциональном внедрении именно SQL становится узким местом при масштабировании системы.
Технологий, которые бы обеспечили надежные механизмы распараллеливания нагрузки SQL-сервера, долгое время просто не было — и это узкое горлышко не позволяло строить сложные решения, использующие все возможности платформы Docsvision с количеством одновременных пользователей больше 7–10 тысяч, даже на очень производительном железе. Появившийся в составе Microsoft SQL Server 2014 механизм AlwaysOn для построения online кластера, обеспечил возможность решения этой проблемы.
Анализ потоков обработки данных показал, что 90% и более нагрузки на SQL-сервере в режимах работы Docsvision приходится на операции, связанные с чтением — это выполнение поисковых запросов, расчет представления и ролевой модели, формирование XML пакетов для отправки и пр.
В версии 5.5 с использованием технологий SQL AlwaysOn был реализован механизм реализации конфигурации 1 Master (сервер записи данных) — N Slave (сервер чтения данных), при котором все операции записи (менее 10% нагрузки системы) реализуются на одном Master-сервере, к которому может быть подключено произвольное количество Slave-серверов, реализующих функции чтения. Такая архитектура позволила расшить узкое место и обеспечить постепенное — по мере необходимости — масштабирование слоя управления данными. При этом нет необходимости в постоянном Upgrade оборудования основного SQL сервера, достаточно устанавливать дополнительные, возможно не очень производительные Slave сервера.
Благодаря использованию этих технологий мы обеспечили практически неограниченные возможности масштабирования системы. Но, для оптимальной реализации данной технологии, потребовалось полностью переписать подсистему хранения файлов и управления полнотекстовым поиском. Об этом — в следующем выпуске!
