trustgraph/docs/tech-specs/cassandra-performance-refactor.tr.md

layout	title	parent
default	Teknik Özellikler: Cassandra Bilgi Tabanı Performans Yenilemesi	Turkish (Beta)

Teknik Özellikler: Cassandra Bilgi Tabanı Performans Yenilemesi

Beta Translation: This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

Durum: Taslak Yazar: Yardımcı Tarih: 2025-09-18

Genel Bakış

Bu özellik, TrustGraph Cassandra bilgi tabanı uygulamasındaki performans sorunlarına değinmekte ve RDF üçlü depolama ve sorgulama için optimizasyonlar önermektedir.

Mevcut Uygulama

Şema Tasarımı

Mevcut uygulama, trustgraph-flow/trustgraph/direct/cassandra_kg.py'da tek bir tablo tasarımı kullanmaktadır:

CREATE TABLE triples (
    collection text,
    s text,
    p text,
    o text,
    PRIMARY KEY (collection, s, p, o)
);

İkincil İndeksler: triples_s ON s (özne) triples_p ON p (yüklem) triples_o ON o (nesne)

Sorgu Desenleri

Mevcut uygulama, 8 farklı sorgu desenini desteklemektedir:

1. get_all(collection, limit=50) - Bir koleksiyon için tüm üçlüleri getirir.

   SELECT s, p, o FROM triples WHERE collection = ? LIMIT 50
   

2. get_s(collection, s, limit=10) - Konuya göre sorgulama

   SELECT p, o FROM triples WHERE collection = ? AND s = ? LIMIT 10
   

3. get_p(collection, p, limit=10) - Öznitelik kullanarak sorgulama

   SELECT s, o FROM triples WHERE collection = ? AND p = ? LIMIT 10
   

4. get_o(collection, o, limit=10) - Nesneye göre sorgulama

   SELECT s, p FROM triples WHERE collection = ? AND o = ? LIMIT 10
   

5. get_sp(collection, s, p, limit=10) - Konu + yüklem ile sorgulama

   SELECT o FROM triples WHERE collection = ? AND s = ? AND p = ? LIMIT 10
   

6. get_po(collection, p, o, limit=10) - Öznitelik + nesneye göre sorgulama ⚠️

   SELECT s FROM triples WHERE collection = ? AND p = ? AND o = ? LIMIT 10 ALLOW FILTERING
   

7. get_os(collection, o, s, limit=10) - Nesne + konu ile sorgulama ⚠️

   SELECT p FROM triples WHERE collection = ? AND o = ? AND s = ? LIMIT 10 ALLOW FILTERING
   

8. get_spo(collection, s, p, o, limit=10) - Tam üçlü eşleşme

   SELECT s as x FROM triples WHERE collection = ? AND s = ? AND p = ? AND o = ? LIMIT 10
   

Mevcut Mimari

Dosya: trustgraph-flow/trustgraph/direct/cassandra_kg.py Tüm işlemleri yöneten tek KnowledgeGraph sınıfı Küresel _active_clusters listesi aracılığıyla bağlantı havuzu Sabit tablo adı: "triples" Kullanıcı modeli başına keyspace Faktörü 1 olan SimpleStrategy replikasyonu

Entegrasyon Noktaları: Yazma Yolu: trustgraph-flow/trustgraph/storage/triples/cassandra/write.py Sorgu Yolu: trustgraph-flow/trustgraph/query/triples/cassandra/service.py Bilgi Deposu: trustgraph-flow/trustgraph/tables/knowledge.py

Tespit Edilen Performans Sorunları

Şema Seviyesi Sorunlar

1. Verimsiz Birincil Anahtar Tasarımı Mevcut: PRIMARY KEY (collection, s, p, o) Sık erişim kalıpları için zayıf kümelenmeye neden olur Pahalı ikincil indeks kullanımını zorlar

2. İkincil İndeks Aşırı Kullanımı ⚠️ Yüksek kardinaliteli sütunlarda (s, p, o) üç ikincil indeks Cassandra'daki ikincil indeksler pahalıdır ve iyi ölçeklenmez 6 ve 7 numaralı sorgular ALLOW FILTERING gerektirir, bu da zayıf veri modellemesini gösterir

