كيف تفسر المجاملة الخالية من الفهرس لمديرك

الشكل 1: شرح التقارب الخالي من الفهرس باستخدام استعارة الجيران المباشر - بحث سريع عن الذاكرة الفعلية.

يعد التقارب الخالي من الفهرس هو المفهوم الأكثر أهمية الذي نحتاج إلى فهمه عند معرفة قواعد بيانات الرسم البياني الأصلية. تحتوي الرسوم البيانية الأصلية على حالات استخدام مختلفة عن قواعد بيانات الرسم البياني غير الأصلية. عادةً ما يتم وضع أنظمة الرسوم البيانية غير الأصلية أعلى قواعد البيانات الأخرى التي لم يتم تحسينها من أجل اجتياز الرسم البياني السريع. يعد وجود نموذج عقلي واضح لهذه الاختلافات أمرًا ضروريًا لكتابة تبرير واضح للأعمال لأي مشروع من مشاريع Enterprise Knowledge Graph. ومع ذلك ، لا يكفي أن تفهم التقارب الخالي من الفهرس: يجب أن تكون قادرًا على شرح ذلك لزملائك غير التقنيين ، والأهم من ذلك مديرك وأي شخص آخر يرخص لمشروعك. لقد قمنا بتطوير استعارة لشرح التقارب الخالي من الفهرس والذي يبدو أنه يعمل. نحن نسميها استعارة "الجيران المباشر". من هنا تبدأ:

لنفترض أنك تعيش بجوار جار لطيف (يتيح لك الاتصال بها آن). وفي يوم بي تريد أن تأخذ لها فطيرة التفاح الساخنة لإقناعها. يمكنك إرسال رسالة نصية إلى آن واسألها عما إذا كانت تحب Apple Pie وتقول "نعم!" ، لذا يمكنك خبزها فطيرة وتريد الآن توصيلها إلى منزلها بسرعة بينما لا تزال الكعكة ساخنة. حتى هنا هي الخطوات (انظر الشكل 1):

  1. أنت تمشي خارج الباب.
  2. أنت تشير نحو منزل آن.
  3. أنت تمشي مباشرة إلى منزل آن ، الذي يستغرق حوالي 30 ثانية ، وتعطيها فطيرة التفاح الساخنة - وتحبها! نهاية سعيدة!

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

الشكل 2: نموذج منطقي لجارين.

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

الآن دعنا نقارن بنية الرسم البياني الأصلي مع الطريقة التي قد تقوم بها قواعد البيانات Relational أو قواعد بيانات الرسم البياني الأخرى غير الأصلية. يوصف هذا في الشكل 3.

الشكل 3: استخدام فهرس مركزي والبحث للعثور على عنوان منزل أحد الجيران.
  1. تمشي خارج الباب ، لكن في عالم RDBMS ، يُحظر عليك المشي إلى العناصر ذات الصلة عبر المؤشرات. تحتاج إلى الذهاب إلى المؤشر المركزي.
  2. قم بالسير في وسط المدينة إلى مبنى الحكومة الذي يشبه DMV حيث لديهم خط طويل للغاية يمتد إلى كتل.
  3. عندما تحصل في الطابور وانتظر دورك. وتقدر أوقات الانتظار في 6 ساعات.
  4. عندما تصل إلى مقدمة السطر ، تذهب إلى عداد وكيل البحث.
  5. يحتوي وكيل البحث على قائمة بجميع الأشخاص في بلدتك مرتبة حسب عناوينهم (تسمى الفهرس). يبحثون في القائمة (باستخدام خوارزمية البحث الثنائية). المشكلة هي أن هناك الكثير من الناس في مدينتك ، وكلما زاد عدد الأشخاص ، كلما استغرقت عملية البحث. يعود البحث ويعطونك أخيرًا إحداثيات GPS لمنزل جارك.
  6. يمكنك أخذ إحداثيات GPS هذه وإدخالها في خريطة هاتفك الخلوي واتبع الإرشادات إلى منزل آن. في المجموع ، يستغرق نقلة المؤشر 1000 مرة (قل 8 ساعات) للوصول إلى هناك.
  7. عندما تصل إلى هناك ، تكون الفطيرة باردة. إنها تمنحك درجة منخفضة صافي المروج على Neighborhood.com. هي تنشر: "رجل لطيف لكنه يأخذه إلى الأبد لتسليم الفطائر".

تلخص هذه القصة الفرق بين تنفيذ الرسم البياني الأصلي لقاعدة بيانات الرسم البياني والتغيرات غير الأصلية التي يتم وضعها فوق قواعد البيانات الأخرى. تأخذ الرسوم البيانية الأصلية البيانات المرتبطة منطقياً عبر الأقواس أو العلاقات وتصلب عناوين ذاكرة الوصول العشوائي الفعلية لهذه العناصر في العقدة. عمليات البحث عن العلاقة سريعة! يتم تخزين العقد المرتبطة في بعض الأحيان بجانب بعضها البعض في الذاكرة مما يزيد من فرص أن البيانات موجودة بالفعل في ذاكرة التخزين المؤقت لوحدات المعالجة المركزية الخاصة بك! نتيجة لذلك ، يمكنك "القفز" بين مليون عقدة تقريبًا كل ثانية لكل نواة لديك على الخادم الخاص بك. إذا كان لديك خادم نموذجي به 16 مركزًا ، فيمكنك تقييم 16 مليون قفزة في الثانية. إذا كنت تستخدم خادم Amazon x1e.32xlarge مع 128 مركزًا ، فيمكنك الحصول على 128 مليون قفزة في الثانية. وبالنسبة لأولئك منكم ممن لديهم ميزانيات على مستوى NSA ، يمكنك الحصول على Cray Graph Engine مع 8192 نواة ستنفذ 12.8 مليار (Giga) Traversal Edges Per Second (GTEPS) وفقًا لمعايير graph500 SSSP.

الشيء الذي يجب تذكره هو أن قواعد البيانات العلائقية ، من المفارقات ، بطيئة للغاية في البحث عن العلاقات. يطلق عليهم أحيانًا "مخازن الصفوف" لأن هدفهم الأساسي هو الوصول السريع تلو الآخر. لماذا ا؟ لأن أنظمة COBOL المبكرة التي تقرأ من البطاقات المثقوبة تقرأ بطاقة واحدة في كل مرة. لقد تم تصميمها لتجميع جميع الحقول في صفوفها معًا. لقد انتهى الأمر إلى وراثة تصميمات COBOL للملفات المسطحة وعمليات البحث عن العلاقة التحديثية لاحقًا كفكرة لاحقة. لذلك إذا كان لديك ملف مسطح كبير دون أي علاقات ، فالمتاجر السريعة سريعة للغاية! وبالنسبة للملفات المسطحة البسيطة ، لن تحتاج إلى البحث عن العلاقات باستخدام وظيفة البحث. والأسوأ من ذلك هو أن كل عملية JOIN علائقية هي عملية بحث تتضاعف عادةً عندما تضاعف حجم قاعدة البيانات الخاصة بك - ما يسمى عملية البحث الثنائية O (log (n)). وكلما زاد عدد المشتركين لديك كلما كان لديك أبطأ. تتفوق قواعد البيانات العلائقية في الاستعلامات على مجموعات البيانات الصغيرة ذات البنية المسطحة الموحدة. تتضمن قواعد بيانات الرسم البياني الأصلية Neo4j و ArangoDB و OrientDB (المملوكة الآن لـ SAS) و TigerGraph.

لا نريد الإيحاء بأن قيمته ليست قيمة لتخطيط الرسوم البيانية في الجزء العلوي من قواعد البيانات الأخرى. إذا كنت لا تبحث عن أنماط معقدة في مجموعات البيانات الكبيرة ، فقد تظل هناك قيمة لتخزين بيانات الرسم البياني في البنية التحتية الحالية واستخدام أدوات تصور الرسم البياني لعرض الهيكل. إذا كان لدى شركتك أقل من 10000 موظف من عرض المخططات التنظيمية التي تحتوي على بيانات من RDBMS فلا بأس طالما يمكنك كتابة استعلامات SQL للقيام بذلك. موضوع لنشر مدونة في المستقبل. قد تكون هناك أيضًا أسباب أخرى مثل مشكلات الأمان أو البيانات الموزعة التي قد تجعل أنظمة الرسوم البيانية غير الأصلية أكثر جاذبية.

لتلخيص: تحتوي قواعد البيانات العلائقية (تسمى مخازن الصفوف) على هدف أساسي يتمثل في الوصول السريع للصف للبيانات الموحدة. يعتبر البحث عن علاقة هدفًا ثانويًا. باستخدام قاعدة بيانات الرسم البياني ، يعد البحث السريع عن العلاقات دائمًا هدفًا أساسيًا. العلاقات هي مواطن من الدرجة الأولى.

هذا الاختلاف له تأثير على كيفية تصميم الرسوم البيانية. على عكس أنظمة RDBMS ، فإننا لا نقوم بتصميم لتقليل عمليات JOIN. نقوم بتصميم الرسوم البيانية لتقليل RAM بحيث تتناسب جميع مؤشراتنا بشكل جيد مع RAM. إن إضافة الكثير من العلاقات ليس سريعًا فحسب ، بل يتم تشجيعه أيضًا!

أخيرًا ، دعنا نتذكر أنه لا توجد بنية مثالية واحدة في تخزين جميع أنواع بيانات الرسم البياني. يعني التقارب الخالي من الفهرس أيضًا أنه إذا كان لديك عقد به عدد كبير جدًا من العلاقات (مثل supernodes) ، فهناك العديد من الروابط التي ستحتاج إلى تحديث عند إجراء التغييرات. على سبيل المثال ، ستتطلب شبكة اجتماعية تضم نجوم أفلام بها ملايين المتابعين ملايين التحديثات إذا تمت إزالتها. منحت ، قد يكون هذا حدثًا نادرًا على نوع معين من الشبكات ، ولكنه شيء يجب مراعاته عند النظر في المفاضلات.

هل هذا الاستعارة العمل؟ هل لديك استعارة أخرى تفسر التقارب الخالي من الفهرس؟ اسمحوا لي أن نعرف في التعليقات.