База данных роботов. Как сделать так чтобы сложная система работала
Лингвистическая база и передача данных
Доставка данных на робота является одной из функций Лингвобазы — одного из основных элементов робота, который позволяет ему вести диалог. Благодаря ней робот распознаёт речь, затем — вопрос, а потом ищет на него ответ.
Лингвобаза представляет базу данных, которая включает более полутора сотен таблиц и занимает объём более 200 Гб. Она состоит из реплик — как реплик собеседника, так и самого робота. Реплики объединяются в целые правила. Например:
База состоит из четырех больших разделов: Лингвобаза, Аналитика, Конфигурация, Администрирование. При этом именно раздел Администрирование позволяет управлять работой самой Лингвобазы, настраивать учётные записи пользователей и права их доступа к роботам. Также раздел содержит данные о статусах, расписании работы роботов, ролях и другую служебную информацию. Здесь же отслеживается состояние очереди задач и работы самой системы синхронизации данных.
Условия нестабильного интернет зачастую диктуют достаточно жёсткие требования к системе передачи данных на робота: передавать любой объем данных необходимо при первой же возможности. В случае, если связь неожиданно оборвётся, процедура должна штатно завершиться и самостоятельно возобновиться при появлении нового окна. При этом нужно учитывать, что это может произойти через длительный промежуток времени, с неопределённым качеством связи и продолжительности окна.
Кроме того, необходимо обеспечить передачу на робота только тех данных, которые относятся к конкретному объекту, что определяет как безопасность (роботу недоступны данные других роботов), так и объём передаваемых данных.
Также существенное требование предъявляется к настройке синхронизации для новых роботов: она должна быть максимально прозрачной. При создании нового робота необходимо, чтобы и сервер и робот автоматически узнали друг о друге и были готовы к работе.
Типы синхронизации
Так как информация передаётся между базами данных, то можно было бы использовать существующие решения по репликации (синхронизации). В данном случае нужна логическая асинхронная двунаправленная репликация.
Доставка данных на робота является одной из функций Лингвобазы — одного из основных элементов робота, который позволяет ему вести диалог. Благодаря ней робот распознаёт речь, затем — вопрос, а потом ищет на него ответ.
Обзор доступных решений показал, что продукта, полностью удовлетворяющего нашим требованиям, нет. Поэтому мы посчитали необходимым разработать собственное решение для синхронизации данных.
Изначально необходимо было синхронизировать только DML (Data Manipulation Language) данные, но в конечном итоге у нас появилось существенно больше типов. Очень быстро потребовалось создать решение по синхронизации данных DDL (Data Definition Language). Требования и ограничения к ней такие же как и к DML, но теперь нужно учитывать, что пока не завершится DDL синхронизация начинать DML нельзя.
При существенном объёме информации необходимо было использовать иной способ ее передачи — массовый. Также требовалось организовать передачу с робота на сервер, причём тоже в 2-х режимах: обычном и массовом. Дополнительно требовалось организовать инициализацию базы данных на роботе, при которой база данных создаётся с нуля. И, наконец, требуется организовать обновления ПО синхронизации на роботах.
Синхронизация
Для передачи данных DML было решено использовать технологию PostrgeSQL Foreign-Data Wrappers (FDW, обёртка сторонних данных). Она позволяет настроить БД сервера и робота таким образом, что обращение с сервера к удалённой таблице робота выглядит как обращение к локальной.
Иными словами, можно на сервере выполнить SQL запрос, указав перед именем таблицы имя робота ( Но, как мы знаем, роботы Promobot могут работать автономно и появляться в сети изредка и ненадолго. Даже за день, если робота готовят к мероприятию, может появиться десятки тысяч записей, которые необходимо передать. При этом с интернетом, как мы помним, бывают проблемы. FDW позволяет быстро синхронизироваться в реальном времени, но при больших объёмах скорость становится крайне низкой. Поэтому в таких случаях запускается массовая репликация, когда все данные, которые требуется отправить на робота, выгружаются в дамп. Далее они отправляются архивом на робота, где происходит их обратная распаковка. Если в БД вносят изменения, то каждая запись проходит процедуру подготовки к синхронизации. Определяется список роботов для отправки изменений. Далее проверяется история изменений этой записи для роботов из списка. Если есть несинхронизированные записи в таблице синхронизации, то они переходят в статус отменённых. Для роботов каждая запись, которая должна быть на него отправлена, существует в актуальном статусе в таблице синхронизации только в одном экземпляре. То есть, когда бы робот не появился в сети, на него будет отправлены только актуальные на текущий момент данные, без истории их изменений, что значительно сокращает объём синхронизации. С учётом множества типов синхронизации необходимо организовать их согласованную работу. Если робот давно не был в сети и требуется провести сразу несколько их типов, то они проводятся в определенном порядке. Сначала обновляется ПО синхронизации, так как от его работы будут зависеть другие типы синхронизации. Затем обновляется структура БД через выполнение DDL-синхронизации. В случае успешного завершения предыдущих операций запустится DML-синхронизация, скорее всего в режиме массовой синхронизации.Во всех случаях, кроме обычной DML, синхронизация проходит в несколько этапов, которые контролирует сервер. Рассмотрим это на примере DDL-синхронизации. При создании DDL-команды сначала сервер исполняет её в серверной БД, далее команда переводится в статус ожидания отправки на робота. Таких команд может быть несколько, но все они выполняются строго последовательно и только в случае успешного исполнения предыдущих, иначе процедура прерывается. Далее проверяется доступность БД робота. При положительном ответе команда отправляется на робота. Установленное на роботе ПО синхронизации, обнаруживая команду в статусе, требующем исполнения, выполняет её и обновляет оболочку FDW. В случае успеха, робот сообщает об этом на сервер. После получения успешного ответа от робота сервер также обновляет оболочку FDW. То есть структура БД и оболочки FDW оказываются в актуальном состоянии. При этом в любой момент процедуры робот может быть выключен, либо прерваться связь с сервером, но это никак не повлияет на успешность процедуры, так как она будет автоматически продолжена и завершена как только появится возможность. Основные характеристики процедуры справедливы и для остальных типов с учётом особенностей и нюансов. Передача данных При том, что робот полностью автономен и может работать без доступа в Интернет, для обновления его ПО и БД требуется подключение к сети. Робот может находиться в любой точке мира, быть подключенным как по wi-fi, так и через мобильные сети. Для этого на роботе настраивается VPN, что позволяет не только устанавливать с ним связь, но и гарантирует передачу данных по защищённому зашифрованному соединению. Для большей безопасности всё управление процессом ведётся на сервере, при этом сам робот непосредственно к нему не обращается (на нём нет учётных записей или инструментов для совершения подобных операций). В итоге мы реализована система, которая позволяет (да при нестабильном интернете) гарантировать доставку между роботами любого объёма данных.
База синхронизации
Порядок и этапы синхронизации