3. Sıcak Bölüm Riski Tek bölüm anahtarı collection, sıcak bölümlere neden olabilir Büyük koleksiyonlar tek düğümlere yoğunlaşacaktır Yük dengeleme için dağıtım stratejisi yoktur

Sorgu Seviyesi Sorunlar

1. ALLOW FILTERING Kullanımı ⚠️ İki sorgu türü (get_po, get_os) ALLOW FILTERING gerektirir Bu sorgular birden fazla bölümü tarar ve son derece pahalıdır Performans, veri boyutuyla doğrusal olarak düşer

2. Verimsiz Erişim Kalıpları Yaygın RDF sorgu kalıpları için optimizasyon yoktur Sık sorgu kombinasyonları için bileşik indeksler eksiktir Grafik geçiş kalıpları dikkate alınmamıştır

3. Sorgu Optimizasyonu Eksikliği Hazırlanmış ifade önbelleği yok Sorgu ipuçları veya optimizasyon stratejileri yok Basit LIMIT'in ötesinde sayfalama dikkate alınmamıştır

Problem Tanımı

Mevcut Cassandra bilgi tabanı uygulaması, iki kritik performans darboğazına sahiptir:

1. Verimsiz get_po Sorgusu Performansı

get_po(collection, p, o) sorgusu, ALLOW FILTERING gerektirdiği için son derece verimsizdir:

SELECT s FROM triples WHERE collection = ? AND p = ? AND o = ? LIMIT 10 ALLOW FILTERING

Neden bunun sorunlu olduğu: ALLOW FILTERING, Cassandra'nın koleksiyon içindeki tüm bölümleri taramasını zorlar. Performans, veri boyutuyla doğrusal olarak düşer. Bu, yaygın bir RDF sorgu desenidir (belirli bir öznelik-nesne ilişkisine sahip konuları bulmak). Veri büyüdükçe kümede önemli bir yük oluşturur.

2. Kötü Kümeleme Stratejisi

Mevcut birincil anahtar PRIMARY KEY (collection, s, p, o), minimum kümeleme faydası sağlar:

Mevcut kümeleme ile ilgili sorunlar: Bölüm anahtarı olarak collection, verileri etkili bir şekilde dağıtmaz. Çoğu koleksiyon, kümelemeyi etkisiz hale getiren çeşitli veriler içerir. RDF sorgularındaki yaygın erişim kalıpları dikkate alınmamıştır. Büyük koleksiyonlar, tek düğümlerde "sıcak" bölümler oluşturur. Kümeleme sütunları (s, p, o), tipik grafik geçiş kalıpları için optimize edilmemiştir.

Etkisi: Sorgular, veri yerelliğinden faydalanmaz. Kötü önbellek kullanımı. Küme düğümleri arasında düzensiz yük dağılımı. Koleksiyonlar büyüdükçe ölçeklenebilirlik darboğazları.

Önerilen Çözüm: 4-Tablolu Normalizasyon Stratejisi

Genel Bakış

Tek triples tablosunu, belirli sorgu kalıpları için optimize edilmiş dört özel amaçlı tabloyla değiştirin. Bu, ikincil dizinlere ve ALLOW FILTERING'e olan ihtiyacı ortadan kaldırırken, tüm sorgu türleri için optimum performans sağlar. Dördüncü tablo, bileşik bölüm anahtarlarına rağmen verimli koleksiyon silme olanağı sağlar.

Yeni Şema Tasarımı

Tablo 1: Konu Odaklı Sorgular (triples_s)

CREATE TABLE triples_s (
    collection text,
    s text,
    p text,
    o text,
    PRIMARY KEY ((collection, s), p, o)
);

Optimize eder: get_s, get_sp, get_os Bölüm Anahtarı: (collection, s) - Yalnızca collection'dan daha iyi dağılım sağlar Kümeleme: (p, o) - Bir konu için verimli öznelik/nesne aramalarını sağlar

Tablo 2: Öznelik-Nesne Sorguları (triples_p)

CREATE TABLE triples_p (
    collection text,
    p text,
    o text,
    s text,
    PRIMARY KEY ((collection, p), o, s)
);

Optimize eder: get_p, get_po (ALLOW FILTERING özelliğini ortadan kaldırır!) Bölüm Anahtarı: (collection, p) - Öznitelik yoluyla doğrudan erişim Kümeleme: (o, s) - Verimli nesne-özne geçişi

