Bu Neo4j'nin RDBMS yürütme süresi ile karşılaştırılması doğru mu?

Arka Plan: Aşağıda, Eylem Neo4j kitabında belirtilen bir performans testini kapsayan Grafik Veritabanları kitabı yer almaktadır :

Bir grafikteki ilişkiler doğal olarak yollar oluşturur. Grafik sorgulama veya çaprazlama, aşağıdaki yolları içerir. Veri modelinin temel olarak yola yönelik doğası nedeniyle, yola dayalı grafik veritabanı işlemlerinin çoğu, verilerin düzenlenme biçimiyle oldukça uyumludur ve bu da onları son derece verimli hale getirir. Neo4j Eylem kitabında, Partner ve Vukotic ilişkisel bir mağaza ve Neo4j kullanarak bir deney gerçekleştirir.

Karşılaştırma, grafik veritabanının bağlı veriler için ilişkisel bir mağazadan çok daha hızlı olduğunu göstermektedir.Partner ve Vukotic'in deneyi, bir sosyal ağda en fazla beş derinliğe kadar arkadaş arkadaşları bulmayı amaçlamaktadır. Rastgele seçilen iki kişi göz önüne alındığında, onları birbirine bağlayan ve en fazla beş ilişki uzunluğunda bir yol var mı? Her biri yaklaşık 50 arkadaşı olan 1.000.000 kişiyi içeren bir sosyal ağ için sonuçlar, Tablo 2-1'de gördüğümüz gibi, grafik veritabanlarının bağlı veriler için en iyi seçim olduğunu kuvvetle göstermektedir.

Tablo 2-1. Neo4j'de etkili bulmaya karşı ilişkisel bir veritabanında genişletilmiş arkadaşlar bulma

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

İkinci derinlikte (arkadaşların arkadaşları) hem ilişkisel veritabanı hem de grafik veritabanı, onları çevrimiçi bir sistemde kullanmayı düşünecek kadar iyi performans gösterir. Neo4j sorgusu ilişkisel olanın üçte ikisinde çalışırken, son kullanıcı ikisi arasındaki milisaniye farkını zar zor fark eder. Üçüncü derinliğe ulaştığımızda (arkadaş arkadaşı), ilişkisel veritabanının sorgu ile makul bir zaman diliminde artık ilgilenemeyeceği açıktır: tamamlanması için geçen otuz saniye tamamen kabul edilemez olacaktır çevrimiçi bir sistem için. Buna karşılık, Neo4j'in tepki süresi nispeten düz kalır: sorguyu gerçekleştirmek için sadece bir saniyenin bir kısmı - çevrimiçi bir sistem için kesinlikle yeterince hızlı.

Dördüncü derinlikte, ilişkisel veritabanı, çevrimiçi bir sistem için pratik olarak işe yaramaz hale getirerek, sakatlama gecikmesi sergiler. Neo4j'in zamanlamaları da biraz kötüleşti, ancak buradaki gecikme, duyarlı bir çevrimiçi sistem için kabul edilebilirliğin çevresinde. Son olarak, beşinci derinlikte, ilişkisel veritabanı sorguyu tamamlamak için çok uzun zaman alır. Buna karşılık Neo4j, yaklaşık iki saniye içinde bir sonuç döndürür. Beşinci derinlikte, neredeyse tüm ağımız dostumuzdur: birçok gerçek dünya kullanım durumu için, sonuçları ve zamanlamaları büyük olasılıkla kesebiliriz.

Sorular:

• Bu, bir sosyal ağda bulmak dışında bir şeyi taklit etmek için makul bir test mi? (Yani gerçek sosyal ağların normalde yaklaşık 50 arkadaşı olan düğümleri vardır; " zengin olsun daha zengin " modeli, sosyal ağlar için daha doğal olsa da, yanlış olabilir.)
• Emülasyonun doğallığından bağımsız olarak, sonuçların kapalı veya tekrarlanamaz olduğuna inanmak için herhangi bir neden var mı?

Facebook Anatomisi adlı bu belgeye baktığımda medyanın 100 olduğunu not ediyorum. Kümülatif fonksiyon planına baktığımda ortalamanın 200'e yakın daha yüksek olduğuna bahse girebilirim. Yani burada en iyi sayı 50 değil gibi görünüyor. Ancak bunun asıl mesele olmadığını düşünüyorum.

Ana sorun, veritabanının nasıl kullanıldığı hakkında bilgi eksikliğidir.

Grafik yapıları için özel olarak tasarlanmış bir veri depolama alanının geleneksel RDBM'lerden daha verimli olması makul görünmektedir. Bununla birlikte, RDBM'ler tercih edilen bir veri depolama alanı olarak en son trendlerde olmasalar bile, bu sistemler veri kümesi boyutları ile sürekli olarak gelişmiştir. Çeşitli olası tasarım türleri, verileri indekslemenin çeşitli yolları, eşzamanlılıkla ilgili iyileştirmeler vb.

Sonuç olarak, çalışmanın tekrarlanabilirlik ile ilgili olarak, veritabanı şemasının nasıl tasarlandığına dair uygun bir açıklama olmadığını düşünüyorum. Bir veritabanının böyle bir sorgulama kralı üzerinde hakim olmasını beklemiyorum, ancak iyi ayarlanmış bir tasarımla farklılıkların bu kadar büyük olmamasını beklerim.

RDBMS'de grafikleri modellemenin iyi / hızlı yolları ve aptal / yavaş yolları vardır.

• Bazıları daha hızlı grafik alma hızı için akıllı indeksleme ve Depolanmış Prosesler, işlemci CPU yükü ve RAM disklerinde ayarlanmış geçici tablolar kullanır.

• Bazıları önceden hesaplanmış grafik yolları kullanır (bu, sosyal ağ senaryosunda daha az uygulanabilir, ancak düğümlerin çoğunluğunun yaprak düğümleri olduğu bir ağaçta, zaman için oldukça iyi bir takas alanıdır.

• Bazıları ayarlanmamış dizinlenmiş geçici tablo kullanarak bir döngü içinde hesaplar. Makalede atılan # 'lardan, bu onların yaptıkları gibi kokuyor (30 saniyelik performans oldukça ufacık veri setinde)

  Örneğin, kendi ağaç hesaplamam var.

  • Yüksek oranda ayarlanmış bir saklı süreç içinde kapsüllenir

  • Kurumsal boyutlu bir donanım Sybase ASE15 veri sunucusunda çalışırken, bu sunucu diğer tüm kurumsal uygulamalardan birkaç terabaytlık veriyle paylaşılıyor; bazı veriler benimkinden daha aç; ve yalnızca sorgularımı yürütmeye adanmış değil.

  • Ben yaptım değil bir RAM disk üzerinde ana hızlanma aracı, geçici bir tabloya erişim hakkına sahiptir.

  • Elde ettiğim temsili bir veri kümesi, 2.5M düğümü tam orman veri kümesinden (5 ile 15 arasında değişen sınırsız ağaç derinliği, ancak belirli bir düğümün daha küçük ortalama arity'sinden 150.000 düğüm alt ağacı elde ediyordu) denemede listelenen 50 arkadaş)

  • Ben bu sorgu ~ 30-45 saniye noktasına ayarladı. Kesinlikle, söz konusu rakamların RDBMS performanslarında gösterdiği gibi üstel yavaşlama sergilemez, sonuç kümesinde üstel bir büyüme olmadığı göz önüne alındığında, bu benim için bir ayarlanmamış indeks reeks kişisel deneyimlerinden geçici tablo).

Bu nedenle, bu karşılaştırma büyük olasılıkla yanlıştır ve zayıf RDBMS yan tasarımına dayanmaktadır, ancak önceki cevabın belirttiği gibi, kodlarının ve tablo tanımlarının% 100'ünü açık kaynak olmadan tespit etmek imkansızdır.