SQL Server 2016 Yenilikleri - 3 (Operational Analytics)

SQL Server 2016 Yenilikleri Serimizin ilk iki yazısında InMemory OLTP ve InMemory DW (ColumnStore) alanında duyurulan gelişmelerden bahsetmiştik. Yazılara bir göz atmak isterseniz aşağıdaki linkleri kullanabilirsiniz

InMemory DW (ColumnStore) tarafındaki gelişmeler için:
http://abdullahkise.blogspot.co.uk/2016/03/sql-server-2016-yenilikleri-1-in-memory.html

InMemory OLTP (Memory Optimized) tarafındaki gelişmeler için :
http://abdullahkise.blogspot.co.uk/2016/03/sql-server-2016-yenilikleri-2-in-memory.html

Bu yazımızda iki alandaki gelişmeleri bir araya getireceğiz ve gerçek zamanlı analizler yapabildiğimiz 'Operational Analytics' konseptinden bahsedeceğiz.

Önce biraz geçmişe bakalım

Geleneksel bir sistemde Insert, Update, Delete iş yükünü karşılayan veritabanlarında normalizasyon kuralları uygulanır. I,U,D işlemlerinin optimum kalitede yapılabildiği bu veritabanı modelleri OLTP kısaltmasıyla anılır. Sıklıkla iş süreçlerinin takibi için kullanılan sistemler zamanla çeşitlenir ve farklı mantıklarda tasarlanmış birden fazla OLTP kaynak, yamalanmış sürecin bir parçası olur.

Sonra bu kaynaklardaki veriler iş kararları vermek amacıyla ele alınmak istendiğinde işin içinden çıkılamaz. Çünkü artık kaynaklar arası bir standart kalmamış, veriler kirlenmiştir. Bu durumda devreye veriambarları girer. Veriambarları (DW, DWH) analiz etmeye yani SELECT etmeye en müsait şekilde modellenmiş veritabanlarıdır. Veriler  ETL dediğimiz veri aktarım ve dönüştürme süreçlerinden geçirilerek bir takım ara katmanlara, sonrasında da veriambarına aktarılır.

Veriambarlarında verinin kolayca analiz edilebileceği Dimensional Model yaklaşımı benimsenir. Artık elimizdeki sistem bir OLAP sistemi olarak anılır. Tabi daha fazla hız ve esneklik bekleyenler için bir adım daha atılır; OLAP Cubelerinin oluşturulması (Multidimensinal, Tabular). En basit söylemle Cubeler veriyi, yapıyı ve ek hesaplamaları üzerinde tutar. Böylece önceden hazırlanmış veriye bir nevi koordinat sistemi mantığıyla erişmek mümkün olur. Tekrar tekrar hesaplama yapılmaz. Bundan sonraki aşamada da veri bir takım raporlama araçlarıyla görüntülenebilir.

Bahsettiğimiz bu geleneksel sürecin avantajları olduğu gibi dezavantajları da var. Bu dezavantajlara kısaca değinelim:

• ETL İşlemlerinin yükü:

Öncelikle verileri temizlemek ve standartlaştırmak için ETL işlemleri yapmanız gerekir. Bu işlemler bazen çok karmaşık olabilir. Bunun yanında sisteme girilen verinin raporlanması için belli bir süre geçmesi gerekir. Bazen bu gecikme dakikalar seviyende, bazen de günler seviyesinde olabilir.

• Küplerin 'Process' edilmesi:

Kaynaklardan veriambarına yapılan aktarımlar ETL süreçlerinde ele alınır. ETL süreçlerine benzer şekilde veriambarından 'OLAP Cube'lerine de veri aktarımı yapılır. Bu sürece Cube Processing denir. Benzer şekilde burada da bir karmaşıklık ve gecikme söz konusudur.

• Yazılım, Donanım, Geliştirme ve Bakım planı:

Sistemdeki karmaşıklık hem geliştirme hem de bakım planının ciddi şekilde ele alınmasını gerektirir. Verinin çeşitli kademelere aktarılması ve çoğaltılması yazılım/donanım yatırımı konusunda titiz olmayı gerektirir.

Özetlersek; geleneksel analitik sistemlerde veri çoklanır ve verinin gelmesi için zamana ihtiyaç vardır. Maliyetli ve yavaş (en azından gerçek zamanlı sayılmaz) bir sistem.

Tabi ki, eğer birden fazla kaynak varsa, bunları bir araya getirmek için veriambarı tasarlamak çoğu zaman en sağlıklı ve en güvenli yol olur. Bazen bu adım atılmadan sistemde performans artışı sağlanamayabilir. 