Tablo 3: Nesne Odaklı Sorgular (triples_o)

CREATE TABLE triples_o (
    collection text,
    o text,
    s text,
    p text,
    PRIMARY KEY ((collection, o), s, p)
);

Optimize eder: get_o Bölüm Anahtarı: (collection, o) - Nesneye doğrudan erişim Kümeleme: (s, p) - Verimli özne-yüklem geçişi

Tablo 4: Koleksiyon Yönetimi ve SPO Sorguları (triples_collection)

CREATE TABLE triples_collection (
    collection text,
    s text,
    p text,
    o text,
    PRIMARY KEY (collection, s, p, o)
);

Optimize eder: get_spo, delete_collection Bölüm Anahtarı: sadece koleksiyon - Verimli koleksiyon seviyesindeki işlemleri sağlar. Kümeleme: (s, p, o) - Standart üçlü sıralama Amaç: Hem tam SPO aramaları için hem de silme indeksi olarak çift amaçlı kullanım.

Sorgu Eşlemesi

Orijinal Sorgu	Hedef Tablo	Performans İyileştirmesi
get_all(collection)	triples_s	FİLTRELEME İZNİ VERİLEBİLİR (taramaya uygun)
get_s(collection, s)	triples_s	Doğrudan bölüm erişimi
get_p(collection, p)	triples_p	Doğrudan bölüm erişimi
get_o(collection, o)	triples_o	Doğrudan bölüm erişimi
get_sp(collection, s, p)	triples_s	Bölüm + kümeleme
get_po(collection, p, o)	triples_p	Artık FİLTRELEME İZNİ YOK!
get_os(collection, o, s)	triples_o	Bölüm + kümeleme
get_spo(collection, s, p, o)	triples_collection	Tam anahtar araması
delete_collection(collection)	triples_collection	İndeksi oku, tümünü toplu olarak sil

Koleksiyon Silme Stratejisi

Birleşik bölüm anahtarlarıyla, DELETE FROM table WHERE collection = ?'ı doğrudan çalıştıramayız. Bunun yerine:

1. Okuma Aşaması: Tüm üçlüleri saymak için triples_collection sorgusunu kullanın:

   SELECT s, p, o FROM triples_collection WHERE collection = ?
   

   Bu, collection'ın bu tablo için bölümleme anahtarı olması nedeniyle verimlidir.

2. Silme Aşaması: Her (s, p, o) üçlüsü için, tüm 4 tablodan, tam bölümleme anahtarlarını kullanarak silin:

   DELETE FROM triples_s WHERE collection = ? AND s = ? AND p = ? AND o = ?
   DELETE FROM triples_p WHERE collection = ? AND p = ? AND o = ? AND s = ?
   DELETE FROM triples_o WHERE collection = ? AND o = ? AND s = ? AND p = ?
   DELETE FROM triples_collection WHERE collection = ? AND s = ? AND p = ? AND o = ?
   

   Verimlilik için 100'lük gruplar halinde işlenir.

Ayrılık Analizi: ✅ Dağıtılmış bölümlerle optimum sorgu performansını korur. ✅ Büyük koleksiyonlar için "sıcak" bölümler yoktur. ❌ Daha karmaşık silme mantığı (okuyup sonra sil). ❌ Silme süresi, koleksiyon boyutuna orantılıdır.

Avantajlar

1. ALLOW FILTERING'i ortadan kaldırır - Her sorgunun optimum bir erişim yolu vardır (get_all taraması hariç).
2. İkincil İndeks Yok - Her tablo, kendi sorgu deseninin indeksidir.
3. Daha İyi Veri Dağılımı - Bileşik bölüm anahtarları, yükü etkili bir şekilde dağıtır.
4. Öngörülebilir Performans - Sorgu süresi, toplam veriye değil, sonuç boyutuna orantılıdır.
5. Cassandra'nın Güçlerinden Yararlanır - Cassandra'nın mimarisi için tasarlanmıştır.
6. Koleksiyon Silme İşlemini Etkinleştirir - triples_collection, silme indeksi olarak hizmet eder.

Uygulama Planı

Değiştirilmesi Gereken Dosyalar

Birincil Uygulama Dosyası

trustgraph-flow/trustgraph/direct/cassandra_kg.py - Tamamen yeniden yazılması gerekir.

