День добрый дорогие разработчики. В очередной раз стоит великая задача создания шустрого и рабочего ИТ сервиса. Перейдем сразу к возникшей проблеме:

Имеются два хранилища данных: некая БД Биллинговой системы (система X) и БД системы осуществления лицензионного доступа к платному контенту типа Verimatrix (система Y).
При осуществлении клиентом покупки платного сервиса (например, покупка контента с мобильного приложения, интерактивной приставки или сайта), информация о покупке регистрируется в системе X и из системы X отправляется команда в систему Y на открытие доступа к соответствующей единице контента. Между системами X и У существуют промежуточные звенья (преобразователи команд, очереди и т.д.), которые могут привести к нарушению консистентности данных в рассматриваемых системах. Стоит задача: один раз в день выгружать из систем X и Y файлы одинаковой структуры (идентификатор клиента, список доступных сервисов) и производить сравнение данных файлов .

По сути стоит задача создания сервиса Z, обладающего следующими характиристиками:
1. сервис Z должен быть вынесен из систем X и Y ;
2. сервис Z должен принимать на вход файлы большого размера от каждой из систем X и Y, производить сравнение файлов и выводить результат расхождения ;
3. сервис Z должен уметь отправлять команды в очередь команд ;
4. сервис Z должен сигнализировать другие сервисы, если показатели расхождений выходят за рамки допустимых значений .

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

Dimitry SibiryakovПоскольку проблема возникла из-за "промежуточных звеньев (преобразователи команд, очереди
и т.д.), которые могут привести к нарушению консистентности данных", то самоочевидным
решением является устранение этих звеньев путём объединения базы системы Х с базой системы
У в метабазу системы Й. А то, о чём Вы написали "многа букафф" это всего лишь кривой костыль.


Дабы уменьшить количество костылей, я и задаю данного рода вопросы. Не совсем понял про метабазу. Внесу уточнения:
1. Биллинговая система X - находится под нашей юрисдикцией. Y cистема управления доступом платного контента - система независимой компании вендера, которая никогда нам не предоставит доступ к своим хранилищам, максимум, что мы можем получить - это выгрузку файла с данными в формате определенного образца.
2. Избавиться от промежуточных звеньев конечно идея хорошая, но не реализуемая. Данная архитектура была построена под определенные нужды. Очереди команд читают не только описанные выше системы, но и Бэкенды и Фронтенды (для организации кэша, обеспечения доступа с определенных девайсов пользователей и т.д.).

x1ca4064ВЕЗУНЧИК,

"Файлы большого размера" - это сколько записей?
В файле могут повторяться записи для одного клиента?
Сколько максимально может быть сервисов, на которые подписан клиент?
Формат файлов какой?

1. Предполагается общий файл объемом до 12GB, но при желании его можно разбить по региональным БД (36 БД), тогда размеры файлов уменьшится до 360 МБ. (если говорить об sql файле на вставку пример №1 в пункте 4).

2. Да информация по одному пользователю повторяется в разрезе подключенных сервисов (пакетов каналов).
Пр. КлиентИдентификатор договораПакет каналовДата подключенияДата Отключения5634562563954501.12.201605.03.20175634562563954311.07.201601.12.201656345625639542001.12.2016 5634201489652106.12.2016

3. Максимальное количество сервисов - 20

4. Форматов файлов два: текстовый для вставки sql и текстовый с перечислением информации связи клиента и подключенного/отключенного сервиса
Пр 1. :


Пр 2. :



Файлы Пр 2. будут иметь сравнимо меньший размер

Постараюсь более подробно описать потребности задачи:
Dimitry Sibiryakov, совершенно прав: нужна некая дублирующая проверка на консистентноть данных между системами X и Y .

Я не уточнил, но по своей сути система X это головной сервер oracle, физически расположенный в определённом городе, таких серверов 36 (физически расположенных в разных регионах). Что бы произвести сравнение данных на сервере X, необходимо со всех серверов скопировать данные на сервер X и сюда же залить файл размером 12GB из системы Y. Любые сторонние нагрузки на сервер X чреваты его отказом, особенно в дни массового выставления счетов и регламентного закрытия доступа недобросовестным клиентам. Вот и была выдвинута идея, организовать сторонний сервис Z, который обладал бы вышеописанными возможностями.

Это бы позволило:
1. Снизить нагрузку на сервер X, так как логика вычислений, сравнений и отправки повторных команд на сервер Y была бы перемещена в другое место.
2. Преждевременно информировать центр мониторинга, о превышении количества допустимых несоответствий между системами X и Y или тенденцию роста этих несоответствий.

Да Злой Бобр прав, что по сети придется гонять возрастающий файл, конечно можно гонять файлы за конкретный день, этот вариант то же рассматривается, но это не даст общей картины.

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