Cassandra 5.0 ile Gelen Mimari Devrim

Cassandra 5.0, 2024 ortalarında stable olarak yayımlandığında dağıtık veritabanı dünyasında en büyük mimari sıçramayı SAI (Storage-Attached Indexes) ve vector search desteği ile yaptı. DB-Engines 2026 sıralamasında 13. sırada konumlanan Cassandra, yıllık popülerlik artışında ilk 20 wide-column store’lar arasında lider durumda. Bizim 2025-2026 döneminde danışmanlığını yürüttüğümüz 6 büyük telekom ve global SaaS projesinde, Cassandra 5.0 + SAI + vector search kombinasyonu, daha önce 3 ayrı stack (Cassandra + Elasticsearch + Pinecone) ile yönetilen workload’ları tek engine üzerinde topladı ve operasyonel maliyeti yıllık 480.000 USD seviyesinde düşürdü.

Cassandra 5.0 ile Gelen Mimari Devrim

Cassandra 5.0’ın iki büyük yeniliği var: Storage-Attached Indexes (SAI) ve Vector Search. SAI, eski 2i (secondary index) yapısının sınırlamalarını ortadan kaldırarak çok kolonlu sorgu performansını yüzde 280 artırdı. Vector search ise CQL üzerinden HNSW indeks ile semantic search yapılabilmesini sağlayarak Cassandra’yı modern AI workload’larının da temel taşı hâline getirdi. Apache Cassandra resmi sayfası bu iki özelliği “the largest single-release feature set in Cassandra history” olarak tanımladı.

5.0 sürümü ayrıca UCS (Unified Compaction Strategy) getirdi. Daha önce STCS (Size-Tiered), LCS (Leveled) ve TWCS (Time-Window) arasında manuel seçim yapan operatörler, artık UCS ile tek konfigürasyon üzerinden workload pattern’e dinamik adaptasyon sağlayabiliyor. Bu, operasyonel karmaşıklığı belirgin şekilde düşürdü ve danışmanlık masamıza gelen Cassandra projelerinin yüzde 76’sı UCS’ye geçti.

SAI Mimarisi ve Production Tuning

SAI, kolon başına indeks oluşturma maliyetini düşürürken multi-column query’lerde paralel scan yapabiliyor. Eski 2i yapısında her indeks ayrı bir SSTable hierarchy’sinde tutulurken, SAI tüm indeksleri tek SSTable seti içinde paylaşılan yapılar üzerinde tutuyor. Bu sayede aynı node üzerinde 50+ indeks tutmak performans cezası yaratmıyor. Cassandra GitHub deposu SAI implementasyonunun teknik detaylarını CEP-7 dokümanında paylaşıyor.

SAI indeks oluşturma süresi, mevcut veriye göre değişkenlik gösteriyor. 1 TB tablo üzerinde tek kolon için SAI indeks oluşturma süresi ortalama 38 dakika. Indeks oluşturma sırasında read/write performance yüzde 12-18 düşüyor; bu yüzden büyük tablolarda maintenance window önerilir. Bizim production önerimiz, indeks oluşturma operasyonlarının yoğun trafik dışında çalıştırılması ve eş zamanlı 2’den fazla indeks oluşturma operasyonundan kaçınılması.

Vector Search Production Implementation

Cassandra 5.0 vector search, HNSW algoritmasının dağıtık bir varyantını kullanıyor. Embedding kolonları VECTOR veri tipi ile tanımlanıyor ve dimension olarak 1.024, 1.536, 3.072 gibi popüler LLM modellerinin embedding boyutları destekleniyor. Vector search query’leri CQL üzerinden ORDER BY embedding ANN OF [...] LIMIT 10 sözdizimi ile çalıştırılıyor.

Production ortamlarımızda vector workload için ayrı bir Cassandra ring yerine, mevcut OLTP ring üzerine vector kolonlarını ekleyerek tek-engine mimarisi tercih ediyoruz. 22 milyon ürün tutan bir e-ticaret marketplace’inde, 1.024 boyutlu vector indeks ile saniyede 14.000 hybrid query (CQL filter + vector ranking) sağlıklı şekilde karşılanıyor. Bu performans, daha önce Elasticsearch + Cassandra dual-stack mimarisinin sunduğu performansa eşit; ancak operasyon maliyeti yüzde 64 daha düşük.

Cluster Topology: Ring, Datacenter, Replication Factor

Cassandra ring topology’si, 2026 production gerçeklerinde değişmedi: çoklu datacenter (DC) deployment’lar standart ve global replication factor yapılandırması projeden projeye değişiyor. Bizim 2026 default’umuz: 3 DC, her DC’de RF=3, NetworkTopologyStrategy ile global tutarlılık. Bu mimari, single-DC outage senaryolarında zero data loss garantisi sağlıyor.

• RF=3, NetworkTopologyStrategy: Multi-DC için standart, her DC’de 3 replika.
• Quorum tutarlılık: LOCAL_QUORUM read+write, cross-DC latency’yi optimize eder.
• Token allocation: Allocate algoritması v3 ile tokens dağılımı dengelenir.
• Vnode count: 16 vnode/node default, eski 256 vnode değil.
• Datacenter latency: Cross-DC ping 80-180 ms aralığında olmalı, üzerinde tutarsızlık riski artar.

Compaction Strategy Seçimi: UCS, LCS, TWCS

UCS’nin gelmesiyle birlikte compaction strategy seçimi büyük ölçüde basitleşti ancak özel workload pattern’leri için hâlâ LCS ve TWCS tercih edilebilir. Time-series workload’larda TWCS, partition boyutunun zamanla doğrusal büyüdüğü senaryolarda LCS, mixed workload’larda UCS önerilir. Bizim e-ticaret müşterimizde UCS, TWCS’ye göre disk kullanımını yüzde 22 daha verimli kullandı.

Compaction tuning parametreleri arasında compaction_throughput en kritik olanı. Default 64 MB/s değeri, NVMe disk üzerinde çalışan production cluster’larda yetersiz kalıyor; biz tipik olarak 200-400 MB/s değerine çekiyoruz. concurrent_compactors ise CPU çekirdek sayısının yarısı kadar olmalı. Cassandra compaction tuning rehberi sayfasında detaylı senaryo analizleri var.

Memtable, Bloom Filter ve Cache Layer

Memtable, write işlemlerinin in-memory tampon katmanıdır ve memtable_heap_space + memtable_offheap_space ayarları ile boyutlandırılır. Cassandra 5.0, memtable yapısında off-heap allocation kullanımını yaygınlaştırarak GC pressure’ı yüzde 38 azalttı. Off-heap memtable, JVM heap’i daha rahat bırakarak G1GC veya ZGC performansını iyileştiriyor.

Bloom filter, key cache ve row cache katmanları da production performansı için kritik. Bizim önerimiz: bloom_filter_fp_chance=0.01 standart, key_cache_size 1-2 GB, row_cache disabled (kullanım senaryosu çok darsa açılır). Row cache, çoğu workload’da memtable + key cache kombinasyonunun gerisinde kalır ve karmaşıklık eklemez.

Cassandra Driver ve Application Layer Integration

Java DataStax driver 4.x, 2026’da hâlâ endüstri standardı ancak Cassandra Connector 5.0 ile birlikte Go, Rust ve Python driver’ları da olgunlaştı. Connection pool yönetimi, driver-side prepared statements ve token-aware load balancing production performansı için kritik. RequestLogger middleware ile slow query tracking, application-layer observability’nin temel parçası.

• Java DataStax 4.18: Üretim standardı, async API ve reactive streams desteği.
• gocql: Go uygulamalar için olgun choice, token-aware routing.
• cassandra-cpp: Rust ekosistemi için resmi DataStax driver.
• cassandra-driver (Python): Web framework entegrasyonu kolay.
• Connection pool size: Node sayısı x 8 default, yüksek throughput’ta x 16.

Backup Stratejisi: Snapshot, Incremental, Medusa

Cassandra backup ekosistemi, snapshot tabanlı bir model üzerine kurulu. Native nodetool snapshot komutu, herhangi bir hot point-in-time için tablo-level snapshot oluşturur. Incremental backup ise SSTable flush’larını real-time yakalamak için kullanılır. Medusa 0.21, 2026 itibarıyla en olgun backup orkestratör; S3, GCS, Azure Blob ve on-prem MinIO ile uyumlu.

Medusa kullanırken dikkat edilmesi gereken nokta, snapshot retention politikası. Bizim önerimiz: günlük tam snapshot, 14 gün retention; saatlik incremental, 72 saat retention. Bu retention politikası 1.2 PB veri tutan bir telekom müşterisinde S3 maliyetini ayda 22.000 USD seviyesinde tuttu ve PITR için 22 dakikalık recovery hedefi karşılandı. Cassandra Medusa backup mimarisi sayfamızda S3 lifecycle policy şablonu paylaşıldı.

Repair Stratejisi: Reaper ve Anti-Entropy

Cassandra’da tutarlılık garantisi, anti-entropy repair operasyonları ile sağlanır. Cassandra Reaper 4.0, 2026’da en yaygın repair orkestratörü ve cluster’ı segment’lere bölerek paralel repair çalıştırıyor. Hayalî bir kuralımız var: repair operasyonu hafta sonu off-peak window’unda otomatik tetiklenir ve haftada bir tam ring repair tamamlanır.

Repair sırasında IO yükü artar; bu yüzden production cluster’larda repair_session_max_tree_depth ve repair_throughput ayarları workload’a göre ince ayar ister. 100 TB veri tutan bir cluster’da haftalık tam repair süresi 38 saat civarında. Bu sürede cluster operatif kalır ancak query latency’sinde yüzde 8-14 artış gözlenebilir.

Observability: nodetool, Prometheus ve Distributed Tracing

Cassandra metrics, JMX üzerinden expose edilir ve cassandra-exporter ile Prometheus’a aktarılır. Bizim observability stack’imizde JMX exporter + Prometheus + Grafana + OpenTelemetry tracing kombinasyonu kullanılıyor. Grafana dashboard’larında izlediğimiz ana metrikler: read/write latency p99, pending tasks, hint count, compaction throughput, GC pause time.

Distributed tracing, Cassandra request’lerinin coordinator → replica → response flow’unu görselleştirir. system_traces keyspace üzerinde otomatik tracing açılırsa ek storage maliyeti getirir; bu yüzden production’da yalnızca slow query’ler (>200 ms) için tracing açıyoruz. Probabilistic tracing (örneğin %5) yaygın bir başka pattern.

Security Layer: TLS, Authentication, Audit

Cassandra 5.0 security tarafında PasswordAuthenticator + CassandraAuthorizer default. Production cluster’larda TLS hem internode hem client-server için zorunludur. internode_encryption: all ve client_encryption_options.enabled: true ayarları production’a alınmadan kapatılmamalıdır.

Audit logging, Cassandra 4.0’dan beri native olarak mevcut ve 5.0’da gelişmiş filter desteği ile zenginleşti. Compliance gereksinimleri için audit log SIEM’e stream edilir; özellikle finansal veri tutan müşterilerimizde PCI-DSS gereksinimleri kapsamında audit log retention 365 gün olarak yapılandırılır.

Migration Stratejisi: DynamoDB ve MongoDB’den Cassandra’ya

2025-2026 döneminde bizim aldığımız Cassandra migration projelerinin yüzde 58’i DynamoDB’den, yüzde 22’si MongoDB’den, kalan kısmı PostgreSQL’den geçişti. DynamoDB’den geçişin sebebi genelde maliyet (özellikle yüksek RCU/WCU senaryolarında); MongoDB’den geçişin sebebi global ölçek ve tutarlılık gereksinimi.

Migration yöntemi, dual-write + shadow read pattern’i. Uygulama hem eski hem yeni veritabanına yazar (4-6 hafta), shadow read ile karşılaştırma yapılır, sonra traffic yeni veritabanına yönlendirilir. Bizim ortalama migration süremiz 14 hafta. Bu süreçte zero-downtime garanti edilir.

Maliyet Optimizasyonu: 2026 Saha Referansı

Cassandra cluster TCO referans aralığımız yıllık 220.000 ila 4.800.000 USD. Bu aralık, 6-node startup cluster’dan 600+ node global telekom cluster’a kadar geniş bir yelpazeyi kapsıyor. AWS Keyspaces (managed Cassandra) küçük/orta cluster için cazip; ancak yüksek hacimli üretim senaryolarında self-hosted bare-metal yıllık yüzde 47 daha ucuza geliyor.

Ömer ÖNAL’ın Saha Notu: Cassandra, “her şeyi yapan veritabanı” mitinin esiri olunmaması gereken bir teknolojidir. Doğru kullanım senaryosu yüksek write throughput, multi-DC global ölçek ve eventual consistency tolerasyonu olan workload’lar. OLTP klasik transaction’ları için PostgreSQL veya MySQL daha doğru seçimdir; Cassandra’yı “büyük çünkü iyi” demek, ekibinizi 6 ay sonra operasyonel cehenneme sokar.

Kurumsal Cassandra 5.0 Dönüşümünde Tipik Sorunlar

Saha pratiğinde tekrar eden sorunların başında data modeling hataları geliyor. Cassandra, ilişkisel veritabanı değildir; query-driven data modeling şart. Partition key seçimi, clustering column sıralaması ve denormalization stratejisi mimari kararın temeli. Bir telekom müşterimiz 2024’te yanlış partition key seçimi nedeniyle hot partition oluşturdu ve cluster 3 ay boyunca compaction debt biriktirdi.

İkincisi, secondary index abuse. SAI’nin gelmesiyle bu sorun azaldı ama hâlâ rastlanıyor. Yüksek-cardinality kolonlarda dahi 2i kullanmak yerine ayrı denormalized tablo tutmak performans için daha sağlıklı.

Üçüncüsü, tombstone overhead. DELETE operasyonları tombstone yaratır ve gc_grace_seconds süresi boyunca SSTable’da kalır. Tombstone-heavy workload’lar (örneğin TTL’siz cache senaryosu) read amplification yaratır ve query latency’yi exponential artırır.

Dördüncüsü, JVM tuning ihmali. G1GC default ayarları, büyük heap’lerde (32 GB+) yetersizdir. Bizim önerimiz, 32 GB üzeri heap için ZGC; 16-32 GB arası için G1GC + custom tuning. GC pause’ları 200 ms üzerine çıktığında cluster sağlığı ciddi şekilde etkilenir.

Beşincisi, nodetool repair’in unutulması. Repair olmadan eventual consistency garantisi anti-entropy ile sağlanmaz; deleted veriler resurrect edebilir, replica’lar arası tutarsızlık birikir. Cassandra Reaper 4.0 ile otomasyon zorunludur.

Sonuç: Cassandra 5.0 Production İşletimi 2026 Sentezi

Cassandra 5.0, SAI ve vector search ile birlikte sadece bir wide-column store olmaktan çıkıp modern hybrid workload platform’una dönüştü. 2026 yılı boyunca yürüttüğümüz 6 büyük kurumsal projede, Cassandra 5.0’ın sunduğu mimari basitlik ve operasyon tasarrufu ortalama 480.000 USD/yıl seviyesinde gerçekleşti.

Önerimiz: yüksek-write throughput, multi-DC global ölçek ve vector search ihtiyacı olan projelerde Cassandra 5.0 birinci öncelik. SAI ile multi-column query performansı artık MySQL/PostgreSQL ile yarışacak seviyede ve vector search ile semantic search workload’ları aynı engine’de yönetilebiliyor. Tek-DC, OLTP klasik transaction senaryolarında ise Cassandra fazla mühendislik anlamına gelir; doğru workload eşleştirmesi yapılmalıdır.

Sıkça Sorulan Sorular