Performance Tuning

နားလည်ထားရမယ့် အချက်

"Mapping explosion" ဆိုတာ dynamic mapping ကို uncontrolled ထားထားလိုက်တဲ့အခါ document structure က field အသစ်တွေအမြဲ ပါလာနေရင် (ဥပမာ user-generated key/value data ကို object field တစ်ခုအောက် ထားထားလိုက်ရင်) index တစ်ခုရဲ့ total field count က ထောင်ချီ/သောင်းချီ ကျဲနေနိုင်ပါတယ်—field တစ်ခုစီက cluster state metadata ထဲမှာ tracked ဖြစ်ရလို့ field count တက်လေ cluster memory/performance ကျဆင်းလေဖြစ်ပါတယ်။ ဒါကို `mappings.dynamic: false` (field အသစ်တွေကို index လုံးဝမလုပ်ဘဲ ignore) သို့ `flattened` field type (nested key/value data ကို field တစ်ခုတည်းအဖြစ် treat) ဖြင့် ကာကွယ်နိုင်ပါတယ်။ Query pattern ဘက်ကလည်း performance ကို ထိခိုက်နိုင်ပါတယ်—`bool` query ရဲ့ `filter` clause ကို Lesson 10 က ရှင်းပြခဲ့သလိုပဲ cacheable ဖြစ်လို့ repeated filter ကို reuse လုပ်ခိုင်းသင့်ပြီး၊ deep pagination (Lesson 12) ကို `search_after` ဖြင့် ရှောင်ရမယ်၊ wildcard query (`*keyword*` leading wildcard) ကို possible ရင် ရှောင်သင့်ပါတယ်—leading wildcard က inverted index ရဲ့ efficient lookup capability ကို လုံးဝ bypass ပြီး term dictionary တစ်ခုလုံးကို scan ခိုင်းရသလိုဖြစ်နေလို့ collection ကြီးလာလေ နှေးလာလေဖြစ်ပါတယ်။ Caching ဘက်မှာတော့ Elasticsearch ကိုယ်တိုင်က shard-level request cache (identical query+filter ကို cache ချထား) နှင့် filter cache (individual filter clause results) ကို internal အနေနဲ့ automatic run ပေးပါတယ်—application ဘက်က ဒီ built-in caching ကို အကျိုးရှိအောင် consistent query shape (parameter order/structure) ကို reuse ဖြစ်အောင် ဆောက်ရုံပဲ လိုအပ်ပါတယ်။ ဒါကို car engine tuning (fuel efficiency—unnecessary weight/friction ဖယ်ခြင်း) နဲ့ တွေးလို့ရပါတယ်—performance tuning ဟာ single silver-bullet မဟုတ်ဘဲ layer အများစုကနေ (mapping, query pattern, caching) waste ကို တစ်ခုချင်းလျှော့ချသွားခြင်းပါ။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ရဲ့ `tutorials` document ထဲ user comment metadata ကို arbitrary key/value object (ဥပမာ `{"customField1": "x", "customField2": "y"}`) အဖြစ် ထည့်ထားခဲ့ရင် comment တစ်ခုချင်းစီက unique field name သစ်ဖန်တီးနိုင်လို့ mapping explosion risk ရှိနေပါတယ်—ဒီအစား `flattened` field type ကို သုံးပြီး metadata တစ်ခုလုံးကို field တစ်ခုတည်းအောက်ထား၊ query time မှာလည်း `flattened` field ရဲ့ dot-notation ကနေ access လုပ်နိုင်ပါတယ်။ Search filter UI ကို build တဲ့အခါ Lesson 10 ကနေတည်ဆောက်ထားခဲ့တဲ့ `filter` clause pattern (difficulty, tags) ကို consistent structure နဲ့ ဆက်သုံးမယ်—filter clause order/structure ကို request တစ်ခုနှင့်တစ်ခု ပြောင်းနေရင် shard-level cache က reuse ဖြစ်ဖို့ opportunity လက်လွတ်နိုင်ပါတယ်။

Dynamic mapping uncontrolled = mapping explosion risk, dynamic: false / flattened type ဖြင့်ကာကွယ်
Leading wildcard query = inverted index bypass, ကြီးလာလေနှေးလာလေ
Consistent query shape ဖြင့် Elasticsearch built-in caching ကို အကျိုးရှိအောင်သုံး

အတူတူ စမ်းရေးကြည့်မယ်

json

PUT /tutorials
{
  "mappings": {
    "dynamic": false,
    "properties": {
      "title": { "type": "text" },
      "metadata": { "type": "flattened" }
    }
  }
}

You should see

`metadata` field က arbitrary key/value data ကို field explosion မဖြစ်ဘဲ single flattened field အနေနဲ့ သိမ်းနိုင်ပြီး `dynamic: false` ကြောင့် unexpected field များ silently ignore ဖြစ်မည်။

၅ မိနစ် စမ်းကြည့်

`*cache*` (leading wildcard) ကိုသုံးထားသော wildcard query တစ်ခုနှင့် ၎င်းအတိတွက် `match`/`filter` ဖြင့် equivalent ရလဒ်ပေးနိုင်မည့် alternative query တစ်ခုကို နှိုင်းယှဉ်ရေးပါ။

သတိလေးတစ်ချက်

Dynamic mapping ကို default (`true`) အတိုင်း ချန်ထားပြီး user-generated/free-form data ကို object field အောက် ကန့်သတ်မထားဘဲ ထည့်ခြင်း—field count ရာနှင့်ချီ/သောင်းနှင့်ချီ ကျဲနိုင်ပြီး cluster performance တစ်ခုလုံး ထိခိုက်နိုင်ပါတယ်။

Leading wildcard query (`*keyword*`) ကို production search feature ထဲ ပုံမှန် pattern အဖြစ်သုံးခြင်း—collection သေးငယ်တဲ့အချိန် fast ပေမယ့် data volume တက်လာတာနဲ့အမျှ query latency ဆိုးဆိုးရွားရွား ကျဆင်းနိုင်ပါတယ်။

Elasticsearch Guide — Tune for Search Speed — Elastic