နားလည်ထားရမယ့် အချက်
Analyzer ဆိုတာ `text` field ကို index ချချိန် (သို့) `match` query run ချိန်မှာ raw text ကို searchable token များအဖြစ် ပြောင်းပေးတဲ့ pipeline တစ်ခုဖြစ်ပြီး component သုံးမျိုးပါဝင်ပါတယ်—character filter (HTML tag ဖယ်ခြင်းစတာ), tokenizer (text ကို word boundary အလိုက် ခွဲခြင်း), token filter (lowercase, stemming, stop word ဖယ်ခြင်း) တို့ဖြစ်ပါတယ်။ Default `standard` analyzer က text ကို word ခွဲပြီး lowercase လုပ်လိုက်တာကြောင့် "Redis Cache" ကို index ချရင် token ["redis", "cache"] ဖြစ်ပြီး၊ query တစ်ခုမှာ "REDIS" ရိုက်ထည့်ရင်တောင် `match` query ကလည်း analyzer တူတူ run ပေးလို့ query ကိုလည်း ["redis"] အဖြစ် lowercase ပြောင်းပြီးမှ inverted index ကို compare လုပ်လို့ case-insensitive match ရနိုင်ပါတယ်—ဒါကြောင့် `match` query တွေဟာ index-time analyzer နဲ့ search-time analyzer နှစ်ခုစလုံး run ပြီးမှ compare လုပ်တာဖြစ်ပါတယ်။ Stemming (word ရဲ့ root form ရှာခြင်း၊ ဥပမာ "running" → "run") ကို support ပေးတဲ့ `english` analyzer လိုမျိုး language-specific analyzer တွေကို သုံးရင် "caching" ရိုက်ထည့်တဲ့ user က "cache" ပါတဲ့ document ကိုလည်း ရှာတွေ့နိုင်ပါတယ်—`term` query ကတော့ analyzer ကို လုံးဝ skip လုပ်ထားလို့ document ထဲက indexed token (ဥပမာ stemmed "cache") နဲ့ query value (raw "caching") ကို တိုက်ရိုက် compare လုပ်ရာက exact match ဖြစ်မှသာ ရှာတွေ့နိုင်ပါတယ်—ဒါဟာ Lesson 6 မှာ ကတိပြောထားခဲ့တဲ့ "match က term မတွေ့တာတွေ ဘာကြောင့်ရှာတွေ့လဲ" ဆိုတဲ့ mechanism ကို ဒီနေရာမှာ အပြည့်အစုံရှင်းပြတာပါ။ Analyzer pipeline ကို coffee roasting process (raw beans → roast → grind → brew) နဲ့ တွေးလို့ရပါတယ်—step တစ်ခုစီက input ကို ပိုသုံးလို့ရအောင် transform လုပ်ပေးတာနဲ့ ဆင်တူပါတယ်။
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Tutorial Platform ရဲ့ `body` field (lesson content) ကို `english` analyzer ဖြင့် index ချမယ်—user က "caching strategies" ဆိုပြီး search လုပ်ရင် stemming ကြောင့် lesson body ထဲက "cached", "caches", "cache" word variants အားလုံးပါတဲ့ document ကို ရှာတွေ့နိုင်ပါတယ်။ `_analyze` API ကို Kibana Dev Tools ထဲမှာ run ပြီး analyzer တစ်ခုစီက text ကို ဘယ်လို token ခွဲမလဲ preview ကြည့်နိုင်ပါတယ်—production mapping ကို deploy ခင် ဒီနည်းနဲ့ analyzer choice ကို verify လုပ်ရမယ်။ `standard` analyzer ကို default alone ထားရင် Burmese/Chinese စတဲ့ language တွေအတွက် word-boundary detection ကောင်းစွာ အလုပ်မလုပ်နိုင်ဘူးဆိုတာကိုလည်း သတိပြုရပါမယ်—multi-language content ဆိုရင် language-specific analyzer ကို per-field သတ်မှတ်ရနိုင်ပါတယ်။
အတူတူ စမ်းရေးကြည့်မယ်
GET /_analyze
{
"analyzer": "english",
"text": "Caching Strategies for Redis"
}
# response tokens (stemmed, lowercased):
# ["cach", "strategi", "redi"]Input text ကို `english` analyzer က lowercase + stemmed token array အဖြစ် ခွဲထားတာကို မြင်ရမည်။၅ မိနစ် စမ်းကြည့်
"The Quick Brown Foxes are Running" ဆိုတဲ့ text ကို `standard` analyzer နှင့် `english` analyzer နှစ်မျိုးနဲ့ `_analyze` API ဖြင့်ရှာကြည့်ပြီး token result ကွာခြားချက်ကို ရေးချပါ။
သတိလေးတစ်ချက်
Field တစ်ခုကို analyzer အလိုက်စမ်းသပ်ကြည့်ခြင်းမပြုဘဲ default `standard` analyzer ကို content type အားလုံးအတွက် သင့်တော်မယ်လို့ ယူဆခြင်း—code snippet, product SKU စတာတွေအတွက် word-splitting က မလိုချင်တဲ့ token တွေ ဖန်တီးနိုင်ပါတယ်။
Analyzer ကို mapping deploy ပြီးနောက်မှ ပြောင်းလိုချင်ရင် existing documents ရဲ့ inverted index က automatically ပြန် rebuild မဖြစ်ဘူးဆိုတာကို မသိခြင်း—reindex မလုပ်ဘဲ analyzer ပြောင်းရင် old documents တွေက analyzer အသစ်နဲ့ search တွေ့မှာ မဟုတ်ပါ။
Elasticsearch Guide — Text Analysis — Elastic