Ben küçük bir (~ 50 çalışan) SaaS şirketi için bir SQL Geliştiricisi (DBA veya Mimar değil). Nasıl yapılacağını bulmakla görevlendirildim:
- 100'den fazla OLTP veritabanımızdan düşük operasyonel raporlama
- Bu raporların birden çok istemci veritabanındaki verilerle çalışmasına izin ver
- Şirketimizi gelecekte daha fazla analitik tabanlı çözüm sunacak şekilde konumlandırın
İşlem çoğaltması (özellikle birden bire / merkezi abone modeli), SQL hizmet komisyoncusu, günlük gönderimi, Değişiklik İzleme (CT) ve Veri Yakalama (CDC, Değişiklik) gibi çeşitli teknolojiler hakkında birkaç makale okudum bu yalnızca kuruluştur) ve hangi yolun izlenmesinin en iyi yol olduğundan emin değilim.
Bazılarınızın entegrasyon uzmanlığına sahip olduğumuzu, bizimkine benzer bir kurulumla karşılaşmış olabileceğini ve beni başarılı bir yola yönlendirebileceğini veya beni yardımcı olabilecek bazı kaynaklara yönlendirebileceğini umuyorum.
Maliyet kısıtlamaları nedeniyle, çözümümüzün SQL Server Standard Edition içinde çalışması gerekir. Ayrıca, çözüm küçük organizasyonumuzda destek / bakım için makul olmalıdır.
Temel yapılandırma:
Şu anda 100'den fazla bireysel istemci veritabanımız var, bunların çoğu veri merkezimizdeki SQL sunucularına dağıtıldı, ancak bazıları veri merkezlerindeki uzaktan kumanda edebileceğimiz istemci sunucularına dağıtıldı. Bunların tümü SQL Server 2008 R2 veritabanlarıdır, ancak yakında SQL 2016'ya geçmeyi planlıyoruz.
Entegre edilecek tüm istemci veritabanlarında şemanın aynı olmasını sağlamak için veritabanı projeleri ve dacpacs kullanıyoruz. Ancak, tüm istemcileri aynı anda yeni sürümlere yükseltmeye zorlamadığımız için, yükseltmeler arasında bazı şema farklılıkları mümkündür. İstemci A, yazılım sürümü 1.0 ve istemci B, sürüm 1.1 ise çözüm kırılmayacak kadar esnek olmalıdır.
Operasyonel raporlar şu anda doğrudan her müşterinin OLTP veritabanından çalıştırılmaktadır. Boşaltmazsak uygulamanın performansı üzerindeki etkisinden endişe duyuyoruz.
Üst Düzey Gereksinimler:
Müşterilerimiz, şimdiye kadar işledikleri, envanterin nerede olduğu, vb. Hakkında güncel raporlar isteyen hastane steril işleme departmanlarıdır (SPD'ler). Bu çabanın temel amaçlarından biri operasyonel raporlamayı daha iyi desteklemek olduğundan, verilerin müşterilerin ihtiyaçlarını karşılamaya devam etmek için mümkün olduğunca gerçek zamana yakın olmasını istiyoruz.
Şu anda, aynı hastane sisteminin bir parçası olan ayrı veritabanlarında bazı SPD'lerimiz var. Bu istemciler, sistemlerindeki tüm SPD'lere karşı bildirimde bulunma yeteneğini ister.
Stratejik olarak konuşursak, dahili analitik girişimlerimizi desteklemek için tüm müşterilerimiz arasında kolayca veri toplama yeteneğini istiyoruz. Beklentimiz, toplanan operasyonel verileri veri pazarları / depo için bir kaynak olarak kullanabileceğimizdir.
Şu ana kadarki düşünceler:
İşlemsel çoğaltma, en "gerçek zamanlı" çözümü sağlayacak gibi görünüyor. Bu yanıtı özellikle yararlı buldum, ancak şema farklılıkları potansiyeli ile bizim için işe yaramayacağı konusunda endişeliyim: SQL Server Çoktan Bire çoğaltma
Sorgular etkinken günlüğün geri yüklenemeyeceği göz önüne alındığında, günlük gönderimi ideal görünmüyor. Ya günlüğü geri yükleyebilmek ya da veriler eski haline gelmek için ya herkesi kovmak zorundayım. Gönderilen her günlük yalnızca geldiği tek bir veritabanı için olacağından, bu yöntemin birden çok veritabanındaki verileri merkezileştirmek için kullanılıp kullanılamayacağı konusunda net değilim.
SQL hizmet aracısı kullanılarak, bir kuyruk işlenecek ileti sayısını yakalayamazsa gecikme öngörülemez.
CT yalnızca her tablo satırı için bir sürüm tanımlar. Gecikme, verileri almak ve merkezi bir depoya eklemek için her veritabanına SSIS paketi gibi bir şeyi ne kadar hızlı işleyebileceğimize bağlı olacaktır.
Her bir veritabanını tek tek kopyalamayı düşünmeli ve daha sonra çeşitli çoğaltılmış kaynaklardan gelen verileri birleştirmek için belki de bir çeşit veri sanallaştırma tekniği kullanmalı mıyız?
Vermek istediğiniz herhangi bir tavsiye veya yön çok takdir edilecektir.
