sql server veritabanı parçalama - ortak verilerle / parçalanmamış verilerle ne yapmalı

Çok büyük ölçekli kurumsal düzeyde bir veritabanımız var. İş modelimizin bir parçası olarak, tüm web kullanıcıları web sunucularımıza her ay aynı saatte vuruyor ve bu da sql kutumuzu kırıyor. Trafik çok ağırdır ve şirket büyüdükçe ağırlaşmaya devam eder. sql proc optimizasyonu yapıldı ve donanım zaten çok yüksek bir seviyeye yükseltildi.

Şirketin büyümesini ve gelecekteki yükleri kaldırabilmemiz için veritabanını şimdi parçalamak istiyoruz.

Hangi verilerin parçalanması gerektiğine karar verdik. Çok kullanılan veritabanımızın bir alt kümesidir.

Ancak sorum, ortak / evrensel olan parçalanmamış verilerle ilgili. Bunun gibi verilere örnek olarak bir Envanter tablosu veya muhtemelen bir Çalışan tablosu, kullanıcı tablosu vb. Verilebilir.

Bu ortak / evrensel verileri işlemek için iki seçenek görüyorum:

1) tasarım 1 - Ortak / evrensel verileri harici bir veritabanına yerleştirin. Bütün yazılar burada olacak. Bu veriler daha sonra, her bir parçanın bu verileri okumasına ve bu verilere t-sql proc'larında iç birleşmesine izin veren her bir parçaya kopyalanacaktır.

2) tasarım 2 - Her parçaya tüm ortak / evrensel verilerin kendi kopyasını verin. Her bir parçanın bu tablolara yerel olarak yazmasına izin verin ve bu verileri diğer tüm parçacıklarda güncellemek / senkronize etmek için sql birleştirme çoğaltması kullanın.

tasarım # 1 ile ilgili endişeler

1) İşlem sorunları: Bir kırıkta veri yazmanız veya güncellemeniz ve daha sonra örneğin 1 depolanmış işlemde ortak / evrensel bir tablo yazmanız / güncellemeniz gereken bir durum varsa, artık bunu kolayca yapamayacaksınız. Veriler artık ayrı sql örnekleri ve veritabanlarında bulunmaktadır. Bu yazma işlemlerini ayrı bir veritabanında oldukları için bir işlemin içine yerleştirip paketleyemeyeceğinizi görmek için MS DTS'yi dahil etmeniz gerekebilir. Performans burada bir endişe kaynağıdır ve parçalanmış ve ortak verilere yazılan procslar için olası yeniden yazma işlemleri söz konusu olabilir.

2) referans bütünlüğünün kaybı. Veritabanları arası bilgi bütünlüğü yapmak mümkün değil.

3) Sistemin geniş alanlarını yeniden kodlamak, böylece yeni evrensel veritabanına ortak veri yazmayı bilmek, ancak kırıntılardan ortak verileri okumak.

4). artan veritabanı gezileri. Yukarıdaki # 1 gibi, parçalanmış verileri ve ortak verileri güncellemeniz gereken bir durumla karşılaştığınızda, veriler artık ayrı veritabanlarında olduğu için bunu gerçekleştirmek için birden fazla gidiş-dönüş gezisi yapacaksınız. Burada bazı ağ gecikmesi var ama bu kadar yukarıda 3 kadar endişelenmiyorum.

tasarım # 2 ile ilgili endişeler

Tasarım # 2'de her parça, tüm ortak / evrensel verilerin kendi örneğini alır. Bu, ortak verilere katılan veya güncellenen tüm kodların, bugün olduğu gibi çalışmaya / çalışmaya devam ettiği anlamına gelir. Geliştirme ekibinden çok az yeniden kodlama / yeniden yazma gerekir. Bununla birlikte, bu tasarım tüm verileri parçalarda senkronize tutmak için tamamen birleştirme çoğaltmasına bağlıdır. dbas son derece yeteneklidir ve birleştirme çoğaltmasının bu sorunu çözemeyebileceğinden ve çoğaltma başarısızlığını birleştirmekten çok endişe duyar, bu başarısızlıktan kurtarma büyük değildir ve bizi çok olumsuz etkileyebilir.

Birinin tasarım seçeneği # 2 ile gidip gitmediğini merak ediyorum. Görmediğim bir 3. veya 4. tasarım seçeneğine bakıp bakmadığımı da merak ediyorum.

şimdiden teşekkür ederim.

Sorunuz buna odaklandı:

Ancak sorum, ortak / evrensel olan parçalanmamış verilerle ilgili. Bunun gibi verilere örnek olarak bir Envanter tablosu veya muhtemelen bir Çalışan tablosu, kullanıcı tablosu vb. Verilebilir.

Parçalama yaparken ve tüm parçaların görmesi gereken verileriniz varsa, bu verileri birkaç özellikle sınıflandırmanız gerekir:

Sık sık değişiyor mu? Örneklerinizde Envanter, Çalışan ve Kullanıcı'yı listelediniz. Genellikle envanter çok hızlı değişir, ancak Çalışanlar kayıtları yalnızca periyodik olarak değişir (örneğin, günde birkaç yüz güncelleme).