Index, paralelizm vb. konfigurasyonların yetmediği yerlerde okuma ve yazma iş yüklerini ayırmak genellik net çözümdür.

Veriambarı zorunluluğunun olduğu sistemlerde gerçek zamana yakın bir raporlama yapmak için veriambarından raporlama yapılır. OLAP Cube'lerinin avantajlarından faydalanmak isteniyorsa, Multimensional için sadece yapının korunduğu, verinin veriambarından her defasında temin edildiği ROLAP modu, Tabular için benzer şekilde verinin veriambarından temin edildiği DirectQuery modu tercih edilir. Böylece yapı her ne kadar OLAP Cube olsa da veri veriambarının performansına ve güncelliğine bağlı olarak sunulur. Geleneksel sistemlerin gerçek zamanlı raporlama konusunda geldiği nokta özetle buydu. 

Oyuna sonradan dahil olan çözümlerle düşünelim

SQL Server 2012 ile duyurulan 'ColumnStore Index'ler zamanla gelişti ve Select konusunda 100 kat performans sunan InMemory DW çözümü, SQL Server 2016 ile birlikte son derece başarılı bir noktaya ulaştı. Benzer şekilde SQL Server 2014 ile birlikte duyurulan InMemory OLTP'de 'Memory Optimized Table'lar üzerinden INSERT, UPDATE, DELETE konusunda 30 kat'a varan performans sunabildi ve geliştirilerek SQL Server 2016 ile birlikte bir çok prangadan kurtuldu.

Artık Disk Based bir tablo ve/veya Memory Optimized bir tablo üzerinde RowStore veya ColumnStore index kullanmak mümkün. Bu indexleri belli şartlar altında çeşitli kombinasyonlarda kullanarak hem yazma iş yükünü hem de okuma iş yükünü aynı tabloda toplayabiliriz. Bu durum yüksek performansın sonucu olan gerçek zamanlı raporlama yapmaya imkan verir. Artık raporlarınızı ister bu tablodan isterseniz direk tabloya erişimle veri getirecek şekilde konfigure edilmiş OLAP Cubelerden gerçek zamanlı olarak elde edebilirsiniz. Böylece bir takım senaryolar için ETL ve DW süreçlerine ihtiyacınız kalmaz. Veri doğrudan gerçek zamanlı olarak kaynaktan temin edilir.

Nasıl yapılır?

1. Operasyonel işlemlerin yüklendiği tablo RowStore veya Memory Optimized olabilir.
• INSERT, UPDATE, DELETE performansını arttıracak bir çok ipucu var. Mesela BTree indexleri kaldırabilirsin (bunun yerine ColumnStore tavsiye edilir.), constrainleri kapatabilirsin, flagler kullanabilirsiniz vs.
• Memory Optimized tablolar IUD işlemlerinde 30 kat performans sunar. Kısıtlar göz önünde bulundurularak bu tür tablolar tercih edilebilir.
2. Yavaş değişen (Warm) veriler için filtrelenmiş (Where koşulu ile belli şarttaki verilerin indexlendiği) Nonclustered ColumnStore indexler tanımlanabilir (Şimdilik Memory Optimized tabloda filtreleme özelliği kullanılamıyor). 
• Mesela girilen siparişlerden sadece teslimat bekleyenleri filtrelemek isteyebilirsiniz. Sadece ihtiyacınız olan aralık indexlenmiş olur. Böylece fragmantasyonu en aza indirmiş olursunuz. Daha az veri yazıldığı için yazma performansına olan negatif etki en aza iner.
• İhtiyaç duyulan diğer noktalar için de RowStore indexler kullanım amacı ve yetenekleri göz önünde bulundurularak tanımlanabilir.
3. Çok sık güncellenen kısım için (Hot) Btree index, daha az güncellenen (Warm) veya neredeyse hiç güncellenmeyen kısım için (Cold) (Daha çok okuma yapılan) ColumnStore index tanımlanabilir. 
• Burada asıl mesele doğru indexi fazla yük getirmeyecek şekilde doğru aralık için kullanmaktır. Tabi ek olarak Query Optimizer da en verimli yolu tercih edecektir.
• ColumnStore indexlerdeki fragmantasyonu azaltmak için COMPRESSION_DELAY ifadesi ile sıkıştırma işlemini dakika cinsinden geciktirmek mümkün. Böylece her 1 milyon satır için sıkıştırma işlemi yapmak yerine, istenen aralıklarda buna vakit ayrılabilir.

Bir sipariş sistemini düşünürsek:

• Alınan siparişler - Çok sık veri girişi olur (Hot Data) - Memory Optimized tablo önerilir.
• Teslimatı bekleyenler - Zaman zaman durumlarında değişiklik olur (Warm Data) - Filtrelenmiş NonClustered indexler önerilir.
• Teslim Edilmiş Siparişler - Neredeyse hiç değişiklik olmaz (Cold Data) - Filtrelenmiş ColumnStore önerilir.

Özetlemek gerekirse;

Senaryonun gereklilikleri göz önde bulundurularak, InMemory OLTP, InMemory DW ve geleneksel performans arttırıcı yöntemler bir araya getirilirse maksimum yazma ve maksimum okuma avantajı elde edilebilir. Böylece ETL ve DW süreçlerine gerek kalmadan yazma ve okuma iş yükünü üstlenebilen bir tablo üzerinden gerçek zamanlı raporlama yapmak mümkün olur.

SQL Server 2016 ile birlikte çok gelişmiş araçlar elimizde olacak. Bunları doğru şekilde bir araya getirdiğimizde etkileyici kazanımlar elde edeceğimiz aşikar.

Veri Yönetimi Ekibi - SQL Server 2014 Bellek İçi Veriambarı - Web Semineri

SQL Server 2014 ile birlikte In-Memory başlığı alınta iki ayrı yenilik duyuruldu. Bunlar daha çok Insert, Update, Delete performansını şaşırtıcı derecede arttıran In-Memory OLTP ve daha çok Select performansını inanılmaz şekilde arttıran In-Memory DW.

In-Memory OLTP hakkında araştırma yapıyorsanız şu yazımıza da bir göz atmak isteyebilirsiniz:
http://abdullahkise.blogspot.com.tr/2014/01/microsoft-sql-server-2014-ctp2.html

In-Memory DW'den kasıt ColumnStore indexlerdir. SQL Server bu index türü sayesinde klasik indexler (Clustered, Non-Clustered) gibi verileri satır bazlı değil de kolon bazlı olarak tutar. Böylece ihtiyacımız olan verilere ulaşmak için daha az page (segment) okuması yapılır. Böylece yüksek okuma performansı elde edilir. Bu konudaki gerçek dünya örneklerine bir yazımızda değinmiştik.

"Bank of Nagoya’dan direktör yardımcısı Atsuo Nakajima; SQL Server 2012 In-Memory ColumnStore’u kullanarak 100 milyonsatırı 30 dakika yerine artık 2 veya 3 saniyede elde edebildiklerini ifade etmiştir. Başka bir örnekte, star şemanın tercih edildiği bir veri ambarında, 2 milyar satır bulunun fact tablosu kullanılarak üretilen rapor önceden 18 saatte açılmaktayken, ColumnStore teknolojisi sayesinde aynı donanım üzerinde 5 dakikada açıldığı gözlemlenmiştir. Bir diğer örnekte ise; fact tablosunun tarandığı bir veri ambarından 17 dakikadan fazla sürede elde edilen sorgu sonucunun bu yeni index türü sayesinde 3 saniye civarında getirildiği tecrübe edilmiştir."

http://abdullahkise.blogspot.com.tr/2014/02/sql-server-2014-in-memory-dw.html

ColumnsStore indexleri ikiye ayrılır; SQL Server 2012 ile birlikte gelen Non-Clustered ColumnStore index ve SQL Server 2014 ile birlikte duyurulan Clustered ColumnStore index.

Son versiyonlarla birlikte gelen, veritabanını %27'lere kadar küçülten yüksek sıkıştırma teknolojisi ve 100 kata varan okuma performansı, inanılmaz sonuçlar elde etmeyi mümkün kılıyor.

Bu konu daha önce düzenlediğimiz bir web seminerine ait video kaydına göz atmak isterseniz şu linki kullanabilirsiniz:
http://abdullahkise.blogspot.com.tr/2014/06/bellek-ici-veriambar-inmemory-dw.html

Veri Yönetimi ekibinde Kıdemli Danışman olarak görev alan Özgür Erecekler, ColumnStore index türünden, bu minvalde SQL Server 2014 ile birlikte gelen yeniliklerden ve önceki teknolojilere göre elde edilen avantajlardan bahsediyor olacak. İş zekası tarafında bir hayli deneyimi olan Özgür Erecekler'in bakış açısı ile bu konuları incelemek kaçırılmayacak bir fırsat.

10 Nisan 2015 - Cuma
11:00 - 12:00

Özgür Erecekler

Aşağıdaki link yardımıyla, seminer saatinden 10 dakika önce Live Meeting ile bağlanıp, online olarak katılım sağlayabilirsiniz.

