نمذجة بيانات الرسم البياني باستخدام Azure Cosmos DB ل Apache Gremlin

ينطبق على: العفريت

توفر هذه المقالة توصيات لاستخدام نماذج بيانات الرسم البياني. تعد أفضل الممارسات هذه حيوية لضمان قابلية التوسع والأداء لنظام قاعدة بيانات الرسم البياني مع تطور البيانات. يعد نموذج البيانات الفعال مهما بشكل خاص للرسوم البيانية واسعة النطاق.

المتطلبات

تستند العملية الموضحة في هذا الدليل إلى الافتراضات التالية:

  • يتم تعريف الكيانات الموجودة في مساحة المشكلة. والمقصود من هذه الكيانات أن تُستهلك ذرياً لكل طلب. بمعنى آخر، لم يتم تصميم نظام قاعدة البيانات لاسترداد بيانات كيان واحد في طلبات استعلام متعددة.
  • هناك فهم لمتطلبات القراءة والكتابة لنظام قاعدة البيانات. توجه هذه المتطلبات التحسينات اللازمة لنموذج بيانات الرسم البياني.
  • مبادئ معايير رسم بياني خاصية Apache Tinkerpop مفهومة جيداً.

متى أحتاج إلى قاعدة بيانات رسم بياني؟

يمكن استخدام حل قاعدة بيانات الرسم البياني على النحو الأمثل إذا كانت الكيانات والعلاقات في مجال البيانات لها أي من الخصائص التالية:

  • ترتبط الكيانات بشكل كبير من خلال العلاقات الوصفية. الفائدة في هذا السيناريو هي أن العلاقات تستمر في التخزين.
  • هناك علاقات دورية أو كيانات مرجعية ذاتياً. غالبا ما يكون هذا النمط تحديا عند استخدام قواعد البيانات الارتباطية أو قواعد بيانات المستندات.
  • وهناك علاقات تتطور ديناميكياً بين الكيانات. ينطبق هذا النمط بشكل خاص على البيانات الهرمية أو الهيكلية مع العديد من المستويات.
  • هناك علاقات متعدد إلى متعدد بين الكيانات.
  • هناك متطلبات الكتابة والقراءة على كل من الكيانات والعلاقات.

إذا تم استيفاء المعايير المذكورة أعلاه، فإن نهج قاعدة بيانات الرسم البياني يوفر على الأرجح مزايا لتعقيد الاستعلاموقابلية توسع نموذج البياناتوأداء الاستعلام.

الخطوة التالية هي تحديد ما إذا كان الرسم البياني سيستخدم لأغراض تحليلية أو معاملات. إذا كان الرسم البياني مخصصا لاستخدامه في أحمال عمل الحساب ومعالجة البيانات الثقيلة، فمن المفيد استكشاف موصل Cosmos DB Sparkومكتبة GraphX.

كيفية استخدام كائنات الرسم البياني

يحدد معيار الرسم البياني لخاصية Apache Tinkerpop نوعين من العناصر: الرؤوسوالحواف.

فيما يلي أفضل الممارسات للخصائص في كائنات الرسم البياني:

عنصر الخاصية النوع ملاحظات
الذروة المعرف سلسلة يتم فرضه بشكل مفرد لكل قسم. إذا لم يتم توفير قيمة عند الإدراج، يتم تخزين GUID تم إنشاؤه تلقائيا.
الذروة تسمية سلسلة يتم استخدام هذه الخاصية لتعريف نوع الكيان الذي تمثله الذروة. إذا لم يتم توفير قيمة، يتم استخدام ذروة قيمة افتراضية.
الذروة الخصائص سلسلة، منطقية، رقمية قائمة من الخصائص المنفصلة المخزنة كأزواج قيم المفاتيح في كل ذروة.
الذروة مفتاح القسم سلسلة، منطقية، رقمية تحدد هذه الخاصية مكان تخزين الذروة وحوافها الصادرة. اقرأ المزيد حول تقسيم الرسم البياني.
Edge المعرف سلسلة يتم فرضه بشكل مفرد لكل قسم. يتم إنشاؤه تلقائياً بشكل افتراضي. لا تحتاج الحواف عادة إلى استردادها بشكل فريد بواسطة معرف.
Edge تسمية سلسلة يتم استخدام هذه الخاصية لتعريف نوع العلاقة التي تمتلكها ذروتان.
Edge الخصائص سلسلة، منطقية، رقمية قائمة من الخصائص المنفصلة المخزنة كأزواج قيمة المفتاح في كل حافة.

ملاحظة

لا تتطلب الحواف قيمة مفتاح القسم، حيث يتم تعيين القيمة تلقائيا استنادا إلى ذروة المصدر الخاصة بها. تعرف على المزيد في الرسم البياني باستخدام تقسيم في Azure Cosmos DB.

إرشادات نمذجة الكيان والعلاقة

تساعدك الإرشادات التالية على التعامل مع نمذجة البيانات لقاعدة بيانات الرسم البياني Azure Cosmos DB ل Apache Gremlin . تفترض هذه الإرشادات وجود تعريف موجود لنطاق البيانات والاستعلامات عنه.

ملاحظة

يتم تقديم الخطوات التالية كتوصيات. يجب تقييم النموذج النهائي واختباره قبل اعتباره جاهزا للإنتاج. بالإضافة إلى ذلك، فإن التوصيات خاصة بتنفيذ واجهة برمجة تطبيقات Gremlin من Azure Cosmos DB.

نمذجة الذروات والخصائص

الخطوة الأولى لنمذجة بيانات رسم بياني هي لتعيين كل كيان معرف إلى كائن ذروة. يجب أن يكون تعيين واحد إلى واحد لجميع الكيانات إلى الذروات خطوة أولية وعرضة للتغيير.

أحد المآزق الشائعة هو تعيين خصائص كيان واحد كذروات منفصلة. ضع في اعتبارك المثال التالي، حيث يتم تمثيل نفس الكيان بطريقتين مختلفتين:

  • الخصائص المستندة إلى ذروة: في هذا الأسلوب، يستخدم الكيان ثلاث ذروات منفصلة وحواف اثنين لوصف خصائصه. وفي حين أن هذا النهج قد يقلل من التكرار، فإنه يزيد من تعقيد النموذج. يمكن أن تؤدي زيادة تعقيد النموذج إلى زمن انتقال إضافي وتعقيد الاستعلام وتكلفة الحساب. هذا النموذج قد يقدم أيضاً تحديات في التقسيم.

    رسم تخطيطي لنموذج الكيان مع رؤوس للخصائص.

  • رؤوس مضمنةفي الخاصية: يستفيد هذا الأسلوب من قائمة زوج قيم المفاتيح لتمثيل جميع خصائص الكيان داخل ذروة. يقلل هذا الأسلوب من تعقيد النموذج، ما يؤدي إلى استعلامات أبسط واجتيازات أكثر كفاءة من حيث التكلفة.

    رسم تخطيطي لرأس Luis من الرسم التخطيطي السابق مع المعرف والتسمية والخصائص.

ملاحظة

تظهر الرسومات التخطيطية السابقة نموذج رسم بياني مبسط يقارن فقط بين الطريقتين لتقسيم خصائص الكيان.

يوفر نمط الذروات ذات الخصائص بشكل عام نهجاً أكثر أداء وقابل للتوسع. يجب أن ينجذب النهج الافتراضي لنموذج بيانات الرسم البياني الجديد إلى هذا النمط.

ومع ذلك، هناك سيناريوهات حيث قد يوفر الرجوع إلى خاصية مزايا. على سبيل المثال، إذا تم تحديث الخاصية المشار إليها بشكل متكرر. استخدم ذروة منفصلة لتمثيل خاصية تتغير باستمرار لتقليل مقدار عمليات الكتابة التي يتطلبها التحديث.

نماذج العلاقة مع اتجاهات الحافة

بعد أن يتم نمذجة الذروات، يمكن إضافة الحواف للدلالة على العلاقات بينها. الجانب الأول الذي يحتاج إلى تقييم هو اتجاه العلاقة.

كائنات الحافة لها اتجاه افتراضي متبوعا باجتياز عند استخدام out() الدالتين أو outE() . يؤدي استخدام هذا الاتجاه الطبيعي إلى عملية فعالة، حيث يتم تخزين جميع الذروات مع حوافها الصادرة.

ومع ذلك، يؤدي الاجتياز في الاتجاه المعاكس للحافة، باستخدام الدالة in() ، دائما إلى استعلام عبر الأقسام. اقرأ المزيد حول تقسيم الرسم البياني. إذا كانت هناك حاجة إلى الاجتياز باستمرار باستخدام الدالةin()، فمن المستحسن إضافة حواف في كلا الاتجاهين.

يمكنك تحديد اتجاه الحافة باستخدام .to() دالات التقييم أو .from() مع .addE() خطوة Gremlin. أو باستخدام مكتبة المنفذ المجمعة لـ Gremlin API.

ملاحظة

كائنات الحافة لها اتجاه بشكل افتراضي.

تسميات العلاقات

إن استخدام تسميات وصفية للعلاقة سوف يحسن كفاءة عمليات دقة الحافة. يمكنك تطبيق هذا النمط بالطرق التالية:

  • استخدم مصطلحات غير عامة لتسمية علاقة.
  • إقران تسمية ذروة المصدر بتسمية ذروة الهدف باسم العلاقة.

رسم تخطيطي للأمثلة على تسمية العلاقة.

كلما كانت التسمية التي يستخدمها الاجتياز أكثر تحديدا لتصفية الحواف، كان ذلك أفضل. يمكن أن يكون لهذا القرار تأثير كبير على تكلفة الاستعلام أيضا. يمكنك تقييم تكلفة الاستعلام في أي وقت باستخدام خطوة executionProfile.

الخطوات التالية