MySQL recursive CTE, C# BFS ve NebulaGraph: 500 milyon satırda karşılaştırma

Bir ekip, ilişki yoğun sistemini MySQL'de tutmaktan graf veritabanlarına geçirirken, yaklaşık 500 milyon satırda MySQL recursive CTE'nin çöktüğünü anlatıyor. Yazar aynı veride üç yaklaşımı karşılaştıran tekrarlanabilir bir benchmark hazırladı. Sonuçlar, sorunun veritabanının kendisinden çok CTE'nin tasarımından kaynaklandığını gösteriyor.

Kilit noktalar

• Recursive CTE, aynı düğümü farklı derinliklerde tekrar genişlettiği için 500M satırda ilişki sorgusunu 15 dakikada da yanıtlayamadı.
• Aynı MySQL tablolarında C# ile yazılan çift yönlü BFS, ilişki sorgusunda 500M satırda 2,7 ms'de yanıt verdi.
• Hub düğümlerden kaçınan sorgu, nGQL'de WHERE NOT "hub" IN tags($$) ile doğru sonuç vermedi; yazar bunu uygulama tarafında BFS ile çözdü.
• Benchmark kodu ve ham sonuçlar GitHub'da yayımlanmış; kendi makinenizde yeniden çalıştırabilirsiniz.
• Tüm grafı gezen sorgularda NebulaGraph, C# BFS'e göre 1,8 ile 3,5 kat daha hızlı çıktı.

Yazar, üç yıl önce SQL tabloları üzerine kurduğu graf benzeri sistemin 500 milyon satırda çöktüğünü ve tek bir ilişki sorgusunun yaklaşık 15 dakika sürdüğünü anlatıyor. Sonrasında sistemi ArangoDB, Neo4j ve NebulaGraph'a taşımış. Bu yazıda ise aynı veriyi MySQL 8.4 ve NebulaGraph 3.8 üzerinde yükleyen, her cevabı karşılaştırıp zamanlamaya öyle geçen tekrarlanabilir bir benchmark sunuluyor.

Asıl bulgu şu: recursive CTE her derinlikte aynı düğümleri yeniden genişletiyor ve hedef düğüm bulunsa bile durmadan komşuluğun tamamını kuruyor. Aynı MySQL tablolarında çalışan, C# ile yazılmış çift yönlü BFS ise her boyutta milisaniyeler içinde yanıt verdi ve çoğu durumda NebulaGraph'tan daha hızlıydı. Hub düğümlerin olduğu grafta ise NebulaGraph, tüm grafı gezen sorgularda öne geçiyor; ancak hub'lardan kaçınmak gereken sorgu tek bir nGQL ifadesiyle doğru yazılamadı.

Gerçek dünyada kullanımı

• Hesap veya cihaz ilişkilerinde dolandırıcılık tespiti yapan, iki düğüm arasındaki en kısa yolu bulması gereken bir servis.
• Hub değerleri (varsayılan telefon numarası gibi) yüzünden her aramanın grafın tamamını gezdiği bir kimlik grafı.
• Mevcut MySQL veritabanını koruyup yalnızca çok adımlı ilişki sorgularını uygulama katmanında yeniden yazmak isteyen bir ekip.

Neden önemli

Çok adımlı ilişki sorgularında veritabanı motorunu değiştirmeden önce sorgunun algoritmasını gözden geçirmek gerekir. Bu benchmark, recursive CTE'nin ölçek sorununun büyük kısmını açıklıyor.

Benzer haberler

• C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıDLNick Cosentino (Dev Leader)2 gün önce
• NebulaGraph'a .NET'ten idempotent toplu yükleme: VID ile çoğaltma sorunuDVDEV Community: #csharp3 gün önce
• C# olayları ve delegate'ler: sözleşme, abonelik ve bildirimDLNick Cosentino (Dev Leader)3 gün önce