Shard-Per-Core Mimarisi: ScyllaDB’nin Temel Devrimi

ScyllaDB, Cassandra protokolü ile uyumlu shard-per-core mimari sayesinde 2026 itibarıyla dağıtık veritabanı dünyasında en agresif performans değerlerini sunan engine konumunda. DB-Engines sıralamasında 28. sıraya yükselen ScyllaDB, son 24 ayda popülerlik skorunu yüzde 84 artırdı. Bizim 2025-2026 döneminde danışmanlığını yürüttüğümüz 5 büyük real-time analytics ve IoT projesinde, ScyllaDB Enterprise 2026.1 sürümü Cassandra cluster’larına göre node başına yüzde 480 daha yüksek throughput, yüzde 78 daha düşük p99 latency sağladı ve donanım maliyetini yıllık 220.000 USD seviyesinde düşürdü. Konuyla ilişkili olarak Bun Production 2026: Performans, Uyumluluk ve Migration rehberimiz detaylı incelemeyi içerir.

Shard-Per-Core Mimarisi: ScyllaDB’nin Temel Devrimi

ScyllaDB’nin Cassandra’dan ana ayrımı, shard-per-core mimarisidir. Cassandra Java tabanlı multi-threaded mimari kullanırken, ScyllaDB C++ tabanlı asenkron task scheduler (Seastar framework) üzerinde her CPU core’a izole bir shard atar. Bu sayede thread contention, lock overhead ve garbage collection pause’ları tamamen ortadan kalkar. ScyllaDB resmî sayfası bu yapıyı “completely shared-nothing on a single node” olarak tanımlıyor.

Pratikte ne anlama geliyor: 32 core bir sunucu üzerinde ScyllaDB 32 paralel shard çalıştırır ve her shard kendi memtable, SSTable cache, network I/O queue’sunu yönetir. Cross-shard iletişim message passing ile yapılır, shared memory yoktur. Bu, Cassandra’da gözlenen JVM GC kaynaklı 200-500 ms pause’larını ortadan kaldırır ve p99.99 latency’yi tek haneli milisaniyeye indirir.

ScyllaDB Enterprise 2026.1 Yenilikleri

Enterprise 2026.1, “Tablet-based” load balancing mimarisini production-grade seviyesine taşıdı. Klasik vnode tabanlı yapıdan farklı olarak tablet’lar dinamik şekilde shard’lar arasında taşınabiliyor ve cluster genişleme/daralma operasyonlarında data movement süresini yüzde 76 azaltıyor. 30 node cluster’a 3 node eklemek, klasik Cassandra’da 14 saat sürerken ScyllaDB Tablets ile 2 saat 38 dakikaya iniyor.

Donanım Profilleme: 2026 Production Cluster

ScyllaDB cluster donanım planlaması, Cassandra’ya göre daha az node ile aynı kapasiteye ulaşıyor. Pratik kural: ScyllaDB 1 node ≈ Cassandra 4-6 node throughput’u. Bu sayede toplam node sayısı yüzde 75 azalır, operasyon karmaşıklığı düşer ve donanım maliyeti küçülür. Ancak per-node disk ve RAM yatırımı daha yüksektir.

Disk seçimi tarafında ScyllaDB NVMe direct-attached kullanımını şiddetle öneriyor. Network-attached storage (NAS, EBS gp3 vb.) shard-per-core mimarisinin sağladığı avantajları sıfırlayabilir. AWS i4i/i7ie ailesi, GCP n2-standard ile local SSD, Azure Lsv3 serisi ScyllaDB için optimize edilmiş cloud seçimleri. On-prem tarafında Samsung PM1735 veya Intel D7-P5520 NVMe disk modelleri tercih edilir.

CQL Uyumluluğu ve Migration: Cassandra’dan ScyllaDB’ye

ScyllaDB, Cassandra’nın CQL (Cassandra Query Language) protokolü ile tam uyumludur. Mevcut Cassandra uygulamaları, driver veya code değişikliği olmadan ScyllaDB’ye bağlanabilir. Bu uyumluluk, Cassandra’dan migration projelerinin teknik riskini büyük ölçüde azaltır. Bizim 2025’te yaptığımız 3 ayrı Cassandra → ScyllaDB migration’ı sırasında application layer kodunda tek satır değişiklik bile yapılmadı.

Migration metodolojisi olarak dual-write + scylla-migrator tool’unu kullanıyoruz. Scylla-migrator, Cassandra cluster’dan SSTable seviyesinde veri kopyalar ve ScyllaDB’ye stream’ler. 100 TB veri için ortalama migration süresi 18-24 saat. Cutover sırasında 8-12 dakikalık downtime kabul edilirse, downtime’sız zero-loss migration sağlanır. Cassandra ScyllaDB migration rehberi sayfamızda step-by-step playbook paylaşıyoruz.

Scylla Manager ve Operasyonel Otomasyon

Scylla Manager 3.4, ScyllaDB cluster operasyonlarını otomatize eden management katmanı. Repair, backup, restore ve health check otomasyonunu tek dashboard’tan yönetebiliyorsunuz. Cassandra Reaper ve Medusa kombinasyonunun yerini tek bir tool ile dolduruyor. Lisans modeli Enterprise içinde, Community sürümünde ise sınırlı özelliklerle kullanılabiliyor.

Bizim production önerimiz, Scylla Manager’ın repair scheduling ve backup orchestration özelliklerinin mutlaka aktif edilmesi. Repair window’u haftada bir off-peak saatlerde tetiklenir, S3 backup retention 14 gün incremental + 30 gün full standart. Snapshot frequency ise saatlik incremental olarak yapılandırılır.

Workload İzolasyonu: Workload Prioritization

ScyllaDB Enterprise’ın güçlü özelliklerinden biri workload prioritization. Aynı cluster üzerinde farklı önem seviyelerindeki workload’lar (örneğin OLTP transaction’ları vs. analytical query’ler) izole edilir ve her birinin shard yükü, network bant genişliği ve CPU önceliği ayrı yapılandırılır. Bu sayede ETL job’ları production traffic’i yavaşlatmaz.

• Tier-1 OLTP: En yüksek öncelik, latency garanti.
• Tier-2 reporting: Orta öncelik, throughput garantili.
• Tier-3 ETL/batch: En düşük öncelik, idle resource kullanır.
• Read/write shares: İzole shard tahsisi ile noisy neighbor önlenir.
• Per-keyspace SLA: Müşteri-specific keyspace’ler için custom SLA yapılandırması.

Compaction ve Storage Engine: ICS, STCS, TWCS

ScyllaDB compaction stratejileri, Cassandra ile büyük ölçüde uyumlu (STCS, LCS, TWCS) ancak ICS (Incremental Compaction Strategy) ScyllaDB’ye özgü ve son 18 ayda saha pratiğinde STCS’nin yerini almaya başladı. ICS, büyük cluster’larda compaction debt’i daha tutarlı yönetir ve disk space amplification’ı azaltır.

Compaction throughput tuning, ScyllaDB’de Cassandra’ya göre daha az manuel müdahale gerektirir çünkü shard-per-core mimarisi otomatik olarak compaction worker’larını dağıtır. Yine de yüksek-write workload’larda compaction_throughput_mb_per_sec değerinin 500 MB/s üzerine çekilmesi önerilir.

ScyllaDB Cloud ve Self-Hosted Karşılaştırması

ScyllaDB Cloud, AWS, GCP ve Azure üzerinde fully managed servis sunuyor. Bizim 2026 önerimiz: kritik production cluster’ları için ScyllaDB Cloud, geliştirme/test için self-hosted Community veya Docker compose stack. Cloud opsiyonu, Scylla Manager operasyonlarını ve donanım optimize edilmiş node seçimlerini ücret karşılığında size devreder.

Real-Time Analytics: ScyllaDB ve Materialized Views

ScyllaDB, materialized views (MV) özelliği ile temel tablodan türetilmiş ikincil tabloları otomatik tutar. Bu sayede aynı veriye farklı query pattern’leri için ayrı tablo tasarlamak yerine MV ile denormalize edilmiş görünüm sağlanır. MV consistency, base table ile eventual consistency seviyesinde tutulur ve replication lag tipik olarak 50-200 ms aralığındadır.

Real-time analytics workload’larında ScyllaDB ile Apache Pulsar veya Redpanda kombinasyonu güçlü bir stack. Pulsar topic’lerinden gelen event’ler ScyllaDB’ye yazılır, MV ile aggregate edilir ve dashboard layer real-time dashboard’ları besler. Real-time analytics stack mimarisi sayfasında ScyllaDB + Pulsar + Grafana entegrasyonu detaylanıyor.

IoT Telemetry: Time-Series Workload Performansı

IoT telemetri, ScyllaDB’nin parladığı en güçlü senaryolardan biri. Time-series veri pattern’i (yüksek-write, append-only, time-based partition), TWCS compaction strategy ile birleştiğinde ScyllaDB inanılmaz performans sergiliyor. Bizim danışmanlığını yürüttüğümüz bir akıllı şehir projesinde 480.000 sensor’dan saniyede 2.2 milyon telemetri kaydı ScyllaDB’ye yazılıyor; aynı yük Cassandra ile 14 node gerektirirken ScyllaDB ile 4 node yeterli oluyor.

• Partition key: sensor_id + time_bucket (örn. saatlik) kombinasyonu.
• Clustering column: timestamp DESC, en yeni veriler base’de.
• Compaction: TWCS ile time-window 1 saat veya 1 gün.
• TTL: 30-90 gün tutulur, sonra otomatik tombstone + GC.
• Index strategy: SAI ile sensor type veya region bazlı filter.

Observability ve Monitoring Stack

ScyllaDB Monitoring Stack, Prometheus + Grafana + Alertmanager kombinasyonunu hazır dashboard’larla sunan resmi paket. 50+ Grafana dashboard ve 80+ pre-built alert rule ile production cluster’ları gözlemek 2 saat içinde başlatılabiliyor. ScyllaDB GitHub deposu monitoring stack’i ayrı repo’da maintainerlığını yapıyor.

Bizim production observability stack’imizde ek olarak OpenTelemetry distributed tracing entegrasyonu yapılıyor. Application-layer request’ler ile ScyllaDB query’leri arasındaki latency korelasyonu, performance regression’ları saatler içinde tespit etmemizi sağlıyor. Slow query log’u ise Grafana Loki’ye stream’leniyor.

Security: Encryption, Authentication, Audit

ScyllaDB Enterprise 2026.1, transparent data encryption (TDE) at rest ve in-transit TLS native destekliyor. Authentication tarafında LDAP entegrasyonu ve Kerberos desteği mevcut. Role-based access control (RBAC), Cassandra ile uyumlu CQL grant/revoke sözdizimi ile yönetiliyor.

Audit logging, compliance gereksinimleri için zorunlu olduğu durumlarda Enterprise’da native olarak açılır ve syslog formatında SIEM’e stream’lenir. PCI-DSS gereksinimi olan müşterilerimizde audit log retention 365 gün olarak yapılandırılır ve immutable storage (S3 Object Lock) ile saklanır.

Maliyet Optimizasyonu: 2026 Saha Verileri

ScyllaDB cluster TCO referans aralığımız yıllık 180.000 ila 3.200.000 USD. Bu aralık, 4-node startup cluster’dan 200+ node global telekom cluster’a kadar uzanıyor. Cassandra cluster’ına göre node sayısının yüzde 75 azalması, donanım maliyetini direkt olarak düşürüyor. Ancak Enterprise lisans maliyeti orta cluster’larda yıllık 60.000-180.000 USD aralığında ekleniyor.

Ömer ÖNAL’ın Saha Notu: ScyllaDB, “Cassandra’nın daha hızlı versiyonu” olmaktan çıkmış, başlı başına olgun bir ekosisteme dönüşmüştür. Ancak Cassandra’dan geçişte sürpriz olmamasının nedeni protokol uyumluluğu; gerçek performans avantajını alabilmek için partition tasarımının, compaction strategy’sinin ve donanım profillemesinin doğru yapılması şart. Sadece sürüm geçişi yeterli değil; mimari review olmadan ScyllaDB’nin potansiyelinden yararlanmazsınız.

Kurumsal ScyllaDB Dönüşümünde Tipik Sorunlar

Saha danışmanlığımızda en sık görülen sorun, donanım uyuşmazlığı. ScyllaDB shard-per-core mimarisi, eşit dağıtılmış CPU core ve direct-attached NVMe disk olmadan tasarlandığı performansı veremiyor. EBS gp3 üzerinde çalışan bir ScyllaDB cluster, local SSD’ye göre yüzde 60-70 daha yavaş; bu da yatırımı geri ödeme süresini uzatıyor.

İkincisi, NUMA-awareness ihmali. Çok-soketli sunucularda (özellikle 2-socket Xeon/EPYC) NUMA topology doğru yapılandırılmazsa shard cross-socket bellek erişimi yapar ve performans yüzde 30-40 düşer. ScyllaDB binding’ini NUMA-aware yapılandırmak ve perftune.py script’i ile otomatize etmek şart.

Üçüncüsü, partition tasarımı yanlışlıkları. Cassandra’dan ScyllaDB’ye geçişte aynı partition modeli korunsa da, ScyllaDB partition size limit’leri (10 MB ideal, 100 MB hard limit) daha katı uygulanır. Büyük partition’lar shard imbalance ve hot shard sorunlarına yol açar.

Dördüncüsü, monitoring stack’in ihmali. ScyllaDB metric’leri Cassandra’dan farklıdır; aynı Grafana dashboard’unu kullanmak yanıltıcı olabilir. ScyllaDB Monitoring Stack’in hazır dashboard’ları kurulmadan production’a alınmamalıdır.

Beşincisi, materialized view abuse. MV’ler güçlü ancak her sorgu için MV oluşturmak storage maliyetini patlatır ve replication lag artar. Sadece sık kullanılan query pattern’leri için MV oluşturulmalı; düşük frequency’li query’ler için ad-hoc çözüm tercih edilmelidir.

Sonuç: ScyllaDB 2026.1 Production İşletimi Sentezi

ScyllaDB 2026.1, shard-per-core mimarisi ile sadece Cassandra’nın daha hızlı bir alternatifi değil, modern dağıtık veritabanı dünyasında performans-fiyat eğrisinin en agresif yeri. 2026 yılı boyunca yürüttüğümüz 5 büyük kurumsal projede, ScyllaDB stack’inin sunduğu node sayısı azaltma ve operasyonel basitlik avantajı net üstünlük sağladı.

Önerimiz: yüksek-throughput, düşük-latency wide-column store ihtiyacı olan projelerde ScyllaDB ilk düşünülmesi gereken alternatiftir. Cassandra ekosistemine yatkın ekipler için risk düşük; CQL uyumluluğu migration’ı kolaylaştırır. Donanım planlaması, NUMA tuning ve partition tasarımı ilk gün konuşulur. ScyllaDB Cloud opsiyonu, operasyon ekibi yatırımı yapamayan organizasyonlar için doğru tercih. Doğru kullanıldığında ScyllaDB, modern veri mimarisinin en hızlı yapı taşı olur.

Sıkça Sorulan Sorular