နားလည်ထားရမယ့် အချက်
ဒါက capstone project ဖြစ်ပြီး schema တစ်ခုမှ ရေးဆွဲစေခြင်းမရှိပါဘူး - သင်ရိုးထဲက ဆုံးဖြတ်ချက်ချသည့်ဘက်ကို ကျင့်သုံးစေပါတယ်။
- SQL-vs-NoSQL - tradeoff များ
- Database-systems-landscape - category တစ်ခုစီ ဘာအတွက်ကောင်းလဲ
- SQLite - embedded engine သေးငယ်တစ်ခုရဲ့ case
- Vector databases - embedding များ သိမ်းဆည်းခြင်း
Author, post, comment, tag ပါတဲ့ blog တစ်ခုက multi-table join နှင့် referential integrity လိုအပ်ပါတယ် - relational database ရဲ့ အားသာချက်အတိုင်းပါပဲ။
Real-time chat app တစ်ခုက release တစ်ခုချင်းစီမှာ ပုံသဏ္ဍာန်ပြောင်းနေတဲ့ message တွေကို မြန်ဆန်စွာ ရေးရမှာဖြစ်ပါတယ် - document database ရဲ့ flexible-write case ပါပဲ။
Cache/session layer တစ်ခုက relationship လိုအပ်ချက်မရှိဘဲ အလွန်မြန်ဆန်တဲ့ key lookup တစ်ခုတည်း လိုအပ်ပါတယ် - key-value store ကို သီးခြား category ပေးထားရတဲ့ အကြောင်းရင်းပါပဲ။
RAG application တစ်ခုက ပုံမှန် application data နှင့် embedding များအပေါ် similarity search နှစ်ခုစလုံး လိုအပ်ပါတယ် - vector index တစ်ခုကို ပုံမှန် store နှင့်အတူ လိုအပ်ပါတယ်။
Type အရင် Product နောက်
Category မှန်ကန်တာကို နာမည်တပ်ပြီး ဘာကြောင့်ဆိုတာ ရှင်းပြနိုင်ခြင်းဟာ ဒီသင်ရိုးတစ်ခုလုံးက တည်ဆောက်ပေးလာခဲ့တဲ့ တကယ့် skill ဖြစ်ပါတယ်။
CHOOSE THE RIGHT DATABASE
-------------------------
CHOOSE THE RIGHT DATABASE
-------------------------
SCENARIO RECOMMENDED TYPE
--------------------------------------------------------
Blog: authors/posts/comments/tags -> Relational (SQL)
needs multi-table JOINs, integrity
Chat app: fast, evolving messages -> Document (NoSQL)
needs flexible schema, high writes
Cache / session layer -> Key-Value store
needs simple, very fast lookups
RAG app: app data + embeddings -> Relational/Document
+ Vector database
needs similarity search on top of normal dataလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Database type တစ်ခု နာမည်မတပ်မီ scenario တစ်ခုစီအတွက် တူညီတဲ့ မေးခွန်းကို မေးပါ - ဒီ data အပေါ် ပုံမှန် query တစ်ခုက တကယ်ဘာလုပ်ပေးရမှာလဲ။
| Scenario | Access pattern က ဘာလိုအပ်လဲ |
|---|---|
| Content-heavy blog | Author/post/comment/tag ကို join လုပ်ပြီး integrity ကောင်းရမည် -> Relational (SQL) database |
| Real-time chat app | ပုံသဏ္ဍာန်ပြောင်းနေသော message ကို မြန်ဆန်စွာ write လုပ်ရမည် -> Document database (NoSQL) |
| Cache / session layer | Relationship မလိုဘဲ အလွန်မြန်သော key lookup သာလိုအပ် -> Key-value store |
| RAG application | ပုံမှန် app data နှင့် embedding အပေါ် similarity search နှစ်ခုလုံးလိုအပ် -> Relational/Document + Vector database |
Dominant need ကို ဖော်ထုတ်ပါ
Scenario တစ်ခုစီအတွက် အရေးအကြီးဆုံး access pattern ကို ရှာပါ - relations, flexible writes, cache, ဒါမှမဟုတ် vector search။
သင်ခန်းစာနှင့် ကိုက်ညှိပါ
Need တစ်ခုစီကို ၎င်းကို ရှင်းပြခဲ့တဲ့ သင်ခန်းစာနှင့် ချိတ်ဆက်ပါ - SQL-vs-NoSQL, landscape, ဒါမှမဟုတ် vector database။
Type ကို ရွေးပါ
Product အမည်မဟုတ်ဘဲ category (relational, document, key-value, vector) ကို ရွေးပါ။
ဝါကျတစ်ကြောင်းနှင့် ခိုင်လုံအောင် ရှင်းပြပါ
Scenario ဘာကြောင့် ဒီ type လိုအပ်လဲကို ဝါကျတစ်ကြောင်းတည်းနှင့် ရေးပါ။
ဝါကျတစ်ကြောင်းနှင့် ဖော်ပြနိုင်ရမည်
Scenario က database type တစ်ခုကို ဘာကြောင့် လိုအပ်လဲဆိုတာ ဖော်ပြနိုင်မှသာ ရွေးချယ်မှု ပြီးဆုံးသည်ဟု ဆိုနိုင်သည်။
အတူတူ စမ်းရေးကြည့်မယ်
function chooseDatabaseType(scenario) {
if (scenario.needsVectorSearch) {
return {
type: "Relational/document store + vector database (e.g. Postgres + pgvector)",
reason: "app data needs relations, but similarity search over embeddings needs a vector index alongside it"
};
}
if (scenario.needsComplexRelations) {
return {
type: "Relational (SQL) database",
reason: "joins across authors, posts, comments, and tags need referential integrity and multi-table JOINs"
};
}
if (scenario.needsSimpleKeyValueCache) {
return {
type: "Key-value store (e.g. Redis)",
reason: "sub-millisecond reads/writes on simple key lookups matter more than relationships"
};
}
if (scenario.needsFlexibleFastWrites) {
return {
type: "Document database (NoSQL)",
reason: "flexible, fast-changing message shape and high write throughput fit a schema-less document model"
};
}
return {
type: "Relational (SQL) database",
reason: "default to SQL when no specialized access pattern dominates"
};
}
const scenarios = {
blog: {
needsComplexRelations: true,
needsFlexibleFastWrites: false,
needsSimpleKeyValueCache: false,
needsVectorSearch: false
},
chat: {
needsComplexRelations: false,
needsFlexibleFastWrites: true,
needsSimpleKeyValueCache: false,
needsVectorSearch: false
},
cache: {
needsComplexRelations: false,
needsFlexibleFastWrites: false,
needsSimpleKeyValueCache: true,
needsVectorSearch: false
},
rag: {
needsComplexRelations: false,
needsFlexibleFastWrites: false,
needsSimpleKeyValueCache: false,
needsVectorSearch: true
}
};
Object.entries(scenarios).forEach(([name, s]) => {
const result = chooseDatabaseType(s);
console.log(`${name}: ${result.type}\n -> ${result.reason}`);
});
blog: Relational (SQL) database
-> joins across authors, posts, comments, and tags need referential integrity and multi-table JOINs
chat: Document database (NoSQL)
-> flexible, fast-changing message shape and high write throughput fit a schema-less document model
cache: Key-value store (e.g. Redis)
-> sub-millisecond reads/writes on simple key lookups matter more than relationships
rag: Relational/document store + vector database (e.g. Postgres + pgvector)
-> app data needs relations, but similarity search over embeddings needs a vector index alongside it၅ မိနစ် စမ်းကြည့်
ပဉ္စမ scenario တစ်ခု - multiplayer game ၏ live leaderboard အတွက် သေးငယ်ပြီး မကြာခဏ update ဖြစ်သော ranked list ကို sub-millisecond ဖတ်ရှုနိုင်ရမည်။ chooseDatabaseType ထဲသို့ needsRankedFastReads flag တစ်ခု ထပ်ထည့်ပြီး ရှိပြီးသား branch ထဲ ထည့်သင့်သလား ဒါမှမဟုတ် branch အသစ်တစ်ခု လိုအပ်သလား ဆုံးဖြတ်ပါ။
သတိလေးတစ်ချက်
Scenario တစ်ခုက တကယ်လိုအပ်တဲ့ database type ကို မဆုံးဖြတ်မီ ထုတ်ကုန်အမည် (ဥပမာ 'MongoDB') ကို အရင်ရွေးချယ်ခြင်း - type ကသာ product ရွေးချယ်မှုကို ဦးဆောင်သင့်ပြီး ပြောင်းပြန်မဟုတ်ပါ
Real system တစ်ခု (RAG app ကဲ့သို့) သည် database type နှစ်ခု အတူတကွ လိုအပ်နေချိန်တွင် dominant need တစ်ခုတည်းသာ ရှိသည်ဟု မှားယွင်းစွာ ယူဆခြင်း
Pinecone: What Is a Vector Database? — How Databases Work