İlişkisel Veritabanları ile Grafik Veritabanlarının Karşılaştırılması

MySQL gibi bir ilişki veri tabanının Neo4j gibi bir grafik veri tabanına kıyasla avantaj ve dezavantajlarını bana birisi açıklayabilir mi?

SQL'de, onları birbirine bağlayan çeşitli kimliklere sahip birden çok tablonuz vardır. Ardından masaları bağlamak için katılmanız gerekir. Yeni başlayanlar açısından bakıldığında, neden bağlantıların başlangıçtan itibaren kenarlar olarak bir grafik veritabanında olduğu gibi açık olması yerine bir birleştirme gerektirecek şekilde veritabanını tasarlarsınız? Kavramsal olarak bir acemi için mantıklı gelmez. Muhtemelen bunun çok teknik ama kavramsal olmayan bir nedeni var mı?

Aslında her iki tarzın arkasında da kavramsal mantık var. İlişkisel model ve grafik veritabanları hakkındaki Wikipedia, bunun iyi bir genel bakışını verir.

Birincil fark, bir grafik veritabanında, ilişkilerin bireysel kayıt düzeyinde depolanması, ilişkisel bir veritabanında ise yapının daha yüksek bir düzeyde (tablo tanımları) tanımlanmasıdır.

Bunun önemli sonuçları vardır:

• İlişkisel bir veritabanı, çok sayıda kayıt üzerinde çalışırken çok daha hızlıdır. Bir grafik veri tabanında, verilerin yapısını belirlemek için her kaydın bir sorgu sırasında ayrı ayrı incelenmesi gerekirken, bu, ilişkisel bir veri tabanında önceden bilinir.
• İlişkisel veritabanları daha az depolama alanı kullanır çünkü tüm bu ilişkileri depolamak zorunda kalmazlar.

Tüm ilişkileri bireysel kayıt düzeyinde depolamak, yalnızca ilişkilerde çok fazla çeşitlilik olacaksa mantıklıdır; aksi halde aynı şeyleri defalarca kopyalıyorsunuz. Bu, grafik veritabanlarının düzensiz, karmaşık yapılara çok uygun olduğu anlamına gelir. Ancak gerçek dünyada, çoğu veritabanı düzenli, nispeten basit yapılar gerektirir. İlişkisel veri tabanlarının baskın olmasının nedeni budur.

Bir grafik ve ilişkisel veritabanı arasındaki temel fark, ilişkisel veritabanlarının kümelerle çalışırken grafik veritabanlarının yollarla çalışmasıdır.

Bu, RDBMS kullanıcısı için beklenmedik ve yararsız yollarla kendini gösterir. Örneğin, ilişkisel bir veritabanına yinelemeli olarak katılarak yol işlemlerini (örneğin arkadaşların arkadaşları) taklit etmeye çalışırken, sorgu gecikmesi, bellek kullanımı gibi öngörülemez ve büyük ölçüde artar, bu tür işlemleri ifade etmek için SQL'e eziyet ettiğinden bahsetmeye bile gerek yok. Daha fazla veri, küme tabanlı bir veritabanında daha yavaş anlamına gelir, mantıklı indeksleme yoluyla acıyı erteleseniz bile.

Dan1111'in ima ettiği gibi, çoğu grafik veritabanı, ilişkileri temel düzeyde ifade ettikleri için bu tür bir birleştirme sıkıntısı çekmez. Yani, ilişkiler diskte fiziksel olarak bulunur ve adlandırılır, yönlendirilir ve kendileri özelliklerle dekore edilebilir (buna özellik grafik modeli denir, bkz: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Model ). Bu, seçerseniz, diskteki ilişkilere bakabileceğiniz ve varlıkları nasıl "birleştirdiklerini" görebileceğiniz anlamına gelir. Bu nedenle ilişkiler, bir grafik veritabanındaki birinci sınıf varlıklardır ve anlamsal olarak ilişkisel bir depoda çalışma zamanında somutlaştırılan örtülü ilişkilerden çok daha güçlüdür.

Neden bu kadar umursamak zorundasın? İki nedenden dolayı:

