Shards, Replicas နှင့် Cluster Architecture

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

Index တစ်ခုက single machine ပေါ်မှာ fit မဖြစ်နိုင်လောက်အောင် ကြီးလာနိုင်လို့ Elasticsearch က index တစ်ခုကို "shards" ဆိုတဲ့ smaller piece များအဖြစ် ခွဲထားပြီး cluster ထဲက node များစွာဆီ distribute ပေးပါတယ်—shard တစ်ခုချင်းစီက Lucene index အပြည့်အစုံတစ်ခု (self-contained) ဖြစ်ပါတယ်။ Primary shard က document ကို ပထမဆုံးလက်ခံသိမ်းတဲ့ shard ဖြစ်ပြီး replica shard ကတော့ primary ရဲ့ copy တစ်ခုဖြစ်ပါတယ်—node တစ်ခု down သွားရင်တောင် replica ရှိနေရင် data availability ဆက်ရှိနေစေနိုင်ပြီး (redundancy), search query တွေကိုလည်း replica shards ပေါ်မှာပါ parallel distribute လုပ်လို့ read throughput တိုးစေနိုင်ပါတယ်—Lesson 3 က `_cluster/health` status `yellow` ဆိုတာ replica shard တွေ unassigned ဖြစ်နေတဲ့ single-node dev environment ကို ရည်ညွှန်းခဲ့တာလည်း ဒီ concept ကနေ လာတာပါ။ Shard count ကို index creation time မှာ ကြိုသတ်မှတ်ရပြီး (default 1 primary in recent versions) shard count များလွန်းရင် (over-sharding) cluster metadata overhead တက်ပြီး node တစ်ခုစီရဲ့ resource (memory, file handles) ကို မလိုအပ်ဘဲ waste ဖြစ်စေနိုင်ပါတယ်—shard count နည်းလွန်းရင်တော့ node အားလုံးကို parallel distribute လုပ်ဖို့ opportunity လက်လွတ်ပြီး single shard ကြီးထွားလာလို့ query performance ကျဆင်းနိုင်ပါတယ်။ ဒါကို library branches (nodes) များကို books (shards) ခွဲဝေထားတာနဲ့ တွေးလို့ရပါတယ်—branch တစ်ခုစီ branch copy (replica) ရှိရင် branch တစ်ခု fire ဖြစ်သွားလည်း book content ဆုံးရှုံးမှာ မဟုတ်သလို readers များကလည်း branch အများကြီးကနေ တစ်ပြိုင်နက်ဖတ်နိုင်ပါတယ်။

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

Tutorial Platform ရဲ့ `tutorials` index ဟာ data volume အနည်းငယ်သာ (tutorials count ရာချီသာ) ဖြစ်လို့ primary shard 1 ခု + replica 1 ခု (total 2 shards) ကလုံလောက်ပါတယ်—shard 10 ခု ကို upfront ခွဲထားရင် data volume ငယ်တဲ့ index တစ်ခုအတွက် unnecessary overhead ဖြစ်ပါတယ်။ Production cluster ကို node 3 ခု (data redundancy + query parallelism အတွက်) ဖြင့် ဆောက်ထားမယ်—node တစ်ခု maintenance အတွက် restart လုပ်ချိန်တောင် replica shard တွေက ကျန်တဲ့ node နှစ်ခုပေါ်မှာ ရှိနေလို့ search service က interruption လုံးဝ မခံစားရပါ။ Analytics event log index (Lesson 16 ရဲ့ `search-logs-*`) ကတော့ daily volume များပြီး rollover ဖြစ်နေလို့ primary shard count ကို ပိုများအောင် calculate ချရနိုင်ပါတယ်—data volume/growth rate ကို shard count decision ရဲ့ input အဖြစ် အမြဲထားရပါမယ်။

Shard = self-contained Lucene index, index ကို node များဆီ distribute ဖို့သုံး
Replica = redundancy + parallel read throughput
Shard count ကို data volume/growth rate ပေါ် decide, over/under-sharding နှစ်ခုလုံးပြဿနာ

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

http

PUT /tutorials
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

GET /_cat/shards/tutorials?v

GET /_cluster/health?level=shards

You should see

`tutorials` index ကို primary shard 1 ခုနှင့် replica shard 1 ခုဖြင့် create ချပြီး `_cat/shards` ဖြင့် node တစ်ခုစီပေါ်က shard distribution ကို ကြည့်နိုင်မည်။

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

Node 3 ခုပါသော cluster တစ်ခုအတွက် `search-logs-*` index (daily rollover, high write volume) ရဲ့ primary/replica shard count ကို ဆုံးဖြတ်ပြီး ဘာကြောင့်ဆိုတဲ့ အကြောင်းပြချက် ရေးပါ။

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

Data volume ငယ်တဲ့ index တစ်ခုအတွက် "more shards = more parallelism = faster" လို့ ထင်ပြီး shard count များများ upfront ခွဲထားခြင်း—cluster metadata overhead တက်ပြီး node resource waste ဖြစ်သွားနိုင်ပါတယ်။

Single-node dev cluster ပေါ်မှာ replica count ကို 1+ ထားပြီး `_cluster/health` status `yellow` ကို bug လို့ထင်ခြင်း—single node ပေါ်မှာ replica shard ကို assign စရာ node မရှိလို့ ပုံမှန်ဖြစ်စဉ်ဖြစ်ပါတယ်။

Elasticsearch Guide — Scalability and Resilience: Nodes and Shards — Elastic