احسان رضایی

توی مطلب قبلی جستجو با استفاده از wildcard query رو توضیح دادم. الگو های wildcard ساده بودن اما کار راه انداز. برای تعریف الگوهای کامل و البته پیچیده تر میشه از عبارات باقاعده یا regex هم استفاده کرد. در این صفحه میتونید ببینید داخل الستیک چه عملگر هایی از regex پشتیبانی میشه.

مثال زیر اسنادی رو که فیلد user شون با k شروع و با y تموم بشه رو match میکنه.

GET /_search
{
    "query": {
        "regexp": {
            "user": {
                "value": "k.*y"
            }
        }
    }
}

با استفاده از wildcard query میتونید الگو های ساده ای برای matching تعریف کنید. wildcard از دو عملگر پشتیبانی میکنه.

? : یک کاراکتر تکی رو match میکنه.

* : صفر یا بیشتر. هر تعداد کاراکترُ match میکنه.

مثال زیر اسنادی رو پیدا میکنه که نویسنده هاشون با حرف t شروع شده باشن.

GET /_search
{
    "query": {
        "wildcard": {
            "authors": {
                "value": "t*"
            }
        }
    }
}

قبلا در مورد جستجوی ساده نوشتم. توی این مطلب میخواییم ببینیم چطور برای جستجو از عملگر های and، or و not در query استفاده کنیم. boolean query این قابلیت رو به ما میده. باهاش query های مرکب/ترکیبی مینویسیم. این پرس و جوی مرکب شامل must، filter، should و must_not میشه.

- must: برای matching یا تطابق در اسناد استفاده میشه. و روی score_ تاثیر میذاره که توی مطالب قبلی در موردش توضیح دادم. برابر با AND

- filter: برای فیلتر اسناد هست و روی score_ تاثیر نداره.

- should: مواردی رو درش قرار میدیم که میخواییم در اسناد وجود داشته باشه. برابر با OR

- must_not: برعکس must، مواردی که در این بخش تعریف میکنیم نباید در اسناد وجود داشته باشن. اینم میشه گفت یه مدل فیلتر هست و معادل عملگر NOT

توی مطالب قبلی هنگام ارسال درخواست و در قسمت body از عبارت query برای جستجوهامون استفاده کردیم.

{
  ...
    "multi_match": {
      "query": "guide"
    }
  ...
}

در واقع query به این سوال پاسخ میده: چقدر اسناد موجود با مقدار query(در اینجا guide) مطابقت داره. الستیک سرچ میزان این مطابقت رو در خروجی درخواست و متا فیلد score_ محاسبه میکنه و قرار میده. مرتب سازی/sort خروجی هم بر همین اساس و معیاره.

توی مطلب قبلی در مورد تفاوت match و multi_match توضیح دادم. معمولا هنگام جستجو و استفاده از multi_match بهتره اولویت های بالاتر یا پایین تری برای فیلد هامون در نظر بگیریم. به طور پیشفرض الستیک سرچ هنگام جستجو و match کردن بین فیلد ها تفاوتی قائل نمیشه. الستیک معیاری به نام boost داره که مقدار اولیه اش 1.0 هست و شما میتونید با افزایش این مقدار به فیلدهاتون برای match شدن اولویت بدین.

مثلا یک document با دو فیلد title و content رو در نظر بگیرید. میخواییم هنگام جستجو اولویت title برای match شدن دو برابر content باشه. چون از نظر ما title مهمتره و اگر بتونیم در title چیزی پیدا کنیم به احتمال خیلی زیاد نتیجه جستجوی بهتری خواهیم داشت.

برای boosting یا اولویت دادن دو راه وجود داره. هنگام تعریف mappings یا زمان جستجو. اگر سیاست های جستجوی ما مشخص باشه بهتره داخل mapping این کار انجام بشه.

توی مطلب قبلی در مورد جستجوی ساده و پایه در الستیک سرچ نوشتم. برای همه ی ما اتفاق افتاده عمدی یا غیر عمدی داخل گوگل چیز اشتباهی رو جستجو کردیم و خودش توضیح داده آیا منظورت فلان مورد بود؟ حقیقتا گوگل تشخیص میده ما اشتباه نوشتیم و اون رو بهمون  گوشزد میکنه. بیایید اسم این مدل جستجو رو بذاریم جستجوی کثیف یا درهم. اتفاقا الستیک هم چنین قابلیتی رو بهمون میده و خوشبختانه برای فارسی هم به خوبی کار میکنه :)
خب برای جستجوی کثیف چکار باید کرد؟ ما توی این مدل کوئری که خود استیک بهش fuzzy query میگه به جای multi_match یا match از fuzzy استفاده میکنیم! به همین راحتی :)

fuzzy query مواردی که مشابه و نزدیک مورد جستجوی ماست رو هم match میکنه. برای اینکار fuzzy همه ی حالت های ممکن رو بررسی میکنه و نتایجی که بیشترین مطابقت رو دارنُ برمیگردونه. این نکته رو گفتم که بدونید مثل جستجو های ساده کم هزینه نیست و در جای مناسب نه همه جا ازش استفده کنید. مثلا گوگل نمیاد توی اسنادش fuzzy search کنه. اون عبارت جستجوی شما رو fuzzy search میکنه تا برای جستجوی دقیق اصلاحش کنید.

اولین مطلب در مورد کوئری های جستجو در elasticsearch رو با ساده ترین روش یا به عبارتی basic match شروع میکنم. دو روش برای match کردن یا جستجو وجود داره. روش اول از طریق پارامتر داخل  url هست و روش دوم ارسال query در body درخواست/request.

توی روش اول هیچ کنترلی روی خروجی الستیک ندارین ولی خب کار راه انداره. اما برعکس، با روش دوم میتونید فیلد های جستجو و موارد دیگه ای که بعدا بیشتر در موردش مینویسم رو مشخص یا تنظیم کنید.

مثال: جستجوی guide در ایندکس developit_ir. کلمه guide در تمام فیلد ها جستجو میشه.

GET /developit_ir/_search?q=guide

نمونه خروجی:

"hits": [
{
  "_index": "developit_ir",
  "_type": "_doc",
  "_id": "1",
  "_score": 3.541,
  "_source": {
    "title": "developit.ir",
    "authors": [
      "ehsan rezaei"
    ],
    "summary": "elasticsearch guide :)",
    "publish_date": "2020-01-01"
  }
}
]

elastic اخیرا ماژول های filebeat رو معرفی کرده، که برای پردازش و به دست آوردن یک بینش بصری از log های رایج طراحی شده. filebeat در kibana به عنوان نقطه ی شروع یک داشبورد از پیش طراحی شده در اختیارتون قرار میده که میتونید بعدا نمودار های دیگه ای هم بسته به نیازتون بهش اضافه کنید. ماژول Apache2 که اینجا در موردش حرف میزنیم، اطلاعات مربوط به log های apache رو از مسیر های پیشفرض جمع آوری میکنه، اگر مسیر های پیشفرض رو هم تغییر دادین امکان پیکره بندی این ماژول وجود داره.
اطلاعات جمع آوری شده توسط filebeat به elasticsearch ingest node ارسال خواهد شد(به گره هایی که قبل از شاخص گذاری روی پرونده ها عملیات پیش پرازش رو انجام میدن ingest node گفته میشه) تا عملیات تجزیه و تحلیل قبل از شاخص گذاری در elasticsearch انجام بگیره.