SQL Server 2016 Yenilikleri Etkinliğine Bekleriz - 23,29 Mart 2017

SQL Server 2016 yeniliklerine odaklandığımız etkinliklerimiz yolda. İlkini 23 Mart 2017 Perşembe günü, ikincisini 29 Mart 2017 Çarşamba günü İTÜ Teknokent'te gerçekleştiriyoruz.

Bekleriz!

Kayıt İçin:
https://docs.google.com/forms/d/e/1FAIpQLSdoNqFN2T-mo7-bZChSAJ8J97CuLyd3LFvulvIQUa2GwlHQgQ/viewform?c=0&w=1

Önceki etkinlikten kareler:

http://www.abdullahkise.com/2016/12/sql-server-2016-new-features-etkinligi.html

SQL Server 2016 New Features Etkinliği - Teşekkürler

29 Kasım 2016'da düzenlemiş olduğumuz SQL Server 2016 New Features etkinliğine 250'den fazla kayıt aldık. Kötü hava koşullarına ve trafiğe rağmen salonumuzu dolduracak kadar bir çoğunluğa ulaştık. O gün bizi dinlemeye gelen tüm katılımcılara özellikle teşekkür etmek istiyorum.

Ekibim SQL Server 2016 yeniliklerinden en etkili 6 başlığı seçti ve tüm gün bu konularda oturumlar düzenlemiş oldu. Yoğun olduğumuz bir dönemde hızla organize olup etkinliğe güzel içerikler hazırladıkları için taktire şayanlar. Ekibimi tebrik ediyorum.

Ayrıca giriş kısmında Microsoft'un yeni vizyonu hakkında bizleri haberdar eden Microsoft'dan Behice Funda'ya (Audience Marketin Lead) müteşekkiriz.

Bu organizasyonda emeği geçen ve birlikte bir ekip olarak çalıştığımız Bilge Adam'dan ilgili diğer arkadaşlarıma da Didem ve Gülcan nezdinde teşekkür ediyorum.

Etkinlik programı şöyleydi :

9:30	10:00	Tanışma ve Açılış Konuşması
10:00	10:45	Real-Time Operational Analytics
11:00	11:45	End-to-End Mobile BI
12:00	12:45	Always Encrypted
		Öğle Arası
14:00	14:45	Stretch Database
15:00	15:45	PolyBase (Big Data in Database)
16:00	16:45	In-database Advanced Analytics (R in Database)

Giriş Kısmı :

Şu youtube listesinden kısa kesitlere göz atabilirsiniz :

https://www.youtube.com/playlist?list=PLcsgXUMaOzkMrvWAxtGed625H8bT8OKwW

https://www.youtube.com/playlist?list=PLcsgXUMaOzkMrvWAxtGed625H8bT8OKwW

SQL Server 2016 Yenilikleri - 4 (Always Encrypted)

SQL Server 2016 ile birlikte irili ufaklı bir çok yenilik duyuruldu.  Bu yeniliklerden bazıları gerçekten diğerlerinden çok daha farklı bir etkiye sahip. Önceki yazılara şu linklerden ulaşabilirsiniz:

SQL Server 2016 BI Yenilikleri - Hızlı Bakış
http://www.abdullahkise.com/2016/09/sql-server-2016-bi-yenilikleri-hzl-baks.html

SQL Server 2016 Yenilikleri - 1 (In-Memory DW - Updatable ColumnStore Indexes)

http://abdullahkise.blogspot.com.tr/2016/03/sql-server-2016-yenilikleri-1-in-memory.html

SQL Server 2016 Yenilikleri - 2 (In-Memory OLTP Geliştirmeleri)

http://abdullahkise.blogspot.com.tr/2016/03/sql-server-2016-yenilikleri-2-in-memory.html

SQL Server 2016 Yenilikleri - 3 (Operational Analytics)

http://abdullahkise.blogspot.com.tr/2016/04/sql-server-2016-yenilikleri-3.html

SQL Server 2016 yenilikleri serimizin bu bölümünde en etkileyici yeniliklerden biri olan Always Encrypted özelliğini ele alacağız.

Nedir Bu Always Encrypted?

Bu özellik yeni bir veritabanı şifreleme yöntemidir. Veritabanı şifreleme yöntemleri ile hassas verileri şifreleyip koruyabilirsiniz. Şifrelenmiş veriler ilk bakışta anlamsız ifadelerle temsil edilir ve üzerinde çalışılması engellenmiş olur. Kredi kartı bilgilerini, kişisel kimlik bilgilerini veya sizin için önemli olan ve kolayca kullanılmasını istemediğiniz diğer verileri hassas veri olarak düşünebilirsiniz.

SQL Server'ın önceki versiyonlarında şu veritabanı şifreleme yöntemleri mevcuttu:

1. Belli alanları korumak istediğinizde kullanacağınız Kolon Seviyesinde Şifreleme (Column-Level Encryption) yöntemi: http://www.abdullahkise.com/2013/09/kolon-satr-bazl-sifreleme-column-level.html
2. Yedekler dahil tüm veritabanını korumak istediğinizde kullanacağınız Dosya Seviyesinde Şifreleme (File-Level Encryption - Transparent Data Encryption) yöntemi: http://www.abdullahkise.com/2014/02/dosya-database-bazl-sifreleme.html
3. Sadece yedeklerin farklı bir serverda çalışmasını engellemek istediğinizde kullanacağınız Yedek Şifreleme (Backup Encryption) yöntemi: http://www.abdullahkise.com/2014/08/sql-server-2014-yenilikleri-5-backup.html

Veri şifreleme ve şifre çözme iş yükü, kullanım yoğunluğuna ve şifreleme tekniğine bağlı olarak kritik seviyelere ulaşabilir. Önceki versiyonlarda kullanılan yöntemlerde tüm iş yükü SQL Server üzerindedir. Kritik seviyede seyir eden serverlar bu iş yükünü kaldıramayabilir. Çoğu zaman hem yönetiminin kritik ve zor olması, hem de sisteme ek yük getirmesi nedeni ile şifreleme yöntemleri yerine sıradan yetkilendirme prosedürleri kullanılmaktadır. Ancak sıradan yetkilendirme prosedürleri veri güvenliğini sağlamak için tek başına yeterli değildir. Özellikle veri yer değiştirdiğinde kontrol elden gider.

SQL Server 2016 ile birlikte duyurulan Always Encrypted yöntemi şifreleme ve şifre çözme iş yükünü SQL Server'a değil, istemcilere yükler. Veritabanındaki şifrelenmesini istediğiniz alanlar daima şifreli olarak durur. En yetkili kullanıcılar bile eğer istemezseniz bu verilerin açık halini göremez. Bu yöntem sayesinde verinin sahibi ve veriyi yöneten kolayca ayrılır. 

Nasıl Çalışır?

Veriler, istemciye şifreli gider. Geliştirilmiş Ado.NET kütüphanesi istemci tarafındaki anahtarı kullanarak şifreyi çözer ve veriyi istemci uygulamasının açık şekilde görmesini sağlar. Uygulama tarafından açık şekilde gönderilen veri aynı şekilde istemci tarafında şifrelenir ve veritabanına şifreli olarak gider. 

İstemci ve veritabanı arasındaki bu süreç otomatik olarak çalışır. .NET 4.6 ile gelen geliştirilmiş Ado.NET kütüphanesi bağlantı cümlesine eklenen bir ifade ve depolanan anahtar yardımıyla işlemleri otomatik olarak yerine getirir. 

Column Master Key olarak ifade edeceğimiz anahtar istemci uygulamların ulaşabileceği bir yerde örneğin; Windows Certificate Store, Azure Key Vault veya bir "hardware security module" (anahtarı yönetmek için kullanılan özel cihazlar) içinde depolanabilir. Ancak bu anahtar SQL Server üzerinde depolanmaz. SQL Server üzerinde sadece Column Master Key tarafından korunan (şifrenmiş) Column Encryption Key tutulur. Column Encryption Key de belirttiğimiz kolonları korur (şifreler).

Diğer şifreleme yöntemlerinde olduğu gibi bu yöntemde de katmanlı bir koruma söz konusu. Yani seçtiğiniz kolonları Column Encryption Key şifreliyor. Column Encryption Key SQL Server'da depolanıyor. Bu önemli anahtarı da istemci tarafında depolanan Column Master Key şifreliyor. Column Master Key'e sahip olan istemciler verileri otomatik olarak temiz haliyle görür. Geri kalan herkes sadece şifrelenmiş metni görür. Bu şekilde şifreleme ve şifre çözme iş yükü istemci tarafına konumlanır. Veritabanında belirtiğimiz kolonlar için sadece şifreli veri yer alır.

Genel olarak istemci tarafında şu değişiklikler yapılır:

• Connection Stringse "Column Encryption Setting=ENABLED" ifadesi eklenir.
• Parametreler SqlParameter nesnesi ile gönderilir.
• Anahtarın (Column Master Key) depolandığı yere göre kodlamada bir miktar farklılık olmaktadır. Eğer anahtar istemci makinedeki Windows Certificate Store'da depolanıyorsa bağlantı cümlesi ve parametre gönderme prensibine uymak yeterli. Ancak diğer depolama yöntemlerinde ruhsat (authorize) alabilmek için bir miktar kod yazmak gerekiyor.

Nasıl yapılır?

Tüm adımları kolayca atmanızı sağlayan Always Encrypted sihirbazını kullanabilirsiniz. T-SQL veya PowerShell komutları da kullanılabilmektedir. İsterseniz her bir nesneyi ayrı ayrı kendi sihirbazları ile oluşturabilirsiniz. Nesnelerin kendi sihirbazları bir miktar esneklik sağlamaktadır.

Biz örneğimizde Always Encrypted sihirbazından yardım alacağız. Hadi başlayalım!

Öncelikle üzerinde çalışmak için bir veritabanı ve tablo oluşturalım. Sonra bu tabloya iki satır veri ekleyip görüntüleyelim :

CREATE DATABASE AlwaysEncryptedDB

GO

USE AlwaysEncryptedDB

CREATE TABLE MusteriBilgileri

(

       Id int identity(1,1) PRIMARY KEY,

       Ad nvarchar(50),

       KartNo char(19)

)

INSERT INTO MusteriBilgileri VALUES ('Abdullah Kise','123 123 123 123'),

                                    ('Veli Uçan','897 897 897 897')

SELECT * FROM MusteriBilgileri

Yukarıda işaretlediğim KartNo alanı bizim için hassas veri olsun. Bu alanı şifreleyeceğiz.
Şifreleme sihirbazını başlatmak için 'Object Explorer'daki tablomuzu sağ tıklayıp açılan menüden 'Encrypt Columns'ı seçiyoruz.



Sihirbazın ilk sayfasında kısa bir bilgilendirme var. İkinci sayfasına geçerek şifrelemek istediğimiz kolonları seçelim. Bu örnekte KartNo kolonunu şifreleyeceğiz:



KartNo kolonu için şifreleme tipini (Encryption Type) Deterministic olarak belirtiyoruz. Bu kolonun şifrelenmesi için bir 'Column Encryption Key (CEK)'e ihtiyacımız olacak. Daha önce oluşturduğumuz bir CEK varsa listeden seçebiliriz. Yeni bir tane oluşturmak için yanında (New) ifadasi olan seçeneği seçiyoruz.

Şifreleme tipi hakkında kısa bir bilgi verelim. İki tür şifreleme tipi mevcut:

1. Deterministic yöntemde temiz veriye göre hep aynı şifrelenmiş değer elde edilir. Bu sayede şifrelenmiş verileri sıralamak, gruplamak, birleştirmek ve indekslemek mümkün olur. Ancak bu yöntem şifreleme paternini keşfetmeyi ve veri hakkında tahminde bulunmayı kolaylaştırır. Özellikle şifrelenen alan çok az benzersiz değer içeriyorsa tahmin etmesi çok kolay olur. Mesela True/False veya cinsiyet, evlilik durumu gibi alanlar kolayca tahmin edilebilir.
2. Randomized yöntemde paterni bulmak daha zor olur. Sürekli aynı veri için aynı şifreli değer elde edilmez. Daha güvenlidir. Ancak bu durumda sıralamak, gruplamak, birleştirmek ve indekslemek mümkün olmayacaktır.

Bu adımda seçimlerimizi yapıp bir sonraki adıma geçiyoruz. CEK, SQL Server tarafında duran bir anahtardır. Bu anahtarı korumak (şifrelemek) için Column Master Key (CMK) oluşturmamız gerekir. CMK istemci uygulamaların erişebileceği şekilde depolanır.

Daha önce oluşturduğumuz bir CMK'yı seçebiliriz veya yukarıdaki gibi yeni bir tane oluşturabiliriz. 

Yeni bir tane oluştururken CMK'nın nerede depolanacağını belirtiyoruz. Burada iki seçenek var fakat CMK'nın kendi sihirbazını kullanarak daha fazla seçeneğe erişmek mümkün. Bir CMK, Windows Certificate Store, Azure Key Vault veya bir "hardware security module" (anahtarı yönetmek için kullanılan özel cihazlar) içinde depolanabilir.

Sonraki adımda bir uyarı alıyoruz. Var olan tablodaki kolonları sonradan şifrelemek istediğimiz için sihirbaz bazı adımları bizim yerimize atacak. Bu adımlar; kolonu şifrelenmiş bir tablo oluşturmak, verileri bu tabloya şifreleyerek taşımak, eski tabloyu silmek ve yeni tablonun adını eskisi olarak atamak şeklindedir. Uyarıda bu işlemler esnasında tablo kullanılırsa veri kaybı olabilir diyor. Yani bu işlemi rastgele bir zamanda yapmamak gerekir. Tablonun kullanılmadığından emin olmak gerekir.

İlerleyen adımlarda yaptığımız ayarların özetini ve çalıştırdığımızda işlemin sonucunu görebiliriz.

Şifreleme işlemi başarıyla tamamlandığında veritabanı içerisinde bir takım nesneler oluşur. Nesnelerin Create scriptlerine göz atarak ne gibi kodlar kullanıldığını inceleyebilirsiniz. İsterseniz bu nesnelerin kendi sihirbazlarını veya ilgili kodları kullanarak adım adım Always Encrypted özelliğini aktif edebilirsiniz.

Always Encrypted özelliğini aktif ettik ve tablomuzdaki KartNo alanını şifreledik. Tablonun önceki ve sonraki haline bir bakalım:

Artık sysadmin bile bu alanı ruhsat (authorize) almadan göremez. Bu ruhsat Column Master Key (CMK) ile alınabilir. İstemciler CMK yardımıyla verileri otomatik olarak şifresiz görür ve üzerinde çalışabilir.

Örneğimizde CMK'yı Windows Certificate Store üzerinde oluşturmuştuk. Bu bizim kendi makinemizde oluştu. CMK'yı görmek isterseniz Run/certmgr.msc veya Run/certlm.msc ile açılan pencereden Personal klasörü altındaki Certificate klasörüne bakabilirsiniz.

CMK kendi makinemizde oluştuğu için kendi makinemizdeki bir istemci verilerin açık haline otomatik olarak erişebilir. Test etmek için istemci uygulaması olarak SSMS'i kullanabiliriz. 

Tek yapmamız gereken SSMS ile bağlanırken Options/Additional Connection Parameters tabından bağlantı cümesine ek bir ifade belirtmek. Bu ifade "Column Encryption Setting=ENABLED" ifadesidir. Bu şekilde bağlandığımızda artık şifreleme ve şifre çözme işlemi otomatik olarak gerçekleştir. Veritbanında verileri şifreli olmasına rağmen SSMS üzerinde bu bağlantı için verinin şifresiz halini görürüz.

Veritabanına bu bağlantı üzerinden erişip veriyi bu kolon dahil dönüştürmek istediğimde şifrelediğim kolonla ilgili hata alıyorum.Sanıyorum SSMS'in bağlantı sağlayıcıları ile ilgili geçici bir durum. 

İstemci tarafından temiz veri girişinin otomatik olarak şifrelendiğini test etmek için uygulama yazmak yerine Import-Export sihirbazını kullanıyorum. Siz de Object Explorer / Veritabanınız (örneğimizde AlwaysEncryptedDB) / Task / Import Data ile bu sihirbazı çalıştırabilirsiniz.

Sihirbazın ilk adımında veri kaynağını seçiyoruz. İkinci adımında ise şifreleme yaptığımız veritabanını (örneğimizde AlwaysEncryptedDB) seçiyoruz. Ancak bağlantı sağlayıcısının .NET Provider olmasına dikkat edelim ve Column Encryption Setting parametresini Enabled olarak değiştirelim.

Sonraki adımlarda kaynak ve hedefteki kolon eşleştirmesini yaptıktan sonra aktarımı başlatalım. Testimizde veri aktarımı şifreli kolon dahil başarıyla gerçekleşti. Kayıtları şifreli ve otomatik şifre (Column Encryption Settings=Enabled) çözen bağlantı üzerinde listelediğimizde testin başarılı olduğunu görebiliriz.

Konu ile ilgili ayrıntılı dökümanlara şu adresten erişebilirsiniz:

https://msdn.microsoft.com/en-us/library/mt163865.aspx

Sonuç olarak bu konu ile ilgili şunları söyleyebiliriz; 

SQL Server 2016 ile birlikte gelen Always Encrypted özelliği yeni bir veritabanı şifreleme bakış açısı sunuyor. Önceki yöntemlerde şifreleme ve şifre çözme iş yükü SQL Server üzerindeyken bu yöntemde iş yükü tamamen istemci üzerinde. Veritabanında veri şifreli halde bulunuyor. CMK'dan ruhsat alan istemci şifreli veriyi alıp otomatik olarak şifresini çözüyor ve üzerinde çalışabiliyor. Veriyi yöneten ve veriyi okuyan güvenle ayrışabiliyor. Yani bu yöntem diğerlerinden farklı olarak daha az şifreleme iş yükü, daha güvenli veri yönetimi imkanı sunuyor.

SQL Server 2016 Yenilikleri - 2 (In-Memory OLTP Geliştirmeleri)

SQL Server 2016 yenilikleri serisine devam ediyoruz.

Serinin bir önceki yazısında In-Memory DW konseptinde yani ColumnStrore indexlerde yapılan geliştirmelere göz atmıştık. İncelemek isterseniz şu linki takip edebilirsiniz:
http://abdullahkise.blogspot.com/2016/03/sql-server-2016-yenilikleri-1-in-memory.html

Bu yazımızda In-Memory OLTP konseptinde yapılan geliştirmelere odaklanacağız.

In-Memory OLTP, SQL Server 2014 ile birlikte karşımıza çıktı. Bu teknoloji sayesinde INSERT, UPDATE, DELETE işlemlerinde 30 kata varan performans elde etmek mümkün oldu. Konu hakkındaki tüm ayrıntılı bilgileri daha önce paylaşmıştık. Şu linkten inceleyebilirsiniz :
http://abdullahkise.blogspot.com/2014/01/microsoft-sql-server-2014-ctp2.html

Yukarıda linkini verdiğimiz yazımızın sonundaki cümle ile bir özet geçelim :

"Lock ve Latch olmayan. ACID kurallarını destekleyen ve multi-version optimistic concurrency control prensibi ile transactionları yöneten. Verinin memoryde tutulduğu. Arka planda C ve FileStream nesnelerinin kullanıldığı mevcut Database Engine’e entegre yeni bir teknoloji. Bu teknoloji INSERT, UPDATE, DELETE performansını 30 kat arttırmak konusunda iddialı."

Testlerimizde de gördük ki bu teknoloji sayesinde OLTP işlemlerinin performansı etkileyici şekilde artıyor. Ancak paylaşılan istatistiklere göre uyumlu veritabanı oranı %5 civarında görünüyordu. Bunun  nedeni kısıtların çok fazla olmasıydı. Neyse ki SQL Server 2016 ile birlikte bu kısıtların bir çoğundan kurtulduk. Son durumda uygulanabilme oranının bir hayli yükseleceğini düşünüyoruz.

Teknoloji trendinin bizi getirdiği noktadan baktığımızda git gide daha modern donanımların yaygınlaşacağını göreceğimiz çok açık. Artık eskiye nazaran daha fazla CPU ve daha fazla memory ile çalışabiliyoruz. Rekabetin artması birim zamanda verilen karar miktarının artmasına sebep oluyor. Karar verme ve operasyon hızının artması için de veri analizinde baş döndürücü bir hıza ihtiyaç duyuluyor.

Şimdilerde devler teknoloji ve matematiği bir araya getirerek bu konularda pratik çözümler sunmaya çalışıyor. Bu çabanın sonucu olan In-Memory OLTP sayesinde RDBMS sistemleri yeni dünya ihtiyaçlarına cevap verebilir hale gelmektedir. Gerçek zamanlı ve/veya düşük gecikmeli analiz, raporlama çözümleri Microsoft, Oracle, IBM vs. gibi bir çok dev tarafından tanıtılmaktadır. Microsoft tarafına odaklanırsak; RDBMS sistemlerinin yaygın, başarılı ve akılda kalıcı çalışma şeklinde pek bir değişiklik yapmadan In-Memory OLTP yi kullanmak mümkün.

Gelelim SQL Server 2016 ile birlikte duyurulan bazı önemli In-Memory OLTP geliştirmelerine;

• In-Memory OLTP kapsamında tanımlanan tabloların (Memory Optimized) maksimum boyutu 256 GB'dan 2 TB'a yükseltildi.
• Artık tablo, procedure, index için ALTER komutları kullanılabilmektedir. Yani Schema da sonradan değişiklik yapılabilir.
• Yeni versiyonda Natively olarak compile edilmiş (C dll) scaler fonksiyonlar tanımlanabiliyor.
• İç içe Natively Compile procedureleri kullanmak mümkün.
• Artık DML trigger tanımlanabilmekte.
• TDE Encryption bu versiyonda destekleniyor.
• Multiple Thread ve Parallel Plan geliştirmeleri ile bir önceki versiyona göre çok daha daha fazla performans elde etmek mümkün.
• OUTER JOIN, UNION, DISTINCT, SubQuery, FOREIGN KEY, CHECK, UNIQUE constraint ve NULL kolon desteği mevcut.
• Nihayet Memory Optimized tablolarda ColumnStore index tanımlanabiliyor. Bu hem yazma hem de okuma performansında şaşırtıcı bir artışın olacağı anlamına geliyor.
• Saniyede 1.2 milyon transaction veya 900 MB/s veri yazma hızına erişilebiliyor.

Şu linkten In-Memory OLTP ile birlikte desteklenen ve desteklenmeyen veritabanı özelliklerini inceleyebilirsiniz: https://msdn.microsoft.com/en-us/library/dn133189.aspx

In-Memory OLTP'nin genel kullanım paternlerine şu linkten erişebilirsiniz:
https://msdn.microsoft.com/library/dn673538.aspx

Yenilikleri buraya kadar özetlersek;

In-Memory OLTP sayesinde INSERT, UPDATE, DELETE performansı 30 kat artıyor. Bu teknojide verinin direk memoryden sunulması, lock ve latch olmaması SELECT performansında da dikkat çekici bir artış sağlıyor. Ancak SELECT performansını asıl arttıran In-Memory DW başlığı ile gelen ColumnStore indexler olmuştur. Bu indexlerin sunduğu performans artışı ise yaklaşık olarak 100 kattır.

In-Memory OLTP ile In-Memory DW bir araya geldiğinde ise ortaya Operational Analytics adı ile duyurulan yenilik çıkıyor. Etkileyici bir tasarım. Bir sonraki yazımızda bu konuya odaklanmayı planlıyorum.

SQL Server 2016 Yenilikleri - 1 (In-Memory DW - Updatable ColumnStore Indexes)

Bu sene SQL Server 2016 ile birlikte veritabanı dünyamıza heyecan veren yeni özellikler dahil oluyor. Microsoft'un son bir kaç senedir depar attığı Advenced Analytics ve Big Data konseptlerinin etkisini SQL Server ürününde de görmek bizleri mutlu ediyor.

Bazı özellikler önceki versiyonlardaki haline göre geliştirilmişken, bazı özellikler tamamen yeni. Özellikle önceleri sadece appliancelarda var olan Polybase engineı şimdi SQL Server'ın kurulabildiği tüm cihazlarda kullanılabilir durumda. Bu özellik büyük veri ile ilişkisel veritabanının birlikte çalışmasına olanak tanıyor. Hatta veritabanı ile çalışma alışkanlıklarınızı açık kaynakta olduğu gibi dramatik şekilde değiştirmenize gerek kalmadan bunu yapabiliyorsunuz.

SQL Server 2016'da bir çok etkileyici özellik mevcut. İşte bazıları;

• Open Source R desteği ile analitik çalışmalarınızı yaygın ve güçlü bir dille gerçekleştirmeniz artık mümkün. 
• Çok az maliyetle verilerinizi daima şifreli tutabilir ve sadece istediğiniz uygulamalarda şifresiz görüntüleyebilirsiniz.
• Alışkın olduğumuz SSRS ile DataZen bir araya geldi. Böylece hem klasik raporlama hem de Mobile raporlama yaparak bunları tek bir çatı altında toplamak artık mümkün.
• Geliştirilmiş In-Memory konsepti ile operasyonlarnıza ait verileri gerçek zamanlı olarak analiz edebilir ve raporlayabilirsiniz.

Biz de bu yazımızda In-Memory DW - Updatable ColumnStore Indexes yeniliklerine yoğunlaşacağız.

ColumnStore indexi SQL Server 2012 ile birlikte duymaya başladık. İlk olarak Update edilemeyen NonClustered ColumnStore index ile tanışmıştık. Sonra SQL Server 2014 ile birlikte Update edilebilir Clustered ColumnStore index ile tanıştık. Önceki verisyonlarda bir çok kısıt mevcuttu. 

Daha önceki yazımızda konu hakkında bir hayli bilgi vermiştik. ColumnStore indexler hakkında şu yazımızı incelemenizi tavsiye ederim:

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

Bu konuda bir de webcastimiz vardı:

http://abdullahkise.blogspot.com.tr/2014/06/bellek-ici-veriambar-inmemory-dw.html

Biz bu yazımızda daha çok yeni özelliklere yoğunlaşacağız.

ColumnStore indexler, RowStore indexlere göre açık ara performanslı. İstatistikler vermek gerekirse; 100 kata varan hız, 15 kata varan sıkıştırma elde etmek mümkün. Önceki yazımızda belirtiğimiz gibi 100 milyon satırın 30 dakika yerine 2 veya 3 saniyede elde edildiği referanslar arasında mevcut.

Bu performans farkını şu 3 özellik üzerinden önceki yazımızda açıklamıştık:

1. Fiziksel Yapısı : Genelde sorgularımız kolon bazlı olur. RowStore indexler tüm satırı indexlerken, ColumnStore indexler sadece ilgili kolonun verilerini indexler. RowStoreda kullanılan pagelerine yerine ColumnStoreda segmentler kullanılır ve segmentler yüksek sıkıştırma özelliği sayesinde çok daha az yer kaplar. Böylece tam olarak ColumnStore indexlerden istediğimiz veriler elimize ulaşır. RowStoredaki gibi ilgilenmediğim kolonların olduğu pagelerde vakit kaybedilmez.
2. Batch Mode : Normalde Query Optimizer verileri satır satır işler. Ancak gelen SQL Server 2012 ile birlikte bazı sorgu operatörleri bir grup satırı (çoğu zaman 900 satır) birlikte işleyebilecek şekilde tasarlanmıştır.
3. Segment Eleme: Sayısal ve tarihsel alanlarda işe yarayan bu özellik sayesinde sadece verdiğimiz aralıkta bulunan verilerin olduğu segmentlere gidilmektedir. Böylece daha az IO yapılır. Her bir segmentte minimum maksimum değerin metadata olarak tutulması buna imkan verir. Eğer istenen değer bu aralıkta değilse segment elenir. Sadece şartımıza uyan segmentler belirlenerek içeriği okunur.

Gelelim SQL Server 2016 ile birlikte karşımıza çıkan ColumnStore indexlere:

