بحث API مقابل بحث Apache Solr
كنت أستخدم Apache Solr Search الوحدة النمطية في Drupal 6 وأنا أنظر إلى Search API for Drupal 7. لقد رأيت بعض المناقشة هنا لكني أبحث عن أي أسباب لاختيار واحد أو آخر.
هل هناك سبب لاختيار واحد على الآخر؟ إذا كان الأمر كذلك، لماذا أو لماذا لا؟ لقد سمعت أنه قد تكون هناك مشكلات معقدة و/أو مشكلات في الأداء في Search API. هل هذا صحيح؟
اعتبارًا من عام 2015 ، يمكننا مقارنة وحدات واجهة برمجة تطبيقات البحث مقابل وحدات Apache Solr Search بالأرقام:
| Apache Solr Search | Search API
Posted in: | 2007 | 2010
Downloads: | >2k | >20k
Reported installs: | >21k | >64k
Total bugs: | >1200 | >600
Active bugs: | >200 | >170
Commits: | >1.3k | >1.5k
مما يشير إلى الاختيار الواضح. تم تطوير Search API بعد 3 سنوات وتمكن من الاستفادة من منافسه.
علاوة على ذلك ، يوفر Search API بنية مختلفة تمامًا وأكثر مرونة ويتم الحفاظ عليه بشكل أكثر نشاطًا. الأهم من ذلك ، أنها تدعم بالفعل أحدث Drupal 8 و Solr 5.x التي لا تمتلكها Apachesolr حتى الآن.
بدأ Search API حديثًا وهو أكثر مرونة في تكوينه بما في ذلك دعم طرق العرض (بالنسبة لـ Apachesolr تحتاج إلى وحدة إضافية). هناك أيضًا الكثير من الوحدات التي توسع وظائفها.
ثانيًا ، لتجنب حل بعض المشكلات من قبل المجتمع مرتين بسبب الاختلافات في بنية هذه الوحدات ، يوجد حاليًا بعض الجهود المشتركة بين هذين المشروعين مثل:
- إنشاء طريقة شائعة لإظهار كتل الواجهات عبر Facet API (تعرف أيضًا بالفلاتر) ،
- مخطط مشترك وملفات تكوين solrconfig.xml ،
- عمل كل من المشرفين معًا وترحيل فئات الاتصال من وحدة بحث Apache Solr إلى Search API.
المصدر: Battleplan for Search & Solr in Drupal 8 at Acquia
ملاحظة ، لا يُنصح باستخدام كلتا الوحدتين في نفس البيئة.
لمزيد من التحليل الفني للاختلافات ، يرجى التحقق من التفاصيل أدناه.
بحث API
نظرة عامة على API:
- إطار لإنشاء عمليات البحث بسهولة
- ملخصات من مصادر البيانات والتطبيقات الخلفية
- نظام بيئي كبير مع امتدادات ، على سبيل المثال الخلفية
- تكامل واجهة API
يعتمد بشكل كبير على Entity API
- يوفر بيانات وصفية
- تستخدم لتكوينات الفهرس والخادم
ميزات التمديد:
- بحث في الإكمال التلقائي لواجهة برمجة التطبيقات
- المرفقات
- الابحاث المحفوظة
- موقعك
- مسارات واجهات جميلة
- شريط التمرير (نطاقات واجهة برمجة تطبيقات البحث)
- و أكثر من ذلك بكثير.
تركيب اساسي:
ميزات الفهرس:
- مصادر البيانات المختلفة
- مصدر بيانات واحد: الكيانات
بناءً على Entity API:
- يمكن فهرسة كل خاصية
- يمكن فهرسة خصائص الكيانات ذات الصلة
كيفية تكوين الفهرس الخاص بك - الحقول:
طرق عرض واجهة برمجة تطبيقات البحث:
- دعم المشاهدات الكاملة
- عرض أي خاصية لكيان
- استخدم أي حقل مفهرس كمرشح أو وسيطة أو فرز
- معظم التعليمات البرمجية تستند إلى تكامل طرق عرض Entity API
افتراضيًا: يتم استرداد البيانات عبر تحميل الكيان
- يمكن تجاوزه (إعداد "استرداد البيانات من Solr" في الخادم)
- البديل: البحث في صفحات API
وصفات API البحث:
- خطافات CRUD للفهارس والخوادم
خطاف لإضافة
- مصادر البيانات
- الخلفية
- تعديلات البيانات
- معالجات
أطلقت هوك عند فهرسة العناصر
- أطلقت هوك عند تنفيذ البحث
أباتشيسولر
ميزات التمديد:
- المرفقات (بدون دعم وسائط ، ترميز مخصص للمرفقات إلى كيانات أخرى)
- الموقع (موقع Apachesolr الجغرافي ، موقع Apachesolr)
وصفات أباتشيسولر:
- منصة بحث مفتوحة المصدر
- مؤسسة أباتشي
- البحث عن النص الكامل ، والتمييز ، والبحث الوجهي ، والتكتل ، ومعالجة المستندات الغنية
- وزعت
- تكرار/قابلة للتحجيم
- Java
- REST HTTP والإجابات في XML/JSON وبعض الآخرين
- غير علائقي
المصدر: Search API vs Apachesolr slideshow
أنظر أيضا:
لقد حاولت استخدام كليهما ويمكنني أن أقول هذا: هذا يعتمد على وضعك.
في الوقت الحالي ، لا يمكن للإصدار 7 الثابت من وحدة ApacheSolr Integration سوى فهرسة العقد. لذلك إذا كان لديك كيانات غير عقدة تحتاج إلى فهرستها ، فيجب عليك استخدام ما زال قيد التقدم multientity patch for it. يمكن لـ ApacheSolr Integration تخزين الكثير من البيانات المختلفة للمحتوى عند تكوينه بشكل صحيح.
إن واجهة برمجة تطبيقات البحث تستقطب الفهرس وتحتوي على الكثير من الأشياء الرائعة التي تمت كتابتها له. ومع ذلك ، فإن Search API يجلب فقط معرف البيانات التي تبحث عنها. هذا يعني تحميل أي بيانات أخرى بخلاف المعرّف سيتطلب تحميل_كيان ، أو ضرب قاعدة بياناتك أو أي طبقة تخزين مؤقت تضعها في مكانها. بالنسبة إلى المواقع كثيفة البحث ، قد لا يكون هذا هو الحل الأمثل.
هنا هو عرض تقديمي رائع في drupalcon chicago حول وحدة ApacheSolr Integration ، الدقيقة 16 للإشارة إلى Search API.
أعتقد أنه يجب عليك بالفعل تجربة كليهما واتخاذ قرار مستنير. لكن ضع في اعتبارك بشدة أن apachesolr لا يزال لا يحتوي على بيتا لـ Drupal 8.
في Search API ، لا يمكنك دمج الكيانات في نفس فهرس SearchAPI. حتى الملفات الشخصية والمستخدمون والعقد على فهارس مختلفة. هناك وحدة تسمح بالبحث المتعدد ، لكنها لم تغط احتياجاتي ، ولكن YMMV. إذا كان لديك العديد من أنواع المحتوى والعديد من الحقول في نفس الفهرس ، فقد يصبح تعريف الفهرس غير عملي تمامًا. (تقارير NB SearchAPI D8 لدعم البحث في الفهارس المتعددة)
يسمح Apachesolr بتحرير الحقول على أساس كل محتوى قد يكون أسهل ، ولكن ليس لديه القدرة على إضافة محتوى ذي صلة إلى مستند ، في الواقع تتوقع أن تضطر إلى كتابة بعض التعليمات البرمجية المخصصة لتضمين معلومات من مجموعات الحقول والمراجع وبعضها الآخر مجالات. Apachesolr D7 لا يدعم ajax ، إلا إذا كنت تستخدم طرق العرض ، ولكن باستخدام طرق العرض تفقد الجوانب. ومع ذلك ... يعد تعديل المعلومات المخزنة في الفهرس أمرًا سهلاً إلى حد ما إذا كنت سعيدًا بالتشفير في الخطافات.
قد تبدو فكرة البحث عن معرّفات الكيانات ثم عرض كل منها على حدة (يمكن استخدامها من قبل كلتا الوحدتين) كابوسًا للأداء ، ولكن إذا عرضت ذاكرة التخزين المؤقت للكيان الخاص بك ، فقد يكون أكثر كفاءة من العرض من استجابة solr.