https://msevents.microsoft.com/cui/EventDetail.aspx?culture=tr-TR&EventID=1032612200&IO=SZ9syfU0CRJivPIc715jdA%3d%3d

Duyurunun Orjinali:

SQL Server 2014 Bellek İçi Veri Ambarı

Bu web seminerinde; SQL Server 2014 ile birlikte gelen Clustered Column Store indexler anlatılacaktır. 10 Nisan 2015 - Cuma 11:00 - 12:00 Özgür Erecekler

Diğer web seminerlerine ulaşmak ve oturuma dahil olma yöntemini öğrenmek için şu linke bir göz atabilirsiniz:

http://abdullahkise.blogspot.com.tr/2015/01/veri-yonetimi-ekibi-microsoft-web.html

Bellek İçi Veriambarı (InMemory DW - ColumnStore) Web Semineri - (Video)

11 Haziran 2014 Çarşamba günü gerçekleştirdiğimiz web seminerinde Bellek İçi Veriambarı (In-Memory DW) konusuna odaklandık.

SQL Server 2014 ile birlikte duyurulan InMemory DW, Clustered ColumnStore Indexi işaret etmektedir.

ColumnStore index sadece SQL Server 2014 versiyonda duyduğumuz bir index türü değildir. İlk olarak SQL Server 2012 ile birlikte kullanıma sunulan Non-Clustered ColumnStore index sayesinde veriler artık RowStore ve ColumnStore olarak tutulabilir hale gelmiştir.

Bu web seminerinde ColumnStore formatı, SQL 2012 ile gelen Non-Clustered ColumnStore index ve SQL Server 2014 ile gelen Clustered ColumnStore index arasındaki farkları, Clustered ColumnStore indexin performans testlerini ve kullanım avantajlarını, ColumnStore Archive kullanımı ile ortaya çıkan yüksek sıkıştırma becerisini inceledik.

Önümüzdeki web seminerlerinde canlı ortamda buluşmak koşuluyla, katılamayan, kaydı bekleyen ve InMemory DW konusuna göz atmak isteyenlere keyifli seyirler dilerim.

http://www.youtube.com/watch?v=GH19petUjDY

Bellek İçi Veri Ambarı - InMemory DW (ColumnStore) Web Seminerini kaçırmayın!

SQL Server 2014 ile birlikte InMemory kapsamında iki çözüm duyuruldu. Bunlardan birisi InMemory OLTP diğer ise InMemory DW dir.

Biz bu web seminerinde In-Memory DW'ye odaklanıyor olacağız.

Bu teknolojinin ilk versiyonu SQL Server 2012 ile birlikte kullanıma sunuldu; Non-Clustered ColumnStore Index.

Klasik B-tree indexlerden çok daha farklı çalışan bu yeni index, veriambarı mantığında kullanılan sistemlerde 100 kata varan SELECT performansı vaad ediyor.

Microsoft bu yeni index türü üzerinde biraz daha geliştirme yaparak SQL Server 2014 ile birlikte Clustered ColumnStore indexi kullanıma sundu.

Artık ColumnStore Index sayesinde columnstore veriler hem güncellenebiliyor hem de yüksek sıkıştırma özelliği ile verilerinizin %27'lere kadar küçülmesini sağlıyor.

Özetle bu yeni teknoloji daha az disk alanı harcayıp, çok daha yüksek okuma performansı sunuyor. Hatta hesaplarınız ne kadar karmaşık, talep ettiğiniz satır miktarı ne kadar fazla olursa, normal indexlerle arasındaki performans farkı o kadar açılıyor.

Sistemlerinde okuma performansını arttırmak isteyenlerin bu web seminerini kaçırmamasını öneririm.

Etkinlik Tarihi :
11 Haziran 2014 Çarşamba - Saat 10:00

Bellek İçi Veri Ambarı
İlk olarak SQL Server 2012 ile birlikte duyurulan ColumnStore yapısı SQL Server 2014 te ile birlikte biraz daha zenginleşti. Bu sunumda okuma performansını etkileyici bir biçimde arttıran ColumnStore indexlere odaklanacağız.

Etkinlik için kayıt olun: 
https://msevents.microsoft.com/cui/EventDetail.aspx?culture=tr-TR&EventID=1032583319&IO=EMoQ04fFYzN7yFn5FnIieA%3d%3d

Seminerde görüşmek üzere,

SQL Server 2014 Yenilikleri - 4 (In-Memory DW - ColumnStore Index)

Yeni nesil teknolojiler, yüksek bellek ve daha çok çekirdekli güçlü işlem yeteneğine sahip modern donanımlar sayesinde veri işleme süratini günden güne arttırmaktadır. Microsoft, SQL Server ürününü bu trend doğrultusunda geliştirmekte ve hem analitik işlemler için hem de çekirdek veri tabanı işlemleri için In-Memory teknolojilerini ön plana çıkarmaktadır.

PowerPivot ve Analysis Services gibi analitik hizmetlerde kullanılan In-Memory teknolojisi geliştirilerek In-Memory OLTP ve In-Memory DW(ColumnStore Indexes) başlıkları ile veri tabanı motorlarında(Database Engine) da kullanıma sunulmuştur.

Önceki yazımızda daha çok INSERT, UPDATE, DELETE performansını arttırmak amacıyla geliştirilen In-Memory OLTP motorunun çalışma esaslarına değinmiştik. Şimdi ise SELECT performansını 10 kat, bazı durumlarda 100 kat arttırabilen ve In-Memory DW başlığı altında yer alan ColumnStore konseptini inceleyeceğiz.

SQL Server önceki versiyonlarında verileri sadece Heap ve B-tree yapılarda yönetmekteydi. SQL Server 2012 ile birlikte In-Memory kapsamına giren yeni bir index türü daha duyuruldu. Böylece çekirdek veri tabanı işlemlerinde de In-Memory teknolojisi kullanılabilir hale geldi.

Non-Clustered ColumnStore Index adıyla duyurulan bu index, verileri Heap ve B-tree yapıdakinden farklı olarak satır odaklı değil, kolon odaklı tutmaktadır. Bu yeni yaklaşım, birkaç kolonun fakat birçok satırın çağrıldığı sorgu sonuçlarının etkileyici hızda elde edilmesini sağladı. Hatta satır sayısı belli bir sınırı aştıktan sonra performans artışı çok daha fazla olmaktadır.

Bank of Nagoya’dan direktör yardımcısı Atsuo Nakajima; SQL Server 2012 In-Memory ColumnStore’u kullanarak 100 milyon satırı 30 dakika yerine artık 2 veya 3 saniyede elde edebildiklerini ifade etmiştir. Başka bir örnekte, star şemanın tercih edildiği bir veri ambarında, 2 milyar satır bulunun fact tablosu kullanılarak üretilen rapor önceden 18 saatte açılmaktayken, ColumnStore teknolojisi sayesinde aynı donanım üzerinde 5 dakikada açıldığı gözlemlenmiştir. Bir diğer örnekte ise; fact tablosunun tarandığı bir veri ambarından 17 dakikadan fazla sürede elde edilen sorgu sonucunun bu yeni index türü sayesinde 3 saniye civarında getirildiği tecrübe edilmiştir.

Sonuçlar oldukça etkileyici görünüyor. Fakat sayılar çok farklı olduğu için inandırıcı gelmemiş olabilir. Aldığımız sonuçlar özetle; işlemci çekirdek sayısına, memory büyüklüğüne, talep edilen satır sayısının belli bir sayıdan fazla olmasına ve sorguların veri ambarı benzeri(Star, SnowFlake şema dizaynlı)  sistemlerde kullanılanlar gibi olmasına bağlıdır. Son kısma bir açıklık getirmek gerekirse; tüm tablonun çağrıldığı bir sorgu performansı sizi etkilemeyecektir. Ancak daha az kolonun ve daha fazla satırda daha karmaşık işlemlerin yapıldığı gruplama sorgularının performansını görmek hoşunuza gidecektir.

ColumnStore index nasıl bir şey?

Fiziksel olarak bağımsız işlem gören kolonlar halinde, mantıksal olarak satır ve sütunlarla tablo şeklinde organize edilen veriye columnstore denir. Verileri bu formatta depolayan ve yöneten yeni index türüne ise ColumnStore index adı verilmektedir.

ColumnStore index verileri, sıkıştırır ve segment adı verilen kolon odaklı parçalar halinde depolayıp yönetir. Sorgulama sırasında Query Optimizer columnstore indexleri mi yoksa diğer indexleri mi kullanacağına kendisi karar verir. Elbette çeşitli sorgu hintleri kullanarak index kararlarına müdahil olmak mümkündür.

ColumnStore indexin temel yapısı şu şekildedir.

Bu yapıda yaklaşık her 1 milyon satır “row grup”lara bölünür. Row gruplar içerisinde ayrı ayrı sıkıştırılan ve kodlanan paralel kolonlar “segment”leri oluşturur. Segmenler disk ile memory arasında transfer olan birimlerdir. Bu resimde A,B,C kolonlarından oluşan satırlar 3 “row group”a ve toplamda 9 “segment”e bölünmüştür. Bu “segment”ler hakkında satır sayısı, büyüklük ve maksimum, minimum değerler için metadata bilgisi directoryde tutulmaktadır. Segmentler ve encoding bilgisinin tutulduğu “dictionary” disk pagelerine blob(LOB) nesneleri olarak kaydedilir.

Veriler talep edildiğinde “segment” ve “dictionary”ler memoryden gelir. Ancak bunun için buffer cache değil direk adjacent(bitişik) memory pageler kullanılır. Dolayısıyla page split derdi olmamaktadır.

Row group, segment ve dictionary hakkındaki bilgileri şu sorgularla inceleyebilirsiniz.

Performansı bu kadar arttıran şey nedir?

Bunu genel olarak şu 3 başlık altında inceleyebiliriz:

1-      Fiziksel yapı:

Heap ve B-tree yapıda veriler sıkıştırılmadan pagelerde satır odaklı tutulmaktadır. Yani indexlenen her kolon sorguda istenmese de getirilen pagelerde yer alır. Columnstore yapıda ise veriler sıkıştırılarak segmentlerde kolon odaklı tutulur. Yani istediğiniz kolonlar için sadece o kolonun bilgisinin bulunduğu segmentler çağrılır. Bazı segmentler diğerlerinden fazla sıkıştırılabilmektedir. 

Çoğu zaman sorgularımızda kullandığımız kolonlar indexlediğimiz kolonlardan daha az sayıda olmaktadır. Özetle B-tree yapıda istediğimiz kadar veriyi elde etmek için daha fazla page okumamız gerekirken columnstore yapıda çok daha az segment okuması yaparak aynı sonuca ulaşabilmekteyiz.

2-      Batch Mode işleme:

SQL Server sorgu operatörleri geleneksel olarak tek seferde bir satır işlemektedir. Yani sürekli “row mode”da çalışmaktadır. Columnstore ile birlikte tek seferde bir grup(batch) satır işleyen yeni operatörler getirildi (genellikle 900 satıra kadar çıkar). Bu özellik yoğun hesap gerektiren işlemden geçecek binlerce satırın daha yüksek hızda elde edilmesini sağlamaktadır. Scan, filter, Project, hash(inner) join ve (local)hash aggregation SQL Server 2012’de “batch mode”u destekleyen sorgu operatörleridir.

Query Optimizer row mode veya batch mode tercihini şu şekilde yapar; binlerce satır filtreleme, birleştirme, gruplama ve yoğun hesapların olduğu işlemlerden geçmesi gerektiğinde batch modeu tercih eder, daha az veride ve batch modu desteklemeyen sorgu operatörleri kullanıldığında row modeu tercih eder.

Aşağıdaki örnekte Musteri2 tablosunda ColumnStore index kullanıldı fakat Musteri3 tablosunda herhangi bir index kullanılmadı. Musteri 3 tablosunda aynı filtre için çok daha az sonuç getirecek kadar veri olmasına rağmen(2 milyona 30 bin) çalışma modundan(row-batch) dolayı ColumnStore indexli tabloya yapılan sorgunun diğer sorgu karşında sisteme olan maliyeti %6 da kalmış durumda.

3-      Segment eleme:

Bu özellik sayısal ve tarihsel alanlarda işe yaramaktadır. Filtre ve join gibi işlemlerde devreye giren bu özellik sayesinde storage engine sadece gerekli segmentleri diskten okur. Diğer segmentleri atlar.

Aşağıdaki örnekte 20080631 değerinden büyük olan OrderDateKey’ler sadece 0 segmentinde bulunmaktadır. Bu sebeple diğer segmentler elimine edilerek sadece 0 segmenti diskten okunacaktır.

Kaç çeşit ColumnStore index vardır?

İki çeşit ColumnStore Index bulunmaktadır. İkisini de ara yüz yardımıyla oluşturmak mümkündür. Ancak uzun sürebilecek indexleme işlemleri için kodlarla çalışmayı tavsiye ederim.

Bu indexler neler bir göz atalım:

1-      Non-Clustered ColumnStore index:

Bu index türü SQL Server 2012 ile birlikte duyuruldu.

Bir tabloda tek bir non-clustered columnstore index olabilir. Fakat diğer B-Tree indexler tablo üzerinde yer alabilir. Tabloda constraintler tanımlanabilir. Primary ve Foreign Keyler kullanılabilir.

Ancak non-Clustered Columnstore indexin tanımlığı olduğu tablolarda yalnızca okuma işlemi yapılabilmektedir. Insert, Update, Delete işlemi yapabilmek için öncelikle bu indexin kaldırılması veya disable edilmesi gerekir. Sonra rebuild edilebilir.

Şu şekilde oluşturabiliriz.

CREATE NONCLUSTERED COLUMNSTORE INDEX IndexAdi ON TabloAdi

(

     Col1,

     Col2

)

Okuma performansını etkileyici bir biçimde arttıran bu indexten dolayı tablonun güncellenememesi maalesef ciddi bir problem olabilmektedir. Sırf bu sebeple kısa aralıklarla güncellenen sistemlerde bu index türü tercih edilmemektedir.

Nihayet yapı biraz daha geliştirildi ve yeni versiyonla birlikte Clustered ColumnStore adında update edilebilir bir columnstore index türü daha duyuruldu.

Şimdi asıl konumuz olan bu Clustered ColumnStore indexe odaklanalım.

2-      Clustered ColumnStore index:

SQL Server 2014 ile birlikte gelecek olan bu index tüm tabloyu depolar ve bir tabloda hem tek bir clustered index tanımlanabilir hem de sonrasında başka hiçbir index tanımlanmasına izin verilmez. Açıkçası başka bir indexe artık ihtiyaç kalmayacaktır.

Clustered ColumnStore indexin en büyük getirilerinden birisi; tanımlandığı tablo üzerinde insert, update, delete işlemlerinin yapılabiliyor olmasıdır.

Bu işlemlerin yapılabilmesi için ek iki bileşene daha ihtiyaç duyulmuştur. Bunlar insert edilen kayıtların belli bir sayıya kadar tutulduğu Delta Store, diğeri ise silinen satırların silindi diye işaretlenebilmesi için row ID’lerinin tutulduğu Deleted Bitmap dir. Her ikisi de verileri B-Tree yapıda barındırır.

Updateable Clustered ColumnStore index nasıl çalışıyor?

Insert: öncelikle insert edilen satırlar row grupun alabileceği maksimum satır sayısına ulaşana kadar Delta Store da bekletilir. Maksimum satır sayısına ulaşan her grubun durumu CLOSED olarak işaretlenir. Tuple Mover adı verilen bir arka plan işlemi default olarak her 5 dakikada bir devreye girerek CLOSED durumundaki satır gruplarını segmentlere bölüp sıkıştırır ve columnstore yapıya ekler. Sonra row groupların durumu COMPRESSED olarak belirtilir.

Bulk Load: 100 bin satırdan daha az veriler Delta Store da tutulur. Daha fazlası 1milyon satırı bir arada tutan row grouplar halinde direk columnstore yapıya eklenir.

Delete: silinen satırların satır ID leri Deleted Bitmapde tutularak satırlar silindi diye işaretlenmiş olur.

Update: bu işlem insert ve delete işleminin birleşimidir.

Clustered Columnstore index şu kodlarla oluşturulabilmektedir.

CREATE CLUSTERED COLUMNSTORE INDEX IndexAdi ON tabloAdi

Okuma performansı ne durumda?

Yazımın başında bazı gerçek hayat örnekleri vermiştim. Bu sonuçlar oldukça etkileyiciydi. Şimdi ise ek olarak az önce kendi bilgisayarımda basitçe denediğim bir örneği sizlerle paylaşmak istiyorum.

Gelen satır sayısı çok az olmasına(34) yani row mode da çalışılmasına rağmen. 5 milyon satırlık fact tablosu üzerindeki toplama işlemi normalde 28 saniyede tamamlanırken Clustered ColumnStore index sayesinde 1 saniyede tamamlandı. Daha fazla satırda ve daha karmaşık işlemlerde aradaki fark iyice açılacaktır.

Ekleme ve Silme Performansları ne durumda?

Silme performansı B-tree yapıya göre daha yüksek. Çünkü B-tree yapıda veriler pagelerden gerçekten siliniyor(daha fazla storage işlemi) ve loga daha fazla kayıt giriliyor. columnstore yapıda ise sadece Deleted Bitmap de silindi diye işaretleniyor. 

Kayıt girme esnasında ise veriler anında sorgulanabiliyor. Bunu sürekli kayıt giren bir sonsuz döngü açarak test edebilirsiniz. Bu esnada yeni kayıtları hızla elde edebildiğinizi göreceksiniz. Tabi ki daha sonra Tuple Moverın girilen verileri columnstore yapıya eklemek için arka planda çalışması gerekecektir.

Veri sıkıştırma(Compression) özelliği ne kadar etkili?

Normalde tablo veya partitionlarda page ve row sıkıştırma özelliği mevcuttur. Eğer bir tabloda Clustered ColumnStore index tanımlanırsa bu tablonun sıkıştırma tipi “Columnstore” olur. 

Eğer daha yüksek sıkıştırmaya ihtiyacımız olursa Columnstore_Archive özelliğini kullanabiliriz. Bu sayade 15 kata varan sıkıştırma sonuçları elde edilebilir. Bu oran elbette veri tekrarına ve veri tiplerine bağlıdır. Ayrıca okuma ve yazma işlemleri sırasında CPU yükünün artacağı da göz önünde bulundurulmalıdır. Columnstore_Archive sıkıştırma tipi okuma işleminin nadir olduğu yazma işleminin de neredeyse hiç olmadığı arşiv verilerinden yer kazanmak için tercih edilmelidir.

Aşağıdaki grafikte 101 milyon satırlık bir tablo, index ve uygulanan sıkıştırma tipleri ile ilgili bazı sonuçlar yer almaktadır.

Bu sonuçlar üzerinde biraz konuşalım.

5 GB lık tablo üzerinde index tanımladığımızda 19.7 GB alanı rezerve etmek zorunda kalabiliyoruz. Bu durumda Page compression uygulasak bile 10.9 GB’a düşülebiliyor.

Üzerinde index bulunmayan bu tabloyu page compression ile sıkıştırırsak 1GB yer kazanabiliyoruz ancak bu yaklaşım okuma performansımıza hiçbir katkı sağlamayacaktır.

Tablo üzerinde tanımladığımız Non-Clustered ColumnStore index bir miktar daha yer kaplayarak alan ihtiyacını 6.9GB’a çıkartmış durumda.

Aynı tablo üzerinde Clustered ColumnStore index tanımlarsak. Tüm veri 1.8 GB’a sıkıştırılabilir.

Biraz daha fazla alan kazanmak için ColumnStore_Archive tercih edilebilir. Bu işlemi bir tablo için şu kod yardımıyla yapabiliriz.

ALTER TABLE TabloAdi

REBUILD WITH (DATA_COMPRESSION=COLUMNSTORE_ARCHIVE)

Benim yaptığım bir örnekte 2 milyon satırlık ve 105 MB’lık bir tablo ColumnStore sıkıştırma tipi ile 10 MB’a, ColumnStore Archive sıkıştırma tipi ile 4MB’a kadar indi.  Örneğimizde 101MB’lık yer kazanmış olduk.

Bu sıkıştırma teknolojileri veri tabanı boyutunu %27’lere kadar düşürebilmektedir.

Artık diğer indexleri kullanmamıza gerek kalmadı diyebilir miyiz?

Tabi ki hayır, Clustered columnstore index tanımlanacak tablo üzerinde trigger tanımlanmamış olması gerekir. XML, varbinary gibi veri tiplerine destek verilmemektedir. Primary Key, Foreign Key ve başka indexlerle birlikte kullanılamamaktadır. Yani bu ve benzeri gereksinimler olduğu sürece hala diğer indexlere ihtiyacımız var demektir.

Ne tür sistemler için uygundur?

Verinin daha az yazılıp çok defa okunduğu sistemlerde, karmaşık filtreleme ve gruplama işlemlerinin yapıldığı büyük ölçekli verilerde, star ve snowflake şema dizaynı benimsenmiş fact ve dimension tablolarından oluşan veri ambarlarında kullanılması uygundur.

İncelediklerimizi bir özetlemek gerekirse;

SQL Server 2014 ile birlikte In-Memory DW olarak adlandırılan ColumnStore yapının temelleri PowerPivot ile analitik sistemlerde atılmıştı. Bu teknoloji SQL Server 2012 ile birlikte tabular ile yine analitik sistemde ve Non-Clustered ColumnStore index ile çekirdek veri tabanı sisteminde kendini gösterdi. Tanımlandığı tabloyu sadece read-only erişime açan non-clustered columnstore index güncelleme işlemlerinde ayak bağı olabilmekteydi. Biraz daha geliştirilen ColumnStore yapısı, SQL Server 2014‘te kullanıma sunulacak olan Clustered ColumnStore index ile birlikte güncelleme işlemlerinin yapılabilmesini mümkün hale getirdi. Bu sayede In-Memory daha geniş sistemlerde kullanılabilir hale geldi diyebiliriz.

In-Memory DW başlığı altında incelediğimiz bu yapı sayesinde 100 kata varan hız, 15 kata varan sıkıştırma elde edebiliyoruz. Kısıtları ile barışık bir sisteme uygulanırsa donanım değişikliğine gitmeye gerek kalmadan kısa sürede kullanıcılarının yüzünü güldüreceğe benziyor.