ประสบการณ์ย้ายระบบครั้งใหญ่จาก MongoDB ไปยัง PostgreSQL

 (infisical.com)
11 คะแนน โดย GN⁺ 2024-03-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Infisical เติบโตอย่างรวดเร็วเป็นแพลตฟอร์มที่ประมวลผล Secret มากกว่า 50 ล้านรายการต่อวัน
  • เมื่อการใช้งานเพิ่มขึ้น ก็จำเป็นต้องอัปเกรดสแตกอย่างต่อเนื่อง และล่าสุดได้ดำเนินการย้ายฐานข้อมูลทั้งหมดจาก MongoDB ไปยัง PostgreSQL
  • การย้ายครั้งนี้เป็นกระบวนการที่ซับซ้อน ซึ่งครอบคลุมถึงการนำเทคโนโลยีใหม่มาใช้ การออกแบบสคีมาฐานข้อมูล การปรับโครงสร้างลอจิก การเขียนคิวรีใหม่ และการย้ายเรคอร์ดข้อมูลหลายล้านรายการ (หรืออาจถึงหลายพันล้านรายการ) ไปยัง PostgreSQL

ขั้นเริ่มต้น

  • ตอนสร้าง Infisical ขึ้นมาในช่วงแรก ทีมเลือกใช้สแตกที่คุ้นเคยที่สุด จึงตัดสินใจใช้ MongoDB + Mongoose ORM
  • ในช่วงแรก Infisical ให้ความสำคัญกับ Infisical Cloud และการให้บริการแบบ managed SaaS มากกว่า และไม่ได้คาดมากนักว่าผู้ใช้จะโฮสต์ผลิตภัณฑ์ด้วยตนเอง

ทำไมไม่ใช้ MongoDB?

  • MongoDB ทำงานได้ดีในช่วงแรก แต่เมื่อกรณีการใช้งานของผลิตภัณฑ์ขยายเกินกว่าบริการแบบ managed จุดด้อยก็เริ่มชัดเจนขึ้น
  • หลายองค์กรต้องการโฮสต์ Infisical เองแทนที่จะใช้ Infisical Cloud และบางแห่งก็ต้องรองรับข้อกำหนดแบบ on-premises
  • ด้วยข้อจำกัดและปัญหาด้านการใช้งานของ MongoDB จึงตัดสินใจเปลี่ยนไปใช้ PostgreSQL

ทำไมถึงเลือก PostgreSQL?

  • ระหว่างมองหาฐานข้อมูลใหม่ ปัจจัยสำคัญที่พิจารณาคือความง่ายในการดูแลจัดการ การรองรับทรานแซกชัน และความสามารถแบบ relational
  • มีการชั่งใจระหว่างโซลูชันจัดเก็บข้อมูลภายในกับโซลูชันจัดเก็บภายนอก แต่สุดท้ายเลือก PostgreSQL
  • PostgreSQL มีชุมชนที่เคลื่อนไหวอย่างแข็งขัน เอกสารที่ครบถ้วน โซลูชันและส่วนขยายที่หลากหลาย และผู้ให้บริการคลาวด์ส่วนใหญ่ก็มีบริการแบบ managed ให้ใช้งาน

เรื่องของ ORM

  • หลังจากเลือก PostgreSQL แล้ว ขั้นต่อไปคือต้องตัดสินใจว่าแอปพลิเคชันจะโต้ตอบกับฐานข้อมูลอย่างไร
  • ทีมมองหาเครื่องมือที่มอบประสบการณ์ใกล้เคียงกับ Mongoose ORM และตัดสินใจใช้ Knex.js query builder
  • Knex.js มีเครื่องมือสำหรับ seeding และ migration และเมื่อนำไปผสานกับ Zod แบบปรับแต่งเองเพื่อรองรับ TypeScript ก็ให้ผลลัพธ์ที่น่าพอใจ