Yeniden Düzenlenmesi Gereken Mevcut Yöntemler:

# Schema initialization
def init(self) -> None  # Replace single table with three tables

# Insert operations
def insert(self, collection, s, p, o) -> None  # Write to all three tables

# Query operations (API unchanged, implementation optimized)
def get_all(self, collection, limit=50)      # Use triples_by_subject
def get_s(self, collection, s, limit=10)     # Use triples_by_subject
def get_p(self, collection, p, limit=10)     # Use triples_by_po
def get_o(self, collection, o, limit=10)     # Use triples_by_object
def get_sp(self, collection, s, p, limit=10) # Use triples_by_subject
def get_po(self, collection, p, o, limit=10) # Use triples_by_po (NO ALLOW FILTERING!)
def get_os(self, collection, o, s, limit=10) # Use triples_by_subject
def get_spo(self, collection, s, p, o, limit=10) # Use triples_by_subject

# Collection management
def delete_collection(self, collection) -> None  # Delete from all three tables

Entegrasyon Dosyaları (Herhangi Bir Mantıksal Değişiklik Gerekmiyor)

trustgraph-flow/trustgraph/storage/triples/cassandra/write.py Herhangi bir değişiklik gerekmiyor - mevcut KnowledgeGraph API'sini kullanır. Performans iyileştirmelerinden otomatik olarak faydalanır.

trustgraph-flow/trustgraph/query/triples/cassandra/service.py Herhangi bir değişiklik gerekmiyor - mevcut KnowledgeGraph API'sini kullanır. Performans iyileştirmelerinden otomatik olarak faydalanır.

Güncelleme Gerektiren Test Dosyaları

Birim Testleri

tests/unit/test_storage/test_triples_cassandra_storage.py Şema değişiklikleri için test beklentilerini güncelleyin. Çok tablolu tutarlılık için testler ekleyin. Sorgu planlarında ALLOW FILTERING kullanımını doğrulayın.

tests/unit/test_query/test_triples_cassandra_query.py Performans doğrulama ifadelerini güncelleyin. Tüm 8 sorgu desenini yeni tablolara karşı test edin. Sorgu yönlendirmesinin doğru tablolara yapıldığını doğrulayın.

Entegrasyon Testleri

tests/integration/test_cassandra_integration.py Yeni şemayla uçtan uca testler. Performans karşılaştırma ölçümleri. Tablolar arasındaki veri tutarlılığının doğrulanması.

tests/unit/test_storage/test_cassandra_config_integration.py Şema doğrulama testlerini güncelleyin. Geçiş senaryolarını test edin.

Uygulama Stratejisi

1. Aşama: Şema ve Temel Yöntemler

1. init() yöntemini yeniden yazın - Dört tablo oluşturun, bir yerine.
2. insert() yöntemini yeniden yazın - Tüm dört tabloya toplu yazma işlemleri.
3. Hazırlanmış ifadeleri uygulayın - Optimum performans için.
4. Tablo yönlendirme mantığını ekleyin - Sorguları en uygun tablolara yönlendirin.
5. Toplu silme işlemini uygulayın - triples_collection'dan okuyun, tüm tablolardan toplu olarak silin.

2. Aşama: Sorgu Yöntemi Optimizasyonu

1. Her get_ yöntemini yeniden yazın* - En uygun tabloyu kullanmak için.
2. Tüm ALLOW FILTERING kullanımını kaldırın.
3. Verimli kümeleme anahtar kullanımı uygulayın.
4. Sorgu performansını kaydetme özelliğini ekleyin.

3. Aşama: Koleksiyon Yönetimi

1. delete_collection()'ı güncelleyin - Tüm üç tablodan kaldırın.
2. Tutarlılık doğrulamasını ekleyin - Tüm tabloların senkronize kalmasını sağlayın.
3. Toplu işlemleri uygulayın - Atomik çok tablolu işlemler için.

Önemli Uygulama Detayları

Toplu Yazma Stratejisi

def insert(self, collection, s, p, o):
    batch = BatchStatement()

    # Insert into all four tables
    batch.add(self.insert_subject_stmt, (collection, s, p, o))
    batch.add(self.insert_po_stmt, (collection, p, o, s))
    batch.add(self.insert_object_stmt, (collection, o, s, p))
    batch.add(self.insert_collection_stmt, (collection, s, p, o))

    self.session.execute(batch)

