Bize Ulaşın
Sonuç bulunamadı.

Grafik Veritabanı Karşılaştırması: Neo4j vs FalkorDB vs Memgraph

Ekrem Sarı
Ekrem Sarı
güncellendi Nis 15, 2026
Bakınız etik normlar

120.000 Amazon ürün yorumundan türetilen sentetik bir grafik üzerinde (381 bin düğüm, 804 bin kenar) Neo4j, FalkorDB ve Memgraph'ı karşılaştırmalı olarak test ettik. Her biri 1.000 ölçüm içeren 12 sorgu şablonu çalıştırdık, 6 farklı toplu işlem boyutunda veri alımını test ettik, 32 iş parçacığına kadar 60 saniye boyunca eş zamanlı yükü sürdürdük ve bellek, soğuk başlatma, karma iş yükü ve indeks etkisini ölçtük.

FalkorDB, 8 iş parçacığında Neo4j ve Memgraph'tan daha yüksek verim sağladı.

Grafik veritabanı kıyaslama sonuçları

Eş zamanlı verim

Loading Chart

QPS (saniyede sorgu sayısı), veritabanının sürekli çoklu iş parçacıklı yük altında saniyede kaç okuma sorgusuna yanıt verdiğini ölçer. Her çalıştırma 60 saniye sürer. Daha yüksek değer daha iyidir.

Sorgu gecikmesi (s50)

p50, ortalama gecikme süresidir: tüm sorguların yarısı bu değerden daha hızlı tamamlanır. Daha düşük değer daha iyidir.

  • Nokta arama: Kimliğe göre tek bir düğümü getirin. FalkorDB'nin Redis karma tabloları, yaklaşık 3 kat daha hızlı olan O(1) bellek içi aramalar yapar.
  • Dolaşım: Bir düğümden komşularına (1 adım) veya komşularının komşularına (2 adım) doğru yürüyüş. FalkorDB, 2 adımlı yürüyüşü 2,9 kat daha hızlı gerçekleştirir.
  • Toplama: Her marka için yorumları sayın, ortalama yıldız puanlarını hesaplayın.
  • Filtrele + Tara: Tüm veri kümesindeki yorumları yıldız derecelendirmesine göre filtrele.

Veri alım hızı

Veri alım hızı, veritabanının saniyede kaç inceleme yazabildiğini ölçer. Grafikteki her nokta farklı bir toplu işlem boyutunu temsil eder: tek bir sorguda kaç inceleme gruplandırılır. Daha yüksek değer daha iyidir.

1'lik parti büyüklüğünde Memgraph önde (1.427/s). Parti büyüklüğü arttıkça FalkorDB hızla ölçekleniyor ve yaklaşık 500'lük parti büyüklüğünde Memgraph'ı geçiyor. Neo4j, parti büyüklüğünden bağımsız olarak ~10.600/s'de sabit kalıyor. 5.000'lik parti büyüklüğünde FalkorDB, 1'lik parti büyüklüğüne göre 77 kat daha hızlı, 22.784/s'ye ulaşıyor.

Grafik veritabanı kıyaslama metodolojimiz hakkında daha fazla bilgi edinebilirsiniz.

Temel bulgular

FalkorDB, 8 iş parçacığında 6.693 QPS'ye ulaştı, Neo4j ise 6.7x performans gösterdi.

Redis'in bellek içi veri yapıları ve olay döngüsü, düşük gecikmeli sorguları yüksek paralellikle birleştirmesine olanak tanır. 8 iş parçacığından sonra, Redis'in tek iş parçacıklı çekirdeği tavanı oluşturduğu için verimlilik plato çizer. Neo4j, 16 iş parçacığında (1.010 QPS) zirveye ulaşır, ardından 32 iş parçacığında (927 QPS) düşer; bu da iş parçacığı çekişmesine işaret eder.

FalkorDB, 1,1 ms'de soğuk başlatma yapıyor ve Neo4j'den 82 kat daha hızlı.

Neo4j, yeniden başlatmanın ardından ilk sorguyu kabul etmek için 90 ms sürüyor. İlk ısınma sorgusu 274 ms'de çalışıyor, ardından 3 sorgudan sonra 34 ms'ye düşüyor. FalkorDB 1,1 ms'de hazır oluyor, ilk sorgu 0,4 ms'de gerçekleşiyor. Pod'ların ölçeklenip küçüldüğü mikro hizmet veya sunucusuz bir kurulumda bu süre önemli.

İndeksler: Neo4j'de 1.700 kat, FalkorDB'de ~1 kat fark

İndeksler olmadan Neo4j'nin deep_feature_products sorgusu 293 ms sürdü. İndekslerle ise 0,17 ms sürdü. Bu, 1.712 katlık bir fark anlamına geliyor. Memgraph benzer bir hassasiyet gösterdi (sorguya bağlı olarak 160-898 kat). FalkorDB'nin sonuçları, indekslerle veya indeksler olmadan yaklaşık olarak aynı kaldı çünkü Redis hash tabloları zaten örtük indeksler olarak işlev görüyor.