1. Grafik veritabanları, bağlantılı veriler için ilişkisel veritabanlarından çok daha hızlıdır - temel modelin bir gücü. Bunun bir sonucu, bir grafik veritabanındaki sorgu gecikmesinin, bir sorguda araştırmayı seçtiğiniz grafiğin ne kadarıyla orantılı olması ve depolanan veri miktarı ile orantılı olmaması, dolayısıyla birleştirme bombasını etkisiz hale getirmesidir .
2. Grafik veritabanları, modellemeyi ve sorgulamayı çok daha keyifli hale getirir, bu da daha hızlı geliştirme ve daha az WTF anı anlamına gelir. Örneğin, tipik bir sosyal ağ için Neo4j Cypher sorgu dilinde arkadaş-arkadaşını ifade etmek sadece MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 zaten doğru olarak işaretlenmiş bir yanıt verdi. Birkaç ek nokta geçerken kayda değer.

İlk olarak, grafik veritabanlarının hemen hemen her uygulamasında kayıtlar "sabitlenir" çünkü mevcut konumunda kaydı işaret eden bilinmeyen sayıda işaretçi vardır. Bu, bir kaydın eski konumda bir yönlendirme adresi bırakmadan veya bilinmeyen sayıda işaretçi kırılmadan yeni bir konuma karıştırılamayacağı anlamına gelir.

Teorik olarak, bir kişi tüm kayıtları bir kerede karıştırabilir ve tüm işaretçileri bulup onarmanın bir yolunu bulabilir. Pratikte bu, büyük bir grafik veri tabanında haftalar sürebilen bir işlemdir ve bu süre zarfında veri tabanının yayından kaldırılması gerekir. Bu mümkün değil.

Buna karşılık, ilişkisel bir veritabanında, kayıtlar oldukça büyük bir ölçekte yeniden karıştırılabilir ve yapılması gereken tek şey, etkilenen tüm dizinleri yeniden oluşturmaktır. Bu oldukça büyük bir işlemdir, ancak bir grafik veritabanı için eşdeğer kadar büyük değildir.

Geçerken dikkat edilmesi gereken ikinci nokta, dünya çapında ağın devasa bir grafik veritabanı olarak görülebilmesidir. Web sayfaları, diğer şeylerin yanı sıra, başka web sayfalarını da içerir. Referans, işaretçiler gibi işlev gören URL'ler aracılığıyladır.

Bir web sayfası, eski URL'de bir yönlendirme adresi bırakmadan farklı bir URL'ye taşındığında, bilinmeyen sayıda köprü kesilir. Bu bozuk bağlantılar daha sonra pek çok sörfçünün zevkini kesintiye uğratan korkunç "Hata 404: sayfa bulunamadı" mesajına yol açar.

İlişkisel bir veritabanı ile, yabancı anahtarlar ve kendi kendine birleştirmeleri kullanarak bir grafiği modelleyebilir ve sorgulayabiliriz. RDBMS'nin ilişkisel kelimesini içermesi, ilişkileri idare etmede iyi oldukları anlamına gelmez. RDBMS'deki ilişkisel kelime, ilişkiden değil ilişkisel cebirden kaynaklanır. Bir RDBMS'de, ilişkinin kendisi kendi başına bir nesne olarak mevcut değildir. Ya açık bir şekilde yabancı anahtar olarak ya da dolaylı olarak bir bağlantı tablosundaki bir değer olarak temsil edilmesi gerekir (genel / evrensel modelleme yaklaşımı kullanılırken). Veri kümeleri arasındaki bağlantılar, verilerin kendisinde saklanır.

İlişkisel bir veritabanında arama derinliğini ne kadar arttırırsak o kadar çok kendi kendine birleşmemiz gerekir ve sorgu performansımız o kadar zarar görür. Hiyerarşimizde ne kadar derine gidersek o kadar çok tabloya katılmamız gerekir ve sorgumuz o kadar yavaş olur. Matematiksel olarak maliyet, ilişkisel bir veritabanında katlanarak artar. Diğer bir deyişle, sorgularımız ve ilişkilerimiz ne kadar karmaşık olursa, ilişkisel bir veritabanına kıyasla bir grafikten o kadar çok yararlanırız. Grafikte gezinirken grafik veritabanında performans sorunlarımız olmaz. Bunun nedeni, bir grafik veritabanının ilişkileri ayrı nesneler olarak saklamasıdır. Ancak, üstün okuma performansı, daha yavaş yazma pahasına gelir.

