Veri türüne göre database indexleme rehberi: B-tree, GIN/GiST, columnstore

Çoğu performans sorunu yanlış indeks seçimi ya da indeks eksikliğinden kaynaklanır; bu makalede B-tree, GIN/GiST ve columnstore gibi indeks türlerinin nasıl çalıştığını ve hangi durumlarda tercih edilmesi gerektiğini öğreneceksiniz. Hem ilişkisel sistemlerde (PostgreSQL, SQL Server) hem de NoSQL yaklaşımlarında (MongoDB, Elasticsearch) geçerli, ölçülebilir optimizasyon adımlarını göreceksiniz.

İndeks türleri: B-tree, GIN, GiST ve columnstore nasıl çalışır

B-tree indeksler tekil değerlerle, aralık sorguları ve sıralama gereksinimleri için uygundur; çoğu birincil anahtar ve sık kullanılan WHERE sütunları için en uygun seçenektir. B-tree'lerin çalışma mekanizması iç düğüm-ara düğüm-yapısıyla anahtar araması yapıp sayfa okuma sayısını düşürür; bu nedenle seçicilik (selectivity) yüksek sütunlarda etkili sonuç verir.

GIN ve GiST indeksleri ise doküman, dizi veya coğrafi veri gibi karmaşık veri türleri için tasarlanmıştır; JSONB, array ve full-text aramalarında GIN sık kullanılır. Columnstore/OLAP-oriented indeksler (ör. PostgreSQL'de cstore_fdw, SQL Server Columnstore) büyük tarama sorgularında I/O'yu azaltır; OLTP yazma maliyetini artırabileceği için mixed workload tasarımında dikkatli kullanılmalıdır.

Sorgu desenine göre indeks seçimi ve planın okunması

İndeks seçimi sorgu örüntüsünü anlamaya bağlıdır: sık kullanılan filtre sütunları, ORDER BY ve JOIN anahtarları önceliklidir. EXPLAIN/EXPLAIN ANALYZE (PostgreSQL, MySQL), Query Store (SQL Server) veya db.collection.explain() (MongoDB) ile planı inceleyip sekans taramaları, index scan ve bitmap kullanımını kontrol edin; planın I/O ve CPU dağılımını ölçmeden karar vermeyin.

İstatistiklerin güncel olması kritiktir: PostgreSQL için ANALYZE, SQL Server'da istatistik güncelleme ve MySQL'de optimizer switch'ler sonuçları ciddi şekilde etkiler. Düşük kardinaliteli sütunlara tam indeks koymak çoğu zaman gereksizdir; bunun yerine kısmi indeks (partial index) veya expression index kullanarak index boyutunu ve yeniden yapılandırma maliyetini azaltabilirsiniz.

Gerçek dünya senaryosu: E-ticaret katalog sorgularında GIN ve kısmi indeks uygulaması

Durum: Bir e-ticaret platformunda ürün özellikleri JSONB içinde saklanıyordu; filtre ve facet sorguları (ör. renk, beden, teknik özellik) yavaşlıyor ve tam tablo taramaları artıyordu. Sistem PostgreSQL kullanıyordu; sorgu örüntüsü hem eşleşme hem de containment (jsonb @>) kullanıyordu.

Çözüm: JSONB için GIN indeks ve aktif ürünler için kısmi indeks oluşturduk; ayrıca sık kullanılan anahtarlar için expression indeksler ekledik. Ölçüm: belirli filtreli aramalarda ortalama sorgu süresi 1200ms'den 95ms'e düştü ve seq scan oranı %80'den %10'a indi; bu sayılar yapılan EXPLAIN ANALYZE ve üretim trace'lerinden elde edildi.

Aşağıdaki örnek, ürün tablosunda JSONB alanı için GIN ve kısmi indeks oluşturur. Önce indeksin amacını ve hangi sorgu desenini hedeflediğini açıkladım, sonra neden kısmi indeks kullandığımızı özetledim.

CREATE INDEX idx_products_attrs_gin
ON products
USING GIN (attributes);

-- Kısmi indeks: yalnızca aktif ve stokta olan ürünler
CREATE INDEX idx_products_attrs_gin_active
ON products
USING GIN (attributes)
WHERE active = true;

Bu yapı, genel containment sorgularını hızlandırırken aktif olmayan ürünleri indeks dışında tutarak indeks boyutunu küçülttü ve güncelleme maliyetini azalttı.

İleri seviye incelikler: bloat, fillfactor, index-only scan ve write amplification

İndeks bakımını atlamak bloat'a yol açar: PostgreSQL'de autovacuum ayarları, SQL Server'da düzenli rebuild/reorganize görevleri performansı korur. Fillfactor değeri ile sayfa içi boşluk kontrolü yaparak update-heavy tablolar için write amplification'ı azaltabilirsiniz; örnek: yüksek güncelleme oranlı bir tabloya fillfactor 80 uygulanması, sayfa split'leri ve index büyümesini düşürebilir.

Index-only scan hedefliyorsanız seçtiğiniz indeksin tüm referans edilen sütunları içerdiğinden (covering index) emin olun; PostgreSQL'de INCLUDE, SQL Server'da INCLUDE sütunları kullanarak heap I/O'yu ortadan kaldırabilirsiniz. Parametre sniffing ve plan cache problemleri için SQL Server'da plan rehberleri ya da optimizasyon ipuçları, PostgreSQL'de ise prepared statement ve bind parametre davranışını değerlendirmek gerekir.

Aşağıdaki kısa örnek, sipariş sorgusu için kapsayıcı (covering) bir indeks oluşturmayı gösterir; neden cover index kullandığımı ve fillfactor'ı neden ayarladığımı açıkladım.

CREATE INDEX idx_orders_user_status_amount
ON orders (user_id, status)
INCLUDE (total_amount)
WITH (fillfactor = 80);

Bu indeks, sık yapılan user_id+status filtreli rapor sorgularını index-only scan ile cevaplamaya olanak verip ana tablo I/O'sunu azalttı.

NoSQL ve hibrit yaklaşımlar: MongoDB, Elasticsearch ve ilişkisel indeks stratejileri ile entegrasyon

NoSQL sistemlerinde indeksleme mantığı farklılık gösterir; MongoDB'de compound ve multikey indeksler, Elasticsearch'te inverted index ve tokenization kullanılır. Bir mimaride hem PostgreSQL hem Elasticsearch varsa, hangi sorguların hangi sisteme yönlendirileceğini net ayırmak veritabanı performans ayarlama sürecinde kritik bir karar noktasıdır.

Hibrit çözümde öneri: OLTP ve tutarlı transactional iş yükünü ilişkisel veritabanında tutun, arama ve facet/agg sorgularını Elasticsearch'e bırakın; veriyi senkronize etmek için değişiklik akışı (Change Data Capture) veya arka plan indeksleme ile tutarlılığı ölçün. Bu sayede hem veritabanı optimizasyonu hem de arama performansı hedeflenebilir.

Bu konuyu neden öğrenmelisiniz?

Veritabanı eğitimi ve SQL eğitimi alanında derinleşmek, aranan bir yetenek sunar; iş ilanlarında veritabanı optimizasyonu ve database indexleme bilgisi orta ve üst seviye roller için sıkça talep edilir. Bu beceri sayesinde sorgu maliyetlerini düşürebilir, altyapı maliyetini azaltabilir ve uygulama kullanıcılarına daha hızlı deneyim sunabilirsiniz.

Ayrıca hem SQL Server eğitimi hem de NoSQL eğitimi bağlamında indeksleme stratejilerini bilmek, hibrit sistemlerde doğru teknolojiyi seçme ve veriyi doğru yerden okuma yeteneği kazandırır; bu, proje risklerini azaltır ve ölçeklenebilirliği artırır.

Özet

• İndeks türü seçimi veri tipi ve sorgu desenine göre yapılmalıdır.
• EXPLAIN ve gerçek izleme metrikleri olmadan indeks kararları yanıltıcı olabilir.
• Kısmi ve expression indeksler, indeks boyutunu ve maliyeti düşürür.
• Bakım (vacuum/reindex/fillfactor) unutulursa indeks bloat performansı bozar.
• NoSQL/Elasticsearch ile hibrit yaklaşımlar arama ve OLTP yüklerini ayrıştırır.

Sık Sorulan Sorular

JSONB için en iyi database indexleme yöntemi nedir?

JSONB için genel olarak GIN indeksleri en iyi başlangıç noktasıdır; containment (@>) sorgularında GIN büyük ölçüde hızlıdır. Ancak sık erişilen belirli anahtarlar varsa expression index veya kısmi indeks kullanmak indeks boyutunu ve güncelleme maliyetini düşürür, bu yüzden EXPLAIN ANALYZE ile ölçüm yapın.

SQL Server eğitimi alırken indeksleme konusunda hangi konulara odaklanmalıyım?

SQL Server için odaklanılması gerekenler: clustered vs nonclustered indeks tasarımı, include sütunları ile covering index oluşturma, fillfactor ve fragmentation yönetimi, Query Store ile plan değişikliklerini izleme ve rebuild/reorganize stratejileridir. Bu konular günlük operasyonlarda doğrudan performans farkı yaratır.

NoSQL eğitimi alırken veritabanı optimizasyonu nasıl farklıdır?

NoSQL sistemlerinde indeksleme veri modeline ve sorgu tipine göre değişir; örneğin MongoDB'de multikey indeksler ve compound indeksler, Elasticsearch'te inverted index yaklaşımı kullanılır. Tutarlı transactional gereksinimler varsa hibrit mimari düşünmeli ve hangi sorguların hangi sisteme yönlendirileceğini tasarlamalısınız.

Veritabanı performans ayarlama sürecinde ilk ölçüm adımları nelerdir?

İlk adım sorgu örüntülerini toplamak: ağır sorguları EXPLAIN/Query Store/slow query log ile tespit edin, ardından istatistikleri güncelleyin ve belirgin seq scan'leri hedefleyin. Değişiklikleri küçük adımlarla uygulayıp her değişikliğin etkisini ölçün; böylece regresyonları hızlıca yakalarsınız.