Bellek: Aynı grafik için 415 MB ve 2.668 MB karşılaştırması.

  • Memgraph: 415 MB
  • FalkorDB: 496MB
  • Neo4j: 2.668 MB (JMX yığını kullanıldı)

Neo4j'nin JVM'si başlangıçta 4 GB önceden ayırır, bu nedenle işlem düzeyindeki belleği (VmRSS) gerçek veri kullanımından bağımsız olarak her zaman ~5,2 GB'tır. Asıl önemli olan JMX yığın metriğidir. Kapasite planlaması için kullanılacak sayı, en yüksek değer olan 2,7 GB'tır.

Neo4j en yüksek toplama oranını kazandı.

FalkorDB, 12 sorgunun 11'inde en düşük gecikme süresine sahipti. İstisna, Neo4j'nin sorgu iyileştiricisinin daha iyi bir yürütme planı ürettiği agg_feature_sentiment (duyguya göre gruplandırma ve filtreleme) sorgusuydu: 131 ms'ye karşılık FalkorDB'nin 152 ms'si.

Karma iş yükü (%80 okuma, %20 yazma)

8 iş parçacığı, 60 saniye, üç veritabanının tamamında sıfır hata:

  • FalkorDB: 50.223 işlem (837 QPS)
  • Neo4j: 44.256 işlem (738 QPS)
  • Memgraf: 28.040 işlem (467 QPS)

Yazma işlemleri, bu cihazların hiçbirinde okuma performansını gözle görülür şekilde düşürmedi.

Bu kıyaslamadaki mimariler

Her veritabanı kendi yönetim arayüzüne sahiptir. Bu ekran görüntüleri, aynı veri kümesinin (16.127 düğüm, 24.318 kenar) üçüne de yüklendiğini ve aynı COMPARED_WITH geçiş sorgusunun çalıştırıldığını göstermektedir.

FalkorDB

FalkorDB, Redis'in bellek içi anahtar-değer deposu üzerine kurulu bir grafik modülüdür. Sorgular OpenCypher ile yapılır, ancak altında Redis hash tabloları bulunur. Bu nedenle, nokta aramaları 0,044-0,048 ms'de tamamlanır.
Bu karşılaştırmada yer alan diğer iki veritabanı, aynı sorgularda 2-3 kat daha yüksek performans gösterdi. Dezavantajı ise Redis'in tek iş parçacıklı çekirdeği nedeniyle eşzamanlı işlem hacminin 8 iş parçacığının ötesinde ölçeklenememesidir.

FalkorDB Tarayıcısı. Sol panelde grafik meta verileri (6 düğüm etiketi, 8 kenar türü, 9 özellik anahtarı) gösteriliyor. Sorgu paneli doğrudan OpenCypher'ı çalıştırıyor. Yalnızca grafik dizini için bellek kullanımı 4 MB olarak raporlanmıştır (veriler Redis belleğinde bulunur).

Neo4j

Neo4j, JVM üzerinde çalışır. JIT derlemesi, tekrarlanan sorguların zamanla daha hızlı çalışmasını sağlar (ısınma süresi: 274 ms -> 34 ms). Çöp toplama duraklamaları kuyruk gecikmesini etkiler ancak IQR aykırı değer kaldırma işlemiyle yakalanır. Sorgu iyileştirici, karmaşık toplama planlarını iyi bir şekilde ele alır ve agg_feature_sentiment kazancı da buradan gelir. Maliyeti ise 4 GB yığın ön tahsisi ve çöp toplama yüküdür.

Neo4j Tarayıcı. Sol kenar çubuğu, düğüm etiketlerini (Marka, Kategori, Özellik, Ürün, Yorum, Yorumcu), ilişki türlerini ve özellik anahtarlarını gösterir. Alt panel, etkileşimli bir grafik olarak KARŞILAŞTIRILDIĞI bir geçişi görüntüler. Aynı 16.127 düğüm ve 24.318 ilişki.

Memgraf

Memgraph C++ ile yazılmıştır. JVM ek yükü yoktur. Tam veri seti için 415 MB, üçü arasında en düşük boyuttur. Sorgu başına minimum ek yük sayesinde bireysel eklemelerde en hızlısıdır (1.427/sn). Ancak eşzamanlı işlem hacminde (en yüksek 684 QPS) geride kalmaktadır. Bolt ile uyumludur, bu nedenle Neo4j sürücüsüyle çalışır.

Memgraph Lab grafik şeması. 16.127 düğüm, 6 düğüm tipi ve 8 kenar tipi üzerinden 24.318 ilişki.

Grafik veritabanı kıyaslama metodolojisi

Çevre

  • RunPod 8 vCPU (AMD EPYC x86_64), 32 GB RAM, Ubuntu 24.04 LTS
  • Yerel kurulum, Docker kullanılmadı. Üç veritabanı da aynı makinede, localhost bağlantıları kullanılarak kuruldu.
  • Python 3.12.3. Tek iş parçacıklı testler için kalıcı oturumlar, çok iş parçacıklı testler için bağlantı havuzundan çağrı başına oturumlar.

