နားလည်ထားရမယ့် အချက်
PostgreSQL လို relational database တစ်ခုက row-based (သို့) column-based storage အသုံးပြုပြီး data ကို table/row/column structure ထဲ organize လုပ်ပါတယ်—row တစ်ခုချင်းစီက primary key နဲ့ တိကျစွာ identify ဖြစ်ပြီး `WHERE id = 42` လို exact-match lookup တွေမှာ B-tree index ကနေတစ်ဆင့် အလွန်မြန်ပါတယ်။ Elasticsearch ကတော့ document ထဲက text field တိုင်းအတွက် inverted index ဆောက်ထားတယ်—word တစ်ခုစီကနေ ဒီ word ပါတဲ့ document IDs စာရင်းဆီ map လုပ်ထားတဲ့ dictionary ကို ကြိုတည်ဆောက်ထားလို့ "redis" ဆိုတဲ့ word ပါတဲ့ document အားလုံးကို document count နဲ့မဆိုင်ဘဲ instantly ရှာနိုင်ပါတယ်။ ဒါကြောင့် relational database က structured, exact-match, transactional workloads (payments, inventory count) မှာ ကောင်းပြီး free-text search, relevance ranking, fuzzy matching မှာတော့ အားနည်းပါတယ်—Elasticsearch ကတော့ ဒီနေရာမှာ ပိုကောင်းပေမယ့် multi-table JOIN, strong consistency, complex transactions မှာတော့ အားနည်းပါတယ်။ Elasticsearch update တစ်ခုက document တစ်ခုလုံးကို replace လုပ်တာဖြစ်ပြီး in-place partial column update မဟုတ်တာလည်း storage model ကွာခြားချက်ရဲ့ ရလဒ်တစ်ခုပါ။ Redis course ကနေသိထားတဲ့ "data တစ်ခုစီအတွက် owner system ရွေးရမယ်" ဆိုတဲ့ mental model ကိုပဲ ဆက်သုံးရမယ်—Redis က cache/ephemeral data ကို ပိုင်သလို Elasticsearch ကတော့ search-optimized read model ကိုပိုင်ပါတယ်။
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Tutorial Platform ရဲ့ `tutorials` table ကို PostgreSQL မှာ `id`, `title`, `author_id`, `created_at` ပါတဲ့ row structure ဖြင့် ဆက်ထားမယ်—enrollment/progress records တွေရဲ့ referential integrity အတွက် foreign key constraints ကို PostgreSQL ကသာ guarantee ပေးနိုင်ပါတယ်။ Elasticsearch ဘက်မှာတော့ tutorial title, lesson body text, tags ကို denormalized document တစ်ခုအဖြစ် flatten လုပ်ပြီး index ချမယ်—join query ကို avoid လုပ်ဖို့ author name ကိုတောင် document ထဲမှာ duplicate ထည့်ထားနိုင်ပါတယ်။ "redis caching" လို search term တစ်ခုကို PostgreSQL မှာ run ရင် full table scan လုပ်ရနိုင်ပေမယ့် Elasticsearch ထဲမှာတော့ inverted index ကနေ instant ရနိုင်ပါတယ်—ဒါကြောင့် search box ကို Elasticsearch ဆီပို့ပြီး edit/create/delete operation တွေကိုတော့ PostgreSQL ကနေတိုက်ရိုက်လုပ်တဲ့ decision ကို ဆက်ထိန်းထားမယ်။
အတူတူ စမ်းရေးကြည့်မယ်
PostgreSQL row storage Elasticsearch inverted index
--------------------------------- ---------------------------------
id | title | author_id "redis" -> [doc 12, doc 47, doc 88]
12 | Redis Intro | 7 "cache" -> [doc 12, doc 30]
47 | Redis Cache | 7 "session" -> [doc 12, doc 47]
WHERE id = 12 -> instant (B-tree) match "redis" -> instant (dictionary lookup)
WHERE title LIKE '%cache%' -> scan match "cache" -> instant (dictionary lookup)Relational database နှင့် Elasticsearch ကွာခြားချက်ကို ရှင်းပြပြီး data တစ်ခုစီအတွက် owner system ရွေးနိုင်မည်။၅ မိနစ် စမ်းကြည့်
Tutorial Platform ရဲ့ data အမျိုးအစားငါးမျိုး (user accounts, payment records, tutorial body text, tags, enrollment counts) ကို PostgreSQL/Elasticsearch/နှစ်ခုလုံး ခွဲပြီး ဘာကြောင့်ဆိုတဲ့ အကြောင်းပြချက် ရေးပါ။
သတိလေးတစ်ချက်
Elasticsearch document update ကို PostgreSQL column update လိုပဲ cheap, partial operation လို့ ထင်မှတ်ခြင်း—အမှန်က document တစ်ခုလုံးကို reindex ပြန်လုပ်ရတာဖြစ်တာကို သတိမထားမိခြင်း။
Elasticsearch ထဲမှာ multi-table JOIN လို relational query pattern (နှစ်ခု index ကြား strong consistency နဲ့ JOIN) ကို တိုက်ရိုက် ပြောင်းသုံးဖို့ ကြိုးစားခြင်း—Elasticsearch က ဒီ pattern အတွက် design မလုပ်ထားပါ။
Elasticsearch Guide — Elasticsearch Basic Concepts — Elastic