https://www.yangdb.org/
ويكي
معلومات الإصدار
الإصدار.ملاحظات
ليئور بيري
رومان مارجوليس
موتي كوهين
العاد ويس
شمعون بنوشتي
منشور يقدم مبادرتنا الجديدة مفتوحة المصدر لبناء قاعدة بيانات للرسم البياني الموزع قابلة للتطوير عبر Opensearch https://www.linkedin.com/pulse/making-db-lior-perry/
استخدام آخر لـ Opensearch كرسم بياني DB https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
كان لعالم قواعد بيانات الرسم البياني تأثير هائل خلال السنوات القليلة الماضية، لا سيما فيما يتعلق بالشبكات الاجتماعية وتأثيرها على نشاطنا اليومي.
إن نظام RDBMS الذي كان قويًا (ووحيدًا) أصبح الآن مضطرًا لإفساح المجال لشريك ناشئ ومتزايد الأهمية في مركز البيانات: قاعدة بيانات الرسم البياني.
يستخدمه تويتر، ويستخدمه فيسبوك، وحتى مواقع المواعدة عبر الإنترنت تستخدمه؛ إنهم يستخدمون الرسوم البيانية العلاقة. بعد كل شيء، الاجتماعي هو اجتماعي، وفي نهاية المطاف، الأمر كله يتعلق بالعلاقات.
هناك عنصران رئيسيان يميزان تقنية الرسم البياني: التخزين والمعالجة.
يشير تخزين الرسم البياني عادةً إلى بنية قاعدة البيانات التي تحتوي على بيانات الرسم البياني.
تم تحسين تخزين الرسم البياني هذا للرسوم البيانية في العديد من الجوانب، مما يضمن تخزين البيانات بكفاءة، والحفاظ على العقد والعلاقات قريبة من بعضها البعض في الطبقة المادية الفعلية.
يتم تصنيف تخزين الرسم البياني على أنه غير أصلي عندما يأتي التخزين من مصدر خارجي، مثل قاعدة بيانات علائقية أو عمودية أو أي نوع آخر من قواعد البيانات (يفضل مخزن NoSQL في معظم الحالات).
تشتمل قواعد بيانات الرسم البياني غير الأصلية عادةً على مخازن علائقية ومستندات وقيمة أساسية موجودة، تم تكييفها لسيناريوهات استعلام نموذج بيانات الرسم البياني.
تتضمن معالجة الرسم البياني الوصول إلى الرسم البياني وعبور القمم والحواف وجمع النتائج.
الاجتياز هو كيفية الاستعلام عن الرسم البياني، والانتقال من عقد البداية إلى العقد ذات الصلة، وتتبع العلاقات وفقًا لبعض القواعد.
العثور على إجابات لأسئلة مثل "ما هي الموسيقى التي يحبها أصدقائي والتي لا أملكها بعد؟"
أحد النماذج الأكثر شيوعًا لتمثيل الرسم البياني هو نموذج الخاصية.
يحتوي هذا النموذج على كيانات متصلة (العقد) يمكنها الاحتفاظ بأي عدد من السمات (أزواج القيمة الرئيسية).
تمتلك العقد معرفًا فريدًا وتمثل قائمة السمات ميزاتها ومحتواها.
يمكن تمييز العقد بتسميات تمثل أدوارها المختلفة في المجال الخاص بك. بالإضافة إلى خصائص العلاقة، يمكن أن تخدم التسميات أيضًا بيانات التعريف عبر عناصر الرسم البياني.
غالبًا ما تُستخدم العقد لتمثيل الكيانات ولكن اعتمادًا على علاقات المجال يمكن استخدامها لهذا الغرض أيضًا.
يتم تمثيل العلاقة من خلال العقدة المصدر والهدف التي يتصلان بها وفي حالة وجود اتصالات متعددة بين نفس القمم – تسمية إضافية للخاصية للتمييز (نوع العلاقة)
تنظم العلاقات العقد في هياكل عشوائية، مما يسمح للرسم البياني بأن يشبه قائمة أو شجرة أو خريطة أو كيانًا مركبًا - يمكن دمج أي منها في هياكل أكثر تعقيدًا.
تشبه إلى حد كبير المفاتيح الخارجية بين الجداول في نموذج قاعدة البيانات العلائقية، في نموذج الرسم البياني تصف العلاقة العلاقات بين القمم.
أحد الاختلافات الرئيسية في هذا النموذج (مقارنة بالمخطط العلائقي الصارم) هو أن هذا الهيكل بدون مخطط يتيح إضافة/إزالة العلاقة بين القمم دون أي قيود.
نموذج الرسم البياني الإضافي هو نموذج إطار وصف الموارد (RDF).
حالة الاستخدام لدينا تقع في مجال الشبكات الاجتماعية. رسم بياني اجتماعي كبير جدًا يجب تحديثه بشكل متكرر وإتاحته لكل من:
بحث بسيط (نصي في الغالب).
الاستعلامات القائمة على الرسم البياني.
تتم جميع عمليات القراءة والكتابة بالتزامن مع وقت استجابة معقول وإنتاجية متزايدة باستمرار.
تم استيفاء المتطلب الأول باستخدام Opensearch - وهو محرك بحث وتخزين مستندات NoSql معروف وراسخ وقادر على احتواء حجم كبير جدًا من البيانات.
بالنسبة للمطلب الثاني ، قررنا أن أفضل حل لدينا هو استخدام Opensearch كطبقة تخزين قاعدة بيانات الرسم البياني غير الأصلية .
كما ذكرنا من قبل، يمكن تنفيذ طبقة تخزين graph-DB باستخدام تخزين غير أصلي مثل تخزين NoSql.
في المناقشة المستقبلية، سوف أتطرق إلى التفاصيل حول سبب عدم تمكن البديل المجتمعي الأكثر شيوعًا لـ graph-DB - Neo4J، من تلبية احتياجاتنا.
المسألة الأولى على لوحتنا هي تصميم نموذج البيانات الذي يمثل الرسم البياني، كمجموعة من القمم والحواف.
باستخدام Opensearch، يمكننا الاستفادة من قدرات البحث القوية لجلب مستندات العقد والعلاقة بكفاءة وفقًا لمرشحات الاستعلام.
في Opensearch، يمكن وصف كل فهرس كجدول لمخطط محدد، ويتم تقسيم الفهرس نفسه إلى فهرس مشترك مما يسمح بالتوسع والتكرار (مع النسخ المتماثلة) عبر المجموعة.
يتم توجيه المستند إلى جزء معين في الفهرس باستخدام الصيغة التالية:
shard_num = hash(_routing) % num_primary_shards
يحتوي كل فهرس على مخطط (يسمى النوع في Opensearch) والذي يحدد بنية المستندات (يسمى التعيين في Opensearch). يمكن لكل فهرس أن يحتوي على نوع واحد فقط من التعيينات (منذ Opensearch 6)
سيحتوي فهرس القمم على مستندات القمم مع خصائصها، وسيحتوي فهرس الحواف على مستندات الحواف مع خصائصها.
الطريقة التي نصف بها كيفية اجتياز الرسم البياني (مصدر البيانات)
هناك عدد قليل من لغات الاستعلام الموجهة نحو الرسم البياني:
Cypher هي لغة استعلام لقاعدة بيانات الرسم البياني Neo4j (راجع مبادرة openCypher)
Gremlin هي لغة اجتياز الرسم البياني لمؤسسة Apache Software لأنظمة الرسم البياني OLTP وOLAP.
SPARQL هي لغة استعلام للرسوم البيانية RDF.
تعتمد بعض اللغات بشكل أكبر على الأنماط والتصريحات، والبعض الآخر أكثر إلحاحًا - فجميعها تصف الطريقة المنطقية لاجتياز البيانات.
دعونا نفكر في Cypher - وهي لغة تعريفية مستوحاة من لغة SQL لوصف الأنماط في الرسوم البيانية بشكل مرئي باستخدام بناء جملة ascii-art.
فهو يتيح لنا تحديد ما نريد تحديده أو إدراجه أو تحديثه أو حذفه من بيانات الرسم البياني الخاصة بنا دون مطالبتنا بوصف كيفية القيام بذلك بالضبط.
بمجرد تقديم استعلام منطقي، نحتاج إلى ترجمته إلى الطبقة المادية لتخزين البيانات وهي Opensearch.
يحتوي Opensearch على استعلام DSL يركز على البحث والتجميعات - وليس على العبور، فنحن بحاجة إلى مرحلة ترجمة إضافية تأخذ في الاعتبار البنية التخطيطية للرسم البياني (والمؤشرات الأساسية).
ترجمة الاستعلام المنطقي إلى الفعلي هي عملية تتضمن خطوات قليلة:
التحقق من صحة الاستعلام مقابل المخطط
ترجمة التسميات إلى كيانات المخطط الحقيقي (المؤشرات)
إنشاء استعلام Opensearch الفعلي
هذه هي العملية في المراجعة عالية المستوى، من الناحية العملية - سيكون هناك المزيد من المراحل التي تعمل على تحسين الاستعلام المنطقي؛ في بعض الحالات من الممكن إنشاء خطط مادية متعددة (خطط التنفيذ) وترتيبها وفقًا لبعض استراتيجيات الكفاءة (التكلفة) مثل عدد العناصر اللازمة لجلب...
لقد بدأنا بمناقشة الغرض من قاعدة بيانات الرسوم البيانية في حالات استخدام الأعمال اليوم وقمنا بمراجعة نماذج مختلفة لتمثيل الرسم البياني. فهم اللبنات الأساسية المنطقية التي يجب أن تتكون منها قاعدة بيانات الرسم البياني المحتملة ومناقشة مرشح NoSql الحالي للوفاء بمتطلبات طبقة التخزين.
بمجرد اختيار Opensearch كطبقة تخزين، أخذنا نموذج الرسم البياني المعياري لشبكة LDBC الاجتماعية وقمنا بتبسيطه لتحسينه في هذا التخزين المحدد. ناقشنا مخطط التخزين الفعلي مع الخصائص المتكررة وقمنا بمراجعة لغة التشفير للاستعلام عن التخزين بلغة نمط الرسم البياني الشبيهة بـ SQL.
واصلنا رؤية التحول الفعلي للاستعلام المشفر إلى استعلام تنفيذ فعلي سيتم تشغيله بواسطة Opensearch.
في القسم الأخير، أجرينا استعلامًا بيانيًا بسيطًا وتعمقنا في تفاصيل استراتيجيات التنفيذ وآلية التضخيم.
البرنامج التعليمي للتثبيت:
البرنامج التعليمي لإنشاء المخطط:
البرنامج التعليمي لتحميل البيانات:
الاستعلام عن البرنامج التعليمي للرسم البياني:
البرنامج التعليمي لتجسيد الإسقاط والعد: