Büyük veri kümelerini işlemek için SQL Server 2008 R2 için parça oluşturma kurulum kalıpları?

SQL Server 2008 R2'de büyük bir veri kümesini (> 1 milyar satır) işlemek istiyorum. "Parçalama" veya "yatay bölümleme" ayarladıysanız, tabloları birden çok dosyaya böldüğünde büyük veri kümelerinin işlenmesini hızlandırdığını duydum.

Daha önce parçalama veya yatay bölümleme kullandınız mı? Öyleyse, deneyiminizde tek bir masif tabloya kıyasla daha iyi sonuçlar veren herhangi bir model önerebilir misiniz?

İlk olarak, sıradan emtia sunucusu donanımında bölümlenmiş bir mimariyle 1 milyar satırın etkili bir şekilde ele alınabileceğini unutmayın. Egzotik paylaşılan hiçbir şey mimariler bu veri hacmi için gerekli olmayacak, ancak muhtemelen tablo bölümlemeden önemli faydalar elde edeceksiniz.

Parçalama, yatay bölümlemeden farklı bir şeydir ve SQL Server'ın çoğu sürümü tarafından desteklenmeyen bir 'paylaşılan hiçbir şey' mimarisi anlamına gelir ¹

SQL Server yatay bölümlemeyi destekleyebilir ve paylaşılan disk mimarisi ~ 1 billon satır için yeterli olacaktır.

SQL Server'da, bir tablodaki bir sütundaki değerlere veya değer aralıklarına göre bir bölüm seçen bir bölüm işlevi oluşturursunuz;

create partition function F_AccPrdPart (int)
    as range left for values (
    180001                         -- Dummy value
   ,199012 ,199112 ,199212 ,199312, 199412 ,199512
   ,199612 ,199712 ,199812 ,199912 ,200012 ,200112
   ,200212 ,200312 ,200412 ,200512 ,200612 ,200712
   ,200812
   ,200901, 200902, 200903, 200904, 200905, 200906
   ,200907, 200908, 200909, 200910, 200911, 200912
   ,201001, 201002, 201003, 201004, 201005, 201006
   ,201007, 201008, 201009, 201010, 201011, 201012
   ,201101, 201102, 201103, 201104, 201105, 201106
   ,201107, 201108, 201109, 201110, 201111, 201112
   ,202012
   ,939999                         -- Dummy value
)
go

Ardından bölümleri ayırmak için bir veya daha fazla dosya grubu oluşturun. Büyük bir veri kümesi için, bu dosya grupları farklı fiziksel birimlerde kurulabilir. Doğrudan takılan depolamanın hemen hemen tüm durumlarda bunun için SAN'dan çok daha hızlı olacağını unutmayın. Aşağıdaki örnekte, PartVol1-PartVol6 adlı 6 dosya grubu yaratırdık.

Bölümleme işlevinin değerine dayalı olarak tablo bölümlerini dosya gruplarına ayırmak için bir veya daha fazla bölüm şeması oluşturulabilir;

create partition S_AccPrdPart as partition F_AccPrdPart
    TO ([PRIMARY]
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6] 
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
      ,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
      ,[PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
      ,[PartVol2]
      ,[PRIMARY]
      ,[PRIMARY])
go

Bu şema bir hesap dönemine bölümlenecek şekilde tasarlanmıştır. Bunun için tarihler de sıklıkla kullanılır, ancak herhangi bir anahtar kullanılabilir.

Bölümleme şemasında bir dosya grubuymuş gibi bir tablo oluşturabilirsiniz;

Create table FooTrans (
       FooTransID        int identity (1,1) not null
      ,AccPeriod         int not null
      ,[...]
) on S_AccPrdPart (AccPeriod)
go

Tablonun, belirli bir dosya grubu yerine bölüm düzeninde oluşturulduğunu ve yan tümce, bölüm anahtarı olarak kullanılacak sütunu belirttiğini unutmayın. Bölüm anahtarına bağlı olarak, tablodaki satırlar bölüm düzenindeki dosya gruplarından birine atanır.

Not: Bir bölümleme şeması tasarlamak için genel bir kural, her bölümün, satırların genişliğine bağlı olarak 10 ila 50 milyon arasında, örneğin 10 ila 50 milyon arasında bir satır sayısına sahip olması gerektiğidir. Bölümün oturduğu disk birimi, birkaç saniye içinde en az bir bölümün taranmasını sağlayacak kadar hızlı olmalıdır.

Bölümleme, Parçalama ve Paylaşılan Hiçbir Şey sistemleri

