Нужны советы о том, как интегрировать данные из более 100 клиентских БД в базу данных централизованной отчетности.

Я являюсь разработчиком SQL (не администратором баз данных или архитектором) для небольшой (~ 50 сотрудников) компании SaaS. Мне поручено выяснить, как:

Перенесите оперативную отчетность из наших 100+ баз данных OLTP
Разрешить этим отчетам работать с данными из нескольких клиентских баз данных
Позиционируйте нашу компанию, чтобы предоставить больше аналитических решений в будущем

Я прочитал ряд статей о различных технологиях, таких как репликация транзакций (в частности, модель «многие к одному / центральная подписка»), брокер служб SQL, доставка журналов, отслеживание изменений (CT) и сбор данных изменений (CDC). Насколько я понимаю, это только для предприятий), и я не уверен, какой путь лучше выбрать.

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

Из-за ограничений по стоимости наше решение должно работать в SQL Server Standard Edition. Кроме того, решение должно быть разумным, чтобы поддерживать / поддерживать в нашей небольшой организации.

Базовая конфигурация:

В настоящее время у нас есть более 100 отдельных клиентских баз данных, большинство из которых развернуто на серверах SQL в нашем центре обработки данных, но некоторые развернуты на клиентских серверах в их центрах обработки данных, в которые мы можем удаленно работать. Все это базы данных SQL Server 2008 R2, но мы планируем вскоре перейти на SQL 2016.

Мы используем проекты баз данных и dacpac, чтобы обеспечить одинаковую схему для всех клиентских баз данных, которые будут интегрированы. Однако, поскольку мы не вынуждаем всех клиентов одновременно обновляться до новых версий, между обновлениями возможны некоторые различия в схемах. Решение должно быть достаточно гибким, чтобы не сломаться, если клиент A использует версию программного обеспечения 1.0, а клиент B - версию 1.1.

Оперативные отчеты в настоящее время запускаются непосредственно из базы данных OLTP каждого клиента. Мы обеспокоены влиянием, которое это окажет на производительность приложения, если мы не разгрузим его.

Требования высокого уровня:

Наши клиенты - это отделы стерильной обработки в больницах (SPD), которым нужны самые свежие отчеты о том, что они уже обработали, где находится инвентарь и т. Д. Инвентаризация SPD производится круглосуточно, включая выходные и праздничные дни. Поскольку одна из основных целей этих усилий заключается в улучшении поддержки оперативной отчетности, мы хотели бы, чтобы данные были как можно ближе к реальному времени, чтобы продолжать удовлетворять потребности клиентов.

В настоящее время у нас есть несколько СПД в отдельных базах данных, которые фактически являются частью одной и той же больничной системы. Эти клиенты хотят иметь возможность сообщать о всех SPD в своей системе.

В стратегическом плане мы хотели бы иметь возможность легко объединять данные по всем нашим клиентам для поддержки наших внутренних аналитических инициатив. Мы ожидаем, что мы сможем использовать собранные оперативные данные в качестве источника для витрин / хранилищ данных.

Мысли пока что

Кажется, что репликация транзакций обеспечит самое «реальное» решение. Я нашел этот ответ особенно полезным, но я обеспокоен тем, что из-за различий в схемах он нам не подойдет: репликация SQL Server «многие-к-одному»

Доставка журналов не звучит идеально, учитывая, что журнал не может быть восстановлен во время активных запросов. Я либо должен выгнать всех, чтобы журнал мог восстановиться, либо данные устареют. Мне неясно, можно ли использовать этот метод для централизации данных из нескольких баз данных, поскольку каждый отправленный журнал будет только для отдельной базы данных, из которой он получен.

При использовании посредника служб SQL задержка может быть непредсказуемой, если очередь не успевает за количеством сообщений для обработки.

CT только идентифицирует версию для каждой строки таблицы. Задержка будет зависеть от того, насколько быстро мы сможем обработать что-то вроде пакета служб SSIS для каждой базы данных, чтобы извлечь данные и вставить их в центральное хранилище.

Нужно ли нам рассматривать репликацию каждой базы данных по отдельности, а затем, возможно, использовать какую-то технику виртуализации данных для объединения данных из различных реплицированных источников?

Будем весьма благодарны за любые советы или указания, которые вы готовы предоставить.

— bperry
источник

Из-за ваших (почти) требований в реальном времени, я бы смотрел на обработку событий только с некоторыми реализациями очереди сообщений (для гарантии доставки). Надеюсь, это поможет

— Гримальди

Я бы бросил HTAP в смесь. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML и SSIS для заполнения общего хранилища.

— Майкл Грин

@Grimaldi, вы бы порекомендовали использовать брокер служб SQL для реализации основанных на событиях очередей обработки / сообщений или какой-либо другой технологии обмена сообщениями?

— bperry

Спасибо за предложение, @MichaelGreen. По сути, похоже, что HTAP позволит нам использовать наши существующие базы данных для OLTP и OLAP, добавляя некластеризованные индексы columnstore (NCCI) в наши таблицы. Запросы отчетов используют NCCI, поэтому они не мешают транзакционным операциям. SQL 2016 включает в себя поддержку HTAP в Standard Edition (SE), но похоже, что кэш столбцов хранилища ограничен 32 ГБ для всего экземпляра SQL. Это может быть проблемой для нас, поскольку у нас есть десятки баз данных в одном экземпляре. microsoft.com/en-us/sql-server/sql-server-2016-editions

— bperry

Да columnstore, но также и в памяти, если ваш сервер позволяет вам туда заходить. Я недавно слышал, как Сунил Агарвал говорил об этом. Эмпирическое правило MS составило около 3% ухудшения OLTP в пользу отчетов с нулевой задержкой. К сожалению, нет бесплатных обедов; Вы можете создать новые экземпляры для хранения базы данных отчетов или создать новый экземпляр, чтобы получить достаточный запас для поддержки HTAP. Я не защищаю эту модель. Это может не сработать для вас. Просто хотел, чтобы вы знали, что оно существует.

— Майкл Грин

Ответы:

Нужно ли нам рассматривать репликацию каждой базы данных по отдельности, а затем, возможно, использовать какую-то технику виртуализации данных для объединения данных из различных реплицированных источников?

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

— Дэвид Браун - Microsoft
источник

Есть ли более элегантный способ настроить эти представления помимо чего-то вроде ... SELECT Field1, Field2, Field3 FROM [Database1]. [Schema]. [TableName] UNION ALL SELECT Field1, Field2, Field3 FROM [Database2]. [Schema ]. [TableName]

— bperry

В соответствии с приведенным выше описанием ссылка поможет вам, и я также работаю по тому же сценарию. Несколько издателей с одним подписчиком.

Добавьте еще один столбец, например server_id, со значением по умолчанию, например 1,2,3 и т. Д., И сделайте его составным первичным ключом.
При создании публикаций и добавлении статей для свойства статьи «Действие», если используется имя, необходимо установить значение «Удалить данные». Если в статье есть фильтр строк, удалите только те данные, которые соответствуют этому фильтру. Это можно установить с помощью диалога свойств статьи мастера публикации или с помощью хранимых процедур репликации sp_addarticle и указания значения delete для аргумента @pre_creation_cmd. Таким образом, когда центральный подписчик инициализируется или повторно инициализируется из нескольких моментальных снимков публикации, ранее примененные данные моментального снимка будут сохранены, поскольку будут удалены только данные, соответствующие предложению фильтра.

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/

— Гулрез Хан
источник

спасибо за статью. Используя модель централизованного подписчика, выяснили ли вы, как вы будете обрабатывать обновления схемы ваших издателей (например, с обновлениями версий)? Вы заставите все базы данных издателя обновляться одновременно? В моей среде у нас не всегда есть этот вариант, и это было моим основным сомнением в реализации модели репликации центрального абонента. Если есть способ обойти этот барьер, я хотел бы знать!

— bperry

Я не использую «Update Publisher». Я разделил базу данных на две части, такие как (два типа репликации), некоторые из таблиц в подробном издателе (издатель для централизованного подписчика), а некоторые - главный издатель (централизованный подписчик для всех издателей) .... Мой централизованный подписчик также входит в группу AlwaysOn avaibality, поэтому моя вторичная реплика работает как сервер отчетов.

— Гулрез Хан

Позвольте мне убедиться, что я понимаю ваше решение. Допустим, Publisher A установлен на версию 1, а Publisher B - на версию 2. 1) Вы отключили репликацию изменений схемы на обоих издателях (используя replicate_ddl = 0 при настройке). 2) Версия 2 включает новый столбец, поэтому вы должны добавить его вручную у центрального подписчика. 3) В издателе B (обновленный) вы затем вручную добавили бы новый столбец в репликацию (используя sp_articlecolumn). В Publisher A не вносятся изменения. Позволит ли это обоим издателям продолжать репликацию на центрального подписчика, не прерывая репликацию?

— bperry

см. ниже ссылку .. dba.stackexchange.com/questions/142449/…

— Гулрез Хан

также смотрите это .. dba.stackexchange.com/questions/146070/…

— Гулрез Хан

Одна возможная архитектура:

Рассматривайте отчетность как решение на основе хранилища данных.

Обычно хранилище данных - это БД со схемой, которая представляет собой необходимое подмножество исходных систем. AdventureWorks и AdventureworksDW демонстрируют это моделирование.

Далее ETL: перемещение данных из источников в хранилище данных.

Возможной реализацией здесь является использование отслеживания изменений.

Во-первых, можно реализовать представления, которые зависят от версии в том, что они потребляют, но с точки зрения того, что они возвращают, одинаковы. Например, если Person.Gender существует в версии 2, но не в версии 1, представление лица для версии 1 может возвращать, скажем, ноль для версии 1.

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

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

Реализация вышеперечисленного основана на ручном инструменте, поэтому вам нужно быть уверенным в кодировании SQL и тестировать сценарии производительности, чтобы увидеть, насколько быстро выполняются приращения. Во многих случаях они могут составлять менее 1 секунды, но некоторые таблицы с высокими транзакциями могут генерировать высокую нагрузку при обработке изменений. (Отслеживание изменений «относительно» легкий вес ... только тестирование подтверждает это).

Хорошо, что вы обладаете высокой степенью контроля над тем, как проявляются различия в схемах, и при отслеживании изменений нет шансов на проблемы с целостностью при правильной реализации, так как отслеживание выполняется на уровне механизма.

Будет ли это точно для вас, сложно сказать.

— Пол Холмс
источник