แผนการย้ายระบบ

  • เมื่อการเขียนโค้ดใหม่ใกล้เสร็จ ทีมก็เริ่มคิดว่าจะทำงานย้ายข้อมูลโดยแมปข้อมูลจาก MongoDB ไปยัง PostgreSQL อย่างไรให้หยุดชะงักน้อยที่สุด
  • สำหรับ Infisical ซึ่งมีบทบาทในโครงสร้างพื้นฐานสำคัญนั้น ไม่สามารถยอมรับ downtime ได้เลย และจึงประนีประนอมด้วยการไม่อนุญาตให้มีการเขียนข้อมูลระหว่างช่วงย้ายระบบ

การย้ายครั้งใหญ่

  • เพื่อเตรียมพร้อมสำหรับการย้ายระบบ ได้จัดทำเช็กลิสต์อย่างละเอียดและไทม์ไลน์โดยประมาณ
  • การย้ายดำเนินการโดยอนุญาตให้อ่านข้อมูลได้อย่างเดียวเป็นเวลา 6 ชั่วโมง และหลังจากย้ายข้อมูลเสร็จก็สลับ DNS ไปยังอินสแตนซ์ใหม่

ผลลัพธ์

  • การย้ายระบบเป็นไปอย่างราบรื่นโดยไม่มีข้อมูลสูญหาย และข้อผิดพลาดของฟีเจอร์บางอย่างที่กระทบลูกค้าน้อยมากก็ได้รับการแก้ไขภายใน 36 ชั่วโมง
  • แพลตฟอร์มมีประสิทธิภาพดีขึ้นจากการเพิ่มประสิทธิภาพคิวรีด้วย join และยังลดค่าใช้จ่ายด้านฐานข้อมูลลงได้ 50%
  • การนำ PostgreSQL มาใช้ช่วยปรับปรุงการตรวจสอบความถูกต้องของข้อมูล และตอนนี้ Infisical ก็โฮสต์ใช้งานด้วยตนเองได้ง่ายขึ้นมาก

บทสรุป

  • การตัดสินใจย้ายจาก MongoDB ไปยัง PostgreSQL ไม่ใช่เรื่องง่าย และใช้เวลา 3-4 เดือนผ่านการวางแผนและการหารืออย่างรอบคอบ
  • ผู้เขียนแนะนำให้คิดให้ลึกถึงกรณีการใช้งานและแนวทางการใช้งานจริงก่อนจะลองทำโปรเจกต์ใหญ่ลักษณะนี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-30
ความคิดเห็นจาก Hacker News

  • ผู้ใช้คนหนึ่งที่มีประสบการณ์ดูแลทั้ง Postgres และ MongoDB ในระดับใหญ่กล่าวว่าชอบทั้งสองฐานข้อมูล แต่ไม่เข้าใจข้อจำกัดของ Postgres ในด้าน high availability (HA) และการรองรับการขยายระบบแบบแนวนอน โดยชี้ว่าการติดตั้ง Postgres แต่ละครั้งมักมีลักษณะเฉพาะตัว และต้องอาศัยส่วนขยายกับสคริปต์หลายอย่างเพื่อชดเชยข้อจำกัดเหล่านี้ พร้อมเสริมว่าส่วนขยายเหล่านี้มักมีบั๊กมากและเอกสารไม่เพียงพอ อีกทั้งยังระบุว่าการอัปเกรดทำได้ยากมากเพราะการเปลี่ยนแปลงรูปแบบไฟล์ของเมเจอร์เวอร์ชัน และรู้สึกประหลาดใจที่ MySQL ทำได้ดีกว่า Postgres มากในเรื่อง HA/การ sharding

  • มีการแชร์บล็อกโพสต์ที่อธิบายประสบการณ์การย้ายจาก MongoDB ไป PostgreSQL ในมุมมองเชิงเทคนิค โดยระบุว่าโพสต์นี้มีตัวอย่างและกราฟประกอบ จึงเน้นด้านเทคนิคมากกว่าเรื่องธุรกิจ

  • ผู้ใช้ที่กล่าวว่า PostgreSQL กำลังครองโลกของฐานข้อมูล ชี้ว่าผู้เขียนเลือกสถาปัตยกรรมที่ไม่เหมาะกับ data model ตั้งแต่แรก และระบุว่าการนำข้อมูลเชิงสัมพันธ์ไปใส่ในที่เก็บข้อมูลแบบไม่สัมพันธ์ย่อมก่อปัญหาเสมอ

  • มีการชี้ให้เห็นถึงความขัดแย้งระหว่างประโยคที่อ้างว่าการเลือก MongoDB และ Mongoose ORM เป็นการตัดสินใจที่เหมาะสมที่สุดเพื่อเร่งความเร็วในการพัฒนาฟีเจอร์ กับประโยคที่ใช้คำกล่าวของ Tony Hoare ว่า "premature optimization is the root of all evil" เพื่อทำให้การเลือกนั้นดูชอบธรรม

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

  • ผู้ใช้ที่เคยเปลี่ยนไปใช้ Postgres เพราะปัญหาที่เกิดจาก MongoDB ระบุว่าพอใจกับการตัดสินใจนั้นมาก และเสริมว่าการที่ MongoDB ใช้ JavaScript แทน SQL ทำให้ใช้งานไม่สะดวก

  • ผู้ใช้ที่ชี้ว่าบทความขาดการพูดถึงปัญหาที่เกิดขึ้นจริงระหว่างการ rewrite ตั้งคำถามว่า query ถูกทำให้เทียบเท่ากันหรือไม่ มีการจัดระบบผลิตภัณฑ์อย่างไรให้สามารถอ่านและเขียนได้จากทั้งสองฐานข้อมูล พบ bug ระหว่างการย้ายหรือไม่ และ query สามารถย้ายแบบ 1:1 ได้หรือเปล่า

  • ผู้ใช้ที่เคยใช้ MongoDB กล่าวว่า ฐานข้อมูลเอกสารเหมาะกับบาง use case แต่เมื่อเริ่มตระหนักว่าจำเป็นต้องใช้ Mongoose ก็ควรพิจารณาย้ายไปใช้ฐานข้อมูลเชิงสัมพันธ์ โดยแนะนำว่าในกรณีส่วนใหญ่ Mongoose เป็นสิ่งที่ต้องเพิ่มเข้ามาในโปรเจกต์เดิม และถ้าจำเป็นต้องใช้มันตั้งแต่แรก ก็ควรใช้ฐานข้อมูลเชิงสัมพันธ์ไปเลย

  • ผู้ใช้ที่รับช่วงต่อโปรเจกต์ซึ่งใช้ MongoDB ระบุว่าแม้รูปแบบ BSON จะไม่ดีนัก แต่ชอบที่สามารถใช้ schema เดียวกันได้ตั้งแต่ JSON API ไปจนถึงฐานข้อมูล และเสริมว่าแนวทางนี้เหมาะกับการเขียนโปรแกรมแบบ data-oriented ใน Go และ Rust พร้อมสรุปว่า MongoDB เหมาะกับงานที่เน้นการอ่านเท่านั้น และหากมีงานเขียนจำนวนมาก MongoDB ก็ไม่ได้ช่วยมากนัก

  • ผู้ใช้ที่ระบุว่าเหตุผลหลักของการย้ายไป PostgreSQL คือปัญหาเรื่องไลเซนส์มากกว่าเหตุผลทางเทคนิค แบ่งปันว่าพบประสิทธิภาพดีขึ้นจากการปรับแต่ง query ที่ใช้ join และกล่าวว่าปัจจัยชี้ขาดคือข้อมูลไม่ได้ถูกออกแบบให้เหมาะกับ key-value store จึงต้องย้ายไปใช้ที่เก็บข้อมูลประเภทที่เหมาะสมกว่า