Grafik Tabanlı Veritabanlarının (http://neo4j.org/) kullanım durumları nelerdir? [kapalı]

İlişkisel DB'leri çok kullandım ve mevcut diğer türler üzerinde girişim yapmaya karar verdim.

Bu belirli ürün iyi ve umut verici görünüyor: http://neo4j.org/

Grafik tabanlı veritabanları kullanan var mı? Kullanılabilirlik perspektifinin artıları ve eksileri nelerdir?

Bunları bir üretim ortamında kullandınız mı? Bunları kullanmanıza neden olan gereklilik neydi?

Önceki bir işte bir grafik veritabanı kullandım. Neo4j kullanmıyorduk, Berkeley DB üzerine inşa edilmiş şirket içi bir şeydi, ama benzerdi. Üretimde kullanıldı (hala öyle).

Grafik veritabanı kullanmamızın nedeni, sistem tarafından depolanan verilerin ve sistemin verilerle yaptığı işlemlerin, ilişkisel veritabanlarının tam olarak zayıf noktası olması ve tam da grafik veritabanlarının güçlü noktası olmasıydı. Sistemin, sabit bir şeması olmayan ve ilişkilerle birbirine bağlanan nesne koleksiyonlarını depolaması gerekiyordu. Veriler hakkında mantık yürütmek için, sistemin bir grafik veritabanında birkaç geçiş olacak, ancak bu SQL'de oldukça karmaşık sorgular olacak birçok işlem yapması gerekiyordu.

Grafik modelin temel avantajları hızlı geliştirme süresi ve esneklikti. Mevcut dağıtımları etkilemeden hızla yeni işlevler ekleyebiliriz. Potansiyel bir müşteri kendi verilerinin bir kısmını içe aktarmak ve modelimizin üzerine aşılamak isterse, bu genellikle satış temsilcisi tarafından sahada yapılabilir. Esneklik, yeni bir özellik tasarlarken de yardımcı oldu ve bizi yeni verileri katı bir veri modeline sıkıştırmaya çalışmaktan kurtardı.

Garip bir veritabanına sahip olmak, diğer birçok tuhaf teknolojimizi oluşturmamıza izin vererek, ürünümüzü rakiplerimizin ürünlerinden ayırmak için bize pek çok gizli sos verir.

Ana dezavantaj, standart ilişkisel veritabanı teknolojisini kullanmıyor olmamızdı, bu da müşterileriniz girişimci olduğunda sorun olabilir. Müşterilerimiz neden verilerimizi dev Oracle kümelerinde barındıramadığımızı soruyorlardı (müşterilerimiz genellikle büyük veri merkezlerine sahipti). Ekipten biri Oracle (veya PostgreSQL veya MySQL) kullanmak için veritabanı katmanını gerçekten yeniden yazdı, ancak orijinalinden biraz daha yavaştı. Hatta en az bir büyük kuruluşun yalnızca Oracle politikası vardı, ancak neyse ki Oracle, Berkeley DB'yi satın aldı. Ayrıca çok sayıda ekstra araç yazmamız gerekiyordu - örneğin Crystal Reports'u kullanamazdık.

Grafik veritabanımızın diğer bir dezavantajı, onu kendimiz oluşturmamızdı, bu da bir problemle (genellikle ölçeklenebilirlikle) karşılaştığımızda onu kendimiz çözmemiz gerektiği anlamına geliyordu. İlişkisel bir veritabanı kullansaydık, satıcı sorunu on yıl önce çözmüş olurdu.

Girişimci müşteriler için bir ürün oluşturuyorsanız ve verileriniz ilişkisel modele uyuyorsa, mümkünse ilişkisel bir veritabanı kullanın. Uygulamanız ilişkisel modele uymuyorsa ancak grafik modeline uyuyorsa bir grafik veritabanı kullanın. Sadece başka bir şeye uyuyorsa, onu kullanın.

Uygulamanızın mevcut blub mimarisine uyması gerekmiyorsa, bir grafik veritabanı veya CouchDB veya BigTable veya uygulamanıza uyan her şeyi kullanın ve harika olduğunu düşünüyorsunuz. Size bir avantaj sağlayabilir ve yeni şeyler denemek eğlenceli olabilir.

Ne seçerseniz seçin, veritabanı motorları oluşturmayı gerçekten sevmiyorsanız, veritabanı motorunu kendiniz oluşturmamaya çalışın.

Neo ekibi ile bir yılı aşkın süredir çalışıyoruz ve çok mutluyuz. Bir grafik veritabanı için belirlenen akademik yapıları ve bunların ilişkilerini modeller ve ağ üzerinden öneri algoritmaları çalıştırırız.

Zaten Java'da çalışıyorsanız, Neo4j kullanarak modellemenin çok basit olduğunu ve denediğimiz diğer çözümlerin R / W için en düz / en hızlı performansına sahip olduğunu düşünüyorum.

Dürüst olmak gerekirse, ben zor zamanlar var değil çok daha kolay tutun nesne özellikleri ve ilişkilere dolambaçlı tablo yapılarını tasarlarken daha çünkü bir Grafik / Ağı açısından düşünme.

Bununla birlikte, bazı bilgileri MySQL'de saklıyoruz çünkü İşletme tarafı için hızlı SQL sorguları çalıştırması daha kolay. Neo ile aynı işlevleri gerçekleştirmek için şu anda bant genişliğine sahip olmadığımız bir kod yazmamız gerekir. Ancak bunu yapar yapmaz, tüm bu verileri Neo'ya taşıyacağım!

İyi şanslar.

İki puan:

Öncelikle, SQL Server'da son 5 yıldır üzerinde çalıştığım veriler üzerinde, çalıştırmamız gereken sorgu türleri için son zamanlarda SQL ile ölçeklenebilirlik duvarına girdim (iç içe geçmiş ilişki ipuçları ... bilirsiniz ... grafikler ). Neo4j ile oynuyordum ve bu tür bir aramaya ihtiyacım olduğunda arama sürelerim birkaç kat daha hızlı.

İkincisi, grafik veritabanlarının güncelliğini yitirdiği noktaya kadar. Um ... hayır. Önceleri, insanlar verileri verimli bir şekilde nasıl depolayacaklarını ve arayacaklarını anlamaya çalışırken, grafik ve ağ stili veritabanı modelleri oluşturup oynadılar. Bunlar, fiziksel model mantıksal modeli yansıtacak şekilde tasarlandı, bu yüzden verimlilikleri o kadar büyük değildi. Bu tür bir veri yapısı, yarı yapılandırılmış veriler için iyiydi, ancak yapılandırılmış yoğun veriler için o kadar iyi değildi. Dolayısıyla, Codd adlı bu IBM çalışanı, yapılandırılmış verileri düzenlemek ve depolamak için verimli yollar araştırıyordu ve ilişkisel veritabanı modeli fikrini ortaya attı. Ve iyiydi ve insanlar mutluydu.

Burada neyimiz var? İki farklı amaç için iki araç. Grafik veritabanı modelleri, yarı yapılandırılmış verileri ve varlıklar arasındaki ilişkileri (var olan veya olmayan) temsil etmek için çok iyidir. İlişkisel veritabanları, çok statik bir şemaya sahip olan ve birleştirme derinliklerinin çok derinleşmediği yapılandırılmış veriler için iyidir. Biri bir tür veri için, diğeri diğer veri türleri için iyidir.

İfadeyi ifade etmek için Silver Bullet yoktur. Grafik veritabanı modellerinin güncelliğini yitirdiğini söylemek ve kullanmanın 40 yıllık ilerlemeyi bıraktığını söylemek çok kısadır. Bu, C'yi kullanmak, Java ve C # gibi şeyleri elde etmek için geçirdiğimiz tüm teknolojik ilerlemeden vazgeçmek anlamına gelir. Bu doğru değil. C, belirli görevler için gerekli olan bir araçtır. Java, diğer görevler için bir araçtır.

Yıllardır mühendislik verilerini yönetmek için MySQL kullanıyorum ve iyi çalıştı, ancak yaşadığımız (ancak yaşadığımızı fark etmediğimiz) sorunlardan biri, şemayı her zaman önceden planlamak zorunda olmamızdı. Sahip olduğumuzu bildiğimiz bir başka sorun da, verileri etki alanı nesnelerine ve geriye doğru eşlemekti.

Şimdi neo4j'yi denemeye başladık ve görünüşe göre her iki sorunu da bizim için çözüyor. Her düğüme (ve ilişkiye) farklı özellikler ekleme yeteneği, verilere yönelik tüm yaklaşımımızı yeniden düşünmemizi sağladı. Dinamik ve statik diller gibidir (Ruby ve Java), ancak veritabanları içindir. Veri modelini veritabanında oluşturmak çok daha çevik ve dinamik bir şekilde yapılabilir ve bu, kodumuzu önemli ölçüde basitleştirir.

Ve koddaki nesne modeli genellikle bir grafik yapısı olduğundan, veritabanından eşleme de daha basittir, daha az kod ve dolayısıyla daha az hata içerir.

Ek bir bonus olarak, verilerimizi neo4j'e yüklemek için ilk prototip kodumuz aslında önceki MySQL sürümünden daha hızlı performans gösteriyor. Bununla ilgili (henüz) sağlam bir rakamım yok, ancak bu güzel bir ek özellikti.

Ancak günün sonunda, seçim muhtemelen çoğunlukla alan modelinizin doğasına dayanmalıdır. Tablolarla veya grafiklerle daha iyi eşleşiyor mu? Bazı prototipler yaparak karar verin, verileri yükleyin ve onunla oynayın. Verilerin farklı görünümlerine bakmak için neoclipse kullanın. Bunu yaptıktan sonra, umarım iyi bir şeyde olup olmadığınızı anlarsınız.

Şirketimde bir intranet oluşturuyorum.

Tablolarda (Oracle, MySQL, SQL Server, Excel, Access, çeşitli rastgele listeler) depolanan verilerin nasıl yükleneceğini ve Neo4J veya başka bir grafik veritabanına nasıl yükleneceğini anlamakla ilgileniyorum. Özellikle, ortak veriler sistemde zaten mevcut olan verilerle çakışırsa ne olur.

Evet, bazı verilerin en iyi RDBMS'de modellendiğini biliyorum, ancak birkaç farklı tabloyu üst üste koymanız gerektiğinde, grafik modelinin tablo yapısından daha iyi olduğu fikrine kapıldım.

Örneğin, bir üretim ortamında çalışıyorum. Üzerinde çalıştığımız büyük bir proje var ve karmaşıklık nedeniyle, her departman soldaki bir sütunda bir BOM (Malzeme Listesi) hiyerarşisi ve ardından bireyler tarafından yapılan birkaç sütun not ve kontrol içeren ayrı bir Excel elektronik tablosu oluşturdu. bu çarşafları kim yaptı.

Dolayısıyla sorunlardan biri, tüm bu notları tek bir "görünümde" bir araya getirmektir, böylece birisi belirli bir bölümde ele alınması gereken tüm konuları görebilir.

İkinci sorun, ortak bir bileşen birden fazla alt montajda kullanıldığında, bir Excel elektronik tablosunun hiyerarşik bir malzeme listesini temsil etmekte berbat olmasıdır. Yani, biri ateşleme alt montajında ​​P34 rölesi hakkında bir not yazarsa, aynı yorum motor sürücüsü alt montajında ​​kullanılan P34 röleleri ile ilişkilendirilmelidir. Bu, Excel elektronik tablosunda gerçekleşmez.

Şirket intraneti için, her şeyi kolayca arayabilmek istiyorum. Parça numarası, ürün reçetesi yapısı, telefon numarası, e-posta adresi, şirket politikası veya prosedürü ile ilgili veriler gibi. Hatta bunu bilgisayar donanım varlıklarını ve kurulu yazılımları yönetmek için genişletmek istiyorum.

Bilgi ağı dolmaya başladığında, "XYZ projesinde çalışan herkese bir e-posta yazmak istiyorum" gibi harika geçişler yapmaya başlayabileceğinizi düşünüyorum. İnsanlar projeyle ilişkilendirilmiş olacak çünkü XYZ projesindeki verileri oluşturuyor ve değiştiriyor olarak etiketlenecekler. Dolayısıyla, XYZ projesini bir arama anahtarı olarak kullanarak, XYZ projesiyle ilgili her şeyi içeren büyük bir küme oluşturulacak. XYZ projesini oluşturan kişilere bağlantılar dahil. Kişi bağlantıları e-posta adreslerine bağlanacaktır. Dolayısıyla, XYZ projesine katılımlarıyla, e-postama dahil edilecekler. Bu, projede çalışan kişilerin bir listesini tutmaya çalışan bazı sekreterlerin tam tersidir. Çok sayıda liste oluşturuyoruz. Listeleri tutmak ve güncel olmalarını sağlamak için çok zaman harcıyoruz.

Başka bir harika geçiş, belirli bir yazılım parçasının yüklü olduğu tüm bilgisayarları sürüme göre rapor edebilir. Bu rapor, eski yazılımın fazladan kopyalarını kaldırmak için görevler oluşturmak ve en son kopyaya sahip olması gereken kişileri güncellemek için kullanılabilir. Ayrıca lisans takibi için de faydalı olacaktır.

İlişkisel olmayan veritabanlarının karşıladığı ihtiyaçlardan bahseden güzel bir makale: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

İlişkisel veritabanlarının kusurlu ya da yanlış olmadığını belirtmekte (ismin dışında) iyi bir iş çıkarıyor, sadece günümüzde insanlar ana akım yazılımlarda ve web sitelerinde giderek daha fazla veri işlemeye başlıyor ve ilişkisel veritabanları ölçeklenmiyor. bu ihtiyaçlar için.

biraz geç olabilir ama Neo4j, listelenen iyi bilinen olanları kullanarak projelerin giderek artan sayıda vardır belki Neo4j . Ayrıca Neo4j'in arkasındaki firma olan NeoTechnology'nin müşteri sayfasında bazı referansları bulunmaktadır.

_{Not: Neo4j ekibinin bir parçasıyım}