Sorgu Yönlendirme Mantığı

def get_po(self, collection, p, o, limit=10):
    # Route to triples_p table - NO ALLOW FILTERING!
    return self.session.execute(
        self.get_po_stmt,
        (collection, p, o, limit)
    )

def get_spo(self, collection, s, p, o, limit=10):
    # Route to triples_collection table for exact SPO lookup
    return self.session.execute(
        self.get_spo_stmt,
        (collection, s, p, o, limit)
    )

Koleksiyon Silme Mantığı

def delete_collection(self, collection):
    # Step 1: Read all triples from collection table
    rows = self.session.execute(
        f"SELECT s, p, o FROM {self.collection_table} WHERE collection = %s",
        (collection,)
    )

    # Step 2: Batch delete from all 4 tables
    batch = BatchStatement()
    count = 0

    for row in rows:
        s, p, o = row.s, row.p, row.o

        # Delete using full partition keys for each table
        batch.add(SimpleStatement(
            f"DELETE FROM {self.subject_table} WHERE collection = ? AND s = ? AND p = ? AND o = ?"
        ), (collection, s, p, o))

        batch.add(SimpleStatement(
            f"DELETE FROM {self.po_table} WHERE collection = ? AND p = ? AND o = ? AND s = ?"
        ), (collection, p, o, s))

        batch.add(SimpleStatement(
            f"DELETE FROM {self.object_table} WHERE collection = ? AND o = ? AND s = ? AND p = ?"
        ), (collection, o, s, p))

        batch.add(SimpleStatement(
            f"DELETE FROM {self.collection_table} WHERE collection = ? AND s = ? AND p = ? AND o = ?"
        ), (collection, s, p, o))

        count += 1

        # Execute every 100 triples to avoid oversized batches
        if count % 100 == 0:
            self.session.execute(batch)
            batch = BatchStatement()

    # Execute remaining deletions
    if count % 100 != 0:
        self.session.execute(batch)

    logger.info(f"Deleted {count} triples from collection {collection}")

Hazırlanmış İfade Optimizasyonu

def prepare_statements(self):
    # Cache prepared statements for better performance
    self.insert_subject_stmt = self.session.prepare(
        f"INSERT INTO {self.subject_table} (collection, s, p, o) VALUES (?, ?, ?, ?)"
    )
    self.insert_po_stmt = self.session.prepare(
        f"INSERT INTO {self.po_table} (collection, p, o, s) VALUES (?, ?, ?, ?)"
    )
    self.insert_object_stmt = self.session.prepare(
        f"INSERT INTO {self.object_table} (collection, o, s, p) VALUES (?, ?, ?, ?)"
    )
    self.insert_collection_stmt = self.session.prepare(
        f"INSERT INTO {self.collection_table} (collection, s, p, o) VALUES (?, ?, ?, ?)"
    )
    # ... query statements

Göç Stratejisi

Veri Göç Yaklaşımı

Seçenek 1: Mavi-Yeşil Dağıtım (Önerilen)

1. Yeni şemayı mevcut olanın yanında dağıtın - Geçici olarak farklı tablo adları kullanın
2. Çift yazma dönemi - Geçiş sırasında hem eski hem de yeni şemalara yazın
3. Arka planda veri taşıma - Mevcut verileri yeni tablolara kopyalayın
4. Okuma yönlendirmesini değiştirin - Veriler taşındıktan sonra sorguları yeni tablolara yönlendirin
5. Eski tabloları kaldırın - Doğrulama süresinden sonra

Seçenek 2: Yerinde Göç

1. Şema ekleme - Yeni tabloları mevcut anahtar uzayında oluşturun
2. Veri taşıma betiği - Eski tablodan yeni tablolara toplu olarak veri kopyalayın
3. Uygulama güncellemesi - Göç tamamlandıktan sonra yeni kodu dağıtın
4. Eski tablo temizliği - Eski tabloyu ve indeksleri kaldırın

Geriye Dönük Uyumluluk

Dağıtım Stratejisi

# Environment variable to control table usage during migration
USE_LEGACY_TABLES = os.getenv('CASSANDRA_USE_LEGACY', 'false').lower() == 'true'

