Mencari saran tentang cara mengintegrasikan data dari 100+ DB klien ke dalam basis data pelaporan terpusat

10

Saya seorang Pengembang SQL (bukan DBA atau Arsitek) untuk perusahaan SaaS kecil (~ 50 karyawan). Saya ditugaskan untuk mencari cara:

  1. Turunkan pelaporan operasional dari 100+ database OLTP kami
  2. Izinkan laporan tersebut dijalankan terhadap data dari banyak basis data klien
  3. Posisikan perusahaan kami untuk memberikan lebih banyak solusi berbasis analitik di masa depan

Saya telah membaca sejumlah artikel tentang berbagai teknologi seperti replikasi transaksional (khususnya model pelanggan banyak-ke-satu / pusat), broker layanan SQL, pengiriman log, Change Tracking (CT), dan Change Data Capture (CDC, pemahaman saya adalah ini hanya untuk perusahaan), dan saya tidak yakin jalur apa yang terbaik untuk ditempuh.

Saya berharap beberapa dari Anda dengan keahlian integrasi mungkin menemui pengaturan yang serupa dengan kami dan dapat menunjukkan jalan yang sukses atau mengarahkan saya ke beberapa sumber yang akan membantu.

Karena kendala biaya, solusi kami harus bekerja dalam SQL Server Edisi Standar. Selain itu, solusinya harus masuk akal untuk mendukung / mempertahankan dalam organisasi kecil kami.

Konfigurasi dasar:

Saat ini kami memiliki 100+ basis data klien individu, yang paling banyak digunakan pada server SQL di pusat data kami, tetapi beberapa digunakan pada server klien di dalam pusat data mereka yang dapat kami jelajahi jauh. Ini semua adalah database SQL Server 2008 R2, tetapi kami berencana untuk segera memperbarui ke SQL 2016.

Kami menggunakan proyek basis data dan dacpac untuk memastikan skema ini sama di semua basis data klien yang akan diintegrasikan. Namun, karena kami tidak memaksa semua klien untuk meningkatkan ke versi baru pada saat yang sama, beberapa perbedaan skema mungkin terjadi di antara peningkatan. Solusinya harus cukup fleksibel agar tidak pecah jika klien A menggunakan perangkat lunak versi 1.0 dan klien B ada di versi 1.1.

Laporan operasional saat ini dijalankan langsung dari database OLTP setiap klien. Kami khawatir tentang dampaknya terhadap kinerja aplikasi jika kami tidak membongkarnya.

Persyaratan Tingkat Tinggi:

Klien kami adalah departemen pemrosesan steril di rumah sakit (SPD) yang menginginkan laporan terkini tentang apa yang telah mereka proses sejauh ini, di mana persediaan, dll. Persediaan proses SPD sepanjang waktu, termasuk akhir pekan dan hari libur. Karena salah satu tujuan utama upaya ini adalah untuk mendukung pelaporan operasional dengan lebih baik, kami ingin agar data sedekat mungkin dengan waktu nyata untuk terus memenuhi kebutuhan klien.

Saat ini kami memiliki beberapa SPD dalam database terpisah yang sebenarnya merupakan bagian dari sistem rumah sakit yang sama. Klien-klien ini menginginkan kemampuan untuk melaporkan terhadap semua SPD dalam sistem mereka.

Secara strategis, kami ingin kemampuan untuk dengan mudah mengumpulkan data di semua klien kami untuk mendukung inisiatif analitik internal kami. Harapan kami adalah bahwa kami akan dapat menggunakan data operasional yang dikumpulkan sebagai sumber untuk data mart / gudang.

Pikiran sejauh ini:

Replikasi transaksional sepertinya akan memberikan solusi paling "real-time". Saya menemukan respons ini sangat membantu, tetapi saya khawatir bahwa dengan potensi perbedaan skema, itu tidak akan bekerja untuk kita: SQL Server Banyak-ke-One replikasi

Pengiriman log tidak terdengar ideal mengingat log tidak dapat dipulihkan saat kueri aktif. Saya juga harus mengusir semua orang sehingga log dapat memulihkan atau data akan menjadi basi. Saya tidak jelas apakah metode ini dapat digunakan untuk memusatkan data dari banyak basis data, karena setiap log yang dikirim hanya untuk basis data individual.

Menggunakan pialang layanan SQL, latensi mungkin tidak dapat diprediksi jika antrian tidak dapat mengikuti jumlah pesan yang akan diproses.

CT hanya mengidentifikasi versi untuk setiap baris tabel. Latensi akan bergantung pada seberapa cepat kita dapat memproses sesuatu seperti paket SSIS terhadap setiap basis data untuk mengambil data dan memasukkannya ke dalam repositori pusat.

Apakah kita perlu mempertimbangkan untuk mereplikasi setiap database secara individual dan kemudian mungkin menggunakan semacam teknik virtualisasi data untuk menggabungkan data dari berbagai sumber yang direplikasi?

Setiap saran atau arahan yang Anda bersedia berikan akan sangat dihargai.

bperry
sumber
1
Karena persyaratan real-time (dekat) Anda, saya hanya akan melihat pemrosesan berdasarkan peristiwa dengan beberapa implementasi antrian pesan (untuk jaminan pengiriman). Semoga ini bisa membantu
Grimaldi
1
Saya akan melemparkan HTAP ke dalam campuran. en.m.wikipedia.org/wiki/Hybrid_Transactional/... BIML dan SSIS untuk mengisi toko umum.
Michael Green
@ Grimrimi, apakah Anda akan merekomendasikan menggunakan broker layanan SQL untuk mengimplementasikan antrian pemrosesan / pesan berbasis acara atau teknologi pesan lainnya?
bperry
Terima kasih atas sarannya, @MichaelGreen. Pada dasarnya sepertinya HTAP akan memungkinkan kami untuk menggunakan basis data kami yang ada untuk OLTP dan OLAP dengan menambahkan indeks kolom-kolom (NCCI) non-clustered ke tabel kami. Kueri laporan menggunakan NCCI sehingga tidak mengganggu operasi transaksional. SQL 2016 menyertakan dukungan HTAP dalam Edisi Standar (SE) tetapi sepertinya cache columnstore terbatas hingga 32GB di seluruh contoh SQL. Ini bisa menjadi masalah bagi kami karena kami memiliki lusinan database pada contoh yang sama. microsoft.com/en-us/sql-server/sql-server-2016-editions
bperry
1
Ya kolomstore tetapi juga dalam memori, jika spec server Anda memungkinkan Anda untuk pergi ke sana. Saya mendengar Sunil Agarwal berbicara tentang ini baru-baru ini. Aturan praktis MS adalah sekitar 3% degradasi OLTP untuk manfaat pelaporan nol latensi. Sayangnya tidak ada makan siang gratis; Anda dapat membuat instance baru untuk menampung DB pelaporan atau Anda dapat membuat instance baru untuk mendapatkan ruang kepala yang cukup untuk mendukung HTAP. Saya tidak menganjurkan untuk pola ini. Ini mungkin tidak bekerja untuk Anda. Hanya ingin membuat Anda sadar keberadaannya.
Michael Green

Jawaban:

1

Apakah kita perlu mempertimbangkan untuk mereplikasi setiap database secara individual dan kemudian mungkin menggunakan semacam teknik virtualisasi data untuk menggabungkan data dari berbagai sumber yang direplikasi?

Iya. Anda bisa meng-host beberapa basis data pelanggan pada satu contoh, dan kemudian kueri di atasnya dengan tampilan, atau memuatnya ke dalam database terkonsolidasi.

David Browne - Microsoft
sumber
Apakah ada cara yang lebih elegan untuk mengatur pandangan itu selain sesuatu seperti ... SELECT Field1, Field2, Field3 FROM [Database1]. [Schema]. [TableName] UNION ALL SELECT Field1, Field2, Field3 FROM [Database2]. [Skema ] [TableName]
bperry
1

Menurut uraian Anda di atas tautan di bawah ini akan membantu Anda dan saya juga bekerja pada scenario.Multiple penerbit yang sama dengan pelanggan tunggal.

  1. Tambahkan satu kolom lagi seperti server_id dengan nilai default seperti 1,2,3 dan seterusnya dan buatlah kunci primer komposit.

  2. Saat membuat publikasi dan menambahkan artikel, artikel properti Tindakan jika nama sedang digunakan perlu diatur ke Hapus data. Jika artikel memiliki filter baris, hapus hanya data yang cocok dengan filter. Ini dapat diatur menggunakan dialog Properti Artikel Wisaya Publikasi Baru atau dengan menggunakan prosedur sp_addarticle replikasi yang tersimpan dan menentukan nilai delete untuk argumen @pre_creation_cmd. Dengan cara ini, ketika pelanggan pusat diinisialisasi atau diinisialisasi ulang dari beberapa snapshot publikasi, data snapshot yang diterapkan sebelumnya akan dipertahankan karena hanya data yang cocok dengan klausa filter yang akan dihapus.