Belirli durumlarda, bir grafik veritabanındaki veri modelini değiştirmek RDBMS'de olduğundan daha kolaydır, örneğin bir tablo ilişkisini 1: n'den m: n'ye değiştirirsem RDBMS'de potansiyel kesinti süresiyle DDL uygulamam gerekir.

RDBMS ise diğer alanlarda, örneğin verileri toplamak veya veriler üzerinde zaman damgalı sürüm kontrolü yapmak gibi avantajlara sahiptir.

Veri ambarlama için grafik veritabanları hakkındaki blog yazımda diğer bazı artıları ve eksileri tartışıyorum

İlişkisel model bir grafik modelinde bulunan verileri kolayca temsil edebilirken, pratikte iki önemli sorunla karşı karşıyayız:

1. SQL, özellikle derinliğin bilinmediği veya sınırsız olduğu çapraz geçişler olmak üzere kolayca grafik geçişi gerçekleştirmek için sözdiziminden yoksundur. Örneğin, arkadaşlarınızın arkadaşlarını belirlemek için SQL kullanmak yeterince kolaydır, ancak “ayrılık derecesi” sorununu çözmek zordur.
2. Grafikte ilerledikçe performans hızla düşer. Her geçiş düzeyi, sorgu yanıt süresine önemli ölçüde katkıda bulunur.

Referans: Yeni Nesil Veritabanları

Grafik veritabanları, üstün oldukları kullanım durumları için araştırmaya değer, ancak yukarıdaki yanıtlardaki bazı iddiaları sorgulamak için bazı nedenlerim oldu. Özellikle:

Çok sayıda kayıt üzerinde çalışırken ilişkisel veritabanı çok daha hızlıdır (dan1111'in ilk madde işareti)

Grafik veritabanları, bağlantılı veriler için ilişkisel veritabanlarından çok daha hızlıdır - temel modelin bir gücü. Bunun bir sonucu, bir grafik veritabanındaki sorgu gecikmesinin, bir sorguda araştırmayı seçtiğiniz grafiğin ne kadarıyla orantılı olması ve depolanan veri miktarı ile orantılı olmaması, dolayısıyla birleştirme bombasını etkisiz hale getirmesidir. (Jim Webber'ın ilk madde işareti)

Başka bir deyişle, sorgularımız ve ilişkilerimiz ne kadar karmaşık olursa, ilişkisel bir veritabanına kıyasla bir grafikten o kadar çok yararlanırız. (Uli Bethke'nin 2. paragrafı)

Bu iddialar haklı olsa da, özel kullanım durumumu bunlarla uyumlu hale getirmenin bir yolunu henüz bulamadım. Referans: Grafik Veritabanı veya İlişkisel Veritabanı Ortak Tablo Uzantıları: Döngüsel olmayan grafik sorgu performansını karşılaştırma

İlişkisel Veritabanları, tablo şeklindeki verileri depolamada çok daha etkilidir. Adlarında "ilişkisel" kelimesine rağmen, ilişkisel veritabanları, depolanan veri öğeleri arasındaki ilişkileri depolamada veya ifade etmede çok daha az etkilidir. İlişkisel veritabanlarındaki 'ilişkisel' terimi, farklı tablolardaki bilgileri ilişkilendirmek yerine daha çok bir tablo içindeki sütunları ilişkilendirmekle ilgilidir. Set işlemlerini desteklemek için sütunlar arasındaki ilişkiler mevcuttur. Dolayısıyla, Veritabanı milyonlarca veya milyarlarca kayıt olarak büyüdükçe, ilişkisel veritabanlarından veri almak son derece yavaş hale gelir.

İlişkisel bir veritabanının aksine, bir grafik veritabanı tamamen veri ilişkileri etrafında yapılandırılmıştır. Grafik veritabanları, ilişkileri bir şema yapısı olarak değil, diğer değerler gibi veri olarak ele alır. Grafik veritabanlarından veri almak çok hızlıdır. İlişkisel veritabanı bakış açısından, bunu her sorgu için hesaplamak yerine JOIN'leri bir kez ekleme zamanında önceden somutlaştırmak olarak düşünebilirsiniz. Veriler tamamen veri ilişkileri etrafında yapılandırıldığından, veri kümesi ne kadar büyük veya bağlantılı olursa olsun gerçek zamanlı sorgu performansı elde edilebilir. Grafik veritabanları, ilişkisel veritabanına kıyasla daha fazla depolama alanı kaplar.