class KnowledgeGraph:
    def __init__(self, ...):
        if USE_LEGACY_TABLES:
            self.init_legacy_schema()
        else:
            self.init_optimized_schema()

Göç Script'i

def migrate_data():
    # Read from old table
    old_triples = session.execute("SELECT collection, s, p, o FROM triples")

    # Batch write to new tables
    for batch in batched(old_triples, 100):
        batch_stmt = BatchStatement()
        for row in batch:
            # Add to all three new tables
            batch_stmt.add(insert_subject_stmt, row)
            batch_stmt.add(insert_po_stmt, (row.collection, row.p, row.o, row.s))
            batch_stmt.add(insert_object_stmt, (row.collection, row.o, row.s, row.p))
        session.execute(batch_stmt)

Doğrulama Stratejisi

Veri Tutarlılık Kontrolleri

def validate_migration():
    # Count total records in old vs new tables
    old_count = session.execute("SELECT COUNT(*) FROM triples WHERE collection = ?", (collection,))
    new_count = session.execute("SELECT COUNT(*) FROM triples_by_subject WHERE collection = ?", (collection,))

    assert old_count == new_count, f"Record count mismatch: {old_count} vs {new_count}"

    # Spot check random samples
    sample_queries = generate_test_queries()
    for query in sample_queries:
        old_result = execute_legacy_query(query)
        new_result = execute_optimized_query(query)
        assert old_result == new_result, f"Query results differ for {query}"

Test Stratejisi

Performans Testi

Benchmark Senaryoları

