MSSQL Server Mimarisi (SQL Server Architecture)

Doğancan Koç
SDTR
Published in
8 min readJul 18, 2019

Merhaba arkadaşlar uzun zamandır bir yazı yazamamıştım. Bu yazımın biraz teknik olmasını tercih ettim. Bu yazımızda Microsoft’un bir ürünü olan MsSql Server’ın mimarisine bakıp işleyişi hakkında elimden geldiğince bildiklerimi ve araştırdıklarımı aktarmaya çalışacağım.

MS SQL Server bir istemci-sunucu mimarisidir. MS SQL Server işlemi, bir istek gönderen istemci uygulamasıyla başlar. SQL Server, işlenen verilerle isteği kabul eder, işler ve yanıtlar. Aşağıda gösterilen mimarinin tamamını ayrıntılı olarak tartışalım

Mimarimiz tamamiyle yukarıdaki görüldüğü gibi bir işleyişe sahip.

Adım adım bu işleyişi parçalayıp detaylandıralım şimdi.

Yukarıdaki görselde gördüğünüz gibi 3 ana gövdeden bileşen mevcuttur.

1. Protocol Layer — SNI (SQL Server Network Interface)

Bu katmanımız istemci ile sunucu arasındaki bağlantıyı sağlayan katmanımızdır. Bu katmanın bazı kaynaklarda 3’e bazı kaynaklarda ise 4’e ayrıldığını gördüğünüzde şaşırmayın. Çünkü 4. katmanın çok az kullanılması ve extra donanımsal kaynaklar gerekliliğinden dolayı anlatılmayabiliyor ancak ben ufakta olsa bahsetmeye çalışacağım hepsinden. 4 protokol halinde incelemeye çalışalım ve SSCM ( Sql Server Configuration Manager) aracılığı ile bu protokolleri yönetebileceğimizi unutmayalım.

1.1 Shared Memory

Mssql sunucu ve istemci aynı kaynak üzerinde çalışıyorsa, PAYLAŞIMLI BELLEK PROTOKOLÜ(Shared Memory) protokolü çalışmaya başlar. Her ikisi de Shared Memory protokolü ile iletişim kurabilir.

Gerekli yapılandırmaları yapmak basittir. Sunucuya bağlanmak için
sunucu adı yerine

“.”

“localhost”

“127.0.0.1”

“Makina Adı”

gibi ifadeler ile şifresiz direk bağlantı da sağlanabilir. (Windows authentication ile)

1.2 TCP/IP

Kullanımı en çok yaygın olan protokol biçimimizdir. Sunucuya IP üzerinden direk erişimimizi sağlayabiliriz. SQL Server için varsayılan portumuz 1433 ‘tür. Windows authentication ile bağlanma sağlayamayız. Sql authentication ile IP, port, şifremizi girerek gerekli bağlantıyı sağlayabiliriz.

1.3 Named Pipes

İstemci ile sunucunun aynı LAN(Local Area Network)’ta olması durumunda kullanılan protokoldür. Bu seçenek varsayılan olarak devre dışı gelir ve sizin aktif hale getirmeniz gerekmektedir. Varsayılan olarak bağlantı olarak TCP 445 portunu kullanır. WAN ( Wide Area Network) içinde kullanımı mümkündür ancak yavaş bir bağlantı sağladığı için pek kullanımı görülmez.
WAN için kullanmak için SQL Server ALIAS tanımlaması yapılması gereklidir.

1.4 Virtual Interface Adapter (VIA)

Benim de tam detayını bilmemekle yüksek seviyeli bir protokol olduğunu duymuştum. Yine hem istemci tarafında hemde sunucu tarafında ekstra donanıma gerek olduğunu duymuştum.

Kısaca SNI’nın görevi suncudaki TDS (Tabular Data Stream) endpoint’e istek yapıp verileri alan ve güvenli bağlantı oluşturmaktırla yükümlüdür.

