Exercise — Slow/Irrelevant Search Query ကို Debug လုပ်ခြင်း

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

ဒီ course တစ်ခုလုံးအတွင်း Lesson 6 (`match` vs `term`), Lesson 8 (`text` vs `keyword`), Lesson 10 (`must` vs `filter`), Lesson 18 (leading wildcard, mapping explosion) မှာ query ကို "correct-looking ပေမယ့် wrong/slow" ဖြစ်စေတဲ့ pattern အများကြီး ကြားခဲ့ပြီးဖြစ်ပါတယ်—ဒီ exercise ကတော့ ဒီ pattern တွေကို theory အနေနဲ့ ပြန်ရွတ်ပြရုံ မဟုတ်ဘဲ real broken query snippet တစ်ခုထဲက symptom ကို ကိုယ်တိုင်ရှာဖွေတွေ့ရှိနိုင်ဖို့ debugging skill အဖြစ် practice လုပ်တာပါ။ Debugging process ရဲ့ systematic approach ကတော့—query ကို component တစ်ခုချင်းစီ (field type, clause type, sort/aggregation logic) ခွဲကြည့်ပြီး field ရဲ့ mapping type ကို `GET /index/_mapping` ဖြင့် ဦးစွာ confirm လုပ်ခြင်း၊ `explain: true`/`profile: true` (Lesson 13, 20) ကို actual behavior ကို verify လုပ်ဖို့ run ကြည့်ခြင်း၊ ပြီးမှ root cause ကို target လုပ်ပြီး fix ချမှတ်ခြင်းဖြစ်ပါတယ်။ Symptom category နှစ်မျိုးကို ခွဲခြားနားလည်ထားရမယ်—"result မရှိ/မှား" (correctness bug, ဥပမာ `keyword` field ပေါ် `match` သုံးခြင်း—analyzer mismatch) နှင့် "result မှန်ပေမယ့် နှေး" (performance bug, ဥပမာ `must` ထဲ binary criteria ထည့်ခြင်း—unnecessary scoring cost) ဟာ symptom တူသလို ထင်ရပေမယ့် root cause လုံးဝကွာပါတယ်—fix ချမယ့်နည်းလမ်းလည်း ကွာပါတယ်။

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

Tutorial Platform ရဲ့ search feature က production ထဲမှာ "advanced tutorials" ဆိုပြီး filter လုပ်တဲ့အခါ result တစ်ခုမှ မထွက်တဲ့ bug report ရလာတယ်ဆိုပါစို့—`GET /tutorials/_mapping` ဖြင့်ဦးစွာ `difficulty` field ရဲ့ type ကိုစစ်ပြီး `keyword` ဖြစ်နေတာကို ရှာတွေ့ရမယ်၊ ဒါပေမယ့် buggy query က `match: { difficulty: "Advanced" }` (capitalized) ကို သုံးထားလို့ `keyword` field ကို analyzer-agnostic exact match သုံးရမယ့်အစား analyzed `match` သုံးမိလို့ case-sensitivity mismatch ဖြစ်နေတာကို တွေ့ရမယ်—fix အနေနဲ့ `term: { difficulty: "advanced" }` (lowercase, `term` query) ပြောင်းရမယ်။ တခြား bug report တစ်ခု—search API response time p99 latency ကို profile လုပ်ကြည့်တော့ `must` clause ထဲမှာ `term: { status: "published" }` binary filter ကို ထည့်ထားတာ တွေ့ရမယ်—fix အနေနဲ့ `filter` ဆီပြောင်းရွှေ့ရင် Elasticsearch built-in caching ကို အကျိုးရှိအောင် ပြန်သုံးနိုင်လာမယ်။

• "No/wrong results" vs "slow but correct results" bug categories ကို ခွဲခြားနားလည်
• GET /index/_mapping ဖြင့် field type ဦးစွာ confirm လုပ်ရန်
• explain: true/profile: true ဖြင့် actual behavior verify ပြီးမှ root cause target

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

// Buggy query — filtering "advanced" difficulty tutorials returns zero results.
// difficulty is mapped as "keyword".
{
  "query": {
    "bool": {
      "must": [
        { "match": { "difficulty": "Advanced" } },
        { "term": { "status": "published" } }
      ]
    }
  }
}

// Your task: find both problems in this query and rewrite it correctly.

Difficulty filter ကို correct case-sensitive `term` query ဖြင့် ပြင်ဆင်ထားပြီး `status` filter ကို `filter` clause ဆီ ရွှေ့ထားသော corrected query ကို ရေးနိုင်မည်။

Elasticsearch Guide — Query DSL — Elastic