Her bir kırık ne kadar gecikme yapabilir?Envanter sürekli değişiyor olsa da, genellikle böyle bir tabloda büyük miktarda gecikmeyi (dakikalar, hatta saatler) tolere edebilirsiniz. Asla yeniden stoklayamayacağınız çok sınırlı miktarda benzersiz ürünler satıyorsanız (orijinal sanat eserlerini düşünün), o zaman bu verileri hiç kırmazsınız - sadece orijinal veritabanını sorgularsınız. Ancak, çoğu çevrimiçi mağazada, her gün her öğeden satış yapmıyorsunuz ve her şeyi hızlı bir şekilde yeniden stoklayacaksınız, bu yüzden gerçekten milisaniye kadar stok sayısına ihtiyacınız yok. Aslında, çoğu durumda, yalnızca 0 veya 1 olan Stokta bir bayrağa ihtiyacınız vardır ve merkezi bir işlem bu bayrağı güncelleştirir. Bu şekilde, öğenin her yukarı / aşağı yumrularını her parçaya itmek zorunda kalmazsınız. Öte yandan, Çalışan veya Kullanıcı verileri,

Parçalanmış tablolardan parçalanmamış masalara katılacak mısınız? İdeal olarak, buradaki cevap hayırdır - verileri almak için iki ayrı sorgu yapmanız ve ardından uygulama tarafında onlara katılmanız gerekir. Bu, uygulama perspektifinden çok daha zorlaşır, ancak size her kaynaktan en taze verileri alma yeteneği verir.

Bu orijinal veriler mi yoksa kopyalanmış mı?Bu soruyu düşünmenin başka bir yolu: neyi yedeklemeniz gerekiyor ve ne sıklıkta? Genellikle yüksek hacimli bir parçalama ortamında, yedeklemelerin olabildiğince hızlı ve küçük olmasını istersiniz. (Sonuçta, her bir düğümü korumanız gerekir ve tüm kırıkların aynı anda DR'ye geçmesini istersiniz - diğerlerinden daha yeni verilerle bazı parçalara sahip olmamanız gerekir.) Bu, parçalanmış verilerin ve gölgeli veriler tamamen aynı veritabanında olmalıdır - aynı sunucuda olsalar bile. Kırık (orijinal) verilerimin sürekli işlem günlüğü yedeklemesine ihtiyacım olabilir, ancak gölgeli olmayan verileri hiç yedeklemem gerekmeyebilir. Çalışanlar veya Kullanıcılar tablomı, her parçaya yedeklemek yerine, tek bir gerçek kaynaktan yenilemek benim için daha kolay. Yine de tüm verilerim tek bir veritabanındaysa,

Şimdi, endişeleriniz hakkında:

"İşlem sorunları ... artık bunu kolayca yapamayacaksınız." Doğru. Kırık senaryolarda, işlem kavramını pencereden dışarı atın. Daha da kötüleşir - parçalanmış veriler için, bir küme örneği yük devretme veya yeniden başlatma nedeniyle bir parça yukarı ve çevrimiçi, diğeri geçici olarak aşağı olabilir. Sistemin herhangi bir parçasının arızalanmasını istediğiniz zaman planlamanız gerekir.

Msgstr "Çapraz veritabanı referans bütünlüğü yapmak mümkün değil." Doğru. Tek bir tabloyu birden çok sunucuya böldüğünüzde, büyük erkek pantolonunuzu giyiyorsunuz ve veritabanı sunucusuna, zaman içinde yedeklemeler, tablolar arasındaki ilişkiler ve çoklu kaynaklar. Artık siz ve kodunuzda.

"Sistemin geniş alanlarını yeniden kodlamak, böylece yeni evrensel veritabanına ortak veri yazmayı biliyor, ancak parçalardan ortak verileri okuyor." Burada da düzeltin. Bunun için kolay bir düğme yok, ancak bunu uygulamaya yerleştirdikten sonra, deli gibi ölçeklenebilirsin. Bunu yapmanın daha kolay yolunun uygulamanın bağlantılarını okumalara ayırmak olduğunu iddia ediyorum .

"artan veritabanı gezileri." - Evet, verileri birden çok sunucuya bölerseniz, uygulamanın ağa daha fazla erişmesi gerekecektir. Anahtar, bu verilerin bir kısmının daha düşük maliyetli, daha yüksek verimli, kilitsiz sistemlerde saklanabilmesi için önbellekleme uygulamaktır. En hızlı sorgu hiç yapmadığınız sorudur.

Ayrıca , burada bireysel kiracılara performans ayarlama, parça başına farklı yedekleme / kurtarma stratejileri ve şema dağıtım zorlukları gibi çok kiracılı veritabanlarını bölmek için daha fazla artı ve eksiler ortaya koydum.

Yüksek düzeyde, verileri parçalamanın (veya yatay olarak bölümlendirmenin) tipik yolu, işlem tablolarını parçalamak ve ana düzey tabloları çoğaltmaktır. Çoğu teknoloji çözümü gibi, bu da elbette bir takım problemleri çözer ve yepyeni bir problemler yaratır ... ama hepimiz buna alıştık, değil mi? ;-)

Ancak SQLServer'ın bunun için en iyi çözüm olup olmadığını sorgulayacağım. İş yükü daha çok OLTP veya DW / BI gibi mi?

Şerefe Dave Sisk

Olası bir 3. seçenek. İlişkisel parçalama (kara kutu parçalama yerine) kullanarak, tüm veritabanınızı parçalayabilir ve dağıtabilirsiniz. Geleneksel bir ilişkisel veri modelinden oluştuğu için, veritabanı hangi verilerin hangi sunucularda depolandığını ve böylece nerede bulunacağını bilir, böylece tüm verileriniz 'ortak / evrensel' olarak kabul edilebilir. Tüm kırma işlemini kolaylaştırmak için dbShards'a göz atın.