هل من الجيد استخدام MySQL و Neo4J معًا؟

Question

سأقوم بعمل تطبيق مع الكثير من العناصر المماثلة (الملايين) ، وأود تخزينها في قاعدة بيانات MySQL ، لأنني أرغب في القيام بالكثير من الإحصائيات والبحث عن قيم محددة لأعمدة محددة.

لكن في الوقت نفسه ، سأقوم بتخزين العلاقات بين جميع العناصر ، التي ترتبط في العديد من الهياكل الشبيهة بالشجرة الثنائية المتصلة (الإغلاق التعريفي) ، وقواعد بيانات العلاقة ليست جيدة في هذا النوع من الهياكل ، لذلك أود تخزينها جميع العلاقات في neo4j والتي لها أداء جيد لهذا النوع من البيانات.

خطتي هي الحصول على جميع البيانات باستثناء العلاقات في قاعدة بيانات MySQL وجميع العلاقات معها item_id مخزنة في قاعدة بيانات NEO4J. عندما أرغب في البحث عن شجرة ، أبحث أولاً عن neo4j لجميع item_id: S في الشجرة ، ثم أبحث عن mysql-database لجميع العناصر المحددة في استعلام يبدو:

SELECT * FROM items WHERE item_id = 45 OR item_id = 345435 OR item_id = 343 OR item_id = 78 OR item_id = 4522 OR item_id = 676 OR item_id = 443 OR item_id = 4255 OR item_id = 4345

هل هذه فكرة جيدة أم أنا مخطئ جدًا؟ لم أستخدم databases الرسم البياني من قبل. هل هناك مقاربات أفضل لمشكلتي؟ كيف يمكن أداء MySQL-Query في هذه الحالة؟

Answer 1

بعض الأفكار حول هذا:

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

أعتقد أن الأمر يتعلق بما ستفعله مع الرسم البياني الخاص بك. على سبيل المثال ، إذا كنت ترغب في العثور على جميع العقد المتصلة بعقدة محددة ، فإن سماتها (أي الاسم ، العمر .. أيا كان) هي قيم معينة ، هل يجب عليك أولاً العثور على معرف العقدة الصحيح في قاعدة بيانات MySQL الخاصة بك ثم انتقل إلى neo4j؟ هذا يبدو بطيئًا ومعقدًا للغاية عندما يمكنك القيام بكل هذا في Neo4J. لذا فإن السؤال هو: هل ستحتاج إلى سمات العقدة عند عبور الرسم البياني؟

هل ستتغير بياناتك أم أنها ثابتة؟ من خلال وجود اثنين من متاجر البيانات منفصلة ، فإنه سيؤدي إلى تعقيد الأمور.

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

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

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

Answer 2

يمكن لقواعد البيانات العلائقية التعامل مع هياكل الرسم البياني. يمكن لبعضهم التعامل معها بشكل معتدل (بأناقة كما تحصل قاعدة بيانات علائقية!).

مفتاح معالجة الرسم البياني العام في قواعد البيانات العلائقية هو تعبير الجدول المشترك العودية (RCTE) ، الذي يتيح لك بشكل أساسي توسيعًا (وليس بشكل متكرر ، على الرغم من الاسم) ، قم بتوسيع استعلام على مجموعة من الصفوف ، من خلال الجمع بين استعلام يختار مجموعة من الصفوف والاستعلام الذي يحدد جيران الصفوف المحددة حتى الآن. بناء الجملة عالي القلق بعض الشيء ، لكنه عام وقوي.

يتم دعم RCTEs في PostgreSQL و Firebird و SQL Server ، ويبدو أنها في DB2. أوراكل لديه بنية مختلفة ولكن مكافئة. لقد قرأت أن الإصدارات الحديثة تدعم المضبوطة المناسبة. MySQL لا يدعم rctes. إذا لم تكن متصلاً بـ MySQL ، فسأحثك على التفكير في استخدام PostgreSQL ، والتي تعد في الأساس قاعدة بيانات أفضل بكثير.

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

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

يتمثل أحد أبسط في تخزين مسار مع كل صف: هذه سلسلة تمثل موضع الصف في الشجرة ، ولديه خاصية أن مسار العقدة هو بادئة للمسار لأي نود فرعي ، مما يتيح لك بكفاءة شديدة هل الاستفسارات المختلفة حول الأصول ("هل العقدة A A طفل من العقدة B؟" ، "ما هي الأسلاف المشتركة للعقدة A والعقدة B؟" ، إلخ). على سبيل المثال ، يمكنك بناء مسار لصف واحد عن طريق المشي على الشجرة من الجذر ، والانضمام إلى معرفات الصفوف التي واجهتها في الطريق مع المائل. هذا بسيط للبناء ، ولكنه يحرص على الحفاظ عليه إذا قمت بإعادة ترتيب الشجرة. مع عمود المسار ، يمكنك تقييد استعلام لشجرة معينة ببساطة عن طريق الإضافة and path like '23/%', ، أين 23 هو معرف الجذر.

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

Answer 3

أنا في الغالب مع الطالب الذي يذاكر كثيرا في هذا ، ولكن أرغب في إضافة تباين. يمكنك تخزين البيانات الحية في Neo4J ثم استخراج البيانات التي تحتاجها للإحصائيات/الإبلاغ ووضعها في MySQL. للبحث سأذهب مع Neo4j-lucene تكامل إذا كان ذلك يناسب احتياجاتك.

Answer 4

يمكنك تحسين الاستعلام باستخدام في:

SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)

كما أنه ليس صحيحًا تمامًا أن قواعد البيانات العلائقية سيئة في تخزين هياكل الأشجار. من المؤكد أن MySQL تفتقد بعض الوظائف التي تجعل الأمر أسهل ، ولكن معظم قواعد البيانات الأخرى تدعمها جيدًا. أوراكل لديه CONNECT BY. معظم RDBMs السائدة لديها شكل من أشكال الاستعلامات العودية - MySQL كونها استثناء ملحوظ. ربما يمكنك إلقاء نظرة على PostgreSQL ومعرفة ما إذا كان ذلك يلبي احتياجاتك؟