Burada bu konuyla ilgili bazı tartışmaları netleştirmek için biraz terminoloji var gibi görünüyor.

• 'Paylaşılan hiçbir şey' sistemi, düğümlerin paylaşılan SAN depolama alanına sahip olmadığı, ancak düğümün yerel depolama birimini kullandığı paralel bir sistemdir. Bu tür mimarinin klasik örneği Teradata'dır. Paylaşılan hiçbir şey, merkezi G / Ç darboğazları olmadığı için çok büyük veri kümelerine iyi ölçeklenmez. G / Ç işlem hacmi sistemdeki düğüm sayısı ile ölçeklenir.

• 'Paylaşılan disk' sistemi, bir veya daha fazla veritabanı sunucusunun tek bir disk depolama altsistemini paylaştığı sistemdir. Veritabanı, yerel depolama alanına sahip veya bir SAN'a bağlı tek bir sunucu veya paylaşılan bir SAN'a bağlı sunucular kümesi olabilir. Bu tür sistemler, depolama altsisteminden sağlanan verim ile sınırlıdır.

• 'Parçalama', paylaşılan bir şey mimarisinde bir veritabanını birden çok fiziksel sunucu arasında bölmeyi tanımlamak için kullanılan bir terimdir. Çeşitli platformlar, parçalanmış veritabanları için daha fazla veya daha az desteğe sahip olacaktır. Teradata çevrelerinde bu terim kullanılmaz çünkü Teradata, fiziksel mimari paylaşılan hiçbir şey türü olmasa da istemcilere saydam bir tek sistem görüntüsü sunar.
  
  SQL Server'ın eski sürümleri dağıtılmış bölümlenmiş görünümler aracılığıyla parçalama için sınırlı desteğe sahiptir. Microsoft artık tek bir sistem görüntüsü ile paylaşılan hiçbir şeyi desteklemeyen bir mimariyi destekleyen SQL Server 2008 R2'nin bir sürümünü üretmektedir, ancak bu sürüm yalnızca OEM'ler tarafından kullanılabilir ve yalnızca bir donanım paketinde satın alınabilir.

1 milyar sıra için

1 milyar sıra için (münferit sıralar çok geniş olmadığı sürece) paylaşılan hiçbir şey veya parçalanmış mimari, aşırıya kaçma alemlerinde rahatça bulunur. Bu tür bir birim, yeterince hızlı bir disk alt sistemine sahipse, makul özellikli tek bir sunucuda işlenebilir.

Yerel doğrudan takılan disk, performans fiyatı açısından açık ara en yüksek maliyetlidir. Tek bir SAS RAID denetleyicisi birkaç dizi alabilir ve bir sunucuya birden çok denetleyici yüklenebilir. Yapılandırmaya bağlı olarak, modern bir 24-25 yuvalı SAS dizisi akış performansında binlerce IOPS veya 1GB + / sn geçebilir; çoklu PCI-e veri yollarına ve çoklu denetleyicilere sahip bir sunucu teorik olarak daha fazla işlem yapabilir.

1 milyar satırlık bir veritabanı ile çalışmak için gerekli olan performans türü, emtia sunucu donanımı ve bu türden doğrudan ek depolama ile oldukça kolay ve ucuz bir şekilde elde edilebilir. Bir SAN da kullanılabilir, ancak eşdeğer performans elde etmek için birden fazla SAN denetleyicisine ihtiyacınız olabilir ve donanımın daha büyük bir sipariş sırası olması muhtemeldir.

Genel bir öneri olarak, gerçekten iyi çalışma süresine ihtiyacınız olmadıkça, ağır I / O gereksinimleri olan uygulamalar için doğrudan takma depolama kullanın. Yapılandırma ve değişiklik kontrol hataları, modern veri merkezi işletim sistemlerindeki donanım arızasından çok daha büyük planlanmamış arıza süresi kaynağıdır.

SAN'lar geniş bir uygulama portföyünüz varsa size bir dizi merkezi depolama yönetimi olanağı sağladığında size daha yönetilebilir bir depolama platformu sağlayabilir. Ancak, bu dik bir fiyata geliyor ve SAN tabanlı altyapıdan yüksek performans elde etmek zor ve pahalıdır.

¹ Microsoft, SQL Server'ın paralel bir sürümünü yapar, ancak yalnızca donanımla birlikte verilen OEM kanalları aracılığıyla kullanılabilir. Rafta bulunan sürümler bu özelliği desteklemez.