Nedir bu TDS
TDS, Tabular Veri Akışı anlamına gelir.
Her 3 (4.sünden emin değilim) protokol de TDS paketlerini kullanır. TDS, Ağ paketlerinde saklanır. İstemci makineden sunucu makineye veri aktarımı sağlamakla yükümlüdür. TDS, ilk önce Sybase firması tarafından geliştirilmiştir ve şu anda Microsoft’a aittir(Geliştirilmeye devam edilmektedir). Her sunucu da bu TDS paketlerini dinleyecek endpoint’ler bulunmaktadır ve her network protokolüne özgü bir TDS endpoint’i mevcuttur. Bu endpoint’leri listesini sys.endpoints isimli view’den alabiliriz.

SELECT * FROM sys.endpoints

İlk sırada meraklı arkadaşlarımız için dikkatinizi çekebilecek bir Dedicated Admin Connection (DAC) adında isim mevcut bunun için internet üzerinden araştırma yapmanızı tavsiye ederim.

Bundan sonraki iki kısım bazı kaynaklarda ayrı ayrı işlenir bazı kaynaklarda beraber işlenir ben kendim ortak bir yol bulup anlatmaya çalışacağım.

2. Relational Engine

Sorgularımızın en verimli şekilde yani en iyi optimizasyon yapmaktan sorumlu olan kısımdır. Sorgu işlemcisi olarak da adlandırılır. Tam olarak bir sorgunun ne yapması gerektiğini ve en iyi nasıl yapılabileceğini belirleyen SQL Server bileşenlerine sahiptir. storage engine (depolama motoru)’dan veri talep etmek ve geri gönderilen sonuçları işlemek suretiyle kullanıcı sorgularının yürütülmesinden sorumludur.

Yukarıdaki mimari şemasından gösterildiği gibi, İlişkisel Motorun (Relational Engin) 3 ana bileşeni vardır. Bileşenleri ayrıntılı olarak inceleyelim.

2.1 Command Parser

Sunucuya gelen sorgulardaki yazım hatalarını denetler ve devam eden sorgu ağacını hızlandırmakla sorumludur yani dahada detaylandırmak gerekirse;

Protokol Katmanından aldığı verileri daha sonra İlişkisel Motor’a iletir. Command Parser sorguları alan ilk İlişkisel Motor bileşenidir. Command Parser’in asıl işi, sözdizimsel(Syntax) ve anlamsal hata sorgusunu denetlemektir. Sonunda, bir Sorgu Ağacı oluşturur. Daha da ayrıntılı olarak ele almaya çalışalım.

2.1.1 Syntactic Check

Sözdizimsel kontrol anlamına gelir.Diğer her programlama dili gibi, MS SQL de önceden tanımlanmış belli anahtar kelimeler sabitlerine sahiptir. Ayrıca, SQL Server kendi anladığı kendi gramerine sahiptir.(Sql Programming Language detaylarına bakabilirsiniz.)
SELECT, INSERT, UPDATE ve diğerleri, MS SQL’de önceden belirlenmiş ve tanımlanmış anahtar kelime sabitleri listelerine aittir.
Command Parser sözdizimsel(syntax) denetim yapar. Kullanıcıların attığı sorgular bu dil sözdizimini veya dilbilgisi kurallarını yerine getirmiyorsa geriye bir hata çevirir. Örneğin select sorgu cümleciği yerine selct yazdığınız anda Command Parser hata üretip size döndürecektir.

2.1.2 Semantic check

Basit olarak ifade etmek gerekirse sorgulanan sütun adının yada tablo adının kullanılan şemada olup olmadığını kontrol eder ve bağlama işlemini gerçekleştirir.

2.1.3 Create Query Tree

Bu adım da ise sorgunun çalıştırılabileceği yürütme ağacı oluşturur.

2.2 Query Optimizer

İstemci tarafından gönderilen sorgu için nasıl yürütüleceği için bir plan oluşturmakla yükümlü olan kısımdır. Ancak önemli bir detay vermek isterim tüm sorgular için bu plan oluşturulmaz. Sadece DML (Data Modification Language) yani Veri Değiştirme Dili olan söz dizimin de genel olarak kullandığımız INSERT, UPDATE vb gibi sorgular için optimizasyon yapmakla sorumludur. CREATE ve ALTER gibi DDL komutları optimize edilmez. Sorgu maliyeti, CPU kullanımı, Bellek kullanımı ve Giriş / Çıkış ihtiyaçları gibi faktörlere göre hesaplanıp optimizasyon yapılır.

Query Optimize’in izlediği rol yada üstlendiği göreve kısaca en ucuz olanı değil, en uygun maliyetli uygulama planını yaratmaktır.

Optimizer’e daha detaylı bakmaya çalışalım.

2.2.1 Trivial Plan (Faz 0)

Bu aşama aynı zamanda ön optimizasyon aşaması olarak da bilinir.
Bazı durumlar için, önemsiz bir faz olarak adlandırılır. Optimize edilmiş hazır bir plan sistemde varsa eğer optimize edilmiş bir plan oluşturmaya gerek yoktur. Bunun nedeni, sunucuda daha fazla plan arama olduğu için aranan plan ekstra maliyet olabilir. Sorguların kalitesi biraz daha ortaya çıkabilir. Eğer önemsiz hazır bir plan bulunmaz ise 1. Faz başlar.

2.2.2 Search for Transaction Processing Plans (Faz 1)

Bu faz , Basit ve Karmaşık Plan (Simple and Complex Plan) aramasını içerir.
Basit Plan Arama: Sorguda yer alan geçmiş sütun ve index verileri, istatistiksel analiz için kullanılacaktır.
Yine de, basit plan bulunmazsa eğer daha karmaşık plan aranmaya başlanır. Tablo başına birden çok index içeren planlar olabilir.

2.2.3 Parallel Processing and Optimization (Faz 2)

Eğer yukarıdaki adımlardan birisi hiçbiri işe yaramazsa, bahsi geçen Faz iki seçenekleri değerlendirilmeye alınır. Bu adım, sunucuda bulunan makinanın işlem yeteneklerine ve yapılandırmasına bağlıdır.
Yine bir plan bulunamazsa, son optimizasyon aşaması başlar. Şimdi, nihai optimizasyon amacı gelinmiş olup, sorguyu en iyi şekilde yürütmek için olası tüm diğer seçenekleri barındırmaktadır. Son optimizasyon aşaması algoritmaları tamamen Microsoft’a aittir.

2.3 Query Executor

Kısaca sorguyu çalıştıran kısımdır. Query Executor AccessMethods ‘u çağırır.

3. Storage Engine

Storage Engine’in işi kısaca veritabanındaki fiziksel dosyalardan sorumlu olup gerektiğinde veriyi depolamak ve gerektiğinde veriyi alabilmekle yükümlüdür. Dahada kısaca özetlersek tüm I/O işlemlerinin en iyi şekilde yapılmasından sorumludur.

FILE

Dosyalar , fiziksel olarak sayfalar biçiminde saklar, her veri sayfası 8 KB büyüklüğündedir ve SQL Server’da en küçük depolama birimini oluştururlar. Bu veri sayfaları, mantıksal olarak Sql Server tarafından gruplandırılmıştır.

File types(Dosya Tipleri)

Primary File (Örn:MDF)
Her veritabanı bir primary file içerir.
Primary File , tablolar, view’ler, triggerler vb. ile ilgili tüm önemli verileri saklar. Uzantıları genellikle .mdf olur ancak herhangi bir uzantıya da sahip olabilirler.
Secondary File(Örn:NDF)
Veritabanı birden çok secondary file içerebilir.
Secondary File’lar oluşturalan dataya bağlı olarak bir veya birden çok olabilirler ve kullanıcıya özel verileri içerirler. Uzantıları genellikle .ndf olur ancak herhangi bir uzantıya sahip olabilir.
Log Files(Log dosyası)
Veritabanımızdaki logları tutan dosya türümüzdür. Uzantısı .ldf olur.
Bu dosyalara istenmeyen herhangi bir durum olduğu zaman geçmiş yapılan işlemlere bakmak için kullanabiliriz.

Şimdi Storage Engine e Detaylı bakalım. 3 bileşene sahiptirler.

3.1 Access Method (Erişim Yönetimi)

