Apache AGE ile Grafik Tabanlı Video İlişki Sorguları Oluşturmak
En maliyetli sorgumuz, basit bir "ilgili videoları göster" paneliydi.
ViralVidVault'ta video trendlerini takip ediyoruz. Paylaşılan kanallar veya birlikte izlenen oturumlar aracılığıyla ilgili videoları bulmanın veritabanı performansımızı bitirdiğini fark ettik. SQLite'ı özyinelemeli (recursive) join'ler ile kullanmayı denedik. Tek bir adımda (one hop) işe yarıyordu. Ancak iki adımda veri patlaması yaşandı. Tek bir sorgu yüz binlerce satır oluşturuyordu. İşleyicilerimiz (workers) zaman aşımına uğramaya başladı.
Veri bir grafiktir. Onu tablolara zorlamaya çalışıyorduk ve bunun bedelini ödüyorduk.
İlişki katmanını Apache AGE'e taşıdık. Bu, PostgreSQL için bir openCypher eklentisidir. PHP 8.4 uygulamamızı ve SQLite depomuzu koruduk.
Sonuçlar: • İlgili panel gecikmesi (latency) 900ms'den 40ms'nin altına düştü. • Karmaşık iki adımlı gezintiler (traversals) artık tek haneli milisaniyeler sürüyor. • Operasyonel iş yükümüz aynı kaldı çünkü AGE, Postgres içinde çalışıyor.
Neden bağımsız bir grafik veritabanı yerine Apache AGE kullanmalısınız?
Operasyonel Basitlik Yedeklemek veya güvence altına almak için yeni bir veritabanına ihtiyacınız yok. AGE; mevcut Postgres kurulumunuzu, bağlantı havuzlarınızı (connection pools) ve güvenlik kurallarınızı kullanır.
Yerel Grafik Sorguları SQL'de değişken uzunluklu yollar karmaşık özyineleme gerektirir. Cypher'da ise bunları basit desenler (patterns) olarak yazarsınız. 40 satırlık özyinelemeli bir SQL bloğu, 6 satırlık bir Cypher sorgusuna dönüştü.
Daha İyi Performans Bir grafik motoru komşuluğu (adjacency) indeksler. Eşleşmeyen yolların genişlemesini durdurur. Bu, önceki sistemimizi çökerten veri yayılımını (data fan-out) engeller.
Migrasyonumuzdan çıkarılan önemli bir ders: Giriş noktası özelliklerinizi (entrypoint properties) her zaman indeksleyin. Bir gezintiyi (traversal) başlatmak için kullandığınız ID'yi indekslemezseniz, AGE tam tarama (full scan) yapacaktır. Bu, en iyi grafik sorgusunu bile yavaşlatır.
Grafiği bir okuma modeli (read model) olarak kullanıyoruz. Ham verilerimiz SQLite'da kalıyor. İkisini senkronize etmek için bir Python betiği kullanıyoruz. Bu, grafiğimizin hızlı, hafif ve yeniden oluşturulabilir olmasını sağlıyor.
Eğer özyinelemeli SQL sorgularınız çok karmaşık hale geliyorsa, ilişkisel modelle savaşmayın. Mevcut deponuzun yanında küçük bir grafik projeksiyonu oluşturun.