on
Infisical โครงการแพลตฟอร์มเก็บความลับ (secret management platform) แบบโอเพนซอร์ส รายงานถึงการย้ายระบบฐานข้อมูลจาก MongoDB มาเป็น PostgreSQL ว่าประสบความสำเร็จดีและทำให้การเซ็ตอัพโครงการใช้งานเองทำได้ง่ายขึ้น
ทางโครงการระบุว่าเลือก MongoDB พร้อมกับ Mongoose ORM เพราะทีมงานเคยชินกับ stack นี้ที่สุด และตอนแรกไม่ได้คิดว่าจะมีผู้ใช้พยายามติดตั้งแพลตฟอร์มใช้งานเองมากนัก แต่หลังจากโครงการได้รับความนิยม MongoDB กลับเป็นคอขวดเนื่องจากฟีเจอร์สำคัญคือการทำ transaction จำเป็นต้องติดตั้งแบบคลัสเตอร์แบบโปรดักชั่นและคนที่เชี่ยวชาญการเซ็ตอัพ MongoDB ก็หาได้ยากกว่า ขณะที่ฝั่งนักพัฒนาเองหลายครั้งก็อยากได้ฟีเจอร์ฝั่ง SQL เช่น CASCADE ที่สามารถลบข้อมูลที่เกี่ยวข้องออกไปพร้อมกันทีเดียวได้
ปัญหาอีกอย่างหนึ่งของ MongoDB คือการเปลี่ยนไลเซนส์ไปเป็น SSPL ทำให้ผู้ให้บริการคลาวด์ไม่สามารถอัพเกรดไปใช้เวอร์ชั่นล่าสุดได้ ทำให้ผู้ใช้ของ Infisical ไม่สามารถใช้บริการฐานข้อมูลคลาวด์ได้อิสระ
ทาง Infisical เลือกระหว่างการใช้ฐานข้อมูลภายใน เช่น SQLite กับฐานข้อมูลภายนอกอย่าง PostgreSQL และตัดสินใจเลือก PostgreSQL เพราะเมื่อต้องการขยายแอปพลิเคชั่นเป็นคลัสเตอร์ไม่ต้องอิมพลีเมนต์ด้วยตัวเอง สำหรับระบบ ORM นั้นโครงการเลือก Knex.js ที่เป็น query builder แทนที่จะเป็น ORM เต็มรูปแบบ เพราะต้องการควบคุมคิวรีสุดท้ายได้ แต่ยังดูแลง่ายกว่าการเขียนคิวรีเองตรงๆ
กระบวนการย้ายฐานข้อมูลของ Infisical Cloud กินเวลา 6 ชั่วโมงที่ระบบจะเปิดให้ลูกค้าอ่านข้อมูลได้เท่านั้นแต่เขียนไม่ได้ ระบบจะย้ายข้อมูลไปยัง PostgreSQL แล้วตรวจสอบข้อมูลว่ายังอยู่ครบ หลังจากนั้นจึงชี้ DNS ไปยังเซิร์ฟเวอร์ใหม่ โดยรวมมีปัญหาเพียงไม่กี่รายการ และแก้ไขได้หมดภายใน 36 ชั่วโมงหลังการย้าย และเมื่อย้ายมาแล้วแอปพลิเคชั่นเสีย overhead น้อยลงทำให้ค่าใช้จ่ายฐานข้อมูลลดลง 50% ขณะที่ตัวแอปพลิเคชั่นมีการตรวจสอบข้อมูลทีี่ระดับฐานข้อมูลละเอียดขึ้น ตัดปัญหาชนิดข้อมูลไม่ตรงกันเพราะเดิมชนิดข้อมูลนั้นไปบังคับที่ระดับ Mongoose
โดยรวมโครงการย้ายออกจาก MongoDB ครั้งนี้กินเวลา 3-4 เดือน และทีมงานพอใจกับการย้ายอย่างมาก แต่แนะนำว่าหากใครจะทำตามให้คิดอย่างระมัดระวังก่อนย้าย
ที่มา - Infisical
ดูแง ดูแล ทีี่ (สระอี) ที่
Mediumrare Sun, 31/03/2024 - 13:22
ดูแล
ที่
ไหนๆก็ใช้ mongodb อยู่ก่อน
7elven Sun, 31/03/2024 - 13:59
ไหนๆก็ใช้ mongodb อยู่ก่อน ทำไมไม่ลองย้ายไป ferretdb
การ setup cluster
Tasksenger Sun, 31/03/2024 - 20:14
In reply to ไหนๆก็ใช้ mongodb อยู่ก่อน by 7elven
การ setup cluster ของฐานข้อมูล relation ถ้าคุณมีพื้นฐานของยี่ห้ออื่นมากก่อน เรียนรู้เพิ่มเติมก็ทำได้ไม่ยาก (แค่ setup นะไม่รวมโอนย้ายข้อมูล และแปลงข้อมูลเดิมข้าม platform) แถมมีเครื่องมือในการโอนย้ายข้อมูลจากผู้ผลิตมาค่อนข้างครบ รวมถึงมันหาคนทำง่ายกว่าด้วย เมื่อหาคนทำง่ายค่าใช้จ่ายก็อยู่ในระดับที่จ่ายได้
แต่ถ้าเป็นการทำ cluster พวก NoSQL มันหาคนทำยากกว่า รวมถึงเครื่องมือในการโอนย้ายก็น้อย ต้องอาศัย manual ซะเยอะ ที่เขาบ่นเป็นเรื่องฐานข้อมูลแบบ cluster ซึ่งในรายละเอียดการ setup ระบบจริงมันยุ่งยาก ซับซ้อนมากกว่าในคู่มือ นี่ยังไม่รวมถึงเรื่องการ tuning ที่ต้องมีการออกแบบระบบเฉพาะด้วย และที่หนักสุดน่าจะเป็นการโอนย้ายข้อมูลเดิม นั่งเขียน batch กันตาบวมแน่ๆ แถมเขียนผิดชีวิตเปลี่ยนเอาง่ายๆ ถ้าเป็นแบบ single instance ผมว่าเขาก็ไม่น่าจะมีปัญหาอะไรหรอกครับ
อันนี้เราคุยเรื่องเดียวกันหรื
7elven Sun, 31/03/2024 - 21:43
In reply to การ setup cluster by Tasksenger
อันนี้เราคุยเรื่องเดียวกันหรือคนละเรื่องนะครับ จะได้อธิบายถูก
ส่วน FerrentDB มันทำตัวเป็น client proxy database ให้แอปที่ใช้ mongodb api สามารถใช้งานบน postgreSQL ได้ครับ ซึ่งแอปของเขาใช้ mongodb อยู่เดิม แต่ทีมนี้อาจจะรู้จัก หรือไม่รู้จัก FerrentDB หรือลองแล้วไม่เวิร์คก็อีกเรื่องนึง
ผมว่า ferretdb
lew Sun, 31/03/2024 - 22:01
In reply to อันนี้เราคุยเรื่องเดียวกันหรื by 7elven
ผมว่า ferretdb ก็อาจจะไม่แก้ปัญหาหลายอย่างที่เขาอยากได้ครับ โดยเฉพาะพวกฟีเจอร์การ control ของ SQL หรือ CASCADE ที่พูดถึง
แต่ก็เป็นคำถามที่ดีว่าเขาได้พิจารณา option นี้ด้วยไหม
เราอาจคุยกันคนละเรื่องก็ได้คร
Tasksenger Sun, 31/03/2024 - 23:26
In reply to อันนี้เราคุยเรื่องเดียวกันหรื by 7elven
เราอาจคุยกันคนละเรื่องก็ได้ครับ แต่โดยส่วนตัวผมจะไม่ on top ด้วยเครื่องมือที่ไม่คุ้นเคย เพราะการใช้เครื่องมือการ migrate มันทำครั้งเดียวแล้วก็จบเลย ไม่ต้องมาดูแลรักษา tool ในการทำงาน ทำให้มีหลาย layer เพราะเราจะต้องมาจัดการปัญหาในหลายโหนด ถ้าคนทำเป็นลาออกไป มันก็จะกลายเป็น black box ทีนี้ก็งานงอกแหล่ะครับ โดยเฉพาะ server ที่ทำให้ลูกค้า
อาจด้วยโจทย์ของตัวผมเองด้วยที่จะต้องสามารถจัดการปัญหาด้วยบุคลากรทั่วไปที่หาได้ในท้องตลาดด้วยล่ะครับ เพราะเคยประสบปัญหาใช้ tool ให้ได้ตามโจทย์ที่ลูกค้าต้องการ ทั้งๆ ที่ความจริงแล้วใช้วิธีบ้านๆ ก็ทำได้ แล้วพอมีปัญหาทีนี่ก็วุ่นล่ะครับ เพราะคน implement ลาออกไปแล้ว พอนั่งฟังปัญหาถึงได้พบว่า tool ที่ on top มันไปทำให้ฐานข้อมูล index พัง ซึ่งเป็นปัญหาที่นึกไม่ถึงว่าจะเกิดขึ้นได้
เอาแค่ในข่าวนะครับ การเปลี่ยน
7elven Mon, 01/04/2024 - 02:05
In reply to เราอาจคุยกันคนละเรื่องก็ได้คร by Tasksenger
เอาแค่ในข่าวนะครับ การเปลี่ยน database ของโปรเจคนี้ ไม่ได้ทำแค่ migrate data ครับ ตัวโค้ดเองก็ต้องเปลี่ยน เพราะมันใช้อันเดิมไม่ได้อยู่แล้ว เปลี่ยน orm จาก mongoose ไป knex แค่นี้โค้ดที่ query ข้อมูลมันก็ต้องเปลี่ยน ต้องแก้เยอะ ทำเทส เขียนเทสใหม่ ผมเลยเม้นต์เรื่อง FerrentDB เพราะมันอาจจะไม่ต้องแก้โค้ด หรือแก้น้อย แค่นั้นครับ
ส่วนแต่ละโปรเจคของท่านจะเลือกใช้ Database ตัวไหน ก็เลือกให้เหมาะกับงาน กับทีมที่ทำครับ
ผมเห็นด้วยกับท่านอื่นนะครับ
xcession Sat, 06/04/2024 - 19:38
In reply to เอาแค่ในข่าวนะครับ การเปลี่ยน by 7elven
ผมเห็นด้วยกับท่านอื่นนะครับ ถ้าปลายทาง สุดท้ายแล้วก็ต้องเปลี่ยน มันก็ไม่จำเป็นต้องเก็บไว้ครับ และ transition นี้ก็ไม่ได้มีอะไรมาบีบครับ ว่าต้องรีบ trans แล้ว deliver เดี๋ยวนั้นเดี๋ยวนี้ เราก็ไม่จำเป็นต้องโปะหน้าเค้กไปเพิ่ม layer ครับ ทั้งนี้ทั้งนั้นก็ขึ้นอยู่กับ vision ของ lead ด้วยครับ
ผมว่า point คือการ deliver a quality software ไม่ใช่ขอแค่ให้มันใช้งานได้ครับ
Share ๆ
EngineerRiddick Mon, 01/04/2024 - 12:15
Share ๆ ตอนนี้ผมก็เป็นผู้ประสบภัย mongodbอยู่ คือตอนimplement เขียนบนmac sonama
พอตอนเอาไป deploy ดันเป็น MacOS High Sierra (แล้วมันupdate osไม่ได้แล้ว)
แล้วเกิดปัญหา mongodb ติดนู่นนี่นั้น ติดversion ติดpluginไปหมด
อ่านข่าวนี้เสร็จ จะลองmoveไป PostgreSQL แทนดู
ทำไมถึงต้องใช้ db บน macOS
mr_tawan Mon, 01/04/2024 - 19:06
In reply to Share ๆ by EngineerRiddick
ทำไมถึงต้องใช้ db บน macOS เหรอครับ ?