Apache Cassandra Nedir, Ne Zaman Kullanılır

Tek bir MySQL sunucusu, ne kadar güçlü olursa olsun, bir gün yetmez. Yazma trafiği o makinenin diskini ve CPU'sunu doldurduğunda önce read replica eklersiniz, sonra sharding'i elle kurgularsınız, sonra da her yeni shard'ın kendi yedeklemesi, kendi failover'ı ve kendi bakım penceresi olduğunu fark edersiniz. Apache Cassandra tam olarak bu duvara çarpmış ekipler için tasarlanmış bir dağıtık veritabanıdır: yatay ölçeklenmeyi sonradan eklenen bir katman olarak değil, mimarinin temeli olarak kabul eder ve sunucu eklemeyi tablo eklemek kadar sıradan bir işleme dönüştürür.

Ama Cassandra sihirli bir çözüm değil; ilişkisel bir veritabanının yerine geçmez ve yanlış senaryoda kullanıldığında hayatınızı MySQL'den çok daha fazla zorlaştırır. Bu rehberde Cassandra'nın halka (ring) mimarisini, partition key'in neden en kritik tasarım kararı olduğunu, ayarlanabilir tutarlılık seviyelerini, yazma yolunu ve compaction'ı, tombstone tuzağını ve en önemlisi hangi iş yüklerinde doğru hangilerinde yanlış seçim olduğunu somut örneklerle anlatacağım.

Halka Mimarisi ve Tek Nokta Arızasının Yokluğu#

Cassandra'yı diğer birçok veritabanından ayıran en temel özellik, master düğümünün olmamasıdır. MySQL replikasyonunda bir primary ve ona bağlı replikalar vardır; primary düşerse yazma durur ve bir failover süreci işletilir. Cassandra'da ise tüm düğümler eşittir. Her düğüm hem yazma hem okuma alabilir, hem de kümenin durumunu gossip protokolü üzerinden diğerleriyle sürekli paylaşır.

Veri, tutarlı karma (consistent hashing) ile düğümler arasında dağıtılır. Her satırın partition key'i bir hash fonksiyonundan geçirilir ve elde edilen token değeri, halkada hangi düğümün o veriden sorumlu olduğunu belirler. Modern kurulumlarda her fiziksel düğüm halkada tek bir yer değil, num_tokens ayarı kadar sanal düğüm (vnode) işgal eder; bu, yeni bir sunucu eklendiğinde veri taşınmasının daha dengeli dağılmasını sağlar.

Bu mimarinin pratik sonucu şudur: üç düğümlü bir kümede bir sunucu tamamen kapansa bile, replikasyon faktörünüz uygunsa uygulama kesintisiz çalışmaya devam eder. Bunun bedeli ise tutarlılık tarafından ödenir — Cassandra varsayılan olarak "eventual consistency" yani nihai tutarlılık modeliyle çalışır. Bu ödünleşmenin teorik arka planı için CAP teoremi nedir yazısı iyi bir başlangıç noktasıdır.

Veri Modeli: Partition Key Her Şeyin Merkezinde#

Cassandra'nın sorgu dili CQL, SQL'e o kadar benzer ki insanı yanıltır. SELECT, INSERT, CREATE TABLE hepsi tanıdıktır ama arkalarındaki motor bambaşkadır. En büyük fark: Cassandra'da istediğiniz kolona göre sorgu yapamazsınız. Tablolar sorgulara göre tasarlanır, sorgular tablolara göre değil.

Bir Cassandra tablosunun birincil anahtarı iki parçadan oluşur. Partition key verinin hangi düğümde duracağını belirler; sorgularınızda neredeyse her zaman bunu vermek zorundasınız. Clustering column ise aynı partition içindeki satırların hangi sırayla saklanacağını belirler ve aralık sorgularına izin verir.

-- Sensör ölçümlerini saklayan tipik bir zaman serisi tablosu
CREATE TABLE olcumler (
    sensor_id   text,          -- partition key: veriyi düğümlere dağıtır
    gun         date,          -- partition key'in ikinci parçası: partition'ı böler
    olcum_zamani timestamp,    -- clustering column: partition içi sıralama
    sicaklik    double,
    nem         double,
    PRIMARY KEY ((sensor_id, gun), olcum_zamani)
) WITH CLUSTERING ORDER BY (olcum_zamani DESC);

Buradaki çift parantez önemlidir: (sensor_id, gun) bileşik partition key'dir, olcum_zamani ise clustering column'dur. Bu tasarım şu sorguya mükemmel uyar:

-- Tek bir partition okunur, disk üzerinde ardışık bloklardan gelir
SELECT olcum_zamani, sicaklik
FROM olcumler
WHERE sensor_id = 'S-1042' AND gun = '2026-08-25'
  AND olcum_zamani > '2026-08-25 08:00:00';

Ama şu sorgu bu tabloda çalışmaz, çünkü partition key verilmemiştir:

-- HATA: partition key olmadan tüm kümeyi taramaya kalkar
SELECT * FROM olcumler WHERE sicaklik > 30;

Cassandra size ALLOW FILTERING eklemenizi önerir. Bu öneriyi üretimde asla dinlemeyin. ALLOW FILTERING, sorgunun tüm düğümlerde tüm partition'ları taraması demektir; küçük test verisiyle çalışır, üretim verisiyle kümeyi dize getirir. Doğru çözüm, o sorgu için ayrı bir tablo oluşturmak ve veriyi yazma anında iki tabloya birden yazmaktır. Bu "denormalizasyon" ilişkisel dünyadan gelenlere ters gelir ama Cassandra'da disk ucuz, koordinasyon pahalıdır.

Tutarlılık Seviyeleri ve Replikasyon Faktörü#

Cassandra'da her keyspace kendi replikasyon ayarını taşır. Üretim kurulumlarında NetworkTopologyStrategy kullanılır ve replikasyon faktörü veri merkezi başına belirtilir:

-- İki veri merkezli bir kurulumda, her birinde 3 kopya
CREATE KEYSPACE uygulama
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'istanbul': 3,
  'ankara': 3
};

Replikasyon faktörü kaç kopya tutulacağını söyler; tutarlılık seviyesi ise bir işlemin başarılı sayılması için kaç kopyanın onay vermesi gerektiğini söyler ve sorgu bazında değiştirilebilir. Bu, Cassandra'nın en güçlü özelliklerinden biridir: aynı kümede kritik bir yazmayı güçlü tutarlılıkla, sıradan bir okumayı hızlı ve gevşek yapabilirsiniz.

Güçlü tutarlılığın altın kuralı şudur: okuma seviyesi + yazma seviyesi > replikasyon faktörü olduğunda, okuduğunuz veri en son yazdığınız veriyi mutlaka içerir. Replikasyon faktörü 3 ise QUORUM yazma (2 onay) + QUORUM okuma (2 onay) bu koşulu sağlar: 2 + 2 = 4 > 3. Buna karşılık ONE yazma + ONE okuma yaptığınızda (1 + 1 = 2, 3'ten küçük) eski veri okuma ihtimaliniz vardır. Bu matematik, ACID ile BASE arasındaki farkın pratikteki en somut hâlidir; konunun tamamı için ACID ve BASE modelleri yazısına bakabilirsiniz.

-- Oturum bazında varsayılan tutarlılık seviyesi
CONSISTENCY LOCAL_QUORUM;

-- Sürücü tarafında sorgu bazında da ayarlanabilir
INSERT INTO olcumler (sensor_id, gun, olcum_zamani, sicaklik)
VALUES ('S-1042', '2026-08-25', toTimestamp(now()), 24.6);

Kurulum, İlk Keyspace ve Temel nodetool Komutları#

Cassandra bir JVM uygulamasıdır; kurulumdan önce sunucuda uyumlu bir Java sürümü bulunması gerekir. Tek düğümlü bir geliştirme kurulumu için adımlar şöyledir:

1. Java çalışma zamanını kurun ve java -version ile doğrulayın.
2. Cassandra paketini resmî depodan kurun.
3. /etc/cassandra/cassandra.yaml içinde cluster_name, listen_address, rpc_address ve seeds değerlerini ayarlayın.
4. Servisi başlatın ve nodetool status ile düğümün UN (Up/Normal) durumuna geçmesini bekleyin.
5. cqlsh ile bağlanıp ilk keyspace'i oluşturun.

# Servisi başlat
sudo systemctl enable --now cassandra

# Küme durumu: her düğüm için durum, adres, yük ve sahip olduğu token yüzdesi
nodetool status

# Örnek çıktı:
# Datacenter: istanbul
# ==========================
# Status=Up/Down |/ State=Normal/Leaving/Joining/Moving
# --  Address        Load       Tokens  Owns    Host ID    Rack
# UN  185.12.34.56   412.7 MiB  16      33.4%   3f2a...    rack1
# UN  185.12.34.57   398.1 MiB  16      33.2%   9c81...    rack1
# UN  185.12.34.58   405.9 MiB  16      33.4%   b740...    rack2

Kümenin sağlığını izlerken düzenli kullanacağınız birkaç komut daha vardır:

# Tablo bazında okuma/yazma gecikmesi, SSTable sayısı, tombstone istatistikleri
nodetool tablestats uygulama.olcumler

# İş parçacığı havuzlarında sıkışma var mı (Dropped mesajlar kötü işarettir)
nodetool tpstats

# Anti-entropy onarımı: replikalar arasındaki farkları giderir
nodetool repair -pr uygulama

Cassandra bellek ve disk I/O açısından cömert bir veritabanıdır; üç düğümlü mütevazı bir küme bile her düğümde birkaç GB heap ve hızlı disk ister. Kendi kümenizi kurmak için VDS veya bulut sunucu paketleri makul bir başlangıçtır; yüksek yazma hacimli üretim kümeleri içinse ayrılmış donanım sunan dedicated sunucu seçenekleri daha öngörülebilir gecikme verir.

Yazma Yolu, Compaction ve Tombstone Tuzağı#

Cassandra'nın yazma performansının sırrı basittir: hiçbir zaman diskte var olan bir veriyi yerinde güncellemez. Gelen yazma önce commit log'a (dayanıklılık için) ve belleğe (memtable) yazılır, memtable dolduğunda diske değişmez bir SSTable dosyası olarak boşaltılır. Aynı satırın güncellenmiş hâli yeni bir SSTable'a yazılır; okuma sırasında Cassandra bu parçaları birleştirip en güncel değeri döner. Bu yapıya LSM ağacı denir ve rastgele disk yazması yapmadığı için çok hızlıdır.

Bedeli ise compaction'dır: zamanla biriken SSTable'ların arka planda birleştirilmesi gerekir. Compaction stratejisi tablo bazında seçilir ve iş yüküne göre doğru seçim ciddi fark yaratır:

-- Zaman serisi tablosu için doğru strateji ve otomatik yaşam süresi
ALTER TABLE olcumler
WITH compaction = {
  'class': 'TimeWindowCompactionStrategy',
  'compaction_window_unit': 'DAYS',
  'compaction_window_size': 1
}
AND default_time_to_live = 2592000;  -- 30 gün sonra otomatik silinsin

Şimdi Cassandra'nın en meşhur tuzağına gelelim: tombstone. Cassandra'da bir satırı sildiğinizde veri hemen kaybolmaz; silindiğini belirten bir işaretçi yazılır. Bu işaretçi gc_grace_seconds süresince (varsayılan 10 gün) saklanır, çünkü o süre boyunca kapalı kalmış bir düğüm geri geldiğinde silinmiş veriyi "diriltmemesi" gerekir. Sorun şu ki bir sorgu, sonuçlarına ulaşmak için binlerce tombstone'un üzerinden geçmek zorunda kalırsa okuma gecikmesi patlar ve Cassandra bir eşikten sonra sorguyu tamamen reddeder.

Tombstone birikimini önlemenin en etkili yolu, silmeye dayalı tasarımdan kaçınmaktır. Kuyruk benzeri desenler (yaz–oku–sil) Cassandra için anti-pattern'dir. Bunun yerine TTL kullanın ve zamana göre bölünmüş partition'lar tasarlayın. Ayrıca gc_grace_seconds süresi içinde mutlaka nodetool repair çalıştırın; aksi hâlde silinmiş veriler geri gelebilir.

Cassandra Ne Zaman Doğru Seçim, Ne Zaman Değil#

Cassandra'yı doğru yere koymak, onu doğru kullanmaktan daha önemlidir. Şu profildeki iş yüklerinde gerçekten parlar: yazma hacmi okuma hacmine yakın ya da ondan yüksek olan sistemler; verinin doğal olarak bir kimliğe göre bölünebildiği yapılar (kullanıcı başına zaman çizelgesi, cihaz başına ölçüm, hesap başına işlem kaydı); coğrafi olarak birden fazla veri merkezine yayılması gereken uygulamalar; ve kesintisiz yazma kabiliyetinin anlık tutarlılıktan daha değerli olduğu senaryolar.

Buna karşılık şu durumlarda Cassandra yanlış araçtır: karmaşık JOIN ve raporlama sorguları gerektiren iş zekâsı yükleri; birden fazla tabloyu atomik olarak güncellemesi gereken finansal işlemler; veri hacminin birkaç yüz gigabaytı geçmediği, tek bir PostgreSQL sunucusunun rahatça kaldırabileceği projeler; ve sorgu desenlerinin sürekli değiştiği, henüz oturmamış ürünler. Bu son madde en sinsi olanıdır — Cassandra'da tabloyu sorguya göre tasarladığınız için, sorgu değiştiğinde tabloyu ve veriyi yeniden üretmeniz gerekir.

Karar aşamasındaysanız SQL mi NoSQL mu seçim rehberi yazısındaki karşılaştırma tablosu ve doküman tabanlı alternatif için MongoDB kurulumu yazısı, seçenekleri yan yana görmenizi sağlar. Çoğu projede doğru cevap "hepsi yerine biri" değil, "hangi veri hangi motorda" olur.

Sık Yapılan Hatalar#

Devasa partition oluşturmak açık ara birinci sıradadır. Partition key'i çok geniş seçerseniz (örneğin yalnızca sensor_id, tarih olmadan) tek bir partition yıllar içinde yüz milyonlarca satıra ulaşır. Cassandra bir partition'ı tek düğümde tutar; o düğüm dengesiz yüklenir, okumalar yavaşlar ve compaction devleşir. Pratik hedef, partition başına yüz megabaytın altında kalmaktır — bunu sağlamak için tarihi ya da başka bir "bucket" alanını partition key'e eklersiniz.

Tek düğümlü Cassandra kurup üretime almak ikinci sıradadır. Cassandra tek düğümde MySQL'den daha yavaş, daha karmaşık ve daha az güvenlidir; tüm değeri çokluktan gelir. Replikasyon faktörü 1 olan bir kurulumda düğüm kaybı doğrudan veri kaybıdır. En az üç düğüm ve replikasyon faktörü 3 ile başlayın.

Onarımı (repair) unutmak üçüncüsüdür. Cassandra'da replikalar zamanla birbirinden ayrışır; nodetool repair bu farkı kapatır. gc_grace_seconds süresi içinde onarım yapılmazsa silinmiş kayıtların geri gelmesi teorik değil, gerçek bir sonuçtur. Onarımı zamanlanmış bir işe bağlayın ve çalıştığını izleyin.

Sorgu tasarımını sonraya bırakmak dördüncüsüdür. İlişkisel dünyada önce veriyi modeller, sonra sorguyu yazarsınız. Cassandra'da sırayı tersine çevirmeniz gerekir: önce uygulamanın hangi sorguları yapacağını listeleyin, sonra her sorgu için bir tablo tasarlayın. Aynı veriyi üç tabloya yazmak burada israf değil, doğru yöntemdir.

Sıkça Sorulan Sorular#

Cassandra ücretsiz mi#

Apache Cassandra, Apache 2.0 lisansıyla dağıtılan tamamen açık kaynaklı ve ücretsiz bir projedir; kurulum, düğüm sayısı ya da veri hacmi üzerinde herhangi bir lisans kısıtı yoktur. Ücretli olan taraf, çeşitli firmaların sunduğu yönetilen hizmetler ve kurumsal destek paketleridir. Kendi sunucularınızda kurup çalıştırdığınızda ödeyeceğiniz tek maliyet donanım ve işletim emeğidir; ancak bu emeğin küçümsenmemesi gerekir, çünkü küme işletmek tek sunuculu bir veritabanından belirgin biçimde daha fazla bakım ister.

Cassandra için kaç sunucu gerekir#

Üretim için pratik alt sınır üç düğümdür. Bunun sebebi replikasyon faktörü 3 ile QUORUM tutarlılık seviyesinin bir düğüm kaybına dayanabilmesidir; iki düğümle bu matematik çalışmaz. Üç düğüm size bir sunucu bakıma alındığında bile kesintisiz okuma ve yazma verir. Birden fazla veri merkezine yayılacaksanız her veri merkezinde en az üç düğüm bulundurmanız gerekir, yani toplam altı sunucuyla başlarsınız.

Cassandra ile MySQL arasındaki temel fark nedir#

MySQL tek bir sunucuda güçlü tutarlılık, JOIN desteği ve esnek sorgulama sunar; ölçeklenmesi için replikasyon ve elle sharding gerekir. Cassandra ise ölçeklenmeyi baştan varsayar, sunucu ekleyerek doğrusal büyür ve tek nokta arızası içermez; buna karşılık JOIN yoktur, sorgular partition key'e bağlıdır ve tutarlılık modeli ayarlanabilir olmakla birlikte varsayılan olarak gevşektir. Kabaca söylemek gerekirse MySQL esnekliği, Cassandra ölçeklenebilirliği önceler.

ALLOW FILTERING kullanmak neden kötü#

ALLOW FILTERING, Cassandra'ya "partition key olmadan da olsa bu sorguyu çalıştır" demektir. Bu durumda sorgu kümedeki tüm düğümlere gider ve her düğüm kendi verisini baştan sona tarar. Küçük test verisiyle anında dönen bu sorgu, üretim hacminde saniyeler hatta dakikalar sürer ve tüm kümenin kaynaklarını tüketir. Doğru çözüm, o sorgu deseni için ayrı bir tablo oluşturup veriyi yazma anında oraya da yazmaktır.

Cassandra'da yedekleme nasıl yapılır#

Cassandra'nın yerleşik yöntemi anlık görüntüdür: nodetool snapshot komutu SSTable dosyalarının sabit disk bağlantılarını (hard link) oluşturur ve bu dizini bir yedek deposuna kopyalarsınız. Ek olarak incremental_backups ayarını açarak yeni oluşan SSTable'ları da toplayabilirsiniz. Kritik nokta, yedeğin tüm düğümlerde eşzamanlı alınması ve geri yükleme prosedürünün önceden denenmiş olmasıdır; küme genelinde tutarlı bir geri dönüş, tek bir dosyayı geri kopyalamaktan daha karmaşıktır.

Küçük bir proje için Cassandra kullanmalı mıyım#

Büyük olasılıkla hayır. Verinizin toplam boyutu birkaç yüz gigabaytın altındaysa, yazma hacminiz tek bir sunucunun kaldırabileceği düzeydeyse ve sorgularınız hâlâ değişiyorsa PostgreSQL ya da MySQL sizi çok daha hızlı ilerletir. Cassandra'nın işletim maliyeti (küme izleme, onarım zamanlaması, compaction ayarı, sürüm yükseltmeleri) küçük ekipler için ciddi bir yüktür. Cassandra'yı, ölçeklenme sorununu gerçekten yaşadığınızda ve sorgu desenleriniz oturduğunda düşünün.

Kapanış#

Cassandra, doğru problemi çözdüğünde eşi az bulunan bir araç: sunucu ekleyerek büyüyen, tek nokta arızası olmayan, coğrafi dağıtıma doğal biçimde uyan bir yazma makinesi. Ancak bu gücü alabilmek için dört alışkanlığı baştan benimsemeniz gerekiyor: tabloları sorgulara göre tasarlayın ve gerektiğinde aynı veriyi birden fazla tabloya yazın; partition'ları makul boyutta tutacak şekilde partition key'e zaman ya da bucket alanı ekleyin; tutarlılık seviyelerini bilinçli seçin ve okuma artı yazma toplamının replikasyon faktörünü aştığından emin olun; ve onarımı zamanlanmış bir iş hâline getirip tombstone birikimini izleyin.

Kendi Cassandra kümenizi kurmayı planlıyorsanız düğüm başına ayrılmış kaynak ve hızlı disk kritik önemdedir; VDS ile başlayıp büyüdükçe dedicated sunucu tarafına geçebilir, esneklik istiyorsanız bulut sunucu paketlerini değerlendirebilirsiniz. Küme kurulumunu, izlemeyi ve düzenli onarım zamanlamasını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu operasyonel yükü devralabilir.