masukkan deskripsi gambar di sini

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

Gulrez Khan
sumber
terima kasih untuk artikelnya. Menggunakan model pelanggan pusat, sudahkah Anda mengetahui bagaimana Anda akan menangani pembaruan untuk skema penerbit Anda (misalnya, dengan peningkatan versi)? Apakah Anda akan memaksa semua database penerbit diperbarui secara bersamaan? Di lingkungan saya, kami tidak selalu memiliki opsi ini dan itu adalah keraguan utama saya dalam mengejar model replikasi pelanggan pusat. Jika ada cara untuk mengatasi penghalang ini, saya ingin tahu!
bperry
Saya tidak menggunakan 'Perbarui Penerbit'. Saya membagi basis data menjadi dua bagian seperti (dua jenis replikasi) beberapa tabel dalam penerbit terperinci (Penerbit untuk pelanggan terpusat) dan beberapa adalah penerbit utama (pelanggan terpusat untuk semua penerbit) .... Pelanggan terpusat. Saya juga merupakan bagian dari grup ketersediaan AlwaysOn karenanya replika sekunder saya berfungsi sebagai server laporan.
Gulrez Khan
Biarkan saya memastikan saya mengerti solusi Anda. Katakanlah Penerbit A ada di versi 1 dan Penerbit B ada di versi 2. 1) Anda telah mematikan replikasi perubahan skema pada kedua penerbit (menggunakan replicate_ddl = 0 pada pengaturan). 2) Versi 2 menyertakan kolom baru, jadi Anda akan menambahkannya secara manual di pelanggan pusat. 3) Di Penerbit B (ditingkatkan) Anda kemudian akan secara manual menambahkan kolom baru ke dalam replikasi (menggunakan sp_articlecolumn). Tidak ada perubahan yang dilakukan di Penerbit A. Apakah ini memungkinkan kedua penerbit untuk terus mereplikasi ke pelanggan pusat tanpa melanggar replikasi?
bperry
lihat tautan di bawah ini .. dba.stackexchange.com/questions/142449/
Gulrez Khan
juga lihat ini .. dba.stackexchange.com/questions/146070/…
Gulrez Khan
1

Satu kemungkinan arsitektur:

Pertimbangkan pelaporan sebagai solusi berbasis data warehouse.

Biasanya data warehouse adalah DB dengan skema yang mewakili subset yang diperlukan dari sistem sumber. AdventureWorks dan AdventureworksDW menunjukkan pemodelan itu.

Berikutnya, ETL: Memindahkan data dari sumber ke gudang data.

Kemungkinan implementasi di sini adalah dengan menggunakan pelacakan perubahan.

Pertama, seseorang dapat mengimplementasikan pandangan yang spesifik versi dalam apa yang mereka konsumsi, tetapi dalam hal apa yang mereka kembalikan, seragam. mis. Jika Person.Gender ada di versi 2 tetapi tidak di versi 1, tampilan orang untuk versi satu dapat kembali, katakanlah, null untuk versi 1.

Untuk konsumen gudang, semata-mata membaca tampilan, data adalah bentuk yang sama (dengan kelengkapan yang berbeda-beda).

Pelacakan perubahan menyediakan cara (relatif) ringan untuk menentukan data apa yang perlu diubah pada setiap penyegaran.

Menerapkan hal di atas bergantung pada perkakas tangan semuanya, jadi Anda harus percaya diri dalam pengkodean SQL, dan menguji skenario kinerja untuk melihat seberapa cepat peningkatan yang diperlukan untuk menjalankan. Dalam banyak kasus mereka bisa menjadi sub 1 detik, tetapi beberapa tabel transaksi tinggi dapat menghasilkan beban tinggi dalam memproses perubahan. (Ubah pelacakan 'relatif' ringan ... hanya pengujian yang membuktikannya).

Hal yang baik di sini adalah Anda memiliki tingkat kontrol yang tinggi atas bagaimana perbedaan skema bermanifestasi, dan dengan pelacakan perubahan, tidak ada peluang masalah integritas bila diterapkan dengan benar, karena pelacakan dilakukan di tingkat engine.

Apakah ini benar untuk Anda, akan sulit untuk mengatakannya.

Paul Holmes
sumber