1. Performans farkını ortaya çıkaran yukarıdaki 3 özellik aynı şekilde işliyor. Buna ek olarak yeni Batch Mode çalışma desteği veren operatörler duyuruldu. Bunlar: SORT, COUNT/COUNT, AVG/SUM, CHECKSUM_AGG, STDEV/STDEVP, COUNT, COUNT_BIG, SUM, AVG, MIN, MAX, CLR, CHECKSUM_AGG, STDEV, STDEVP, VAR, VARP, GROUPING, LAG, LEAD, FIRST_VALUE, LAST_VALUE, PERCENTILE_CONT, PERCENTILE_DISC, CUME_DIST, PERCENT_RANK
2. Artık ColumnStore (Clustered,NonClustered) indexler update edilebiliyor. Yani veri girişi sırasında indexi kaldırmaya gerek kalmıyor.
3. Bu yeni versiyonla birlikte ColumnStore indexlerin bulunduğu tablolarda Pimary Key ve Foreign Key kullanılabilmektedir. (RC0'da test edecek olanlar PK'yı Heap üzerinde, FK'yı da ColumnStore indexten sonra tanımlamalılar.) PK oluşturken Clustered index otomatik oluşacaktır. Clustered yerine NonClustered oluşturalım ki Clustered ColumnStore index ile çakışmasın. Yani PRIMARY KEY NONCLUSTERED ifadesi ile PK oluşturulmalıdır. 
4. Clustered ColumnStore indexten sonra RowStore (btree) index tanımlamak daha önceki versiyonlarda mümkün değildi. SQL Server 2016 ile birlikte artık hem Clustered ColumnStore hem de birden fazla NonClustered RowStore index tanımlamak mümkün.
5. Yeri geldiği için hatırlatalım; bir tabloda tek bir Clustered (ColumnStore veya RowStore farketmez) index bulunabilir. Ayrıca bir tabloda birden fazla ColumnStore index tanımlanamaz.
6. Artık NonClustered ColumnStore indexler filtrelenerek daha efektif kullanılabilmektedi.
7. Clustered ColumnStore index, Memory Optimized (In-Memory OLTP) tablolarda tanımlanabilmektedir. (RC0'da test edecek olanlar önce Clustered ColumnStore indexi tanımlamalılar.)
8. Storege Engine seviyesinde yapılan bir diğer geliştirme ise Pushdown (Aggregate Pushdown, String Predicate Pushdown) özelliğidir. Bu özelliği şöyle açıklayalım; Önceki yazımızda da geçtiği üzere veriler segmentlere dönüştürlürken encoding bilgisinin tutulduğu Dictionary nesneleri de oluşur. Segmentler, Dictionary'da tutulan gerçek verilerin giriş numaralarını içerir. Bu teknik sayesinde tekrar eden verilerle ilgili ciddi sıkıştırma performansı elde edilebilir. İki tür Dictionary nesnesi vardır. Primary Dictionary : tüm segmentler tarafından kullanılır. Secondary Dictionary : Birden fazla segment (aynı kolona ait) tarafından paylaşılır. Her zaman Secondary Dictionary kullanılmayabilir. Bazı durumlarda devreye giren Pushdown özelliği sayesinde kritere uygun satırlar Dictionary seviyesinde taranır. Diğer satırlar segment seviyesinde taranır ve filtrelenir. Bu çalışma şeklinin performansı SQL Server 2014 ile karşılaştırıldığında sonuçlar şaşırtıcı derecede farklı olur.         

Aynı sorgu üzerinden testimizi gerçekleştirdiğimizde, SQL Server 2016 istenen sonuçları açık ara önde sunabiliyor.

ColumnStore indexlerin sorgulama performansını incelemek isterseniz şu linke bir göz atabilirsiniz:

https://msdn.microsoft.com/en-us/library/dn935005.aspx

Sonuç olarak SQL Server 2016 versiyonu ile birlikte ColumnStore indexlerde hem performans bakımından hem de fonksiyonalite bakımından ciddi iyileştirmeler oldu. Diske bağımlılığın minimuma düşürülmesi hem operasyonel anlamda hem de analitik anlamda iş süreçlerine ciddi katkısı olmaktadır. Bu iyileştirmelerin yeni gelen diğer özelliklere de etkisi var. Sonuçlarını hep birlikte göreceğiz.