VPS ที่เหมาะกับฐานข้อมูล: เลือกตามภาระงานของคุณ

ฐานข้อมูลสองชุดอาจใช้ดิสก์เท่ากันแต่ต้องการ VPS ต่างกัน ชุดหนึ่งอ่านแถวจำนวนน้อยซ้ำ ๆ อีกชุดเขียนต่อเนื่อง สร้างดัชนีใหญ่ หรือต้องฟื้นตัวเร็วหลังขัดข้อง การเลือกเริ่มจากความต่างนี้ ก่อนเปรียบเทียบผู้ให้บริการ

การซื้อ VPS ที่ดูแลเองรวมถึงความรับผิดชอบในการเดินระบบฐานข้อมูล PostgreSQL, MySQL และ MariaDB ใช้งบหน่วยความจำต่างกัน และต้องออกแบบการกู้คืนพร้อมเซิร์ฟเวอร์หลัก การตั้งค่าตั้งต้นต้องเผื่อการสำรองและบำรุงรักษา แล้วผ่านการทดสอบภาระงานที่เป็นตัวแทน

วัดภาระฐานข้อมูลก่อนเลือกแพ็กเกจ

ก่อนเลือก CPU, RAM และดิสก์ ให้วัดข้อมูลและดัชนีที่ใช้งาน คิวรีพร้อมกันช่วงสูงสุด การเติบโต และความต้องการกู้คืน เพิ่มทรัพยากรตามข้อจำกัดที่วัดได้ รวมพื้นที่บำรุงรักษาและยอดใช้แอปเมื่ออยู่เครื่องเดียวกัน งบต้องรองรับทั้งช่วงยุ่งและปกติ

ชุดข้อมูลทำงานคือข้อมูลและดัชนีที่เข้าถึงบ่อยพอจะคุ้มกับการเก็บใน RAM ขนาดที่เก็บรวมข้อมูลเย็นด้วย การเชื่อมต่อที่เปิดไม่ใช่คิวรีที่ทำงาน ไคลเอนต์ว่างกับการเรียงพร้อมกันต้องการ CPU และ RAM ต่างกัน บันทึกทั้งสองพร้อมรูปแบบคิวรีและสัดส่วนอ่าน/เขียน

กำหนดข้อซื้อจากช่วงงานหนาแน่นที่เป็นตัวแทน:

• วัดยอดใช้หน่วยความจำแอปหากใช้ VPS ร่วมกัน
• บันทึกขนาดข้อมูลและดัชนี ชุดทำงานโดยประมาณ งานพร้อมกัน และการเติบโตในช่วงที่วางแผน
• วัดการสร้างบันทึกและหางานสร้างดัชนี เขียนตารางใหม่ หรือบำรุงรักษาที่ใหญ่ที่สุดที่คาดไว้
• กำหนดเป้าหมายความหน่วง p95 ช่วงข้อมูลสูญหายที่ยอมรับ และเวลาคืนข้อมูล
• เลือกตำแหน่งแอปและทดสอบเส้นทางไปฐานข้อมูล

เอกสารการติดตาม PostgreSQL แนะนำใช้สถิติฐานข้อมูลร่วมกับเครื่องมือระบบปฏิบัติการ วัด CPU แรงกดดัน RAM และดิสก์ร่วมกับเวลาคิวรีและ commit ความหน่วงเพิ่มระหว่างสำรองต้องตรวจสอบ แม้การทดสอบเครื่องว่างจะปกติ

vCPU เฉพาะให้เข้าถึง CPU ที่จัดสรรอย่างต่อเนื่อง ไม่ใช่เซิร์ฟเวอร์จริงทั้งเครื่องหรือการรับประกัน IOPS ประเมิน CPU, RAM และพฤติกรรมดิสก์แยกกัน หากผลวัดเกินตัวเลือก VPS ให้ศึกษาฮาร์ดแวร์เฉพาะแทนการเดาจากชื่อแพ็กเกจใหญ่กว่า

จับคู่ภาระ SQL กับการตั้งค่าเริ่มต้น

เลือก PostgreSQL 16, MySQL 8.4 กับ InnoDB หรือ MariaDB 11.4 กับ InnoDB เป็นสภาพแวดล้อมตัวอย่างทางเลือกตามความเข้ากันได้ ไม่ใช่เอนจินทดแทนกันได้หรือคำกล่าวว่าเป็นรุ่นล่าสุด บันทึกรุ่นแพตช์ก่อนทดสอบ ตัวอย่างไม่ระบุรุ่นอิมเมจของผู้ให้บริการ

วางแอปเล็กและฐานข้อมูลร่วมเครื่อง

เมื่อสมมติข้อมูล 3 GB ชุดร้อน 1 GB และห้าคิวรีดัชนีแบบง่ายที่ทำงาน ให้ลอง 2 vCPU, RAM 4 GB และ SSD/NVMe ตามระบุ 60 GB การเชื่อมต่อเป็นภายใน แต่ทั้งคู่ต้องพอดีกับงบ RAM สูงสุดร่วมกัน

สมมติอ่าน/เขียน 90/10 โตเดือนละ 1 GB และไม่มีรายงานยาวระหว่างสำรอง CPU ร่วมอาจเหมาะกับ staging ที่ยอมรับความผันผวน เลือกเฉพาะหากการแย่งต่อเนื่องทำให้ตอบช้า ตารางใช้งานจริงต่อไปใช้ vCPU เฉพาะทั้งหมด

ข้อเสนองบ RAM ต่อไปนี้ ทุกตัวเลขเป็น GB:

ให้พูล InnoDB ของ MySQL/MariaDB อยู่ในกรอบนี้ การใช้เปอร์เซ็นต์สำหรับเครื่องฐานข้อมูลเฉพาะกับทั้งโฮสต์จะกิน RAM ของแอป สำหรับ PostgreSQL นับบัฟเฟอร์ร่วมและหน่วยความจำงานแยกในส่วนฐานข้อมูลและสำรอง วัดยอดรวมก่อนยอมรับแต่ละแบบ

ตัวอย่างดิสก์: ระบบ/บันทึก 5 GB ข้อมูล/ดัชนี 3 GB บันทึกเอนจิน 4 GB ชั่วคราว 3 GB และเติบโต 6 GB รวม 21 GB ที่เหลือตามระบุรองรับส่วนเกินระบบไฟล์และงานชั่วคราว ไม่ใช่เหตุผลให้เก็บชุดสำรองบนเครื่องหลัก

เชื่อมต่อผ่านซ็อกเก็ตภายในหรือ localhost ทดสอบ commit ที่คงทนขณะแอปและสำรองทำงาน รวมการซิงก์ (fsync) ที่ขอให้ระบบเขียนลงสื่อถาวร หากผู้รับผิดชอบยอมรับ RPO 24 ชั่วโมงคือช่วงข้อมูลสูญหาย และ RTO สี่ชั่วโมงคือเป้ากู้คืน ให้เสนอสำรองด้วยเครื่องมือของฐานข้อมูลทุกคืนนอกโหนดและพิสูจน์เวลาด้วยซ้อม หาก RAM ความหน่วง หรือกู้คืนเกินงบ ให้แยก เพิ่มขนาด หรือปรับแผนหลังวิเคราะห์คิวรี/ดัชนี

แยกฐานข้อมูล SQL ธุรกรรม

เมื่อแอปอยู่อีกเครื่อง ตัวอย่าง SQL 12 GB และชุดร้อน 6 GB เริ่มลองบน 2 vCPU เฉพาะ RAM ระดับ 16 GB และดิสก์ภายในระดับ 50 GB ได้ โดยสมมติ 20 คิวรีดัชนีที่ทำงาน การเขียนสั้น และคำนวณต่อเนื่องน้อย งานใหญ่กว่าอาจทำให้งบใช้ไม่ได้

สมมติอ่าน/เขียน 90/10 และโตเดือนละ 1 GB ตลอดสามเดือน นี่คือภาระอ้างอิงตาราง หน่วยต่างกันจึงเปรียบเทียบ RAM ที่ใช้ได้จริงกับไบต์ระบบไฟล์ที่ใช้ได้ก่อนจัดสรร

สำหรับ PostgreSQL VPS แนวทางบัฟเฟอร์ร่วม PostgreSQL 16 เริ่มที่ 25% ของ RAM บนเครื่องฐานข้อมูลเฉพาะที่มีอย่างน้อย 1 GB และยังใช้แคชระบบด้วย ข้อเสนอ 16 GB คือบัฟเฟอร์ 4 GB ระบบ/ตัวแทน 2 GB สำรองคิวรี/การเชื่อมต่อ/บำรุง 2 GB และแคชไฟล์/เผื่อ 8 GB

ส่วนสำรองไม่ใช่ค่า work_mem เอกสารหน่วยความจำงานคิวรี PostgreSQL อธิบายว่าการเรียงและแฮชแยกกันอาจต่างจัด RAM เมื่อหลายเซสชันทำงาน แฮชยังใช้ hash_mem_multiplier ตั้งขีดจำกัดตามงานพร้อมกันที่อนุญาต ค่าสูงต่อหนึ่งงานอาจเกินเครื่องแม้บัฟเฟอร์ร่วมเพียงพอ

สำหรับ MySQL VPS แนวทางพูลบัฟเฟอร์ MySQL 8.4 Oracle มักแนะนำ RAM 50–75% โดยคำนึงระบบและส่วนอื่น ทดสอบ InnoDB 8 GB แล้วเหลือให้ผู้ใช้อื่นกับช่วงสูงสุด

MariaDB คิดต่างเล็กน้อย แนวทางจัดสรร RAM เริ่ม 60–70% ของ RAM หลังระบบ/บริการเมื่อใช้ InnoDB เป็นหลัก หากเหลือ 13 GB คือ 7.8–9.1 GB เริ่ม 8 GB จึงเข้ากรอบ MyISAM หรือ Aria ต้องคิดแคชแยก งบเอนจินเหล่านี้เป็นทางเลือก อย่ารวมกัน

ดิสก์: ข้อมูล/ดัชนี 12 GB + เติบโต 3 GB + ระบบ 5 GB + บันทึก 4 GB + ชั่วคราว/บำรุง 8 GB = 32 GB ดิสก์ระดับ 50 GB เหลือตามระบุราว 18 GB ก่อนค่าเกิน ต้องวัดว่างอย่างน้อย 15 GB บันทึกหรือการเขียนใหม่มากกว่านี้ทำให้ตัวอย่างใช้ไม่ได้

วางแอปกับฐานใกล้กัน ใช้ทางส่วนตัวที่ทดสอบหากรองรับ พร้อมยืนยันตัวตน ควบคุมสิทธิ์และเข้ารหัส ตรวจความหน่วงคิวรีและ commit คงทนช่วง checkpoint, flush และสำรอง จัดเก็บสำรองอิสระตามรายละเอียดถัดไป เพิ่มขนาดหากทรัพยากรเต็ม พื้นที่ไม่พอ หรือกู้คืนไม่ถึงเป้าหลังวิเคราะห์คิวรี/ดัชนี

วางแผนชุดทำงานใหญ่หรือการเขียนต่อเนื่อง

สมมติข้อมูล 100 GB ชุดร้อน 16 GB ให้ลอง 4 vCPU เฉพาะ RAM 32 GB และ NVMe ระดับ 300 GB โดยแยกแอป ตัวอย่างมี 30 คิวรีผสมที่ทำงานและอ่าน/เขียน 60/40 วัดการประมวลผลและแรงกดดันดิสก์ก่อนเพิ่ม

สมมติโตเดือนละ 10 GB สามเดือน PostgreSQL คือบัฟเฟอร์ 8 GB ระบบ/คิวรี/บำรุง 4 GB และแคชไฟล์/เผื่อ 20 GB สำหรับ MySQL/MariaDB InnoDB ราว 16 GB เป็นทางเลือกหลังกันส่วนอื่น ห้ามย้ายค่า PostgreSQL ไปตรง ๆ

ดิสก์รวมงานที่กำลังทำ: ข้อมูล/ดัชนี 100 GB + เติบโต 30 GB + บันทึกเก็บ/รอ 30 GB + งานชั่วคราว/บำรุงใหญ่สุด 60 GB + ระบบ 10 GB = 230 GB เหลือตามระบุราว 70 GB การเขียนตารางใหม่ใหญ่ขึ้นต้องคิดใหม่แม้โตต่อวันน้อย

เอกสาร vacuum ตามรอบ PostgreSQL แยก VACUUM ที่ทำพื้นที่แถวตายใช้ซ้ำได้ จาก VACUUM FULL ที่เขียนตารางชุดใหม่และต้องมีที่เพิ่มชั่วคราว ดิสก์ใหญ่กว่าข้อมูลเพียงเล็กน้อยอาจขวางการบำรุงเพื่อคืนพื้นที่

วัด CPU แรงกดดันแคชและ I/O จริงแยกจากความหน่วงเขียน รวมงานเขียนชั่วคราวและช่วง checkpoint/flush NVMe และ CPU เฉพาะเป็นคำอธิบาย ไม่รับประกัน IOPS ทดสอบการส่งสำรอง/จำลองต่อเนื่องผ่านแอปส่วนตัวใกล้และที่กู้คืนอิสระ บันทึกเร็วขึ้นเปลี่ยนพื้นที่เก็บและเครือข่าย เพิ่มคอร์ RAM หรือดิสก์ตามข้อจำกัด ไม่ใช่เพราะแพ็กเกจถัดไปเพิ่มทุกอย่าง

เพิ่มความสามารถกู้คืนให้ระบบจริง

ยอมสูญข้อมูล 15 นาทีและกู้คืนหนึ่งชั่วโมงต้องออกแบบเกินงบเครื่องหลัก คงสมมติ SQL แยก แล้วเพิ่มสำรองด้วยเครื่องมือของฐานข้อมูล บันทึกที่เก็บ พื้นที่อิสระ และซ้อมจับเวลา ตัวเลขคือเป้าวางแผน การซ้อมเท่านั้นพิสูจน์ได้

เอกสารเก็บถาวรต่อเนื่อง PostgreSQL อธิบายสำรองฐานกับ WAL ไม่ขาดสำหรับย้อนจุดเวลา เอกสารกู้คืน MySQL Oracle ใช้สำรองเต็มตามด้วยบันทึกไบนารี ขั้นตอน PITR MariaDB คืนข้อมูลเต็ม/ส่วนเพิ่มก่อนเล่นบันทึกไบนารี ต้องเปิดบันทึกไบนารีสำหรับขั้นตอน MySQL/MariaDB นี้

ตัวอย่างความจุ: สำรองเต็ม/ฐานไม่บีบอัดชุดละ 12 GB เก็บสามฐานรายสัปดาห์กับบันทึกต่อเนื่องตั้งแต่เริ่มฐานเก่าสุด คิดสูงสุด 21 วัน วันละ 2 GB และเผื่อ 20%:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

วางแผนสำรองอิสระอย่างน้อย 100 GB โดยไม่สมมติการบีบอัด ผูกการลบบันทึกกับหมดอายุและแทนสำรองสำเร็จ ตรวจห่วงโซ่ฐานกับบันทึกครบสำหรับทุกจุดกู้คืนที่สัญญา

ใช้สำรองบนปลายทางอิสระ พร้อมข้อมูลรับรองและสิทธิ์ลบแยกเครื่องหลัก snapshot ผู้ให้บริการอย่างเดียวไม่พิสูจน์ห่วงโซ่นี้ ซ้อมต้องสร้างเป้าหมายสะอาด ส่ง/คืนสำรอง เล่นบันทึก ตรวจความสอดคล้องฐาน/แอป แล้วเปลี่ยนเส้นทางแอป จับเวลาจัดเตรียมและส่งด้วย

หยุดสั้นลงอาจต้องสำเนาที่ตั้งอิสระและรับภาระทั้งหมด คิด CPU, RAM, ดิสก์แยก กำหนดเลื่อนบทบาท กั้นเครื่องหลักเก่า และทางไคลเอนต์ แล้วซ้อม การจำลองไม่แทนสำรอง VPS เดียวไม่ใช่พร้อมใช้งานสูง ปรับเมื่อคืนเกินชั่วโมง บันทึกช้าเกิน RPO เครื่องสำรองรับไม่ไหว หรือพื้นที่สำรองใกล้เต็ม

เมื่อใดควรเลือก VPS แบบมีผู้จัดการ

หากไม่มีผู้ตอบแจ้งเตือนหรือคืนฐานขณะเกิดเหตุ ให้ซื้อขอบเขตปฏิบัติการชัดเจน VPS แบบจัดการอาจรับงานบำรุง แต่สัญญาต้องระบุงานฐานข้อมูล แผงควบคุมไม่พิสูจน์ขอบเขต และ VPS จัดการต่างจากฐานข้อมูลจัดการ

ความต่างของหน้าที่ VPS แบบจัดการและดูแลเอง มีประโยชน์เมื่อแยกงาน นี่คือรายการซื้อ ไม่สัญญาบริการทุกแห่งเหมือนกัน โครงสร้างจริงยังเป็นของผู้ให้บริการ แต่ซอฟต์แวร์ระบบแขกและฐานต้องระบุเจ้าของงาน

คำถามสัญญาที่มีประโยชน์คือ ‘หากดิสก์เต็มตอนสำรอง ใครวิเคราะห์ คืนบริการ และตรวจว่าสำรองครั้งหน้าสำเร็จ?’ คำตอบแยกการเข้าถึงช่วยเหลือกับความรับผิดผล ถามกรณีอัปเกรดเอนจินพลาดและลบโดยไม่ตั้งใจด้วย

ฐานข้อมูลจัดการมีข้อตกลงวงจรเอนจิน สำรอง และสลับเมื่อเสียของตน อาจเหมาะเมื่ออยากส่งต่องานกู้คืนและอัปเกรด อย่าอนุมานการปรับแอปจากชื่อ การออกแบบคิวรีและพฤติกรรมแอปยังต้องมีเจ้าของเว้นแต่ตกลงต่าง

มอบแต่ละงานครั้งเดียวพร้อมทางส่งต่อและเกณฑ์รับงาน เปรียบราคากับเวลาและความพร้อมของคุณ การดูแลเองไม่มีค่าชั่วโมงสากล และค่าเครื่องถูกไม่แก้เหตุที่ไร้ผู้รับผิดชอบ

เลือก VPS สำหรับงานนอก SQL

ตัวอย่างแยกงานในหน่วยความจำ เอกสาร และดัชนีค้นหา วางแอปใกล้ ทดสอบเชื่อมต่อและส่งไปสำรอง/สำเนาที่ใช้ด้วย

แนวทางผู้ดูแล Redis เตือนว่าบันทึก RDB หรือเขียน AOF ใหม่ที่เขียนหนักอาจใช้ RAM สองเท่าปกติตามหน้าที่เปลี่ยน ข้อมูล 2 GB จึงใช้ RAM ทั้งหมดไม่ได้ เอกสารความคงทน แยก snapshot RDB ตามรอบกับบันทึก AOF เลือกตามการสูญที่รับได้ แล้ววัดยอด RAM/ดิสก์ขณะทำงาน

เอกสารแคช WiredTiger MongoDB อธิบายแคชภายในและระบบไฟล์ ค่าเริ่มต้นคือค่ามากกว่าระหว่าง 50% × (RAM − 1 GB) กับ 0.256 GB แนวทาง replica set แนะนำสามสมาชิกที่ถือข้อมูล ตัวตัดสินโหวตแต่ไม่เก็บข้อมูล จัดสำรองอิสระและเปิดการยืนยันตัวตน MongoDB ก่อนเชื่อมแอป

เอกสารตั้งค่า JVM Elastic แนะนำ heap อัตโนมัติ หากตั้งเอง ให้ต่ำสุด/สูงสุดเท่ากันและไม่เกิน 50% RAM ที่ใช้ได้ แนวทางความทนทานคลัสเตอร์เล็ก อธิบายสองโหนดข้อมูลที่เป็น master ได้บวกตัวตัดสินโหวตอย่างเดียว ตั้งสำเนาและส่งไคลเอนต์ไปโหนดข้อมูล ตัวตัดสินเพิ่มเสียง ไม่เพิ่มสำเนาข้อมูล หากรวม/ระยะเก็บกินพื้นที่เผื่อ ให้ปรับงบดิสก์ก่อนเพิ่มเอกสาร

เปรียบแพ็กเกจดูแลเองตามการตั้งค่าที่ต้องการ

สำหรับ SQL ธุรกรรมแยก กรองขั้นต่ำ 2 vCPU เฉพาะ RAM ระดับ 16 GB และที่เก็บภายในระดับ 50 GB ผ่านขั้นต่ำแค่เป็นผู้สมัครทดสอบ ชุด CPU/ดิสก์ หน่วยและข้อผูกพันต่างกัน จึงไม่ใช่ฮาร์ดแวร์เท่ากันหรืออันดับความเร็ว

อ้างอิงเป็น Linux ดูแลเองในเยอรมนีหรือยุโรปกลางใกล้เคียง ข้อมูลน้อยและ RAM มาก ใกล้ไม่ได้แปลความหน่วงเท่ากัน ใช้ทางส่วนตัวหากรองรับ ราคาเก็บ IPv4 สาธารณะมาตรฐาน สมมติส่งต่ำกว่าทุกโควตา

เอกสารเลือก DigitalOcean ระบุ Memory-Optimized สำหรับ SQL/NoSQL และแคช ผมแนะนำชุดนี้สำหรับดิสก์น้อย RAM มาก VPS เน้น RAM ไม่ได้จำกัด SQL หากวัดว่าความจุหรือความต้องการดิสก์ต่อเนื่องเป็นคอขวด ให้ประเมิน Storage-Optimized แยก

ทั้งห้าผ่านขั้นต่ำแต่เหลือ CPU/ดิสก์ต่างกัน ส่วนเกินอาจรองรับโต แต่ไม่พิสูจน์ว่าฐานเร็วกว่าโดยไม่ทดสอบ รายการ Hetzner ไม่รับประกันสต็อกสั่ง Akamai ระบุ SSD สำหรับ G7 Dedicated ส่วน Vultr Optimized Memory ต่างจาก High Frequency Compute ร่วม

ทรัพยากรเฉพาะของเราเหมาะการดูแลเองที่ราคานี้ เปรียบทรัพยากร สกุลเงิน ข้อผูกพันและ IPv4 ก่อนตัดสินคุณค่ารวม

ต้นทุนเจ้าของคือประมวลผล + ที่อยู่ + ที่เก็บ/คำขอ/ส่งสำรองอิสระ + เครื่องทดสอบคืน + standby ทางเลือก ค่าที่ไม่รู้ไม่ใช่ศูนย์ ขอราคากู้คืนล่าสุดและตรวจแพ็กเกจ ตำแหน่ง เส้นทางอัปเกรดก่อนผูกพัน อย่าเอาค่ารายเดือนเฉลี่ยปัดเศษคูณเป็นใบแจ้งหนี้ปี

เลือกเอนจิน SQL ที่เข้ากันแล้ว แอปคลิกเดียวช่วยลดขั้นติดตั้ง PostgreSQL, MySQL และ MariaDB เป็นตัวเลือกแยก เลือกหนึ่งไม่ได้ติดตั้งสาม การแพตช์ ปรับและกู้คืนยังเป็นงานคุณ

คำถามที่พบบ่อย

อัตราการพบข้อมูลในแคชของ PostgreSQL บอกว่าที่เก็บช้าได้ไหม?

ไม่ได้ เอกสารสถิติ I/O PostgreSQL อธิบายว่าแคชระบบอาจตอบอ่านโดยไม่แตะดิสก์ ใช้อัตรานี้ร่วม I/O ระบบและเวลาคิวรี อัตราอย่างเดียวแยกความช้าจริงของที่เก็บจากการอ่าน RAM เคอร์เนลไม่ได้

ดัมพ์เชิงตรรกะ PostgreSQL ใช้คืนจุดเวลาผ่าน WAL ได้ไหม?

ไม่ได้ ข้อกำหนดเก็บถาวรต่อเนื่อง PostgreSQL ระบุว่าดัมพ์ตรรกะไม่มีข้อมูลเล่น WAL ดัมพ์คืนสถานะที่จับไว้ ส่วน WAL ต้องมีสำรองฐานเหมาะสมและ WAL ต่อเนื่อง เลือกรูปแบบตามวิธีกู้คืน

แคช MongoDB ในคอนเทนเนอร์ควรใช้ RAM ทั้งโฮสต์ไหม?

ใช้ RAM ที่คอนเทนเนอร์เข้าถึงได้ แนวทาง RAM คอนเทนเนอร์ MongoDB เตือนว่า WiredTiger บางครั้งไม่คำนึงขีดจำกัดต่ำกว่า ตั้งแคชใต้ขีดจำกัดและเผื่อโปรเซสอื่น RAM ทั้งโฮสต์อาจทำให้ประเมินที่ฐานใช้ได้สูงเกิน