Veri

  • Zipf (markalar, özellikler) ve Poisson (varlıklar, ilişkiler) dağılımlarından oluşturulan 120.000 sentetik yorum, sabit başlangıç değeri=42.
  • 6 düğüm türü: İnceleme, Ürün, İnceleyen, Marka, Özellik, Kategori
  • 8 kenar türü: HAKKINDA, YAZAN, KATEGORİDE, YAPILAN, OLUMLU ETKİ, OLUMSUZ ETKİ, BAHSEDİLDİĞİ, KARŞILAŞTIRILDIĞI

Sorgular

5 kategoriye yayılmış 12 Cypher şablonu: nokta arama (3), 1 adımlı geçiş (2), 2 adımlı geçiş (2), toplama (3), filtre (1), tam tarama (1). Her parametreli sorgu, her biri 100 kez olmak üzere 10 farklı parametre değeriyle çalıştırılır ve veritabanı başına sorgu başına 1.000 ölçüm yapılır.

Parametreler, Zipf ağırlıklı seçim yöntemi kullanılarak tüm kimlik alanından örneklenir; bu nedenle hem popüler hem de nadir öğeler test edilir.

Üç örnek:

Nokta arama : İndekslenmiş kimliğe göre tek bir düğümü getir.

2 aşamalı geçiş : Bir markadan başlayarak ürünlerini ve yorumlarını inceleyin.

Birleştirme : Çok adımlı birleştirme ve hesaplama ile tam grafik taraması

Ölçüm

  • Zamanlama: time.perf_counter_ns(), 500 ısınma sorgusu, sorgu başına minimum 100 çalıştırma
  • İstatistikler: 10.000 bootstrap örneği, %95 güven aralığı, çeyrekler arası aralıkta aykırı değerlerin çıkarılması (3,0x faktör). Hem ham hem de filtrelenmiş veriler raporlanmıştır.
  • Bellek: Neo4j, JMX yığını üzerinden kullanılıyor (VmRSS anlamsız çünkü JVM önceden bellek ayırıyor), FalkorDB, Redis used_memory_rss üzerinden, Memgraph ise /proc/{pid}/status VmRSS üzerinden kullanılıyor.

Adalet

  • Üç veritabanının tamamında aynı bağlantı havuzu boyutu, ısınma sayısı, Cypher sorguları, veriler ve makine kullanılmıştır.
  • Eş zamanlı test: Sabit pool_size=32 ile 1, 2, 4, 8, 16 ve 32 iş parçacığında 60 saniyelik sürekli yük. Sorgu karışımı: %40 tek adımlı geçiş, %30 iki adımlı geçiş, %20 toplama, %10 üç adımlı geçiş.

Test edilen veritabanları

Sınırlamalar

Veritabanı başına tek makine, tek düğüm. Dağıtılmış veya küme tabanlı performans testi yapılmamıştır. Neo4j Enterprise kümeleme ve Memgraph replikasyonu kapsam dışındadır.

Gerçek Amazon yorumlarından türetilen dağılımlara sahip sentetik veriler. Belirli üretim iş yükü modelleriyle eşleşmeyebilir.

Ölçülmeyenler: disk kalıcılığı/kurtarma, tam metin arama, grafik algoritmaları (PageRank, topluluk tespiti) ve yoğun yazma işlemleri içeren iş yükleri (>%50 yazma).

Farklı sürücüler: Neo4j ve Memgraph, Neo4j Python sürücüsünü kullanırken, FalkorDB kendi sürücüsünü kullandı. Tek iş parçacıklı testlerde ek yük farkı <0,5 ms idi.

Çözüm

FalkorDB, 12 sorgudan 11'ini kazandı, 6.693 QPS'ye ulaştı ve 1,1 ms'de soğuk başlatma yaptı. Okuma ağırlıklı grafik iş yükleri için bu kıyaslamada en hızlı seçenektir. Memgraph, en bellek verimli seçenektir (415 MB'a karşı 2,7 GB). Neo4j, en geniş ekosistemi sunar: RBAC, kümeleme, izleme ve karmaşık toplama planlarını her iki alternatife göre daha iyi ele alan bir sorgu iyileştirici.

Mimari, tavanı belirler. Dağıtılmış kümeler, 1 milyondan fazla düğümlü grafikler ve yoğun yazma işlemleri içeren iş yükleri, bu sıralamaları yeniden şekillendirebilecek testlerdir.

Ekrem Sarı
Ekrem Sarı
Yapay Zeka Araştırmacısı
Ekrem, AIMultiple'da yapay zeka araştırmacısı olarak çalışmakta olup, akıllı otomasyon, GPU'lar, yapay zeka ajanları ve RAG çerçeveleri üzerine yoğunlaşmaktadır.
Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.

0/450