Bilgi grafiği ve Neo4j gerçek savaş
Mevcut büyük veri endüstrisinde, algoritmaların yükseltilmesiyle, özellikle makine öğreniminin eklenmesiyle, kuralları bulma algoritmasının getirdiği kar payları giderek ortadan kalkmakta ve daha derin bir veri seviyesine ihtiyaç duyulmaktadır. Madenciliğin yolu, bu yeni yol bilgi grafiğidir. Daguan verilerindeki bilgi grafiği ve bilgi grafiği uygulaması hakkında konuşalım.
1. Bilgi grafiği nedir
Bilgi Grafiği, varlıklar arasındaki ilişkiler yerine varlıklar ve kenarlar yerine noktalar kullanan anlamsal bir ağdır. Layman'ın terimleriyle, bilgi grafiği, tüm farklı bilgi türlerini (Heterojen Bilgi) birbirine bağlayarak elde edilen ilişkisel bir ağdır ve sorunları ilişkiler açısından analiz etmek için bir perspektif sağlar. Bu perspektiften, kuralları bulma boyutundan anlama boyutuna yükselebiliriz, bu yüzden bazı insanlar bilgi grafiklerinin YZ'nin geleceği olduğunu söylüyor.
"Daguan Data bir yapay zeka şirketidir" cümlesi makinenin gözünde sadece bir dizi karakterdir, ancak bize göre üç kısma ayrılabilir: "Daguan Data" konusu, yüklem "" nesne "dir. Yapay Zeka Şirketi ". Öyleyse, makine bu cümleyi gördüğünde, artık bir dizge değil, özne, yüklem ve nesneye benzer şekilde "anlaşılabilen" bir yapı olacak şekilde bir veri organizasyonu biçimi var mı? Elbette bilgi grafiğinin yaptığı budur.
Bilgi grafiği, bir varlık ilişkisi ağ grafiği olarak ifade edilebilir Bir varlık, çizildiğinde bir düğüm olarak adlandırılan bilgi içeren bir bireydir; ilişki, çizildiğinde kenar olarak adlandırılan iki varlık arasındaki bir bağlantıdır. Yukarıdaki örneği ödünç alırsak, "Daguan Data bir yapay zeka şirketidir", "Daguan Data" ve "Yapay Zeka Şirketi" iki varlıktır ve "Evet" bu iki varlık arasındaki ilişkidir. Yani bu cümle bir bilgi grafiği ile aşağıdaki şekil ile ifade edilebilir.
2. Bilgi grafiğinin uygulama senaryoları
Bilgi grafiğinin ne olduğunu bilerek, o zaman bilgi grafiğinin kullanımı nedir? Burada iki örnek vereceğim: bilgi grafiklerinin arama motorlarındaki rolü ve banka risk kontrol sistemlerindeki uygulamaları.
1. Bilgi Grafiğinin Arama Motorunda Uygulanması
Bazen bir arama motoru kullandığımızda, arama terimimiz (Sorgu) genellikle "Zhang San nereden mezun oldu" gibi bir soruya daha çok benziyor, o zaman doğrudan istediğim sonuçları vermek için arama motoruna ihtiyacımız var , Bir sayfa sıralaması değil. Örneğin, Google'da "Zuckerberg'in karısı kimdir" diye arama yaptığımda, bilgilerini içeren bazı web sayfaları yerine Zuckerberg'in eşi Priscilla Chen'in ayrıntılı bilgilerine ihtiyacım var. Önce google sonuçlarına bakalım:
Peki Google bunu nasıl yaptı? Aslında, 2012 gibi erken bir tarihte, Google, aramaya bir bilgi grafiği ekledi. Kullanıcılar, Google tarafından oluşturulan bilgi grafiği aracılığıyla doğrudan sonuçları sorgulayabilir ve bu da kullanıcı deneyimini büyük ölçüde iyileştirir. Bununla birlikte, Google'ın işlemesi de nispeten uygundur. İlk olarak, "Zuckerberg'in karısı kimdir" sorgusu, doğal dil işleme teknolojisi (NLP) aracılığıyla "Zuckerberg" varlığı ile "has_wife" arasındaki ilişkiye işlenir. Yerleşik bilgi grafiğinde sorgulama yapın ve ardından sorgu sonucunu kullanıcıya döndürün.
Ancak tam da böyle bir değişiklik ... Kullanıcı kullanımı açısından normal bir arama motorundan akıllı bir soru cevaplama sistemine dönüştü ve kullanıcı deneyimi bir seviyeye yükseldi.
2. Örtülü ilişkilerin madenciliğinde bilgi grafiğinin uygulanması
Max Weber bir keresinde "insanlar kendi kendine örülmüş anlamlar ağında asılı olan hayvanlardır" demişti Bu cümle, insanlar arasındaki ilişkinin çok karmaşık olduğunu yandan gösteriyor. Karmaşık kişilerarası ilişkiyi inceleyebilir miyiz? ?
Her şeyden önce, kişilerarası ilişki aslında bir ağ şeklinde şekillenir, bir ağ olduğu için bir özelliği olması gerekir, yani ağdaki iki bitişik düğüm arasındaki yolun hasarının tüm ağı etkilemesi gerekmez. Örneğin, bir ağdaki A düğümünden B düğümüne giden yol (yönlendirilmemiş grafik) "bozuksa", tüm ağı etkilemeden A'dan B'ye başka bir yol bulmak çok mümkündür. Peki, web'in bu özelliği veri madenciliğine nasıl uygulanmalıdır? Bir bankanın risk kontrol sistemindeki bir bilgi grafiği örneğine bakalım.
Borç alan tarafından borç alırken doldurulan ilişkiye dayalı bir bilgi grafiği oluşturabiliriz.Şekilde gösterildiği gibi, borçlunun Zhang San ile bir arkadaş ilişkisi ve Li Si ile bir baba-oğul ilişkisi vardır. Borçlunun bilgilerini bilgi grafiğine eklemeye çalıştığımızda, "tutarlılık doğrulama" motoru tetiklenecektir. Motor, "üçgen ilişkisinin" doğru olup olmadığını doğrulamak için önce Zhang San ve Li Si arasındaki ilişkiyi okuyacaktır. Açıkçası, bir arkadaşın arkadaşı baba-oğul ilişkisi değildir, bu yüzden bariz riskler vardır. Buradaki örtük ilişki madenciliği genel bir ilişki madenciliği motorunu ödünç alabilir veya örtük ilişki madenciliği motorunu kendi başına uygulayabilir. Çok yönlülüğü nedeniyle, genel ilişki ilişkilerinin madenciliği, ilişki madenciliğinin doğruluğunu sağlamak için genellikle zordur.Genellikle, kurallar ilişki madenciliğinin doğruluğunu sağlamak için yapılandırılır. Örtük ilişkiler madenciliği teknolojisi şu anda bilgi grafiği araştırmalarının sınırını oluşturmaktadır.Eğer ilgileniyorsanız, ilgili makalelere başvurabilirsiniz.
Banka riski kontrolünde, borçluları bulmak için kayıp borçluların iki veya hatta birden çok kazılması gibi bilgi grafiklerinin daha birçok işlevi vardır. "İlişki" ne kadar karmaşık olursa bilgi grafiğinin de o kadar etkili olabileceği görülebilir.
Bilgi grafiklerinin burada listelenmeyen birçok başka uygulama senaryosu vardır. İlgileniyorsanız, lütfen "Bilgi Grafiklerinin Uygulamaları" na bakın.
3. Bilgi Grafiğinin Oluşturulması
Bilgi grafiği çok faydalı olduğundan, kendi bilgi grafiğinizi nasıl oluşturabilirsiniz ve geleneksel verileri bir bilgi grafiğine nasıl dönüştürebilirsiniz?
Geleneksel veriler temel olarak iki türe ayrılır: biçimlendirilmiş veriler ve biçimlendirilmemiş veriler. Biçimlendirilmiş veriler bir bilgi grafiğine dönüştürüldüğünde, biçimlendirilmiş verilerin bir bilgi grafiği oluşturmak için varlık ilişkisi gruplarına eşlenmesi gerekir. Bununla birlikte, biçimlendirilmemiş verilerin dönüştürülmesi daha karmaşıktır ve genellikle iki algoritma çıkarma ve program çıkarma yöntemi kullanılır.
1. Algoritma çıkarma yöntemi:
Doğal dil işleme (NLP) teknolojisi sayesinde, metne varlık tanıma (NER) adı verilir ve uygun isimler ve anlamlı ifadeler, formatlanmamış metinden tanınır ve sınıflandırılır. Örneğin, yukarıdaki örnekte, "Daguan Data" ve "Artificial Intelligence Company" adlı iki varlık, "Daguan Data bir yapay zeka şirketidir" metninden ve "Evet" alt ilişkisinden tanımlanmıştır, böylece "Daguan Verileri" ni iletebiliriz "Evet" "Yapay Zeka Şirketi", bir bilgi grafiği oluşturmak için bir varlık grubudur. Mevcut NER tanıma teknolojisi yeterince olgun olmadığından, tanımlanan varlıkların doğruluğunu sağlamak için genellikle NER tarafından tanımlanan varlıkları manuel olarak düzeltiriz.
2. Program çıkarma yöntemi:
Biçimlendirilmemiş varlık tanıma verilerini işleme sürecinde, genellikle bir özgeçmiş metni gibi yarı biçimlendirilmiş verilerle karşılaşırız. Metin genellikle ad: XXX ve şirket adı: XXX gibi biçimleri içerir. Bilgi grafiği yapısının eksiksizliğini ve doğruluğunu sağlamak için biçimlendirilmiş metni çıkarmak için normal yöntemler de kullanabiliriz.
4. bilgi grafiğinin ve neo4j performans testinin saklanması
Bilgi grafiği, genellikle bir grafik veritabanında depolanan, grafik tabanlı bir veri yapısıdır, önce grafik veritabanı sıralamasına bir göz atalım.
Neo4j veri tabanının çok ileride olduğu sıralama listesinden görülebilir.Aslında neo4j, sektördeki bilgi grafiklerini analiz etmek için zaten ana veri tabanıdır. Peki neo4j grafik veritabanı projeye nasıl uygulanır ve neo4j grafik veritabanı nasıl optimize edilir? Öncelikle neo4j'nin performansına bir göz atalım:
test ortamı:
1. İşletim sistemi: Mac OS X 10.10.5
2. Bellek: 8G
3. cpu parametreleri: 8 çekirdek ve 8 iş parçacığı
4. Programlama dili: python 2.7
5. Neo4j sürümü: 3.3.0
6. Sunucu düğümlerinin sayısı: tek nokta
Test içeriği: Düğüm sayısı sırasıyla 10.000, 100.000, 1 milyon ve 10 milyon olduğunda, dizin ayarlandığında ve dizin ayarlanmadığında bir düğüm bulmanın ortalama gecikmesi. Test sonuçları aşağıdaki gibidir:
Yukarıdaki testten, düğüm sayısı 10 milyonu aştığında, ortalama sorgu gecikmesinin bir indeks ayarlamadan 6 saniyeyi aştığı görülebilir, bu da açıkça şu anda neo4j'nin açıkça "dayanılmaz" olduğunu gösterir. Bu gecikme, gerçek proje uygulamalarında tamamen kabul edilemez. Ancak, dizin ayarlandıktan sonra sorgu süresinin önemli ölçüde düştüğünü gördük, bu nedenle daha fazla dizin ayarlamak daha mı iyidir? 10 milyon düğüm durumunda indeksli ve indekssiz ekleme gecikme testine bakalım:
Yukarıdaki şeklin test sonuçlarından da görülebilir: On milyonlarca veri durumunda, indeks ekleme, indekssiz eklemeye göre% 30 daha yavaştır, bu nedenle daha fazla indeks daha iyi değildir, öyleyse neo4j için başka ne optimize edilebilir? Ne?
Beş. Neo4j grafik veritabanı optimizasyonu
Hiçbir şema kullanılmaz, bu nedenle teorik olarak neo4j her türlü veriyi depolayabilir. Ancak neo4j, düğümlerin ve ilişkilerin öznitelik değerlerini anahtar-değer çiftlerinin iki yönlü bir listesi aracılığıyla kaydettiğinden, neo4j yalnızca varlık ilişkilerini ve varlıkların basit özniteliklerini depolamak için uygundur. Gerçek uygulamalarda, bir varlık genellikle birçok öznitelik içerir. Tüm bu öznitelikler neo4j'de saklanırsa, neo4j'nin sorgusu anormal şekilde yavaşlayacaktır. Gerçek uygulama senaryolarında, yüksek eşzamanlılıkla sık sık karşılaşılır. Şu anda, tek düğümlü neo4j güçsüz görünecek. Peki, gerçek proje savaşında yüksek eşzamanlılığa direnmek için neo4j nasıl daha iyi kullanılır?
1. Yüksek düzeyde kullanılabilir mimari:
HA (Yüksek Kullanılabilirlik), neo4j'nin yüksek kullanılabilirlik özelliğidir, ancak bu özellik yalnızca neo4j kurumsal sürümünde mevcuttur. neo4j HA, tek bir neo4j ana veritabanının hataya dayanıklı mimarisini değiştirmek için birden çok neo4j bağımlı veritabanı ayarı kullanır. Bu mimari, veritabanının fiziksel bir makine arızası durumunda mükemmel okuma ve yazma işlemlerine sahip olmasını sağlayabilir. Neo4j HA, ana-bağımlı veri senkronizasyonunu kullanır , Ve yazma işlemleri, bağımlı kitaplıkta da gerçekleştirilebilir (bu yöntem, ana düğüm yazma kadar güvenilir değildir), bu nedenle neo4j HA'nın kullanımı, tek bir neo4j veritabanından daha fazla okuma yükü işleme kapasitesine sahiptir.
Neo4j kurumsal sürümünü kullanmıyorsanız, yüksek kullanılabilirliğe sahip bir mimari elde etmek için kendiniz bir neo4j kümesi oluşturmanız gerekebilir. Elbette Neo4j + DRBD'yi (Dağıtılmış Çoğaltılmış Blok) kullanabilirsiniz.
Device) + Kendi neo4j kümenizi oluşturmak için Keepalived yöntemi, neo4j kitaplık verilerini tek bir noktada yedeklemek için DRBD'yi kullanın ve kümenizi yönetmek için Keepalived'ı kullanın. Ek olarak, küme düğümlerinizi zookeeper aracılığıyla yönetebilir ve ana düğüm veri modifikasyonunun Cypher cümle öğesi işlemlerini yardımcı düğümlerle (MySQL binlog'a benzer) senkronize ederek ana-bağımlı senkronizasyon elde edebilir, böylece okuma-yazma ayrımı elde edebilirsiniz. Elbette, birinci yöntemi veya ikinci yöntemi kullanın, geliştirme ve bakım maliyetlerini artıracaktır.
2. Önbelleği artırın:
Uygulama önbelleği: Gerçek uygulama sürecinde, galeriyi okurken ve yazarken sık sık değiştirilmeyen bazı verilerle karşılaşırız.Örneğin, kullanıcının ülke bilgilerini sık sık sorgulamamız gerekir ve ülke özellik değişikliklerinin sıklığı nispeten düşüktür ve kullanıcının uyruğu bilgileri Sık sık değişmez, şu anda sorgu sonuçlarını önbelleğe almak, galeriye doğrudan erişim sıklığını azaltmak ve galeriyi okuma baskısını azaltmak için uygulama önbelleklerini (redis, leveldb vb.) Ekleyebiliriz.
Veritabanı önbelleği: neo4j bir sorgu işlemi gerçekleştirdikten sonra, verileri bellekte önbelleğe alacak ve aynı sorgu işlemini gerçekleştirecektir Neo4j, bellekte önbelleğe alınan verileri doğrudan geri döndürür. Rastgele bir sorgu gerçekleştirilirse, sonraki sorgunun sonucu, önceki sorgunun verilerinin üzerine yazılır Bellek önbelleğinin yapılandırması, yapılandırma dosyasındaki dbms.query_cache_size parametresi değiştirilerek ayarlanabilir. Bu nedenle, ifadeleri çalıştırırken, Cache-Miss durumlarının oluşumunu azaltmak için mevcut veri önbelleğini mümkün olduğunca kullanın.
3. Dizin sorgu optimizasyonu:
Sorgu optimizasyonu: neo4j sorgu sonuçlarını bellekte önbelleğe aldığından, aşağıdaki cypher deyimi gibi gereksiz sorgu sonuçlarını belleğe koymamaya çalışın:
1. MAÇ (n) İSTEĞE BAĞLI MAÇ (n) - > () GERİ DÖNÜŞ sayısı (n.prop) + sayı (r.prop);
2. MAÇ (n) İSTEĞE BAĞLI MAÇ (n) - > () DÖNÜŞ sayımı (*) + sayım (*);
İfade 1, ifade 2'den daha iyidir, çünkü ikincisi, tüm düğümlerin ve ilişkilerin özniteliklerini belleğe yükleyecek ve ardından sayma değerini hesaplayacak, ilki ise, sayma değerini değerlendirmek için yalnızca gerekli öznitelikleri belleğe yükleyecektir.
İndeks optimizasyonu: Veritabanı indeksinin aslında belirli bir algoritmanın (B + Ağacı gibi) veri yapısını verilerin dışında tuttuğunu biliyoruz.Örneğin, Şekil 7, Col2 sorgusunu hızlandırmak için bir ikili ağaç oluşturur, böylece orijinal "sıralı" arama "İkili arama" sorgu karmaşıklığını o (logn) değerine düşürür ve dizin ayrıca aramayı hızlandırmak için işletim sisteminin sayfa önbelleğinden tam olarak yararlanmak için erişim yerelliği ilkesini kullanır.
Bir indeksin eklenmesi, kütüphanenin verileri korurken ek bir veri yapısını korumasına izin vereceğinden, verileri güncellerken ek yüke neden olur Bu aynı zamanda, yukarıdaki teste veri eklenirken hiçbir indeksin indeksten daha hızlı olmadığı sonucunu da doğrular.
Neo4j 1.4 ve sonraki sürümleri otomatik indeks (otomatik indeks) tanıttı, otomatik indeks oluşturmayı config / neo4j.properties içinde yapılandırabilir veya CREATE ifadesini kullanabilirsiniz.
DİZİN AÇIK: Etiket (ÖzellikAdı) sorgu verimliliğini artırmak için manuel olarak bir dizin oluşturur.
4. Neo4j ve KV (Anahtar-Değer) veritabanının ortak kullanımı
Neo4j'in düğüm ve ilişki öznitelikleri Anahtar-Değer üzerinden olduğu için
İki yönlü liste kaydedilir, bu nedenle bu veri düğümü, neo4j'de depolanan düğümlerin çok fazla öznitelik değeri içeremeyeceğini belirler. Bununla birlikte, pratik uygulamalarda, bazı varlıklar genellikle çok sayıda özniteliğe sahiptir.Gerekirse, varlıkların sahip olduğu ilişkileri bulmak için bu özniteliklerin değerleri aracılığıyla varlıkları sorgulamak gerekir. Şu anda neo4j veritabanı ve KV veritabanı (MongoDB gibi) birlikte kullanılabilir, örneğin MongoDB'deki objectId neo4j düğümünün özniteliğinde saklanabilir. Bu şekilde, ilişkisel sorgular gerçekleştirmek için neo4j'nin özelliklerinden tam olarak faydalanabilir ve ayrıca varlıkların özniteliklerini sorgulamak için KV veritabanının özelliklerini kullanabilirsiniz. Genellikle kütüphane KV veritabanı ile bağlantılı olarak kullanıldığında, varlıkları özniteliklere göre sorgularken, yani neo4j'deki KV veritabanıyla ilişkili değerin indeksini ayarlamak için neo4j şema İndeksini ayarlamak gerekir.
Özet ve görünüm
Bilgi grafiği ve Neo4j'nin de birçok ilginç özelliği var, bu yüzden uzunlukları nedeniyle burada tekrar etmeyeceğim. Google'ın 2012'de bilgi grafiği teknolojisini piyasaya sürmesinden bu yana, bilgi grafiği hızlı bir gelişmeye yol açtı. İlişkisel "anlayışta" bilgi grafiğinin avantajı nedeniyle büyük internet şirketlerinin ve geleneksel işletmelerin projelerinde uygulanmış ve güzel sonuçlar elde etmiştir. Kesin olarak, bilgi grafiği verileri anlamak için geleneksel yöntemlerle tutarsız olduğundan, geleneksel veri madenciliği algoritmalarına zorluklar getirir. İnsanlar bilgi grafiklerine daha fazla önem verdikçe, bilgi grafikleri alanında daha olgun inşaat, depolama ve madencilik kavramlarının ortaya çıkacağına inanıyorum.Yakın gelecekte bilgi grafiklerinin daha geniş bir alanda olacağına inanıyorum. Herkese hizmet et.
Transfer adresi: https://zhuanlan.zhihu.com/p/36404872
