SQL Server 2008 - Bölümleme ve Kümelenmiş Dizinler

Bu yüzden db tasarımım üzerinde tam bir kontrole sahip olmadığımı söyleyerek önsöz edelim, bu nedenle mevcut sistemin yönlerinin birçoğu bu senaryonun amaçları için değiştirilemez .

Tasarımın yönlerini nasıl yeniden düşünmemiz gerektiğine dair yorumlar muhtemelen doğru ama yararsızdır :)

Çok sayıda işlemi yürüten çok büyük bir masam var, yaklaşık 150 alan genişliğinde ve yaklaşık 600m sıralarım var. Bu bir veri ambarı durumunda olduğundan, zamanlanan yükleme işlemi dışında HİÇBİR güncellememiz / eklememiz yok, bu nedenle büyük ölçüde dizine eklenmiş.

Bu tabloyu bölümlemeye çalışmamaya karar verildi ve bölümlenmiş bir tabloyu indeksleme konusunda bazı endişelerim var. Bölümleme ile ilgili herhangi bir deneyimim yok, bu yüzden herhangi bir giriş veya bağlantı takdir ediliyor. BOL veya msdn üzerinde özellikle ne olduğumu bulamadım.

Şu anda biz diyeceğiz ki sahada küme IncidentKeybir olan varchar(50)aynı ile 1-100 kayıtları arasında olabilir - ve benzersiz IK(hiç yorum lütfen). Eski IncidentKeykayıtlarla ilgili sık sık yeni veriler alırız, bu yüzden de sıralı değildir.

IncidentDateBölümün düzgün çalışması için kümelenmiş dizin anahtarımda bölüm alanımı eklemem gerektiğini anlıyorum . Olacağını düşünüyorum IncidentKey, IncidentDate.

Soru, "yeni" bir bölümdeki bir kayıt, kümelenmiş dizindeki "eski" bir bölümdeki bir kayıttan önce olursa, kümelenmiş bir dizinin mekaniği bölümlenmiş bir tabloda 2 bölümlü bir anahtar üzerinde nasıl çalışır?

Örneğin, 5 kaydım var:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Yeni bir kayıt ABC123, 2/1/2011alırsam ÖNCE kümelenmiş dizin içinde olması gerekir XYZ999, 1/1/2010. Bu nasıl çalışıyor?

Parçalanma ve işaretçiler varsayıyorum, ancak fiziksel depolama ve çift bölüm anahtarları ile bölümlenmiş tablolarda bölümlenmiş kümelenmiş dizin yapılandırması hakkında herhangi bir bilgi bulamıyorum.

Bölümlenmiş bir tablo gerçekten birbirine dikilmiş ayrı tabloların bir koleksiyonuna benzer. Bu nedenle, kümeleme IncidentKeyve bölümleme örneğinizde IncidentDate, bölümleme işlevinin tabloları iki bölüme ayırdığını, böylece 1/1/2010 bölüm 1'de ve 7/1/2010 bölüm 2'de olduğunu varsayalım. Veriler disk üzerinde şu şekilde düzenlenir:

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

Düşük bir seviyede gerçekten iki ayrı sıra vardır. Tüm satır kümelerini bir arada arayan, tarayan ve güncelleyen planlar oluşturarak tek bir tablonun illüzyonunu veren sorgu işlemcisidir .

Kümelenmemiş herhangi bir dizindeki herhangi bir satır, karşılık gelen kümelenmiş dizin anahtarına sahip olacaktır ABC123,7/1/2010. Kümelenmiş dizin anahtarı her zaman bölümleme anahtarı sütununu içerdiğinden, motor her zaman bu değeri aramak için kümelenmiş dizinin hangi bölümünde (satır kümesi) (bu durumda bölüm 2'de) bilir.

Şimdi bölümleme ile uğraşırken, NC dizinlerinizin hizalanıp (NC dizininin kümelenmiş dizinle tamamen aynı bölümlenmiş olup olmadığını) veya hizalanmamış (NC dizinin bölümlenmemiş veya kümelenmiş dizinden farklı bölümlenip bölünmeyeceğini) dikkate almalısınız. . Hizalanmamış dizinler daha esnektir, ancak bazı dezavantajları vardır:

• hizalanmayan dizinler belirli sorgu planları için büyük miktarda bellek gerektirir
• hizalanmayan dizinler verimli bölme anahtarı işlemlerini önler

Hizalanmış dizinleri kullanmak bu sorunları çözer, ancak kendi sorun kümesini getirir, çünkü bu fiziksel, depolama tasarımı seçeneği veri modeline dalgalanır:

• hizalı dizinler, benzersiz kısıtlamaların artık oluşturulamayacağı / uygulanamayacağı anlamına gelir (bölümleme sütunu hariç)
• bölümlenmiş tabloya başvuran tüm yabancı anahtarlar ilişkide bölümleme anahtarını içermelidir (çünkü bölümleme anahtarı, hizalama nedeniyle, her dizinde) ve bu da bölümlenmiş tabloya başvuran tüm tabloların bölümleme anahtar sütun değeri içermesini gerektirir. Siparişleri SiparişNo var ama SiparişTarihi tarafından bölümlenmiş ise Siparişler-> OrderDetails, ardından OrderDetails sadece OrderID ama içermelidir düşünün da yabancı anahtar kısıtlamasını beyan düzgün amacıyla SiparişTarihi.

Bölümlendirmeyi dağıtan bir projenin başında nadiren bulduğum bu etkiler, ancak bunlar var ve ciddi sonuçları var.

Hizalanmış dizinlerin nadir veya aşırı bir durum olduğunu düşünüyorsanız, bunu göz önünde bulundurun: çoğu durumda ETL ve bölümleme çözümlerinin temel taşı, hazırlama tablolarının hızlı geçişidir. Geçiş işlemleri hizalanmış dizinler gerektirir.

Oh, bir şey daha: yabancı anahtarlar ve bölümleme sütun değeri diğer tablolara eklemek dalgalanma etkisi hakkında tüm benim argüman birleşimleri için de geçerlidir .

Kümelenmiş bir dizin birden çok bölüm içeriyorsa, her bölüm ilgili bölüme ait verileri içeren bir B ağacı yapısına sahiptir. Örneğin, kümelenmiş bir dizinin dört bölümü varsa, dört B-ağacı yapısı vardır; her bölümde bir tane. Ref. Kümelenmiş Dizin Yapıları

Bölümlenmiş Dizinler için Özel Yönergeler

Bölümlenmiş bir dizinin belirli bölümlerini yeniden oluşturabilirsiniz.

Örneğin

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO