Ana içeriğe atla

Heap, Clustered İndeks ve Nonclustered İndeks Data Yapıları - Bölüm 1 (Tablo ve İndeks Organizasyonu, Heap Mimarisi)

1.Tablo ve İndeks Organizasyonu
Tablo Organizasyonu
Tablolar bir veya birden fazla partition ile oluşabilir. Her partition heap veya clustered indeks yapısında veri satırlarıdan oluşur.
Partition Organizasyonu
Partition kullanıcı tanımlı veri organizasyon birimidir. Tablolar varsayılan olarak bir partitiona sahiptirler. Bir tablo ve indeks, birden fazla partition içeriyorsa, veri yatay olarak bölümlenir. Partitionlar veritabanında bir veya daha fazla filegroup içerisine konulabilirler. Veri üzerinde sorgu ve updateler gerçekleştirilirken tablo veya indeksler tek mantıksal varlıklar olarak işlem görürler.
Clustered Tablolar, Heap ve İndeksler
SQL Server tabloları partitiondaki data pageleri organize etmek için iki metot kullanır:
1.Clustered Tablo: Clustered indeks içeren tablodur.
Veri satırları (data rows) clustered indeks anahtarının sırasıyla dosyada saklanır. Clustered indeks, clustered indeks anahtar değerine dayanarak daha hızlı satır erişimi sağlayan B-tree indeks yapısında yürütülür. İndeksin her seviyesindeki pageler(leaf seviyesindeki data pageler de dahil) doubly-linked list içerisinde bağlıdırlar. Ancak bir seviyeden diğerine dolaşmak key değerlerini kullanarak gerçekleşir.
2.Heap: Clustered indeks içermeyen tablodur.
Veri satırları özel bir sıralama içinde saklanmazlar, ve data pagelerin sırasında da özel bir sıralama yoktur. Data pageler linked list içinde bağlı değillerdir. Indexed Viewler de clustered tablolarla aynı yapıda saklanırlar. Heap veya clustered tablolar birden fazla partition içerirse, her partition kendine ait satır gruplarını içeren heap veya B-tree yapısına sahip olur. Örneğin bir clustered tablo dört partition içeriyorsa, dört tane B-tree yapısı vardır.

Nonclustered İndeksler
Nonclustered indeksler bir clustered indekse benzer B-tree indeks yapısına sahiptir. Farklı olarak nonclustered indeksler veri satırlarının sıralanmasını etkilemezler. Leaf seviyesi indeks satırlarını içerir. Her indeks satırı bir değer, satır göstergesi ve varsa included(veya nonkey) kolon içerir. Gösterge anahtar değerine sahip veri satırını işaret eder.
Bir allocation unit, kendi page tipindeki veriyi yönetmek için kullanılan heap veya B-tree içinde page grubudur. Aşağıdaki tabloda, tablo ve indeksin verisini yönetmek için kullanılan allocation unit tipleri listelenmektedir:
IN_ROW_DATA Veri veya indeks satırları Large Object Data (LOB) dışında tüm veriyi kapsar.
Pageler veri veya indeks tipleridir.
LOB_DATA Large Object veri text, ntext, image, xml, varchar(max), nvarchar(max), varbinary(max) veya user defined types data tipleri içinde depolanır.
Pageler text\Image tipleridir.
ROW_OVERFLOW_DATA Variable-Length veri, 8060 byte row size ile sınırlı varchar, nvarchar, varbinary ve sql_variant veri tiplerinde depolanır.
Pageler veri tipleridir.
2.Heap Mimarisi
Heap, clustered indeks içermeyen tablodur. Heap, heapte kullanılan her partition için sys.partitions içerisinde indid = 0 olan bir satır içerir. Heap ön değer olarak bir partitiona sahiptir. Eğer birden fazla partition oluşturulursa her biri kendine özel veri yapısını içeren bir heap yapısı içerir. Örneğin bir heap dört partition ise, burada dört heap yapısı vardır.
Heap içinde veri tipine bağlı olarak her heap yapısı, partitiona özel veriyi kaydetmek ve yönetmek için bir veya daha fazla yerleşim birimine(allocation unit) sahiptir. Her heap, her partition için minimum bir IN_ROW_DATA yerleşim birimine sahiptir. Heap eğer large object (LOB) kolon içeriyorsa her partition için bir de LOB_DATA yerleşim birimini içerir. Heap eğer 8060 byte row size ile sınırlanmış variable length kolon içeriyorsa her partition için bir de ROW_OVERFLOW_DATA yerleşim birimine sahiptir.
sys.system_internals_allocation_units sistem view içinde first_iam_page kolonu, heap yapısının boş alanlarını yöneten IAM page zincirindeki ilk IAM page göstergesidir. SQL Server IAM pageleri heaplere ulaşmak için kullanır. Data page ve rowlar bunları içinde özel bir sıralamada da değildir ve birbirine bağlı değildir. IAM pagelerin içine kaydedilmiş data pageler mantıksal olarak birbirine bağlıdır.
Tablo tarama ve heap okuma, heap için tutulan pagelerin alanlarını IAM pageleri tarayarak bulur. Çünkü IAM veri dosyasında bulunduğu sıra ile aynı sırada tutan bir alanı gösterir, yani Heap dosyaları birbirleriyle aynı sırada scan işlemi yapar.
Referanslar
1. http://msdn.microsoft.com
Serap PARLAK

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara