Я являюсь разработчиком 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 для каждой базы данных, чтобы извлечь данные и вставить их в центральное хранилище.
Нужно ли нам рассматривать репликацию каждой базы данных по отдельности, а затем, возможно, использовать какую-то технику виртуализации данных для объединения данных из различных реплицированных источников?
Будем весьма благодарны за любые советы или указания, которые вы готовы предоставить.
Ответы:
Да. Вы можете разместить несколько баз данных подписчиков в одном экземпляре, а затем запросить их с помощью представлений или загрузить их в консолидированную базу данных.
источник
В соответствии с приведенным выше описанием ссылка поможет вам, и я также работаю по тому же сценарию. Несколько издателей с одним подписчиком.
Добавьте еще один столбец, например server_id, со значением по умолчанию, например 1,2,3 и т. Д., И сделайте его составным первичным ключом.
При создании публикаций и добавлении статей для свойства статьи «Действие», если используется имя, необходимо установить значение «Удалить данные». Если в статье есть фильтр строк, удалите только те данные, которые соответствуют этому фильтру. Это можно установить с помощью диалога свойств статьи мастера публикации или с помощью хранимых процедур репликации sp_addarticle и указания значения delete для аргумента @pre_creation_cmd. Таким образом, когда центральный подписчик инициализируется или повторно инициализируется из нескольких моментальных снимков публикации, ранее примененные данные моментального снимка будут сохранены, поскольку будут удалены только данные, соответствующие предложению фильтра.
http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/
источник
Одна возможная архитектура:
Рассматривайте отчетность как решение на основе хранилища данных.
Обычно хранилище данных - это БД со схемой, которая представляет собой необходимое подмножество исходных систем. AdventureWorks и AdventureworksDW демонстрируют это моделирование.
Далее ETL: перемещение данных из источников в хранилище данных.
Возможной реализацией здесь является использование отслеживания изменений.
Во-первых, можно реализовать представления, которые зависят от версии в том, что они потребляют, но с точки зрения того, что они возвращают, одинаковы. Например, если Person.Gender существует в версии 2, но не в версии 1, представление лица для версии 1 может возвращать, скажем, ноль для версии 1.
Для потребителя склада, только читающего представления, данные имеют одинаковую форму (с различной полнотой).
Отслеживание изменений обеспечивает (относительно) легкий способ определения того, какие данные необходимо изменять при каждом обновлении.
Реализация вышеперечисленного основана на ручном инструменте, поэтому вам нужно быть уверенным в кодировании SQL и тестировать сценарии производительности, чтобы увидеть, насколько быстро выполняются приращения. Во многих случаях они могут составлять менее 1 секунды, но некоторые таблицы с высокими транзакциями могут генерировать высокую нагрузку при обработке изменений. (Отслеживание изменений «относительно» легкий вес ... только тестирование подтверждает это).
Хорошо, что вы обладаете высокой степенью контроля над тем, как проявляются различия в схемах, и при отслеживании изменений нет шансов на проблемы с целостностью при правильной реализации, так как отслеживание выполняется на уровне механизма.
Будет ли это точно для вас, сложно сказать.
источник