managed database ምቹ መሆኑን አቁሞ ግድግዳ መሆን የሚጀምርበት የተለየ ቅጽበት አለ። tier የማይሰጠውን extension ይፈልጋሉ። ትክክለኛውን query plan ማየት እና work_mem ማስተካከል ይፈልጋሉ። superuser ይፈልጋሉ። managed service ነገሩን መያዝ እስከሚያስፈልግዎት ነጥብ ድረስ ጥሩ ነባሪ ነው — ከዚያም በሙሉ root ያለው VPS ታማኝ መልሱ ነው።
ይህ ገጽ የራስዎን PostgreSQL ወይም Redis በትክክል ስለ ማሄድ ነው፣ እና የተጋራ box የት ትክክለኛ ምርጫ እንደሆነ እና የት እንዳልሆነ ስለ ማብራራት ነው።
database በእውነት የሚፈልገው
Databases game server የማይጨነቅባቸው ሁለት ነገሮች ይጨነቃሉ: ለworking set memory እና disk I/O። ሸካራ ቅርፁ:
- አንድ app — Postgres (ወይም Redis) instance እና backend service። working set ብዙ ጊዜ 1.7-2 GB ነው። Small ($8) ያለ ችግር ያስተናግደዋል።
- ጥቂት apps፣ ወይም እውነተኛ production concurrency — ተጨማሪ connections፣ ትልቅ caches፣ background jobs። Medium ($12) ቦታ ይሰጥዎታል።
- ሌሎች ማሽኖች መድረስ አለባቸው — የተረጋጋ፣ routable አድራሻ ይፈልጋሉ፣ ስለዚህ dedicated-IPv4 ዕቅድ (Small-IP $16 እና በላይ)። ስለዚህ ከታች ተጨማሪ።
Redis የበለጠ ቀላል ነው — memory-bound ነው፣ ስለዚህ ዕቅዱን ወደ datasetዎ እና overhead ይመዝኑ እና ጨርሰዋል። Postgres ትንሽ tuning የሚሸልመው ነው።
ራስ-ለማስተናገድ እውነተኛው ምክንያት: ቁጥጥር
VPS ቦታውን የሚያገኘው እዚህ ነው። በራስዎ box ላይ ያገኛሉ:
- ሙሉ
postgresql.conf—shared_buffers፣work_mem፣max_connections፣ WAL settings፣ ሁሉም፣ ከአቅራቢ ነባሪዎች ይልቅ ለworkloadዎ የተስተካከለ። - ማንኛውም extension። ለembeddings እና semantic search
pgvector፣ ለgeospatialPostGIS፣ ለtime seriesTimescaleDB፣pg_cron፣pg_stat_statements— የሚፈልጉትን ይጫኑ። Managed tiers ብዙ ጊዜ የextension ዝርዝሩን ይገድባሉ ወይም ከከፍተኛ ዕቅድ በስተጀርባ ያስቀምጡታል። - Superuser እና ከስሩ ያለው OS። data directoryን ማንቀሳቀስ፣ kernelን ማስተካከል፣
pg_dumpን በራስዎ schedule ማሄድ፣ እና ከፈለጉ ወደ ሌላ box streaming replication ማዋቀር ይችላሉ።
ከዚያ ምንም ለእርስዎ የማይጠቅም ከሆነ፣ managed database በእውነት ጥሩ ነው እና አንዱን መጠቀም አለብዎት። ይህ ገጽ የሚጠቅምበት ጉዳይ ነው።
የተጋራ box የተሳሳተ መሣሪያ የሚሆንበት
በግልጽ ለመናገር: shared-vCPU VPS ለከባድ OLTP — latency-critical writes ያሉት በሰከንድ በመቶዎች transactions — አልተገነባም። ያ workload በተረጋገጠ disk I/O እና በተረጋጋ clock ላይ ይኖራል ይሞታል፣ እና የተጋሩ ዕቅዶች ሁለቱንም አይሰጡም። ያ እርስዎ ከሆኑ፣ dedicated hardware ይፈልጋሉ፣ እና p99 latencyዎ ሁለታችንንም ሲያሳፍር ከማየት ይልቅ አሁን ልንነግርዎ እንመርጣለን።
ለበጣም ለተለመደው ጉዳይ — ከአንድ app በስተጀርባ ያለ database፣ internal tool፣ analytics store፣ cache — የተጋራ ዕቅድ በትክክል ትክክል ነው።
Backups አማራጭ አይደሉም
ራስ-ማስተናገድ ማለት backups የእርስዎ ስራ ናቸው፣ እና አንዱ ደንብ: ከመፈለግዎ በፊት ያድርጓቸው። ለPostgres፣ ለlogical backups pg_dump በcron፣ ወይም በእውነት ለሚያስቡት ማንኛውም ነገር point-in-time recovery WAL archiving። dumpsን ከbox ውጭ ይላኩ — ወደ object storage ወይም ሌላ server — ስለዚህ የሞተ disk backupsን ከእሱ ጋር እንዳይወስድ። ቢያንስ አንድ ጊዜ restore ይሞክሩ። በጭራሽ ያልመለሱት backup ተስፋ ነው፣ backup አይደለም።
ሌሎች ሰርቨሮች እንዲገናኙ ማድረግ
Database በተመሳሳይ box ላይ ያለ app ብቻ የሚያገለግል ከሆነ፣ ወደ localhost ያስሩት እና ጨርሰዋል — ማጋለጥ ምንም የለም። ሌላ ማሽን መግባት ባለበት ቅጽበት፣ ሁለት ነገሮች ይለወጣሉ:
- የተረጋጋ፣ routable አድራሻ ይፈልጋሉ — ያ dedicated-IPv4 ዕቅድ ነው (Small-IP $16፣ Medium-IP $20)። NAT ዕቅዶች አድራሻ ይጋራሉ፣ ይህም ለወጪ ጥሩ ነው ግን ሌሎች ሰርቨሮች ለሚደውሉበት database ላይ አይደለም።
- በጥብቅ firewall ያደርጉታል። 5432 (ወይም 6379)ን ለሚያስፈልጋቸው የተወሰኑ IPs ብቻ ይክፈቱ፣ ለ
0.0.0.0/0በጭራሽ አይደለም፣ እና TLS ይጠይቁ። በሕዝብ internet ላይ ክፍት Postgres port በደቂቃዎች ውስጥ ይገኛል።
ዕቅዱን መምረጥ
| Setup | ዕቅድ |
|---|---|
| ከአንድ app በስተጀርባ DB፣ localhost ብቻ | Small ($8) |
| ጥቂት apps / production concurrency | Medium ($12) |
| ሌሎች ሰርቨሮች መገናኘት አለባቸው | Small-IP ($16) / Medium-IP ($20) |
| ከባድ OLTP፣ በመቶዎች TPS | dedicated hardware፣ የተጋራ VPS አይደለም |
አብዛኞቹ ራስ-የተስተናገዱ databases በSmall ይጀምራሉ እና ተጨማሪ apps ወይም external clients ሲወስዱ ወደ Medium ወይም dedicated-IP ዕቅድ ያድጋሉ።
ለምን እዚህ
ሙሉ root ማለት የእርስዎ database ነው፣ እስከ ታች — እያንዳንዱ የconfig መስመር፣ እያንዳንዱ extension፣ የራስዎ backup schedule፣ ምን መጫን እንደሚፈቀድልዎ የሚወስን tier የለም። ክፍያ ክሪፕቶ ነው (USDC ወይም USDT በBase፣ Ethereum ወይም Polygon)፣ KYC የለም፣ ሰነዶች የሉም። ከክፍያ በኋላ root በ60 ሰከንድ ገደማ፣ እና ጥቂት ደቂቃ በኋላ Postgres connections እንዲቀበል ማድረግ ይችላሉ።
ታማኝ ማጠቃለያ: ቁጥጥር ሲፈልጉ — extensions፣ tuning፣ superuser — እና workloadዎ መጠነኛ ሲሆን ራስ-ያስተናግዱ። ለትንሽ-እስከ-መካከለኛ app database፣ የተጋራ ዕቅድ ትክክለኛ መሣሪያ ነው። ለlatency-critical OLTP በመቶዎች TPS፣ አይደለም፣ እና እንዲህ እንላለን። ዝግጁ ኖት? ዕቅድ ይምረጡ።
አስተያየቶች
እስካሁን አስተያየቶች የሉም። መጀመሪያ ይሁኑ።