Pola untuk menyiapkan sharding untuk SQL Server 2008 R2, untuk menangani dataset besar?

Saya ingin menangani dataset besar (> 1 miliar baris) di SQL Server 2008 R2. Saya mendengar bahwa jika Anda mengatur "sharding" atau "partisi horisontal", itu membuatnya lebih cepat untuk menangani dataset besar karena memecah tabel menjadi beberapa file.

Apakah Anda pernah menggunakan sharding atau partisi horizontal sebelumnya? Jika demikian, dapatkah Anda menyarankan pola apa pun yang, dalam pengalaman Anda, mencapai hasil yang lebih baik dibandingkan dengan satu tabel besar?

Pertama, perhatikan bahwa 1 miliar baris dapat ditangani secara efektif dengan arsitektur yang dipartisi pada perangkat keras server komoditas biasa. Arsitektur apa-apa yang dibagikan secara eksotis tidak diperlukan untuk volume data ini, namun, Anda mungkin akan mendapatkan manfaat signifikan dari partisi tabel.

Sharding adalah sesuatu yang berbeda dari partisi horizontal, dan menyiratkan arsitektur 'shared nothing', yang tidak didukung oleh sebagian besar versi SQL Server ¹

SQL Server dapat mendukung partisi horisontal, dan arsitektur disk bersama akan memadai untuk ~ 1 miliar baris.

Dalam SQL Server, Anda membuat fungsi partisi memilih partisi berdasarkan nilai atau rentang nilai dalam kolom di atas tabel, misalnya

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

Kemudian buat satu atau lebih grup berkas untuk mengalokasikan partisi. Untuk kumpulan data besar, grup file ini dapat diatur pada volume fisik yang berbeda. Perhatikan bahwa penyimpanan lampiran langsung akan jauh lebih cepat daripada SAN untuk ini di hampir semua kasus. Pada contoh di bawah ini, kita akan membuat 6 filegroup yang disebut PartVol1-PartVol6.

Satu atau lebih skema partisi dapat dibuat untuk mengalokasikan partisi tabel ke filegroup berdasarkan nilai fungsi partisi, misalnya

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

Skema ini dirancang untuk dipartisi pada periode akuntansi. Tanggal juga sering digunakan untuk ini, meskipun kunci apa pun dapat digunakan.

Anda dapat membuat tabel pada skema partisi seolah-olah itu adalah filegroup, misalnya

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

Perhatikan bahwa tabel dibuat pada skema partisi alih-alih grup file yang ditentukan, dan klausa menentukan kolom yang akan digunakan sebagai kunci partisi. Berdasarkan kunci partisi, baris-baris dalam tabel akan dialokasikan ke salah satu filegroup dalam skema partisi.

catatan: Aturan praktis untuk merancang skema pemartisian adalah bahwa setiap partisi harus memiliki jumlah baris dalam 10 dari jutaan, katakan antara 10 dan 50 juta tergantung pada lebar baris. Volume disk tempat partisi itu harus cukup cepat untuk melakukan pemindaian setidaknya satu partisi dalam beberapa detik.

Sistem Partisi, Sharding, dan Tidak Ada yang Dibagikan

Agak terminologi tampaknya untuk disambiguasi beberapa diskusi tentang topik ini.

• Sistem 'shared nothing' adalah sistem paralel di mana node tidak memiliki penyimpanan SAN bersama, tetapi menggunakan penyimpanan lokal ke node. Contoh klasik dari jenis arsitektur ini adalah Teradata. Sistem apa-apa yang dibagi skala dengan baik untuk set data yang sangat besar karena mereka tidak memiliki hambatan I / O pusat. I / O skala throughput dengan jumlah node dalam sistem.

• Sistem 'disk bersama' adalah sistem di mana satu atau lebih server database berbagi subsistem penyimpanan disk tunggal. Basis data dapat berupa server tunggal dengan penyimpanan lokal atau terpasang ke SAN, atau sekelompok server yang terhubung ke SAN bersama. Sistem jenis ini dibatasi oleh throughput yang tersedia dari subsistem penyimpanan.

• 'Sharding' adalah istilah yang digunakan untuk menggambarkan pemisahan database di antara beberapa server fisik dalam arsitektur apa-apa yang dibagikan. Berbagai platform akan memiliki dukungan yang lebih besar atau lebih kecil untuk basis data sharded. Dalam lingkaran Teradata, istilah ini tidak digunakan karena Teradata menghadirkan gambar sistem tunggal transparan kepada klien, meskipun arsitektur fisiknya adalah tipe apa-apa yang dibagikan.
  
  Versi SQL Server yang lebih lama memiliki dukungan terbatas untuk sharding melalui tampilan yang dipartisi terdistribusi. Microsoft sekarang membuat versi SQL Server 2008 R2 yang mendukung arsitektur apa-apa bersama dengan gambar sistem tunggal, tetapi versi ini hanya tersedia untuk OEM dan hanya dapat dibeli dalam bundel perangkat keras.

Untuk 1 miliar baris

Untuk 1 miliar baris (kecuali masing-masing baris sangat lebar), tidak ada apa pun yang dibagikan atau arsitektur yang terbengkalai dengan nyaman di ranah pembunuhan berlebihan. Jenis volume ini dapat ditangani pada satu server dengan spesifikasi wajar jika memiliki subsistem disk yang cukup cepat.

Disk sambungan langsung lokal sejauh ini merupakan yang paling efektif dari segi harga untuk kinerja. Pengontrol SAS RAID tunggal dapat mengambil beberapa larik, dan beberapa pengontrol dapat diinstal di server. Bergantung pada konfigurasi, array SAS 24-25 slot modern dapat digunakan melalui ribuan IOPS atau 1GB + / detik dalam kinerja streaming; server dengan banyak bus PCI-e dan beberapa pengontrol secara teoritis dapat menangani lebih banyak.

Jenis kinerja yang diperlukan untuk bekerja dengan basis data 1 miliar baris dapat dicapai dengan cukup mudah dan murah dengan perangkat keras server komoditas dan penyimpanan pemasangan langsung jenis ini. SAN juga dapat digunakan, tetapi Anda mungkin memerlukan beberapa pengontrol SAN untuk mendapatkan kinerja yang setara, dan perangkat kerasnya kemungkinan besar lebih mahal.

Sebagai rekomendasi umum, gunakan penyimpanan attachment langsung untuk aplikasi dengan persyaratan I / O yang berat kecuali Anda membutuhkan waktu kerja yang sangat baik. Kesalahan konfigurasi dan perubahan kontrol adalah sumber downtime yang jauh lebih besar daripada kegagalan perangkat keras di operasi pusat data modern.

SAN dapat memberi Anda platform penyimpanan yang lebih mudah dikelola jika Anda memiliki portofolio aplikasi yang besar karena menyediakan berbagai fasilitas manajemen penyimpanan terpusat. Namun, ini datang dengan harga yang mahal dan mendapatkan kinerja tinggi dari infrastruktur berbasis SAN itu sulit dan mahal.

¹ Microsoft memang membuat versi paralel SQL Server, tetapi hanya tersedia melalui saluran OEM yang dibundel dengan perangkat keras. Versi yang tersedia dari rak tidak mendukung kemampuan ini.