Apache Gremlin için Azure Cosmos DB ile graf veri modelleme

Önemli

99,999% kullanılabilirlik hizmet düzeyi sözleşmesi (SLA), anında otomatik ölçeklendirme ve birden çok bölgede otomatik yük devretme ile yüksek ölçekli senaryolar için bir veritabanı çözümü mü arıyorsunuz? NoSQL için Azure Cosmos DB'ye göz önünde bulundurun.

Çevrimiçi analitik işleme (OLAP) grafı uygulamak mı yoksa mevcut bir Apache Gremlin uygulamasını geçirmek mi istiyorsunuz? Microsoft Fabric'te Graph'i göz önünde bulundurun.

Bu makalede, grafik veri modellerinin kullanımına yönelik öneriler sağlanır. Bu en iyi yöntemler, veriler geliştikçe graf veritabanı sisteminin ölçeklenebilirliğini ve performansını sağlamak için çok önemlidir. Verimli bir veri modeli özellikle büyük ölçekli grafikler için önemlidir.

Gereksinimler

Bu kılavuzda özetlenen işlem aşağıdaki varsayımları temel alır:

• Sorun alanı içindeki varlıklar tanımlanır. Bu varlıkların her istek için atomik olarak tüketilmesi amaçlanır. Başka bir deyişle, veritabanı sistemi birden çok sorgu isteğinde tek bir varlığın verilerini alacak şekilde tasarlanmamıştır.
• Veritabanı sistemi için okuma ve yazma gereksinimleri hakkında bilgi vardır. Bu gereksinimler graf veri modeli için gereken iyileştirmelere yol gösterir.
• Apache'nin özellik grafiği standardının ilkeleri iyi anlaşılmıştır.

Graf veritabanına ne zaman ihtiyacım var?

Bir veri etki alanındaki varlıklar ve ilişkiler aşağıdaki özelliklerden herhangi birine sahipse graf veritabanı çözümü en uygun şekilde kullanılabilir:

• Varlıklar açıklayıcı ilişkiler aracılığıyla yüksek oranda bağlıdır . Bu senaryonun avantajı, ilişkilerin depolamada kalıcı olmasıdır.
• Döngüsel ilişkiler veya kendi kendine başvurulan varlıklar vardır. bu düzen genellikle ilişkisel veya belge veritabanlarını kullandığınızda bir zorluk oluşturur.
• Varlıklar arasında dinamik olarak gelişen ilişkiler vardır. Bu desen özellikle birçok düzeye sahip hiyerarşik veya ağaç yapılandırılmış veriler için geçerlidir.
• Varlıklar arasında çoka çok ilişkiler vardır.
• Hem varlıklar hem de ilişkilerde yazma ve okuma gereksinimleri vardır.

Yukarıdaki ölçütler karşılanırsa, grafik veritabanı yaklaşımı büyük olasılıkla sorgu karmaşıklığı, veri modeli ölçeklenebilirliği ve sorgu performansı için avantajlar sağlar.

Sonraki adım, grafiğin analiz veya işlem amaçları için kullanılıp kullanılmayacağını belirlemektir. Grafın yoğun hesaplama ve veri işleme iş yükleri için kullanılması amaçlanıyorsa Cosmos DB Spark bağlayıcısını ve GraphX kitaplığını keşfetmeye değer.

Grafik nesnelerini kullanma

Apache'nin özellik grafiği standardı iki tür nesne tanımlar: köşeler ve kenarlar.

Graf nesnelerindeki özellikler için en iyi yöntemler aşağıdadır:

Object	Özellik	Türü	Notlar
Köşe	Kimlik	String	Bölüm başına benzersiz olarak zorlanır. Ekleme işleminde bir değer sağlanmazsa, otomatik olarak oluşturulan BIR GUID depolanır.
Köşe	Etiket	String	Bu özellik köşenin temsil ettiği varlık türünü tanımlamak için kullanılır. Bir değer sağlanmazsa, varsayılan değer köşesi kullanılır.
Köşe	Properties	Dize, boole, sayısal	Her köşedeki anahtar-değer çiftleri olarak depolanan ayrı özelliklerin listesi.
Köşe	Bölüm anahtarı	Dize, boole, sayısal	Bu özellik, köşenin ve giden kenarlarının nerede depolandığını tanımlar. Grafik bölümleme hakkında daha fazla bilgi edinin.
Kenar	Kimlik	String	Bölüm başına benzersiz olarak zorlanır. Varsayılan olarak otomatik olarak oluşturulur. Kenarlar genellikle kimlik kullanılarak benzersiz bir şekilde alınması gerekmez.
Kenar	Etiket	String	Bu özellik, iki köşenin sahip olduğu ilişki türünü tanımlamak için kullanılır.
Kenar	Properties	Dize, boole, sayısal	Her kenarda anahtar-değer çiftleri olarak depolanan ayrı özelliklerin listesi.

Not

Kenarlar bölüm anahtarı değeri gerektirmez, çünkü değer kendi kaynak köşelerine göre otomatik olarak atanır. Azure Cosmos DB'de bölümlenmiş graf kullanma bölümünde daha fazla bilgi edinin.

Varlık ve ilişki modelleme yönergeleri

Aşağıdaki yönergeler, Apache Gremlin için Azure Cosmos DB graf veritabanı için veri modellemeye yaklaşmanıza yardımcı olur. Bu yönergelerde, veri etki alanının mevcut bir tanımı olduğu ve bu etki alanı için sorgular olduğu varsayılır.

Not

Aşağıdaki adımlar öneri olarak sunulur. Son modeli üretime hazır olarak değerlendirmeden önce değerlendirip test etmeniz gerekir. Ayrıca öneriler Azure Cosmos DB'nin Gremlin API uygulamasına özeldir.

Modelleme köşeleri ve özellikleri

Graf veri modelinin ilk adımı, tanımlanan her varlığı bir köşe nesnesine eşlemektir. Tüm varlıkların köşelere bire bir eşlenmesi ilk adım olmalı ve değiştirilebilir.

Yaygın bir tuzak, tek bir varlığın özelliklerini ayrı köşeler olarak eşlemektir. Aynı varlığın iki farklı şekilde temsil edildiği aşağıdaki örneği göz önünde bulundurun:

• Köşe tabanlı özellikler: Bu yaklaşımda varlık, özelliklerini açıklamak için üç ayrı köşe ve iki kenar kullanır. Bu yaklaşım yedekliliği azaltabilir ancak model karmaşıklığını artırır. Model karmaşıklığındaki artış ek gecikme süresi, sorgu karmaşıklığı ve hesaplama maliyetine neden olabilir. Bu model bölümleme konusunda da güçlükler sunabilir.

  

• Özellik eklenmiş köşeler: Bu yaklaşım, bir köşe içindeki varlığın tüm özelliklerini temsil etmek için anahtar-değer çifti listesinden yararlanır. Bu yaklaşım model karmaşıklığını azaltarak daha basit sorgulara ve daha uygun maliyetli çapraz geçişlere yol açar.

  

Not

Yukarıdaki diyagramlarda, varlık özelliklerini bölmenin yalnızca iki yolunu karşılaştıran basitleştirilmiş bir grafik modeli gösterilmektedir.

Özellik eklenmiş köşe deseni genellikle daha performanslı ve ölçeklenebilir bir yaklaşım sağlar. Yeni bir graf veri modeline yönelik varsayılan yaklaşım bu desene doğru çekim yapmalıdır.

Ancak, bir özelliğe başvurmanın avantajlar sağlayabileceği senaryolar vardır. Örneğin, başvuruda bulunan özellik sık sık güncelleştiriliyorsa. Güncelleştirmenin gerektirdiği yazma işlemi miktarını en aza indirmek için sürekli değişen bir özelliği temsil etmek için ayrı bir köşe kullanın.

Uç yönleri olan ilişki modelleri

Köşeler modellendikten sonra, aralarındaki ilişkileri belirtmek için kenarlar eklenebilir. Değerlendirilmesi gereken ilk yön, ilişkinin yönüdür.

Kenarlar, veya out() işlevlerini kullanırken outE() bir dolaşmanın ardından gelen varsayılan bir yöne sahiptir. Bu doğal yön, tüm köşeler giden kenarlarla depolandığından verimli bir işlemle sonuçlanıyor.

işlevini kullanarak in() bir kenarın ters yönünde geçiş yaparak her zaman bölümler arası sorgu elde edebilirsiniz. Grafik bölümleme hakkında daha fazla bilgi edinin. İşlevle in() sık sık dolaşma gerekiyorsa, kenarları her iki yönde de ekleyin.

Gremlin adımıyla .to() veya .from() koşullarını kullanarak .addE() kenar yönünü belirleyebilirsiniz. Veya Gremlin API için toplu yürütücü kitaplığını kullanarak.

Not

Kenarlar varsayılan olarak bir yöne sahiptir.

İlişki etiketleri

Açıklayıcı ilişki etiketlerinin kullanılması uç çözümleme işlemlerinin verimliliğini artırabilir. Bu deseni aşağıdaki yollarla uygulayabilirsiniz:

• bir ilişkiyi etiketlemek için genel olmayan terimler kullanın.
• Kaynak köşenin etiketini hedef köşenin etiketiyle ilişki adıyla ilişkilendirin.

Çapraz geçişin kenarları filtrelemek için kullandığı etiket ne kadar belirgin olursa o kadar iyi olur. Bu kararın sorgu maliyeti üzerinde de önemli bir etkisi olabilir. Adımını kullanarak executionProfile istediğiniz zaman sorgu maliyetini değerlendirebilirsiniz.