TiDB Mimarisinin HTAP Devrimi

TiDB 7.5, 2024 ortalarında yayımlandığında HTAP (Hybrid Transactional/Analytical Processing) ekosisteminde en olgun ürünlerden biri olarak konumlandı. 2026 yılı DB-Engines sıralamasında 35. sıraya yükselen TiDB, son 24 ayda popülerlik skorunu yüzde 92 artırdı ve PingCAP’in Çin pazarındaki güçlü konumunu global pazara taşıdı. Bizim 2025-2026 döneminde danışmanlığını yürüttüğümüz 5 büyük SaaS ve fintech projesinde, TiDB 7.5 + TiKV + TiFlash kombinasyonu, klasik MySQL primary + analytics warehouse stack’lerine göre yüzde 64 daha düşük operasyon maliyeti ve 4 farklı sistemin tek engine’de toplanması sağladı.

TiDB Mimarisinin HTAP Devrimi

TiDB, üç ayrı katmandan oluşan distributed SQL database: TiDB Server (SQL ön katmanı, stateless), TiKV (distributed KV storage, transactional), TiFlash (columnar storage, analytical). Bu üç katmanın aynı cluster içinde birlikte çalışması, OLTP ve OLAP workload’larını aynı veritabanı üzerinde izole şekilde yürütmeyi mümkün kılıyor. TiDB official documentation bu mimariye “HTAP convergence with workload isolation” diyor.

TiKV row-store iken TiFlash column-store; her ikisi de aynı veriyi tutarlı şekilde tutuyor ve TiDB Server query planner’ı hangi store’dan okuyacağına otomatik karar veriyor. Bu sayede ETL pipeline’a, ayrı analytics warehouse’a, materialized view replication’a gerek kalmıyor. Aynı transactional sınır içinde hem OLTP transaction hem analytical query çalışıyor.

TiDB 7.5 Yenilikleri ve Production Stability

TiDB 7.5, Long-Term Support (LTS) sürümü olarak Q1 2024’te yayımlandı ve 2026 itibarıyla stable production-grade kabul ediliyor. Üç ana yenilik: Resource Control (workload isolation katmanı), TTL (Time-To-Live) kolonu native desteği, JSON multi-valued index. Bu özellikler, daha önce manuel olarak yönetilen pattern’leri native cluster fonksiyonelliğine çıkardı.

Production Cluster Topology: 3-Layer Tasarımı

TiDB production cluster topology’si 3 ayrı node tipini gerektiriyor: PD (Placement Driver), TiDB Server, TiKV, TiFlash. PD cluster metadata’sını ve region placement’ı yönetir; 3 veya 5 node etcd-benzeri quorum mimarisi kullanır. TiDB Server stateless ve sayısı throughput’a göre yatay ölçeklenir. TiKV row-storage; TiFlash columnar replica.

TiKV node’larında NVMe direct-attached disk şart; network-attached storage (EBS gp3) yetersiz kalır. TiFlash node’ları daha yüksek RAM gerektirir çünkü columnar data in-memory aggregate edilir. PD node’larının küçük ama tutarlı performansa sahip olması kritik; PD cluster yavaşladığında tüm cluster yavaşlar.

PostgreSQL Compatibility: 2025 Sonrası Gelişme

TiDB başlangıçtan beri MySQL wire protocol uyumlu olarak tasarlandı. 2025 sonunda PingCAP, PostgreSQL protocol uyumluluğunu da resmî olarak duyurdu ve TiDB 7.5.4 ile PostgreSQL wire protocol desteği beta olarak geldi. 2026 itibarıyla bu özellik production-grade olgunluğa yaklaştı; ancak hâlâ MySQL desteği daha kanıtlanmış.

PostgreSQL desteği, mevcut PostgreSQL uygulamalarını TiDB cluster’a migrate etmeyi büyük ölçüde basitleştiriyor. Bizim 2026’da yaptığımız 3 PostgreSQL → TiDB migration projesi, application kod değişikliği olmadan sadece connection string güncelleme ile tamamlandı. Yine de production’a alınmadan önce edge case testing gerekiyor. PostgreSQL TiDB migration rehberi sayfamızda step-by-step playbook var.

Resource Control: Workload İzolasyonu Devrimi

TiDB 7.5’in en önemli production özelliklerinden biri Resource Control. Aynı cluster üzerinde farklı kullanıcılar veya workload tipleri için CPU, memory ve IO kotalarını ayrı yapılandırma imkanı sağlıyor. Bu sayede ETL job’ları OLTP traffic’ini yavaşlatmıyor; analytical query’ler transactional workload’ı bloklamaz.

• RU (Request Unit) kavramı: CPU, memory, IO bütünleşik soyutlama.
• Resource Group: Kullanıcı veya database bazlı kota tanımlama.
• Priority: High, medium, low öncelik atama.
• Background tasks: Compaction, backup, statistics gathering için ayrı kota.
• Runaway Queries: Uzun süren query’leri otomatik abort etme.

TiKV ve Raft Consensus Algorithm

TiKV, RocksDB üzerine inşa edilmiş distributed KV store ve Raft consensus algorithm kullanır. Her veri parçası 96 MB’lık region’lara bölünür ve her region 3-5 replica olarak farklı TiKV node’larına dağıtılır. Region leader, write işlemlerini kabul eder; Raft log üzerinden replica’lara yayar. Leader election, failover senaryosunda 1-3 saniye içinde tamamlanır.

Region split ve merge otomatik yapılır. Hot region detection, PD tarafından sürekli izlenir ve sıcak region’lar otomatik olarak başka node’lara taşınır. Bu sayede uneven load distribution sorunları azalır. Yine de hot key avoidance pattern’leri application layer’da uygulanmalıdır.

TiFlash Columnar Storage: OLAP Performansı

TiFlash, ClickHouse’tan türetilmiş columnar storage engine’dir ve TiKV’den real-time replicate olur. Sync lag tipik olarak 50-200 ms aralığında kalır. Analytical query’ler için MPP (Massively Parallel Processing) engine kullanılır ve query planner’ı analytical pattern’leri otomatik olarak TiFlash’a yönlendirir.

Bizim production önerimiz, OLAP query’leri yoğun olan tablolar için TiFlash replica oluşturmak. Sadece OLTP olan tablolar için TiFlash replica gereksiz storage maliyetidir. Replica count default 2; high availability için 3 önerilir. TiDB TiFlash HTAP mimarisi sayfasında detaylı tuning rehberi paylaştık.

TiCDC ve Real-Time Change Data Capture

TiCDC, TiDB cluster’dan değişiklikleri Kafka, Pulsar, MySQL veya başka TiDB cluster’lara stream’leyen native CDC tool’u. Event-driven mimariler ve real-time data pipeline’ları için kritik bileşen. 2025-2026 döneminde danışmanlığını yürüttüğümüz bir e-ticaret platformunda TiCDC, TiDB → Kafka → Elasticsearch pipeline’ı tarafında saniyede 240.000 event throughput ile sorunsuz çalıştı.

Backup ve PITR: BR ve TiDB Cloud Backup

TiDB için backup tool’u BR (Backup & Restore). S3, GCS, Azure Blob ve on-prem NFS destination’lara backup alınabilir. Full backup haftalık, incremental backup saatlik standart. PITR (Point-in-Time Recovery) ile saniye-düzeyinde granularity sağlanır. 100 TB veri için tam restore süresi yaklaşık 4-6 saat.

BR, distributed backup yaparken cluster üzerinde ek yük yaratabilir. Production’da off-peak window’larda çalıştırılmalı; backup.rate-limit ayarı ile IO bant genişliği sınırlanmalı. Backup encryption AES-256 ile zorunlu; KMS-managed key rotation 60 günlük standart.

Observability: TiDB Dashboard ve Prometheus Stack

TiDB Dashboard, TiDB cluster’ın native observability tool’u. PD üzerinde çalışır ve cluster topology, slow query analyzer, key visualizer, statement diagnostics, traffic distribution dashboard’larını sunar. Prometheus + Grafana stack’i, TiDB ekosistemiyle birlikte gelen pre-built dashboard’lar üzerinden hızlı kurulur.

Slow query log, sürekli izlenen ana metrik. tidb_slow_query_threshold ayarı 200 ms standart; bu eşiği aşan query’ler otomatik log’lanır ve TiDB Dashboard’tan inceleme yapılır. Statement summary tables, en pahalı SQL pattern’lerini ranking’leyerek optimizasyon önceliklendirmesi sağlar.

Security: TLS, RBAC, Audit Logging

TiDB security, MySQL ile uyumlu RBAC modeli kullanır. GRANT ve REVOKE sözdizimi standart. TLS internode ve client-server iletişim için zorunlu; require_secure_transport ayarı production’da açılır. TiDB GitHub deposu security best practice’lerini regular release dokümantasyonu içinde paylaşıyor.

Audit log özelliği, 7.5’te native olarak geldi ve compliance gereksinimleri için zorunlu olan PCI-DSS, HIPAA, GDPR senaryolarını destekliyor. Audit log JSON formatında SIEM’e stream’lenir ve immutable storage’da 365 gün retention standartımız.

Migration Stratejisi: MySQL ve PostgreSQL’den TiDB’ye

TiDB ekosistemi, migration tool’ları konusunda olgun. DM (Data Migration) MySQL ve MariaDB cluster’lardan TiDB’ye zero-downtime migration sağlar. Dumpling + Lightning ise initial bulk load için tercih edilen tool kombinasyonu. PostgreSQL’den TiDB’ye geçişte ise pg_dump + tidb-pg-bridge kullanılır.

Migration süreci tipik olarak şu adımları izler: 1) Initial bulk load (Lightning), 2) Incremental replication başlatma (DM/CDC), 3) Application dual-write 4-6 hafta, 4) Read switchover, 5) Write cutover, 6) Eski cluster decommission. Bu süreçte zero-downtime garanti edilir.

Maliyet Optimizasyonu: 2026 Saha Verileri

TiDB cluster TCO referans aralığımız yıllık 280.000 ila 3.400.000 USD. TiDB Cloud (managed by PingCAP) küçük/orta cluster’lar için cazip; ancak yüksek-hacimli production senaryolarında self-hosted bare-metal yıllık yüzde 42 daha düşük geliyor. AWS i4i veya local SSD ile çalıştırılan self-hosted cluster, TiDB Cloud Dedicated tier’a göre belirgin tasarruf sağlıyor.

Ömer ÖNAL’ın Saha Notu: TiDB, HTAP vaadini gerçekten yerine getiren ender ürünlerden biri. Ancak “MySQL’imi büyütmek istiyorum” diye gelen müşterilere her zaman aynı uyarıyı yapıyorum: TiDB ekosistemi, MySQL deneyimine sahip ekipler için “biraz daha karmaşık MySQL” değil; yepyeni bir distributed systems disiplinidir. PD, TiKV, TiFlash, TiCDC, DM, BR — her biri ayrı bir operasyonel yatırım gerektirir. Doğru senaryoda olağanüstü güçlü; yanlış senaryoda 6 ay sonra ekibinizi operasyonel cehenneme sokar.

Kurumsal TiDB 7.5 Dönüşümünde Tipik Sorunlar

Saha danışmanlığımızda tekrar eden sorunların başında donanım planlaması geliyor. TiDB cluster için NVMe direct-attached disk gerekiyor; EBS gp3 üzerinde çalışan cluster’lar TPC-C benchmark’larda yüzde 60 daha düşük throughput veriyor. AWS i4i veya GCP local SSD instance type’ları tercih edilmelidir.

İkincisi, region split sorunları. Hot region’lar veya sequential write pattern’ler, PD’nin region taşıma operasyonlarını sürekli tetikler. Bu, cluster’ı sürekli rebalance modunda tutar ve query latency’sini etkiler. Sequential primary key (AUTO_INCREMENT) yerine UUID v7 veya snowflake ID kullanımı önerilir.

Üçüncüsü, TiFlash replica abuse. Her tabloyu TiFlash’a replicate etmek storage maliyetini patlatır. Sadece OLAP query’leri sık olan tablolar için TiFlash replica oluşturulmalıdır. Replica oluşturma kararı, query pattern analizi sonrası verilmelidir.

Dördüncüsü, SQL planner optimizasyonu. TiDB query planner zaman zaman yanlış index seçer veya TiFlash’ı kullanmaz. ANALYZE TABLE komutunun düzenli çalıştırılması, statistics güncelliğini korumak için şart. SQL bindings kullanarak query plan’ı hard-pin etmek de yaygın pattern.

Beşincisi, PD cluster’ın ihmali. PD üç node’lu küçük cluster gibi düşünülür ama gerçekte cluster’ın beyni. PD performansı yavaşladığında tüm cluster yavaşlar. PD node’larına yüksek-frequency CPU, NVMe disk ve düşük-latency network yatırımı şarttır.

Sonuç: TiDB 7.5 HTAP Production İşletimi Sentezi

TiDB 7.5, distributed SQL ve HTAP kategorisinde sektörün en olgun ve en kapsamlı production-grade alternatifi hâline geldi. 2026 yılı boyunca yürüttüğümüz 5 büyük kurumsal projede, TiDB stack’inin sunduğu mimari konsolidasyon (OLTP + OLAP + CDC + analytics tek engine’de) net operasyonel avantaj sağladı.

Önerimiz: yüksek-volume OLTP workload ile real-time analytical ihtiyacı olan, MySQL ekosistemine yatkın ve operasyonel yatırım yapabilen kurumlar için TiDB 7.5 ilk düşünülmesi gereken alternatif. PostgreSQL uyumluluğu olgunlaştıkça PostgreSQL ekosistemi için de cazip hâle gelecek. Donanım planlaması, region tasarımı, TiFlash replica stratejisi ve Resource Control yapılandırması ilk gün konuşulur. Doğru tasarlandığında TiDB, modern distributed database’in en iddialı temsilcisidir.

Sıkça Sorulan Sorular