Введение

Интеграционные контуры обмена сообщениями нередко совмещают метаданные и тело XML в одной реляционной таблице. При росте документооборота увеличивается объем базы данных, замедляются INSERT и SELECT, особенно в сценариях журналирования и фильтрации без чтения полного XML. Цифровизация межведомственного взаимодействия предполагает устойчивое хранение истории обмена: оператору интеграционного контура необходимо быстро получать журнал сообщений, фильтровать записи по статусу и периоду, не загружая при этом полный XML каждого документа. Именно такие сценарии list/filter составляют основную долю обращений к таблице учета сообщений и определяют требования к производительности СУБД [1]. Ранее влияние накопления XML на объем реляционного контура систем межведомственного электронного взаимодействия (СМЭВ) рассматривалось авторами в задаче резервного копирования [2]. Архитектурной альтернативой монолитному хранению является гибридная архитектура, в которой можно использовать композицию паттернов Claim Check и External Payload Storage (EPS), где в транзакционном хранилище остается «квитанция» (ключ), а полезная нагрузка выносится во внешнее хранилище соответственно. Паттерн Claim Check [3, 4] отвечает за логику «выдал квитанцию – забрал по квитанции»: в БД хранится только ключ, а данные временно вынесены. Паттерн EPS [5, 6] задает конкретное решение – в какое внешнее хранилище выносить данные и как ими управлять. Близкий прием – отделение реестра от тел объектов – рассматривается в работах по организации хранения данных [7, 8]. В отличие от монолитного хранения и частичного выноса через TOAST PostgreSQL [9], EPS явно разграничивает ответственность контуров и позволяет независимо масштабировать объектное хранилище [10]. В связи с этим исследование возможности применения гибридной модели с паттерном EPS в высоконагруженных системах с большим объемом бинарных данных с целью ускорения операций чтения/записи представляется актуальным.

Цель исследования – формализовать гибридную модель хранения полезной нагрузки сообщений по паттерну External Payload Storage, разработать методику количественной оценки объемов и времени операций записи и чтения (INSERT/SELECT) и подтвердить ее применимость экспериментально на промышленных инсталляциях.

Материалы и методы исследования

Объект – таблица smev_messages интеграционного контура. До EPS XML размещались в полях a_xml, a_service_message, a_generated_message; после миграции в PostgreSQL остаются идентификаторы, статусы, даты и ключи объектов, а payload хранится в MinIO [11]. Эксперимент проводился на БД № 1 (≈89 ГБ) и БД № 2 (≈1768 ГБ).

Для количественной оценки скорости операций чтения/записи применялись следующие методы сбора данных. Объемные характеристики определялись средствами PostgreSQL (параметры pg_database_size, pg_total_relation_size, pg_column_size) [12]. Планы выполнения и нагрузка на буферный кеш анализировались с помощью EXPLAIN (ANALYZE, BUFFERS). Временные характеристики операций записи и чтения измерялись c помощью Apache JMeter [13] на выборке N = 1000 операций; для каждой серии фиксировались минимальное, среднее и максимальное время. Массовая выборка моделировала запрос оператора с фильтром по диапазону дат и ограничением M = 1000 строк:

L = Lm + Lp, (1)

где Lm – служебные поля; Lp – XML-поля (pg_column_size).

Доля payload в объеме БД:

(2)

где Vp – объем XML-полей; Vdb – объем базы данных.

Сокращение таблицы после EPS:

(3)

где , – pg_total_relation_size до и после миграции.

Среднее время INSERT (N = 1000):

(4)

где ti – время i-й записи в монолитной схеме; после EPS:

(5)

где – INSERT метаданных;

TPUT – PUT в S3.

Коэффициент ускорения записи в СУБД:

(6)

Также для выборки метаданных вводился коэффициент KSEL как отношение среднего времени SELECT до и после внедрения EPS:

(7)

В монолитной схеме по формуле (4) измеряется одно время записи : INSERT строки вместе с XML. После EPS это время разделяется: – только INSERT метаданных в PostgreSQL, без обращения к объектному хранилищу, TPUT – только PUT XML в MinIO. Полный цикл записи сообщения является суммой этих величин (формула (5)). В формуле (6) коэффициент KINS относится исключительно к и не характеризует полный цикл . Сопоставление полного цикла с монолитной записью выполняется по и , а не по KINS.

