Статья "живая" - будет дополняться и изменяться по мере написания примеров кода и выполнения замеров производительности. Таким образом я постараюсь продемонстрировать возможности SQL Server для построения распределённых информационных систем. Эта мощнейшая СУБД приобретена большинством компаний, использующих клиент-серверный вариант 1С:Предприятие 8, однако подавляющее большинство её возможностей остаётся не востребованной.
Чтобы было понятно, распределённую информациолнную систему какого масштаба можно построить при помощи SQL Server, приведу в пример такую известную во всём мире социальную сеть, как MySpace, которая по состоянию на 2016 год имеет более 25 млн. пользователей и более 1000 серверов SQL Server.
Для построения тестового стенда я использую 1С:Предприятие 8.3 и SQL Server 2014 Developer Edition (бесплатная версия для индивидуальных разработчиков). Можно использовать Express Edition - код примеров будет совместим с этой версией SQL Server тоже.
Highload обмен характеризуется, прежде всего, большим объёмом данных, который необходимо передавать между узлами распределённой информационной системы. "Highload" я предлагаю называть такие системы, в которых во всех её узлах для обмена генерируется от 1 Гб чистых данных (размер данных СУБД) ежесуточно. (Может быть больше - замечания и примеры из жизни членов сообщества приветствуются). В то же самое время скорость передачи данных является не единственным требованием, которое предъявляется к системам этого класса. Не менее важную роль при этом играют обеспечение целостности данных, сохранение приемлемой параллельности работы пользователей, безопасность, масштабируемость и прочее.
Типовой сценарий и его задачи.
Один цикл обмена данными между двумя узлами в одном направлении выглядит следующим образом (упрощённая базовая схема):
1. Регистрация изменений данных (состояния) объектов в промежуточном хранилище (специальные таблицы или очереди сообщений).
2. Чтение изменений (по событию или расписанию).
3. Формирование сообщений обмена (агрегирование изменений).
4. Маршрутизация сообщений по узлам.
5. Трансляция/конвертация сообщений для приёмника.
6. Запись сообщений обмена (выгрузка).
7. Доставка сообщений получателю.
8. Чтение сообщений обмена (по событию или расписанию).
9. Запись изменений (загрузка).
Обеспечение целостности данных.
1. Регистрация изменений должна быть согласована с записью нового состояния объекта в базу данных. Не должно быть "потерянных" изменений, когда объект записан в базу, а изменение - нет. То же самое относится к обратной ситуации, когда изменение зарегистрировано, а запись объекта была отменена. Целостность данных системы в таких случаях считается нарушенной.
2. Восстановление системы после сбоя должно гарантировать восстановление зарегистрированных изменений или уже сформированных, но ещё недоставленных сообщений обмена, которые хранятся в специальных таблицах СУБД или очередях сообщений.
3. Удаление сообщений обмена из канала его передачи и запись изменений в целевую базу данных должны быть согласованны ровно таким же образом, как это описано в пункте 1.
Параллельность работы пользователей.
1. Процесс регистрации изменений (работа пользователей) не должен блокировать процесс их выгрузки (обмен данными) и наоборот.
2. Процесс загрузки сообщений обмена должен происходить максимально быстро, чтобы создавать как можно меньше ситуаций ожидания на блокировках для текущей работы пользователей.
Производительность (пропускная способность).
Общая производительность системы обмена данными или другими словами её пропускная способность должна превышать скорость генерации новых изменений в 5 раз (в идеале - 10). Этого "запаса прочности" должно быть достаточно для сглаживания пиковых нагрузок или восстановления работы системы после продолжительного сбоя.
Методика замера производительности.
Производительность системы предлагаю оценивать для двух её отдельно взятых узлов, расположенных на разных серверах сети. Производительность вычисляется как отношение размера передаваемых данных к общему времени нахождения сообщений в системе. Таким образом началом цикла обмена следует считать выполнение регистрации изменения, а окончанием - загрузку сообщения обмена в целевом узле распределённой системы. Замеры следует выполнять для сообщений среднего размера. Средним размером предлагаю считать 1 Мб чистых данных (размер данных СУБД).
Таким образом, если мы определяем highload обмен как систему, в которой генерируется от 1 Гб чистых данных ежесуточно, а запасом прочности 10-кратное превышение этой цифры, тогда целевая производительность системы должна равняться 10 Гб / 20 часов = 512 Мб/час (4 часа в сутки беру на технологическое обслуживание).
Чтобы было понятнее, то в формате XML это может быть эквивалентно файлам, которые имеют размер приблизительно равный 5 Гб. И это нужно "прокачать" за час. Если мы имеем сервер, например, с 10-тью процессорными ядрами, то это всего лишь по 512 Мб XML на ядро, что в общем-то, как мне кажется, не так много.
Связанные статьи:
Использование SQL Server Change Tracking для регистрации изменений данных объектов 1С:Предприятие 8
