Я розробник SQL (не DBA або архітектор) для невеликої (близько 50 співробітників) компанії SaaS. Мені доручено з'ясувати, як:
- Вивантажте оперативну звітність з наших 100+ баз даних OLTP
- Дозвольте цим звітам працювати з даними з декількох клієнтських баз даних
- Позиціонуйте нашу компанію надавати більше рішень на основі аналітики у майбутньому
Я прочитав ряд статей з різних технологій, таких як транзакційна реплікація (зокрема модель "багато в одному / центральній абонентській"), брокер служби SQL, доставка журналів, відстеження змін (CT) та зйомка даних змін (CDC, наскільки я розумію) це лише для підприємств), і я не впевнений, який шлях найкраще пройти.
Я сподіваюся, що хтось із вас із досвідом інтеграції, можливо, зіткнувся з настановою, подібною до нашої, і зможе вказати мені на успішний шлях або направити мене на деякі ресурси, які були б корисні.
Через обмеження витрат наше рішення має працювати в стандартній версії SQL Server. Також рішення повинно бути розумним для підтримки / підтримки в нашій невеликій організації.
Основна конфігурація:
В даний час у нас є більше 100 індивідуальних клієнтських баз даних, більшість яких розгорнута на SQL-серверах у нашому центрі обробки даних, але деякі розгорнуті на клієнтських серверах у їх центрі обробки даних, до яких ми можемо віддалено працювати. Це все бази даних SQL Server 2008 R2, але незабаром ми плануємо оновити до SQL 2016.
Ми використовуємо проекти баз даних і дакпаки для того, щоб схема була однаковою для всіх клієнтських баз даних, які були б інтегровані. Однак, оскільки ми не змушуємо всіх клієнтів одночасно переходити на нові версії, деякі оновлення можливі між оновленнями. Рішення повинно бути досить гнучким, щоб не порушуватися, якщо клієнт A має версію програмного забезпечення 1.0, а клієнт B - версію 1.1.
Наразі операційні звіти запускаються безпосередньо з баз даних OLTP кожного клієнта. Ми стурбовані впливом, яке це матиме на продуктивність програми, якщо ми не завантажимо її.
Вимоги високого рівня:
Нашими клієнтами є відділення для стерильної обробки в лікарнях (SPD), які хочуть отримувати актуальні звіти про те, що вони обробляли дотепер, де проводиться інвентаризація та ін. Оскільки однією з головних цілей цих зусиль є краща підтримка оперативної звітності, ми хотіли б, щоб дані були максимально наближені до реального часу, щоб продовжувати задовольняти потреби клієнтів.
Наразі у нас є окремі SPD в окремих базах даних, які фактично є частиною тієї ж лікарняної системи. Ці клієнти хочуть можливість звітувати проти всіх SPD в їх системі.
Стратегічно кажучи, ми хотіли б можливість легко агрегувати дані для всіх наших клієнтів для підтримки наших ініціатив внутрішньої аналітики. Ми сподіваємось, що ми зможемо використовувати зібрані оперативні дані як джерело для маркшейдів / сховищ даних.
Поки що думки:
Транзакційна реплікація, схоже, забезпечила б найбільш рішення у режимі реального часу. Я вважав, що ця відповідь є особливо корисною, але я стурбований тим, що з можливістю відмінностей у схемі вона не буде працювати для нас: реплікація "багато на один" SQL Server
Доставка журналу не здається ідеальною, враховуючи те, що журнал не може відновитись під час активних запитів. Мені або потрібно вигнати всіх, щоб журнал міг відновитись, або дані стануть застарілими. Мені незрозуміло, чи міг би цей метод використовуватись для централізації даних із кількох баз даних, оскільки кожен відправлений журнал був би лише для окремо взятої бази даних.
За допомогою сервісного брокера SQL затримка може бути непередбачуваною, якщо черга не змогла не відставати від кількості повідомлень, які обробляються.
КТ ідентифікує лише версію для кожного рядка таблиці. Затримка залежатиме від того, наскільки швидко ми зможемо обробити щось на зразок пакета SSIS проти кожної бази даних, щоб отримати дані та вставити їх у центральний сховище.
Чи потрібно розглядати реплікацію кожної бази даних окремо, а потім, можливо, використовувати якусь техніку віртуалізації даних для об'єднання даних з різних реплікуваних джерел?
Будемо дуже вдячні за будь-яку пораду чи напрямок, який ви готові надати.