Запись в случае использования EPS включает три последовательных шага: прием сообщения, загрузка XML во внешнее хранилище и INSERT компактной строки метаданных в PostgreSQL. Согласованность двух шагов обеспечивает Storage Adapter: при сбое записи в объектное хранилище транзакция в СУБД не фиксируется. Такой прикладной порядок согласуется с паттерном Claim Check и опирается на модели транзакционной фиксации [14] и восстановления [15]. Чтение реализовано в двух сценариях: сценарий A – SELECT только метаданных из PostgreSQL (журналирование / list-filter); сценарий B – SELECT метаданных с последующим GET объекта из S3 для формирования полного сообщения. Архитектура EPS и соответствующий процесс выполнения операций чтения/записи наглядно представлены на рис. 1 и 2.

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

Рис. 1. Архитектура паттерна External Payload Storage Примечание: составлен авторами по результатам данного исследования

Рис. 2. Контракты чтения/записи при использовании EPS Примечание: составлен авторами по результатам данного исследования

Результаты исследования и их обсуждение

В рамках данного исследования под гибридной моделью хранения полезной нагрузки сообщений в работе понимается разделение данных сообщения на два связанных контура:

1) транзакционный реестр в PostgreSQL – компактная строка метаданных сообщения (идентификаторы, статусы, временные метки, атрибуты маршрутизации) и ключ объекта полезной нагрузки;

2) внешнее объектное хранилище (S3-совместимое [16], MinIO) – тело сообщения (XML/payload) как независимый объект по этому ключу.

Связь между контурами однозначная: каждой строке реестра соответствует ровно один объект полезной нагрузки. Согласованной запись считается лишь тогда, когда успешно завершены оба шага контракта – размещение объекта во внешнем хранилище (PUT) и фиксация строки реестра (INSERT/UPDATE). Если сбой происходит на стороне объектного слоя, транзакция в СУБД не подтверждается. Для чтения предусмотрены два сценария. В первом из СУБД выбираются только метаданные (журнал, list/filter). Во втором к метаданным добавляется извлечение payload через GET, и сообщение собирается целиком.

От монолитного хранения XML в строке таблицы и от TOAST PostgreSQL предложенная модель External Payload Storage отличается тем, что крупные объекты оказываются вне СУБД. Реляционный контур в этом случае ведет учет транзакций и хранит ключ, обеспечивающий ссылку на внешний объект.

Алгоритм, представленный на рис. 3, задает методику количественной оценки объемов данных и времени выполнения операций чтения/записи и включает следующие этапы.

Рис. 3. Алгоритм экспериментальной оценки паттерна EPS Примечание: составлен авторами по результатам данного исследования

Опишем каждый из этапов предложенного алгоритма.

Этап 1. Фиксация исходного состояния монолитной схемы: объем базы Vdb, объем таблицы сообщений , средняя длина строки L, доля полезной нагрузки dp.

Этап 2. Замер временных характеристик «до EPS»: среднее время INSERT (), SELECT метаданных () и массовой журнальной выборки () на выборке N = 1000 операций и M = 1000 строк.

Этап 3. Миграция полезной нагрузки во внешнее хранилище и переход к гибридной схеме (метаданные и ключ объекта – в PostgreSQL, payload – в MinIO).

Этап 4. Повторный замер тех же показателей «после EPS»: объем таблицы V1, время INSERT метаданных и полного цикла записи , время SELECT метаданных и журнальной выборки .

Этап 5. Расчет относительных эффектов по формулам (1)–(7): сокращение объема δV, коэффициенты ускорения KINS и KSEL;

Этап 6. Сопоставление результатов на БД № 1 и БД № 2.

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

В результате проведенных вычислений были сделаны следующие выводы.