Query Executor ile Buffer Manager/Transaction Logs arasında bir arayüz görevi görür.

Access Method’un kendisi herhangi bir işlem yapmaz. İlk yaptığı iş, kendisine gelen sorgunun olup olmadığını bakmaktır. Kendi içinde sorguya bakarken ikiye ayırır ve ona göre işlem yürütmeye devam eder.

  1. Select Statement (DDL)
  2. Non- Select Statement (DDL & DML)

Sonuca bağlı olarakta işlemi yürütmeye devam eder.

Sorgu DDL ve Select sorgusu ise sonraki işlemleri için Buffer Manager’e yönlendirir.

Sorgu DDL ve Select olmayan bir sorgu ise (Örneğin:Update) sorgu Transaction Manager’a yönlendirilir.

3.2 Buffer Manager

Buffer manager aşağıdaki modülleri için temel fonksiyonları yönetmekle yükümlüdür.

  • Plan Cache
  • Data Parsing: Buffer cache & Data storage
  • Dirty Page

3.2.1 Plan Cache

Mevcut Sorgu planı: Buffer Manager, yürütme planının saklanan Plan Cache’de olup olmadığını kontrol bakar. Eğer cache de var onu kullanır.
Mevcut olmayan Sorgu Planı:
İlk kez sorgu yürütme planı çalıştırılıyorsa ve karmaşıksa, sunucu önbelleğinde depolamak mantıklı olur. Bu, bir sonraki SQL sunucusu aynı sorguyu aldığında daha hızlı kullanılabilirlik sağlayacaktır.

3.2.2 Data Parsing: Buffer cache & Data Storage

Buffer Manager gerekli verilere erişim sağlar. Veri önbelleğinde veri olup olmamasına bağlı olarak iki yaklaşım sergiler.

3.2.3 Dirty Page

Transaction Manager ‘da işlem mantığı olarak saklanır. Transaction Manager’i bölümünde detaylı olarak incelemeye çalışacağız.

3.3 Transaction Manager

Transaction Manager Non- Select Statement sorgu olduğunda çağırılan kısımdır.

3.3.1 Log Manager

İşlem Günlükleri’ndeki(Transaction Log) günlükler aracılığıyla sistemde yapılan tüm güncellemelerin kaydını tutar.
Logs Sequence Number with the Transaction ID ve Data Modification kayıtlarını saklar.

3.3.2 Lock Manager

İşlem sırasında veritabanındaki veriler kilitli şekilde tutulur. Bu işlemlerden sorumlu kısımdır.

3.3.3 Execution Process

Log Manager günlüğe kaydetmeye başlatır ve Lock Manager ilişkili verileri kilitleme işlemini sağlattırır. Verilerin kopyası ise Buffer Cache’e yazılır.

4. SQLOS API

İşletim sistemi ile Sql Server arasındaki katmandır. Detaylarını bende tam bilmiyorum. : )

Sonuç

Öncelikle yanlış herhangi bir bilgi aktarmak istemem gözünüze takılan bir sorun varsa direk bana ulaşmanızı önemle rica ediyorum. Sürçü lisan ettiysemde affola.

Özetlemek gerekirse istek ilk önce sunucuya gider ve gerekli protokol vasıtasıyla Command Parser’a yönlendirilir. Sonrasında Optimizer ‘e ordan query plan belirlenip Query Executer’e aktarılır. Query Executer Access Method ile iletişime geçer. Gelen sorgu ve sorgunun daha önce yapılıp yapılmamasına göre Transaction Manager ile yada Buffer Manager ile haberleşir. Yönlendirelen kısımdaki gerekli datalar okunduktan sonra işlem tekrar Access Method aracılığı ile Query Executer’e ordan da istemciye veri gönderilir.

Kendinize iyi bakın. Sağlıcakla kalın. Sizlere eğer bir iki kelime katabildiysem ne mutlu bana. Eğer buraya kadar okuduysanız..
Alkışlar sizlere…

Software Development Turkey discord sunucumuza katılmak için aşağıdaki linke tıklayabilirsiniz.

https://discord.gg/9zN8CQQ

Doğancan Koç

Saygılarımla

--

--