Bu makalede modern veri tabanı sistemlerinde verimliliği artıran HashTable, HashIndex ve Hashpartition yapılarını inceleyeceğiz. Bu kavramların nasıl çalıştığını, avantajlarını, dezavantajlarını ve pratik kullanım örneklerini SQL kodlarıyla açıklayacağız.

Hash tabanlı bir veri yapısı tasarlayacağımız ortamda bilmemiz gereken özellikle hash partitioning ya da bucketing gibi bölümlendirme stratejilerinde sıkça karşımıza çıkacak bir parametre olan bucket_count, verilerin kaç adet bucket içine dağıtılacağını belirleyen sayısal bir değerdir. Her bir bucket, belirli bir hash değeri aralığına denk gelir ve veriler, belirli bir kolona uygulanan hash fonksiyonunun çıktısına göre bu bucket ‘lardan birine atanır. Peki, bu bizim için neden önemli?

• Doğru belirlenmiş bir bucket_count değeri, verilerin eşit dağılımı sağlar bu da sorgu performansını iyileştirir.
• Bucket sayısı, paralel çalışan işlemlerin sayısını doğrudan etkiler, örneğin bir tablo 16 bucket sahipse, aynı anda 16 thread veriyi işleyebilir. Aynı bucket sayısıyla bölünmüş tablolar arasında yapılan join işlemleri daha verimli olur.

CREATE TABLE UserActiviy
(
Id_user INT,
activity_type STRING
)
CLUSTERED BY (Id_user) INTO 16 BUCKETS

• Olumsuz yönleri olarak bilmemiz gereken; Bucket_count değeri genellikle tablo oluşturulurken sabitlenir ve daha sonra değiştirilemez. Veri hacmine göre Bucket_count değeri belirlenmelidir çünkü düşük olursa bucket ’lar aşırı dolabilir, fazla olursa kaynak israfı olur.

Hash Table Nedir?

Hash table, bir veri yapısıdır, key-value eşleşmesi yaparak verileri saklayan ve onlara hızlı erişim sağlayan veri yapısıdır.

Burada karıştırılmaması ve birbirinden net olarak ayırmak adına hash table ile Inmemory table arasındaki farklardan da bahsetmek istiyorum. Inmemory (Memory-Optimized) tables iki yapıdan oluşur: indexes (Hash or Range) ve rows (tablodaki verinin kendisidir); Hash table sadece bir veri yapısıdır doğrudan bir key-value pair olarak tutulur. Inmemory (Memory-Optimized) tables bir veri tabanı nesnesi olduğu için ACID kurallarına uyar bu bağlamda default isolation level SNAPSHOT ‘dır ancak hash table için bir default isolation level veya benzeri ACID kuralı yoktur çünkü hash table bir veri yapısıdır.

Hash table kullanımı açısından sunmuş olduğu avantajları; hızlı erişim, basit yapı, key-value tabanlı yapısı, uygun bucket sayısı ile ölçeklenebilirliğini söyleyebiliriz. Bunlara karşılık dezavantajlı yanları ise; collision riski, verilerin sıralı tutulmasından dolayı aralık sorguları veya sıralama gerektiren işlemler için uygun olmaması, bucket sayısı ölçeklendirilebilmesi açısından bir avantaj olarak görünse de gereğinden fazla ayarlanmış bucket kaynak israfı olacaktır, etkili olmayan bir hash fonksiyonu dengesiz dağılım ve yüksek collision ile performansı ciddi şekilde düşürebilir diyebiliriz.

--Inmemory hash Index için bir MEMORY_OPTIMIZED_DATA filegroup oluşturarak içerisine file ekliyoruz (File Type “FILESTREAM Data” seçmemiz gerekmektedir)
USE [master]
GO
ALTER DATABASE [MuratTest] ADD FILEGROUP [FGHashIndex] CONTAINS MEMORY_OPTIMIZED_DATA 
GO

Görsel – 1

USE [master]
GO
ALTER DATABASE [MuratTest] ADD FILE ( NAME = N'MuratTest_FGHashPartition', FILENAME = N'D:\Data4\Data\MuratTest_FGHashPartition.ndf' ) TO FILEGROUP [FGHashIndex]
GO

Inmemory + Hash Index örneği

CREATE TABLE USERS (
ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1024),
UserName NVARCHAR (100) ) WITH (MEMORY_OPTIMIZED = ON)

Inmemory örneği

CREATE TABLE dbo.TradeOrders (
OrderID BIGINT NOT NULL PRIMARY KEY NONCLUSTERED,
TraderID INT NOT NULL,
OrderType CHAR(1) NOT NULL,    
INDEX IX_OrderTime NONCLUSTERED(OrderTime) )WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);	--WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);

Hash Index Nedir?

Temelde bir hash indeksi N adet buckets veya slot dizisidir ve her bir satır pointer içerir. Hash indexes bir hash function kullanır ve function karşılık gelen buckets veya slot veriyi yerleştirir. Peki, burada kısaca hash function açıklayacak olursak onu da şu şekilde söyleyebiliriz; değişken uzunluktaki verileri sabit uzunluktaki verilere deterministik (aynı girdiye her zaman aynı sonuç) ve rastgeleye yakın bir şekilde eşleyen bizim belirlediğimiz bir algoritmadır, örneklerini göreceğiz. Bir bucket alanına öncesinde bir veri eklenmiş ve zamanla hash algoritması ile aynı bucket alanına tekrar veri geldiğinde bunun kendi içinde point atarak çözmeye çalışır ancak bu gibi durumlarda collision sebebiyet verecektir. Sistemimizde hash yapısını kullanma amacımız yüksek performans elde etmektir kurgulayacağımız hash function olabildiğince az “collision(çakışma)” yaşamalıdır fazla miktarda collision görmemiz yapıyı bozmaz ancak performans kaybı yaşamamıza ve okuma işlemlerinde erişim süresinin uzamasına sebebiyet verecektir.

Peki ama ben oluşturacağım yapıda neden B-Tree Index kullanmak yerine Hash Index kullanmayı tercih etmeliyim bunun bana ne gibi avantaj ve dezavantajları olabilir? Hash indexes key-value yapısı sayesinde kullanılan hash fonksiyonu ile hedef veri hemen bulunur özellikle “where” koşulundan eşitlik sorgularında çok hızlıdır, B-Tree index ‘in verileri sıralı tutması bu sayede aralık sorguları (BETWEEN, <, >, ORDER BY) verimli şekilde çalışır. Hash indexes B-Tree gibi bir dallanma olmadığı için işlemler sisteme çok daha az yük getirir, yapısı daha sade ve daha az kaynak tüketir, B-Tree index ‘in yapısı gereği dallanma yapısı ile daha fazla bellek ve işlem yükü oluşturur. Hash indexes yapısı daha sade ve daha az kaynak tüketir, B-Tree index ‘in hash ‘e göre collision problemi yoktur.

Hash indexes Inmemory (MEMORY_OPTIMIZED = ON) tablolar ile birlikte, büyük veri kümelerinde bucket_count doğru seçilerek uygun dağılım sağlandığında, “Where” koşulunda eşitliğe dayalı yüksek okuma performansının beklendiği ortam ve sistemler için maksimum performansı gösterecektir.

Hash Partitioning Nedir?

Veri miktarının büyük olduğu sistemlerde, performansı artırmak ve yönetilebilirliği kolaylaştırmak adına partitioning önemli bir mimari yaklaşımdır. Hash partitioning, bir tablonun satırlarının belirli bir sütun / sütunlar üzerinden hesaplanan hash değeri aracılığıyla, önceden tanımlanmış partitioning içerisine dağıtma işlemidir. Bu yöntemde, her bir kayıt için hash fonksiyonu çalıştırılır ve çıkan sonuç ile partition ‘lardan hangisine düşeceği belirlenir. Bu yaklaşım sayesinde veriler rastgele ancak dengeli şekilde bölümlere ayrılır. Özellikle eşitlik temelli sorgular (WHERE customer_id = 123) partition ‘lar arasında dağıtıldığından, veri tabanı yalnızca ilgili bölüme erişerek daha az maliyet oluşturur ve daha hızlı sonuç döner.

Hash partitioning ‘in en belirgin faydası, veri tabanı sistemlerinin veriyi paralel işleyebilme yeteneğini artırmasıdır. Farklı partition ‘lar birbirinden bağımsız olarak işleyebildiğinden, büyük sorgular paralel olarak işleyebilir bu da genel performansa ciddi katkı sağlar. Şimdi anlattıklarımızı örneklendirelim;

Öncelikle partition yapımız için bir filegroup oluşturarak içerisine file ekliyoruz.

USE [master]
GO
ALTER DATABASE [MuratTest] ADD FILEGROUP [FGHashPartition]
GO
ALTER DATABASE [MuratTest] ADD FILE ( NAME = N'MuratTest_FGHashPartition_1', FILENAME = N'D:\Data4\Data\MuratTest_FGHashPartition_1.ndf' , SIZE = 1048576KB , FILEGROWTH = 1048576KB ) TO FILEGROUP [FGHashPartition]
GO

1) Aşağıdaki sorgu ile sunucumuzun cpu core sayısını öğreniyoruz.

SELECT *
FROM SYS.dm_os_sys_info		--numa_node_count

2) –16 Core system için aşağıdaki şekilde partition function oluşturuyoruz

USE [MuratTest]
CREATE PARTITION FUNCTION [pf_hash32] (tinyint) AS RANGE LEFT FOR VALUES
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 28, 29, 30, 31) 

3) –partition schema oluşturuyoruz

USE [MuratTest]
CREATE PARTITION SCHEME [ps_hash32] AS PARTITION [pf_hash32] ALL TO ( [FGHashPartition] )

4) –tablomuzu oluşturuyoruz ve gerekli indeksi atıyoruz

USE [MuratTest]
GO
CREATE TABLE [dbo].[OtomobilGecis](
       [Id] INT NOT NULL,
       [KayitTarih] [datetime] NOT NULL,
       [Plaka] [varchar](50) NULL,
       [GecisZamani] [varchar](50) NOT NULL,
       [Sehir] [varchar](20) NULL,
       [TimeStamp] [datetime] NOT NULL CONSTRAINT [DF_LOGPTSTEST]  DEFAULT (getdate()),
       [HashValue]  AS (CONVERT([tinyint],abs(binary_checksum([KayitTarih])%(32)),(0))) PERSISTED NOT NULL
) ON [ps_hash32]([FGHashPartition])
GO
CREATE NONCLUSTERED INDEX [IX_Plaka] ON [dbo].[OtomobilGecis]
(
    [Plaka] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = on, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [ps_hash32]([FGHashPartition])
GO

Modern veri tabanı sistemlerinde verimliliği artıran, veri yönetimi ve erişimi performansına önemli katkılar sağlayan, kavramlardan olan hashTable, hashIndex ve hashPartition kavramlarından bahsettik, siz de optimal sonuçlar elde etmek için collision riskini en aza indiren iyi tasarlanmış hash fonksiyonları ve uygun bucket_count seçimine dikkat ederek HashTable, HashIndex ve HashPartition ile veri tabanı sistemlerinizde kullanabilir performansınızı ileri bir seviyeye taşıyabilirsiniz, bir sonraki makalede görüşünceye dek iyi ki varsınız, sevgiler J

KAYNAK

https://learn.microsoft.com/en-us/sql/relational-databases/indexes/indexes?view=sql-server-ver17

https://www.mssqltips.com/sqlservertip/3099/understanding-sql-server-memoryoptimized-tables-hash-indexes/

Deep dive into Hash indexes for In-Memory OLTP tables

https://www.brentozar.com/archive/2012/04/hash-partitioning-sql-server-scaling-writes/