На БД № 1 dp = (28/89)·100 % ≈ 31,5 %; на БД № 2 – 35,6 %. После EPS δV ≈ 90,3 % и 90,5 %; объем таблицы снизился с 31 до 3 ГБ и с 696 до 66 ГБ (рис. 4, таблица). L уменьшился с 18–42 до 0,3–0,8 КБ; общий Vdb – с 89 до 61 ГБ и с 1768 до 1071 ГБ.

На БД № 2 сокращение таблицы сообщений составило 630 ГБ (696 → 66), а сокращение всей базы данных – 697 ГБ (1768 → 1071). Дополнительные ≈ 67 ГБ объясняются уменьшением структур, связанных с XML-полями: внутренней TOAST-таблицы и индексов / служебных объектов отношения после удаления крупных атрибутов, а также отражением освобожденного места в показателе pg_database_size после миграции.

Результаты операции INSERT: = 300 мс → = 25 мс, KINS = 12 (рис. 5); полное ≈ 105 мс (TPUT ≈ 80 мс). Результаты операции SELECT метаданных: = 80 мс → = 7,5 мс, KSEL ≈ 10,7 (рис. 6). Журнальная выборка (M = 1000): 7,8 с → 0,72 с; shared buffers: 8420 → 1180 (Kbuf ≈ 7,1). Полное чтение сообщения (SELECT + GET) осталось сопоставимым: 45–130 мс.

Сопоставление двух площадок показывает сохранение тенденций при разном масштабе данных. На БД № 2 абсолютные значения и выше, однако относительный выигрыш после внедрения EPS не снижается: KINS ≈ 13,1, KSEL ≈ 15. Это подтверждает, что эффект обусловлен не только уменьшением L, но и снижением объема данных, считываемых из буферного кеша PostgreSQL при каждой транзакции.

Рис. 4. Объем таблицы сообщений до и после внедрения EPS Примечание: составлен авторами по результатам данного исследования

Рис. 5. Среднее время операции вставки (INSERT) в PostgreSQL до и после EPS Примечание: составлен авторами по результатам данного исследования

Рис. 6. Среднее время операции чтения (SELECT) метаданных до и после EPS римечание: составлен авторами по результатам данного исследования

Полученные результаты эксперимента

Примечание: составлена авторами на основе полученных данных в ходе исследования.

При переходе на EPS основная транзакционная нагрузка остается в PostgreSQL, тогда как тела сообщений выносятся в S3-совместимое хранилище. Расчетные и экспериментальные значения по формулам (1)–(7) совпадают по порядку величины. Для исследованного профиля нагрузки – журнальные list/filter-запросы к метаданным без полного чтения XML – гибридная схема на двух площадках предпочтительнее монолитного хранения. Обобщение на контуры с иной долей полного чтения Payload требует отдельной оценки трафика.

Время записи складывается не только из INSERT в СУБД, но и из сетевого PUT; при интенсивном потоке входящих сообщений узким местом становятся пропускная способность объектного слоя и степень параллелизма Storage Adapter. Для полного просмотра сообщения задержка в основном определяется GET-запросом и для работы оператора остается в допустимых пределах. Так, EPS наиболее оправдан, когда система чаще ищет и фильтрует метаданные, чем выгружает полные XML-тела.

Заключение

На двух исследованных промышленных инсталляциях и для принятого профиля нагрузки (преобладание журнальных list/filter-запросов к метаданным без полного чтения XML) паттерн EPS показал устойчивый эффект: объем табличной части сообщений сократился примерно на 90 %, операции INSERT и выборка метаданных ускорились в 8–15 раз, при этом полное чтение сообщения по времени осталось сопоставимым с монолитной схемой. Полученные результаты подтверждены для указанных площадок и профиля запросов; перенос выводов на контуры с иной долей полного чтения payload требует отдельной экспериментальной оценки.

Для промышленного внедрения необходимо зафиксировать правила формирования ключей объектов, контролировать связь «метаданные ↔ объект в S3» и отслеживать длительность PUT/GET. Предложенный алгоритм оценки удобен на этапе модернизации: достаточно снять показатели «до / после» на репрезентативной выборке и вычислить δV, KINS и KSEL по приведенным формулам. В дальнейшем планируется проверить EPS при geo-распределенном объектном хранилище и асинхронной репликации Payload.