1. Sorgu Performansı Karşılaştırması Tüm 8 sorgu türü için performans metrikleri (önce/sonra) get_po performans iyileştirmesine odaklanın (ALLOW FILTERING'i kaldırın) Çeşitli veri boyutları altında sorgu gecikmesini ölçün

2. Yük Testi Eşzamanlı sorgu yürütme Toplu işlemlerle yazma hızı Bellek ve CPU kullanımı

3. Ölçeklenebilirlik Testi Artan koleksiyon boyutlarıyla performans Çoklu koleksiyon sorgu dağıtımı Küme düğümü kullanımı

Test Veri Kümeleri

Küçük: Koleksiyon başına 10K üçlü Orta: Koleksiyon başına 100K üçlü Büyük: Koleksiyon başına 1M+ üçlü Çoklu koleksiyonlar: Test bölüm dağıtımı

Fonksiyonel Test

Birim Testi Güncellemeleri

# Example test structure for new implementation
class TestCassandraKGPerformance:
    def test_get_po_no_allow_filtering(self):
        # Verify get_po queries don't use ALLOW FILTERING
        with patch('cassandra.cluster.Session.execute') as mock_execute:
            kg.get_po('test_collection', 'predicate', 'object')
            executed_query = mock_execute.call_args[0][0]
            assert 'ALLOW FILTERING' not in executed_query

    def test_multi_table_consistency(self):
        # Verify all tables stay in sync
        kg.insert('test', 's1', 'p1', 'o1')

        # Check all tables contain the triple
        assert_triple_exists('triples_by_subject', 'test', 's1', 'p1', 'o1')
        assert_triple_exists('triples_by_po', 'test', 'p1', 'o1', 's1')
        assert_triple_exists('triples_by_object', 'test', 'o1', 's1', 'p1')

Entegrasyon Testi Güncellemeleri

class TestCassandraIntegration:
    def test_query_performance_regression(self):
        # Ensure new implementation is faster than old
        old_time = benchmark_legacy_get_po()
        new_time = benchmark_optimized_get_po()
        assert new_time < old_time * 0.5  # At least 50% improvement

    def test_end_to_end_workflow(self):
        # Test complete write -> query -> delete cycle
        # Verify no performance degradation in integration

Geri Alma Planı

Hızlı Geri Alma Stratejisi

1. Ortam değişkeni geçişi - Eski tablolara hemen geri dönün.
2. Eski tablolara devam edin - Performans kanıtlanana kadar silmeyin.
3. İzleme uyarıları - Hata oranlarına/gecikmelere göre otomatik geri alma tetikleyicileri.

Geri Alma Doğrulama

def rollback_to_legacy():
    # Set environment variable
    os.environ['CASSANDRA_USE_LEGACY'] = 'true'

    # Restart services to pick up change
    restart_cassandra_services()

    # Validate functionality
    run_smoke_tests()

Riskler ve Dikkat Edilmesi Gerekenler

Performans Riskleri

Yazma gecikmesi artışı - Her eklemeye 4 yazma işlemi (3 tablolu yaklaşıma göre %33 daha fazla) Depolama alanı kullanımı - 4 kat daha fazla depolama alanı gereksinimi (3 tablolu yaklaşıma göre %33 daha fazla) Toplu yazma hataları - Uygun hata yönetimi gereklidir Silme karmaşıklığı - Koleksiyon silme işlemi, okuma-sonra-silme döngüsü gerektirir

İşletim Riskleri

Geçiş karmaşıklığı - Büyük veri kümeleri için veri geçişi Tutarlılık sorunları - Tüm tabloların senkronize olduğundan emin olmak İzleme eksiklikleri - Çok tablolu işlemler için yeni metrikler gereklidir

Azaltma Stratejileri

1. Aşamalı dağıtım - Küçük koleksiyonlarla başlayın
2. Kapsamlı izleme - Tüm performans metriklerini takip edin
3. Otomatik doğrulama - Sürekli tutarlılık kontrolü
4. Hızlı geri alma yeteneği - Ortam tabanlı tablo seçimi

Başarı Kriterleri

Performans İyileştirmeleri

[ ] ALLOW FILTERING'i ortadan kaldırın - get_po ve get_os sorguları filtreleme olmadan çalışır [ ] Sorgu gecikmesi azaltma - Sorgu yanıt sürelerinde %50 veya daha fazla iyileşme [ ] Daha iyi yük dağılımı - Hiçbir "sıcak" bölüm yok, küme düğümleri arasında eşit yük dağılımı [ ] Ölçeklenebilir performans - Sorgu süresi, toplam veri miktarı yerine sonuç büyüklüğüne orantılı

Fonksiyonel Gereksinimler

[ ] API uyumluluğu - Tüm mevcut kod, herhangi bir değişiklik olmadan çalışmaya devam eder [ ] Veri tutarlılığı - Tüm üç tablo senkronize kalır [ ] Sıfır veri kaybı - Geçiş, tüm mevcut üçlüleri korur [ ] Geriye dönme uyumluluğu - Eski şemaya geri dönme yeteneği

İşletim Gereksinimleri

[ ] Güvenli geçiş - Geri alma yeteneği olan mavi-yeşil dağıtım [ ] İzleme kapsamı - Çok tablolu işlemler için kapsamlı metrikler [ ] Test kapsamı - Tüm sorgu kalıpları, performans kıyaslamalarıyla test edilmiştir [ ] Belgeleme - Güncellenmiş dağıtım ve işletim prosedürleri

Zaman Çizelgesi

1. Aşama: Uygulama

[ ] cassandra_kg.py'ı çok tablolu şemayla yeniden yazın [ ] Toplu yazma işlemlerini uygulayın [ ] Hazırlanmış ifade optimizasyonunu ekleyin [ ] Birim testlerini güncelleyin

2. Aşama: Entegrasyon Testi

[ ] Entegrasyon testlerini güncelleyin [ ] Performans kıyaslaması [ ] Gerçekçi veri hacimleriyle yük testi [ ] Veri tutarlılığı için doğrulama betikleri

3. Aşama: Geçiş Planlaması

[ ] Mavi-yeşil dağıtım betikleri [ ] Veri geçiş araçları [ ] İzleme panosu güncellemeleri [ ] Geri alma prosedürleri

4. Aşama: Üretim Dağıtımı

[ ] Üretime aşamalı dağıtım [ ] Performans izleme ve doğrulama [ ] Eski tabloların temizlenmesi [ ] Belgeleme güncellemeleri

Sonuç

Bu çok tablolu normalleştirme stratejisi, doğrudan iki kritik performans darboğazını ele almaktadır:

1. Pahalı ALLOW FILTERING'i ortadan kaldırır ve her sorgu kalıbı için optimum tablo yapıları sağlar.
2. Kompozit bölüm anahtarları aracılığıyla kümeleme etkinliğini artırır ve yükü düzgün bir şekilde dağıtır.

Bu yaklaşım, Cassandra'nın güçlü yönlerinden yararlanırken, mevcut kodun performans iyileştirmelerinden otomatik olarak yararlanmasını sağlayan tam API uyumluluğunu korur.