para search elasticsearch v5
v1.36.1
Elasticsearch 5.x Plugin for Para
تم إهمال هذا المشروع ولن يتم الحفاظ عليه بعد الآن ، يرجى استخدام أحدث مكون إضافي لـ Elasticsearch
تم تصميم الفقرة كإطار خلفي بسيط ومعيار لاستمرار الكائن واسترجاعه. يمكّن تطبيقك من تخزين الكائنات مباشرةً إلى متجر بيانات (NOSQL) أو أي قاعدة بيانات علائقية (RDBMS) ، كما أنه يفهرس هذه الكائنات تلقائيًا ويجعلها قابلة للبحث.
يتيح لك هذا البرنامج المساعد استخدام Elasticsearch كمحرك بحث للفقرة وهو متوافق فقط مع إصدار 5.x من Elasticsearch .
Search ويدعم عميل النقلDAO حتى تتمكن من استخدام Elasticsearch كقاعدة بيانات (تجنب الإنتاج!)/v1/_elasticsearch - يرقل جميع الطلبات مباشرة إلى Elasticsearch (معطل افتراضيًا) المكون الإضافي على Maven Central. إليك مقتطف Maven لتضمينه في pom.xml الخاص بك:
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch-v5</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency > بدلاً من ذلك ، يمكنك تنزيل الجرة من علامة التبويب "الإصدارات" أعلاه وضعها في مجلد lib إلى جانب ملف حرب الخادم para-xyzwar . سوف تبحث الفقرة عن الإضافات داخل lib والتقاط المكون الإضافي Elasticsearch.
فيما يلي جميع خصائص التكوين لهذا المكون الإضافي (هذه تذهب داخل application.conf الخاص بك. مونف):
# enable this to bypass the DB and read all data straight from ES
para.read_from_index = false
para.es.shards = 5
para.es.replicas = 0
para.es.dir = " data "
para.es.auto_expand_replicas = " 0-1 "
para.es.use_transportclient = false
para.es.transportclient_host = " localhost "
para.es.transportclient_port = 9300
para.es.fail_on_indexing_errors = false
# asynchronous settings
para.es.async_enabled = false
para.es.bulk.size_limit_mb = 5
para.es.bulk.action_limit = 1000
para.es.bulk.concurrent_requests = 1
para.es.bulk.flush_interval_ms = 5000
para.es.bulk.backoff_initial_delay_ms = 50
para.es.bulk.max_num_retries = 8
para.es.bulk.flush_immediately = false
# proxy settings
para.es.proxy_enabled = false
para.es.proxy_path = " _elasticsearch "
para.es.restclient_scheme = " http "
para.es.restclient_host = " localhost "
para.es.restclient_port = 9200أخيرًا ، قم بتعيين خاصية التكوين:
para.search = "ElasticSearch"
يمكن أن يكون هذا خاصية نظام Java أو جزء من ملف application.conf على ClassPath. هذا يطلب من Para استخدام تطبيق Elasticsearch بدلاً من الافتراضي (Lucene).
يدعم المكون الإضافي Elasticsearch كل من أوضاع الفهرسة المتزامنة (الافتراضية) والفهرسة غير المتزامنة. للفهرسة المتزامنة ، سيقوم Elasticsearch البرنامج بتقديم طلب واحد ، حظر من خلال العميل وينتظر استجابة. هذا يعني أن كل عملية مستند (الفهرس أو الرنة أو الحذف) تستدعي طلب عميل جديد. بالنسبة لتطبيقات معينة ، يمكن أن يؤدي ذلك إلى حمل ثقيل على مجموعة Elasticsearch. ومع ذلك ، فإن ميزة الفهرسة المتزامنة هي نتيجة الطلب يمكن إرسالها إلى تطبيق العميل. إذا تم تعيين إعداد para.es.fail_on_indexing_errors على true ، فإن الطلبات المتزامنة تؤدي إلى خطأ في إعادة تطبيق العميل باستخدام رمز خطأ HTTP.
يستخدم وضع الفهرسة غير المتزامن معالج Elasticsearch BulkProcessor لدجام جميع الطلبات إلى مجموعة Elasticsearch. إذا تم تمكين الوضع غير المتزامن ، فسيتم تغذية جميع طلبات المستندات في BulkProcessor ، والتي ستقوم بتدفق الطلبات إلى المجموعة في بعض الأحيان. هناك العديد من المعلمات القابلة للتكوين للتحكم في تردد التدفق بناءً على عدد المستندات ، وحجم المستند الكلي (MB) ، والمدة الإجمالية (MS). نظرًا لأن Elasticsearch مصمم كمحرك بحث قريب في الوقت الفعلي ، يوصى بشدة بالوضع غير المتزامن. سيساعد صنع دفعات أكبر من طلبات المستندات في تقليل الحمل على مجموعة Elasticsearch.
يوفر وضع الفهرسة غير المتزامن أيضًا ميزة جذابة لإعادة إعادة تلقائيًا لطلبات الفهرسة. إذا كانت مجموعة Elasticsearch الخاصة بك تحت الحمل الثقيل ، فمن المحتمل أن يتم رفض طلب فهرسة المستندات الجديدة. مع الفهرسة المتزامنة ، يقع العبء على تطبيق العميل لتجربة طلب الفهرسة مرة أخرى. ومع ذلك ، يوفر Elasticsearch BulkProcessor ميزة مفيدة لإعادة إعادة تلقائي طلبات الفهرسة مع دعم أسي بين إعادة المحاولة. إذا فشل طلب الفهرس مع EsRejectedExecutionException ، فسيتم إعادة تشغيل الطلب إلى para.es.bulk.max_num_retries . حتى إذا كانت حالة الاستخدام تتطلب درجة عالية من الثقة فيما يتعلق بتناسق البيانات بين DAO والبحث ، فلا يزال من المستحسن استخدام الفهرسة غير المتزامنة مع تمكين إعادة التمكين. إذا كنت تفضل استخدام الفهرسة غير المتزامنة ولكنك تم وضع BulkProcessor على كل الاحتجاج من الفهرس/unindex/indexall/unindexall ، ما عليك سوى تمكين para.es.bulk.flush_immediately . عند تمكين هذا الخيار ، سيتم استدعاء طريقة التدفق في BulkProcessor مباشرة بعد إضافة المستندات في الطلب. هذا الخيار مفيد أيضًا في كتابة اختبارات الوحدة حيث تريد تأكد من تدفق المستندات على الفور.
يحتوي هذا المكون الإضافي على وضعين فهرسة: عادي ومتداخل . تمت إضافة الوضع المتداخل بعد V1.28 للحماية من انفجار رسم الخرائط المحتمل الذي يحدث عندما يكون هناك الكثير من الكائنات مع الكثير من الخصائص المخصصة المختلفة فيها. هذا يحمل بيانات تعريف مؤشر Elasticsearch ويمكن أن تصطدم المجموعة بأكملها. يؤثر وضع الفهرسة هذا فقط على الخصائص المخصصة في كائنات Sysprop .
الوضع "العادي" القديم مناسب لمعظم عمليات نشر الفقرة ، مع عدد قليل من المستأجرين أو مستأجر واحد (تطبيق واحد لكل خادم). في هذا الوضع ، يتم فهرسة كائنات الفقرة دون تعديل (يتم الحفاظ على جميع أنواع البيانات) ولكن هذا قد يؤدي إلى انفجار رسم الخرائط.
ويرد أدناه بنية البيانات المتداخلة لهذين وضعي الفهرسة:
// NORMAL MODE // NESTED MODE
{ {
"id": "123", "id": "123",
"appid": "para", "appid": "para",
"type": "custom", "type": "custom",
"properties": { "properties": [
"key1": "value1", {"k": "key1", "v": "value1"},
"key2": { {"k": "key2-subkey1", "v": "subValue1"},
"subkey1": "subValue1" {"k": "numericKey3", "vn": 5}
}, ],
"numericKey3": 5 "_properties": "{"key1":"value1"}..."
} }
}
يتم التبديل إلى وضع الفهرسة المتداخل الجديد باستخدام خاصية التكوين:
para.es.es.use_nested_custom_fields = true
فائدة أخرى ، عند استخدام وضع "المتداخلة" ، هي دعم الاستعلامات المتداخلة في سلاسل الاستعلام. هذه ميزة مفيدة حقًا ، في وقت كتابة هذا التقرير ، لم يتم تنفيذها بعد في Elasticsearch (إصدار مرنة/Elasticsearch#11322). والأفضل من ذلك ، يمكنك الاستعلام عن الكائنات داخل المصفوفات المتداخلة بدقة تحديد ، على سبيل المثال ?q=properties.nestedArray[2].key:value تم اكتشاف استعلام سلسلة الاستعلام المتداخلة إذا كان يحتوي على حقل له properties.* . أمثلة على استعلامات سلسلة الاستعلام:
/v1/search?q=term AND properties.owner.age:[* TO 34]
/v1/search?q=properties.owner.name:alice OR properties.owner.pets[1].name=whiskers
ملاحظة: يعمل الفرز على الحقول المتداخلة فقط مع بيانات رقمية. على سبيل المثال ، ستعمل الفرز properties.month properties.year الحقل.
يمكنك الاتصال مباشرة واجهة برمجة تطبيقات Elasticsearch من خلال /v1/_elasticsearch . لتمكينه تعيين para.es.proxy_enabled = true أولاً. ثم يجب تحديد معلمة path يتوافق مع مسار موارد API Elasticsearch. يتم ذلك لكل GET ، PUT ، POST ، PATCH أو DELETE طلب إلى Elasticsearch. تقبل نقطة النهاية طلب إما /v1/_elasticsearch أو /v1/_elasticsearch/{path} حيث يكون path معلمة مسار مشفرة عن URL. لا تضيف معلمات الاستعلام إلى مسار الطلب ? ، بدلاً من ذلك ، تمريرها كخريطة معلمة.
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
مثال ParaClient :
Response get = paraClient . invokeGet ( "_elasticsearch/" + Utils . urlEncode ( "tweet/_search" ), params );
Response post = paraClient . invokePost ( "_elasticsearch/_count" ,
Entity . json ( Collections . singletonMap ( "query" ,
Collections . singletonMap ( "term" ,
Collections . singletonMap ( "type" , "cat" ))))); إذا تم حذف معلمة path ، فإنها تتخلف عن _search .
سيتم تحويل كائن الاستجابة ليكون متوافقًا مع عملاء الفقرة ، يبدو هذا:
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} إذا كنت ترغب في الحصول على استجابة الاستعلام الخام من Elasticsearch ، فأضف المعلمة getRawResponse=true إلى مسار requst وأيضًا url-encode:
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
على ما يعادل ، يمكن القيام الشيء نفسه عن طريق إضافة معلمة الاستعلام باستخدام ParaClient :
MultivaluedHashMap<String, String> params = new MultivaluedHashMap<>();
params.putSingle("getRawRequest", "true");
paraClient.invokeGet("_elasticsearch/" + Utils.urlEncode("mytype/_search"), params);
ملاحظة: تتطلب نقطة النهاية مصادقة ولا يُسمح بالطلبات غير الموقعة. ضع في اعتبارك أن جميع طلبات Elasticsearch مملوءة مع معرف التطبيق. على سبيل المثال ، إذا كان معرف التطبيق هو "التطبيق: myApp ، فسيقوم Para بتكليف طلبات Elasticsearch على http://eshost:9200/myapp/{path} .
يمكنك إعادة بناء فهرس التطبيق بالكامل من نقطة الصفر عن طريق استدعاء POST /v1/_elasticsearch/reindex . لتمكينه تعيين para.es.proxy_reindexing_enabled = true أولاً. تنفذ هذه العملية ElasticSearchUtils.rebuildIndex() داخليًا ، وتُرجع استجابة تشير إلى عدد الكائنات المُعدة والوقت المنقضي:
{
"reindexed": 154,
"tookMillis": 365
}
بالإضافة إلى ذلك ، يمكنك تحديد فهرس الوجهة إلى Reindex ، والذي يجب أن يكون قد تم إنشاؤه مسبقًا:
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
يدعم المكون الإضافي أيضًا مشاركة الفهرس ، حيث تتم مشاركة فهرس تطبيق الجذر مع تطبيقات أخرى يتم إنشاؤها باستخدام app.isSharingIndex = true . يتم تمكين هذه الميزة باستخدام para.es.root_index_sharing_enabled = true وهو خارج افتراضيًا. عند إنشاء فهرس الجذر مع تمكين المشاركة ، يتم إنشاء اسم مستعار خاص له يحتوي على حقل توجيه يرسل جميع مستندات تطبيق الطفل إلى قشرة معينة ، مع توفير العزلة التامة بين التطبيقات. يكون هذا مفيدًا عندما يكون هناك الكثير من التطبيقات الأصغر مع بضع مئات من المستندات فقط ونريد تجنب النفقات العامة لفهرس واحد لكل تطبيق.
Apache 2.0
