+90 850 305 14 95 info@padima.com.tr

Merhaba,
SQL Server 2012’nin çıkışının ardından 2 sene geçti ve büyük bir heyecanla SQL Server 2014 çıkışını bekliyoruz. SQL Server 2014 heyecan verici birçok yenilikle geliyor. Bu heyecan verici yeniliklerin başında gelenlerden birisi ise In-Memory OLTP. In-Memory kavramı özellikle benim gibi İş Zekası tarafında da çalışanlar için yeni bir kavram değil. Fakat bu teknolojinin günlük veri tabanlarına taşınması bizim içinde dikkate değer.

Bilindiği üzere SQL Server üzerinde performans çalışmaları yapıldığında dar boğaz oluşumuna sebep olan kaynakların en başında diskler gelmektedir. Bu sorunun temelinde 3 şey yatmakta

1. Disklerin kendi içinde veri okuma hızı sorunu.

2. Veriyi Diskten alıp CPU taşıyacak chipsetlerin hızı.

3. Disk ile CPU arasındaki veri yollarının genişliği.

MotherBoardSchema

Şekil 1a : Anakart şeması

Yukarıda bahsettiğimiz sorunların çözümünde birçok ilerleme kaydedildi. Mesela SSD diskler disk kaynaklı performans sorunlarına biraz çözüm oldu. Mesela disk hızları 150-200 MB/s lerden 400-500 MB/s çıktı (PCI Express SSD daha yüksek). Bağlantı portlarındaki hız artışları ile 6Gb/s (Sata 3) hızlara ulaşıldı. Raid0 ,10 ,5 sistemleri ile hızlar artırıldı. Fakat Şekil 1a da gördüğünüz üzere CPU ile doğrudan bağlı olan RAM ile hiç biri boy ölçüşemez. Bir karşılaştırma olması için şöyle ifade edeyim. Benchmark değerlerine baktığımız zaman SSD diskler maksimum 500MB/s erişim hızları verirken ve bu değerler düşük okumalarda 9MB/s düşerken RAM okumalarında hız 16000MB/s düşük boyutlu veri okumalarında 20000MB/s civarlarındadır. Fark korkunç düzeylerde değil mi! Bu rakamların sorgu performanslarına bu oranlarla etki etmeyeceği kesin ama büyük bir fark yaratacağı da aşikâr.

Bu rakamları ortaya koyduktan sonra ve In-Memory OLTP kullanımına karar verdikten sonra aklımıza gelen ilk soru ise benim veri tabanı çok büyük. Disklerde çok büyük sorun olmuyordu ama veriyi belleğe taşımayı düşünürsek o kadar büyük belleği nereden bulacağız? Bilindiği üzere In-Memory OLTP database düzeyinde değil tablo düzeyinde çalışıyor. Sizin bütün veri tabanınızı değil sorun yaratan ve uygun olan tablolarınızı belleğe taşımanız gerekiyor. O zaman soruyu şu şekilde sormamız daha doğru olacaktır.

Taşımayı düşündüğüm tablo bellekte ne kadar yer tutar?

Bir tablonun bellekteki büyüklüğü hesaplamak istiyorsanız 3 noktaya bakmamız gerekiyor. Bu 3 şeyi tespit ettikten sonra bunların toplamı ihtiyacımızı ortaya koyacaktır.

1. Tablonun ihtiyaç duyduğu bellek alanı

2. Tabloya bağlı indekslerin ihtiyaç duyduğu bellek alanı

3. Ekstra bellek ihtiyaçları

Tablo İçin bellek hesaplaması:

Tablo içerisindeki her satır veri açısından 2 bölümden oluşmaktadır. Bunların toplamı satır maliyetini verir. Satır sayısı ile çarpımı da toplam ihtiyacı belirler.

rowstruct

  • · Satır Başlığı

o Başlangıç timestamp – 12 byte.

o Bitiş timestamp – 12 byte.

o Her bir index için işaretçi – 8 byte.

· Asıl Veri

o Alanların toplam büyüklüğü

Yukarıdaki tanımlamalara göre hesap basit

TabloBüyüklüğü = (BaşlıkBüyüklüğü + VeriBüyüklüğü)* SatırSayısı

İndeksler İçin bellek hesaplaması:

İndeksler bellekte diske nazaran genelde daha az yer tutar. İndeksler bellekte 8 bytelık hashcode larla tekilleştirilir ve bu kodlarla ana tabloya bağlanır. İndekslere ait büyüklüğü hesaplamak için önce olası kaç farklı değer olduğunun tespit edilmesi gerekir. Bunun için en uygun kod aşağıdadır

Select DISTINCT COUNT indeksAlanları FROM kaynakTablo

Ortaya çıkacak olan sayı tam olarak istediğimizi yansıtmamaktadır. Ortaya çıkan sayı 2 lik sayı sisteminde kendisine en yakın üst değere yuvarlanmalıdır. Mesela 30 çıktıya 32 ye 50 çıktıysa 64 de, 900 çıktıysa 1024 gibi.

Elde ettiğimiz indeks değerlerinin toplamlarını 8 bytelik işaretçi hash ile çarparsak indeksler için ihtiyaç duyacağımız değeri bulabiliriz.

Yukarıdaki tanımlamalara göre hesap basit

İndekslerBüyüklüğü = (İndeks1 + İndeks2+..+İndeks-n)* 8

Ekstra bellek ihtiyacı hesaplaması:

Ekstra bellek kavramı altında 2 şeye dikkat etmek gerekiyor.

1. Tablonun büyüyecek olması. Günlük bir veri tabanında tablonun büyümesini dikkate almadan ucu ucuna bir hesap daha sonra sizin başınızı ağrıtacaktır.

2. DML işlemleri sırasında sistem belleğinizden ekstra alanlar kullanır. Bu alanlar Garbage Collector tarafından temizlense de transaction süreleri ve sayıları dikkate alınarak ekstra bellek ihtiyacı olduğu dikkatimizden kaçmamalıdır.

Bu üç başlığı dikkate alarak yapacağınız bir hesaplama ile aşağıdaki formüle ulaşıyoruz.

ToplamBellekİhtiyacı = TabloBüyüklüğü+İndekslerBüyüklüğü+Ekstraİhtiyaçlar

In-Memory OLTP tabloları kullanmaya başlamadan önce uygulamalarımızda ve tasarımlarımızda dikkat etmemiz gereken birçok konu var. Belki başka bir yazıda da onların üzerinde dururuz.