Microsoft SQL Server 2016 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Microsoft SQL Server 2016 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

8 Mayıs 2016 Pazar

SQL Server 2016 - General Availability - 1 Haziran 2016'da yayında

Microsoft SQL Server 2016, 1 Haziran 2016 tarihinde geliyor.

Bu ürünle birlikte Microsoft veritabanı dünyasına artık çok daha farklı bir gözle bakacağız. Bu sürümde hem önceki özelliklerde beklenen geliştirmeler yapıldı hem de ürüne şaşırtıcı yenilikler eklendi.

Yenilikleri şu ana başlıklarda özetleyebiliriz:


  • Real-Time Operational Analytics
  • Always Encrypted
  • PolyBase
  • End-to-End Mobile BI
  • In-database Advanced Analytics
  • Stretch Database

Yakın zamanda yazdığım ilgili yazılara şu linklerden ulaşabilirsiniz:

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

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

SQL Server 2016 Yenilikleri - 3 (Operational Analytics)

1 Haziran'da yayınlanacak olan SQL Server 2016 Edition'ları şöyle:

  • Enterprise
  • Standard
  • Express
  • Developer (Geliştirme ve test için ücretsiz - tüm özellikleri sağlar)


SQL Server 2016 Gartner'ın Magic Quadrant'ında şöyle görünüyor:



Benchmark sonuçları:

Daha önce paylaştığım yeniliklerin özeti:

12 Nisan 2016 Salı

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.


28 Mart 2016 Pazartesi

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.

30 Aralık 2015 Çarşamba

Rapor ihtiyacını Seviyelendirme (Üst Yönetim, Yönetim, Veri Analistleri)

Raporlama projelerindeki gözlemlerimizi düşündüğümüzde firmaların büyük bir kısmının raporlama yaklaşımında bir takım kafa karışıklığının olduğunu farkediyoruz. Özellikle son dönemlerde revaçta olan yeni Self Service BI ürünleri bu kafa karışıklığına daha fazla katkıda bulunuyor.

Fazla uzatmadan direk konuya gireceğim. Eğer bir raporlama projesine girişecekseniz üründen önce ihtiyaçlarınıza odaklanmalısınız. Önce aracın seçilmesi ve geliştirmelere başlanması talepler arttıkça sürecin içinden çıkılamaz bir hal almasına neden oluyor. Çoğu zaman firmalar ihtiyacından fazla yatırım yaparak ciddi maliyetlerin altına giriyor veya ihtiyacına uygun olmayan ürünleri deneyerek vakit ve güven kaybediyor. Genellikle bu kayıpları telafi etmek oldukça zordur.

Çarşaf raporlar üzerinden verileri didik didik edecek veri analistlerine mobile raporlama ürünlerinin çıktısını sunmak, dilediği yerden özet verilere erişerek strateji geliştirmek isteyen yöneticilere çarşaf raporlar üzerinden detaylı bilgiler sunmak en başta gelen hatalı yaklaşımlardandır.

Bu aralar en yaygın dalgınlık, binlerce satırdan oluşan bir kaç gblık detaylı raporların mobile cihazlardan servis edilmesi eğilimi şeklinde karşımıza çıkıyor. Bir an durup düşünürsek cep telefonlarının belleğinin buna yetişemeyeceğini hemen farkederiz.

İstemcileri şu 3 gruba ayırarak tüm raporlama ihtiyaçlarına cevap vermek mümkün görünüyor:


1- Üst yönetim: 


Stratejik kararları etkileyecek özet raporları bekleyen bu istemci gurubuna çoğu zaman mobile cihazlar üzerinden dashboardlar sunmak gerekir. Grafiklerin kabul görmüş en hızlı ve etkili şekilde sunulması beklenir. Microsoft'un Power BI Portal ürünü bu kısım için biçilmiş kaftan.


2- Yönetim: 


Operasyonel kararları etkileyecek belli bir kalıpta olan, sık kullanılan ve bir miktar daha detaylı raporlar bekleyen bu istemci grubu çoğu zaman raporlarını bilgisayar üzerinden görmek isteyecektir. Raporların maillerine gelmesi, versiyonlanması, farklı formatlarda çıktılarının alınabilmesi ve hatta raporlarda gelişmiş yetkilendirme, detaylandırma gibi fonksiyonalitelerin olması bu grubun ihtiyaçlarından bir kaçıdır. Bu grurup çoğunlukla ihtiyaca göre özelleştirilmiş statik raporları incelemek ister. Geleneksel olarak bu böyledir.

