DBA Günlükleri #1 : SQL Server In-Memory Tablo Kullanım Koşulları ve Tablo Geçişi
SQL Server geleneksel veritabanı mimarisinde veri “page” denilen bloklarda disk üzerinde bulunmaktadır. Kullanıcı SELECT işlemi başlattığında, sorgunun talep ettiği verilerin varlığı önce bellek üzerindeki tampon alanda sorgulanır(Memory buffer). Eğer veri burada yoksa, doğrudan disk’e gidilir ve gerekli veriler oradan temin edilip kullanıcıya ulaştırılmaktadır. Bilgisayar organizasyonlarda bellek(memory) disk’e göre daha hızlı cevap alınabilecek br donanımdır. Bu nedenle verilerin bellek üzerinde olması ve buradan istenilen verileri getirmek her zaman daha hızlı olacaktır. Aslında temel nedeni, bellek parçası her zaman CPU’ya en yakın yol üzerindedir. Bu nedenle tüm donanım içerisinde iletişim kurmaları çok daha hızlıdır. Konunun tam teknik açıklamasını ise bu link üzerinden daha detaylı öğrenebilirsiniz.
Microsoft SQL Server ise, bu kapsamda veritabanı performansını arttırmak için In-Memory özelliklerini kullanmaktadır. Yeni nesil SQL Server mimarilerinde uygun şartlar oluştuğunda performans kazanımı için tavsiye edilen bir özelliktir. In-Memory tablolar, SQL Server’ın tabloya ait verileri doğrudan memory üzerinde tutması ve veri kaybını önlemek için bu duruma özel disk üzerinde dosya sistemi kullanıması olayıdır. Bu sayede, veritabanına gelen isteklerin cevaplanma süreleri(iyi pratikler uygulandığında) dramatik oranda düşmektedir. Peki SQL Server In-Memory teknolojisinde nasıl performans artışı kazandırıyor ?
- Bilgisayar Organizasyonu : Memory’nin doğal yapısı nedeniyle cevap süreleri disk’e göre daha azdır.
- Veritabanı Seviyesinde “Lock” : In-Memory tablolara gelen isteklerde optimistic lock mekanizması kullanılmaktadır. Bu sayede, işlemler doğrudan tüm diğer işlemleri bloklamaz. Kullanıcı güncelleme gibi işlemler yapmak istediğinde SQL Server sadece işlem bitiminde okunan veri ile işlem sonunda okunan veriyi kontrol eder. Eğer farklılık varsa işlemi ROLLBACK eder. Bu sayede de bloklanma nedeniyle bekleme yaşanmaz. Yazılım katmanında “retry” kullanımı ile bu sorunun üstesinden gelmek mümkündür.
Optimistic Locking hakkında detaylı bilgi almak için Microsoft’un kendi yayınladığı dökümanlarını kontrol edebilirsiniz.
In-Memory tablo mimarisi ise aşağıdaki şekilde kurgulanmıştır. Aslında anlatılanların kısa bir özeti şeklinde incelenebilir aşağıdaki şema. Bu şemada natively compiled SP kısmına ise daha sonra değineceğim :) Pastanın üzerinde çilek = natively compiled SP :)
SQL Server In-Memory Geçişi Adımları
SQL Server üzerinde mevcut bir tabloyu in-memory hale taşımak için tamamlanması gereken önkoşullar vardır. Bu önkoşullar temelde aşağıdaki gibidir.
- Tablo üzerinde FK olmamalıdır.
- Tablo üzerinde “datetimeoffset” tipinde alanlar olmamalıdır.
- Memory-Optimized dosya grubu oluşturulmalıdır.
Diğer gereklilikler için yine Microsoft’un yayınladığı rehberler incelenmelidir.
Bu gereklilikleri tamamladıktan sonra SQL Server Management Studio kullanarak in-memory tablo geçişi yapılabilir. İlk adımda göç edilmesi gereken tablonun üzerinde Memory Optimization Advisor işlemi başlatılır.
Daha sonrasında memory-optimization sihirbazı üzerinde geçiş öncesi gerekliliklerin sağlandığı teyit edilir. Burada bir problem olduğunda geçiş işlemleri durdurulur ve gereklilikler tamamlanır.
Daha sonrasında ise, geçiş seçenekleri yapılmaktadır. Bu sekmede yeni tablonun ismi belirlenir ve eski tablonun içindeki verileri de yeniye aktarması için “Also copy date table to the new memory optimized table” seçeneği işaretlenir.
Not: Standart olarak data durability opsiyonu tablo için açık gelmektedir. Ancak “Check this box to migrate this table to a memory-optimized table with no data durability” seçeneği işaretlenirse bu özellikten vazgeçilir ve olası bir sunucu kesintisinde ya da restart’ı sonrasında veri ortadan kaybolur.
Daha sonrasında ise, tablo üzerindeki indexlerin HASH ya da RANGE index’e taşınması işlemleri yapılır. Burada, hash index oluştururken verilecek “bucket count” değeri önemlidir. Tablodaki DISTINCT count sayısına ve tablonun yazılım katmanında kullanımına göre bu değer verilmelidir. Eğer tablo çok yoğun insert alan bir tablo ise, SQL Server’ın önerisinin 2–3 katı fazla bucket count değeri verilebilir. Hash index bucket count ayarlama rehberinin tam haline ise buradan ulaşabilirsiniz.
Son olarak ise yapılan işlemlerin özeti kontrol edilir ve geçiş işlemi başlatılır. Bu adımdan sonra geçişin tamamlandığı görülür ve işlemler tamamlanır.
Bundan sonraki yazıda, SQL Server In-Memory tabloların performans konusundaki etkilerini inceleyeceğim. Aslında, performans kavramı DBA kişisi için çok geniş bir kazanımdır. Hangi işlem tipinde ve hangi yazılım davranışlarında yüksek performans bekleniyor gibi konuların belirlenmesi gerekmektedir :) Bunun yanısıra, “Natively Compiled SP” özelliğininde performans üzerindeki etkilerini inceleyeceğim. Şimdilik demo ortamını hazırlamaktayım.
NOT : Serinin üçüncü yazısında ise, Columnstore indexleri bu yapıya entegre etmeye çalışacağım ve yine performans etkilerini tartışacağım.
Sevgiler,
Demir.