Ancak son zamanlarda mobile cihazların yaygınlaşması ve daha bir çok sebepten ötürü bu gruptaki istemciler de raporlarını mobile cihazlar üzerinden görmek istemektedir. Tabi ki bu hizmet geleneksel raporlama ürünlerine göre daha pahalıya gelir.

Bu grubun ihtiyacına cevap vermek için Microsoft, yeni satın aldığı DataZen ürününü SQL Server Reporting Services'a entegre etti. SQL Server 2016 CTP 3.2 kurulumuyla birlikte artık her iki ürün tek bir SSRS hizmeti olarak karşımıza çıkmaktadır.

Artık hem geleneksel SSRS raporlarını (görselleri geliştirildi) hem de mobile cihazlarla tam uyumlu DataZen raporlarını tek bir noktadan yayınlayabiliyoruz. Harika! Yeni duyurulan Microsoft SQL Server Mobile Report Publisher ve mevcut Rerport Builder & Report Designer ile bu grubun taleplerine cevap vermek artık mümkün ve daha ucuz.

3- Veri Analistileri : 


Analitik çalışmalarda verileri didik didik eden bu grup, verilerin ham hallerine ulaşmak ve bunlar üzerinde dilediği gibi çalışmak isteyecektir. Bu grubun ihtiyacı olan ürün Excel olur genelde. Ancak Excel'deki satır sınırı hala bir engel. Buna rağmen Excel Power BI veya Power BI Desktop ürnünde böyle bir sınır mevcut değil. Power BI veri modelindeki veriler memory üzerinden çalışır ve çok yüksek miktarda sıkıştırmaya tabi tutulur. Dolayısıyla pür Excel'in yetmediği yerde Power BI tarafına yönelmek mantıklı olacaktır.

İstemcileri 3 gruba ayırmak işleri kolaylaştırıyor. Tabi bu şekilde birden fazla ürünle çalışmanın kötü yanları da ortaya çıkıyor. Örneğin raporları merkezileştirmek büyük bir problemdir. Neyse ki bu aralar bu konuda da bazı gelişmeler var. Power BI portaldeki raporları ve/veya SSRS 2016 üzerinde hazırlanan geleneksel ve mobile raporları mobile cihazlar üzerinde Power BI Native App yardımıyla bir araya getirmek mümkün (şu aralar bu özelliğe sadece IOS'ta destek verilmektedir). Raporların HTML5 standardına getirilmesi de yayınlama konusunda esnekliği arttırdı.

Ürünlerle ilgili kısa bir bilgi vermek gerekirse;

Power BI Portal: üzerinde şirket mail hesabınızla bir deneme hesabı açabilirsiniz. Bu hesabın pro versiyonu aylık 10$.
www.powerbi.com
https://powerbi.microsoft.com/en-us/features

Power BI Desktop: Power Query, Power Pivot, Power Map ürünlerini bir araya getiren ücretsiz bir masaüstü uygulamasıdır.
https://powerbi.microsoft.com/en-us/desktop


SSRS & DataZen Entegrasyonu (SQL Server Mobile Report Publisher): Microsoft SQL Server 2016 ile birlikte gelen bir yeniliktir. Hem geleneksel raporları hem de DataZen temelli mobile raporları aynı servis üzerinden yayınlamak mümkün.
https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2016

Power BI Mobile App: IOS, Android ve Windows Mobile cihazlarda mağazadan indirebileceğini ve Power BI portal raporlarına erişim sağlayabileceğiniz Native uygulamadır. Şimdilik sadece IOS üzerinde SSRS raporlarına erişmek mümkün olsa da bu özellik diğer platformlarda da kullanılabilir olacaktır.
https://powerbi.microsoft.com/en-us/mobile

Excel Power BI: Ücretsiz olarak edinilen Power Query, Power Pivot, Power View, Power Map eklentileri Power BI ürününü oluşturmaktadır. Bu 4 ürünü Excel içerisinde kullanıp nimetlerinden faydalanmak mümkün. Excel 2016 ile ürünlerin tamamını kullanabilirsiniz. Diğer versiyonlarda bu hizmetler kısıtlıdır.

Ürünleri bir arada düşünürsek aşağı yukarı şöyle bir senaryo ile karşılaşırız:



Etkili rapor tasarlama konusunda bir şeyler okumak isterseniz bu konuda yazdığım serinin şu son makalesine ve öncesine bir göz atabilirsiniz.
http://abdullahkise.blogspot.com.tr/2015/10/etkili-rapor-tasarlama-teknikleri-7.html