จาก MongoDB สู่ Postgres

หมายเหตุ: บล็อกโพสต์นี้เป็นการรวม จาก MongoDB สู่ Postgres (2024-03-06) และ Sequelize ปะทะ Prisma (2023-05-25) เข้าด้วยกัน บล็อกต้นฉบับถูกลบออกแล้ว และบล็อกนี้เข้ามาแทนที่ เนื่องจากทั้งสองบล็อกมีเนื้อหา/ข้อมูลโดยพื้นฐานเหมือนกัน การย้ายเริ่มต้นใน ช่วงต้นเดือนมีนาคม 2023, การสลับระบบเกิดขึ้นใน ช่วงกลางเดือนพฤศจิกายน 2023, และอินสแตนซ์ทั้งหมดของระบบ MongoDB เดิมถูกปิดใช้งานโดยสมบูรณ์ใน ช่วงต้นเดือนมกราคม 2024

บทนำ

ในช่วงเวลาที่ผมทำงานที่ eBay ผมเผชิญกับปัญหาที่กลายเป็นปัญหาทางเทคนิคซึ่งท้าทายที่สุดในอาชีพของผม นั่นคือการย้ายระบบจัดการพื้นที่จัดเก็บข้อมูล (STMS) จาก MongoDB ไปยัง Postgres นี่ไม่ใช่เพียงการสลับฐานข้อมูลแบบง่าย ๆ แต่เป็นการเปลี่ยนแปลงสถาปัตยกรรมทั้งหมดของระบบสำคัญที่รับเมตริกมากกว่า 1.5 ล้านรายการต่อนาทีจากศูนย์ข้อมูลของ eBay โดยมีข้อกำหนดว่าต้องไม่มีเวลาหยุดทำงานและต้องคงฟังก์ชันการทำงานที่มีอยู่เกือบทั้งหมดไว้

STMS คืออะไร?

ระบบจัดการพื้นที่จัดเก็บข้อมูล (STMS) ทำหน้าที่เป็นเครื่องมือภายในที่สำคัญสำหรับทีมโครงสร้างพื้นฐานบริการและพื้นที่จัดเก็บข้อมูล (SSI) ของ eBay ระบบนี้ตรวจสอบและจัดการอุปกรณ์ต่าง ๆ ในศูนย์ข้อมูลของ eBay ทำให้วิศวกรสามารถ:

• ตรวจสอบเมตริกจากอาร์เรย์ สวิตช์ โฮสต์ กลุ่มดิสก์ และคลัสเตอร์จำนวนมาก
• จัดการการแจ้งเตือนสำหรับสวิตช์และอาร์เรย์
• ดำเนินงานขั้นสูง เช่น การจัดสรรโฮสต์
• เข้าถึงข้อมูลแบบเรียลไทม์สำหรับบริการภายในอื่น ๆ ของ eBay

STMS ครอบคลุมอาร์เรย์มากกว่า 70 รายการ สวิตช์ 60 ตัว โฮสต์ 1100 เครื่อง กลุ่มดิสก์ 900 กลุ่ม และคลัสเตอร์ 200 คลัสเตอร์ในศูนย์ข้อมูล 3 แห่งของ eBay เนื่องจากระบบนี้มีบทบาทสำคัญต่อโครงสร้างพื้นฐานของ eBay การหยุดทำงานหรือการสูญเสียฟังก์ชันการทำงานใด ๆ จะส่งผลกระทบโดยตรงต่อบริการหลักและการดำเนินธุรกิจของบริษัท

ความท้าทาย

เหตุใดจึงจำเป็นต้องย้ายระบบ

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

สิ่งที่ทำให้ปัญหานี้ยาก

ความซับซ้อนของการย้ายระบบนี้เกิดจากความท้าทายพื้นฐานหลายประการ:

1. ความแตกต่างพื้นฐานของฐานข้อมูล
MongoDB และ Postgres เป็นฐานข้อมูลที่แตกต่างกันโดยพื้นฐาน MongoDB เป็นฐานข้อมูลแบบเอกสาร (NoSQL) ซึ่งหมายความว่าข้อมูลถูกจัดเก็บเป็น JSON ในคอลเลกชัน คล้ายกับเอกสารในตู้เก็บเอกสาร ส่วน Postgres เป็นฐานข้อมูลเชิงสัมพันธ์ (SQL) ซึ่งหมายความว่าข้อมูลถูกจัดเก็บเป็นแถวในตาราง คล้ายกับในสเปรดชีต

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

3. ข้อกำหนดเรื่องไม่มีเวลาหยุดทำงาน
เนื่องจาก STMS เป็นเครื่องมือภายในที่สำคัญอย่างยิ่ง จึงไม่สามารถมีเวลาหยุดทำงานระหว่างการย้ายระบบได้ ระบบต้องยังคงให้บริการเมตริกมากกว่า 1.5 ล้านรายการต่อนาทีตลอดกระบวนการทั้งหมด

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

5. ขนาดและความซับซ้อน
การย้ายระบบเกี่ยวข้องกับการแปลงคอลเลกชัน MongoDB 36 คอลเลกชันให้เป็นตาราง Postgres 74 ตาราง ซึ่งจำเป็นต้องพิจารณาความสัมพันธ์ การทำดัชนี และการปรับประสิทธิภาพการสืบค้นอย่างรอบคอบ

การเลือก ORM ที่เหมาะสม: Sequelize ปะทะ Prisma

หนึ่งในการตัดสินใจสำคัญครั้งแรกคือการเลือกเครื่องมือ ORM (การแมปเชิงวัตถุ-เชิงสัมพันธ์) เนื่องจากโค้ดเบสของเราได้รับการออกแบบไว้แล้วให้ใช้ Mongoose สำหรับ MongoDB การใช้ ORM จะช่วยให้เส้นทางการเปลี่ยนผ่านราบรื่นที่สุด

การวิเคราะห์ข้อกำหนด

หลังจากวิเคราะห์ความต้องการของโครงการอย่างรอบคอบแล้ว ผมได้กำหนดเกณฑ์สำคัญสำหรับโซลูชัน ORM ใด ๆ ไว้ดังนี้:

• ต้องเป็นแพ็กเกจ JavaScript (โค้ดส่วนใหญ่ของเราเขียนด้วย JavaScript)
• ต้องรองรับ Postgres และฟีเจอร์ส่วนใหญ่ของ Postgres
• ประสิทธิภาพต้องอย่างน้อยเทียบเท่าหรือดีกว่า Mongoose
• ต้องเป็นโอเพนซอร์สและมีการดูแลรักษาอย่างต่อเนื่อง

ตัวเลือกที่พิจารณา

หลังจากค้นคว้าอย่างกว้างขวาง ผมจำกัดตัวเลือกลงเหลือคู่แข่งหลักสองราย ได้แก่ Sequelize และ Prisma ผมสร้างสภาพแวดล้อมสำหรับการทดสอบอย่างครอบคลุมโดยใช้ Docker สำหรับ Postgres และแปลงชุดข้อมูลที่ใหญ่และซับซ้อนที่สุดของเรา จากโครงสร้างเอกสารให้เป็นโครงสร้างตาราง

วิธีการทดสอบ

สำหรับ ORM แต่ละตัว ผมวัดประสิทธิภาพของการดำเนินการที่สำคัญดังต่อไปนี้:

• เวลาที่ใช้ในการสร้างรายการ
• เวลาที่ใช้ในการอัปเดตรายการ
• เวลาที่ใช้ในการอัปเดตรายการซ้อนกัน (ความสัมพันธ์และคู่คีย์-ค่าใน JSON)
• เวลาที่ใช้ในการลบรายการ
• เวลาที่ใช้ในการสืบค้น/ดึงรายการ

การตัดสินใจ: Sequelize

ประมาณวันที่ 15 พฤษภาคม 2023 ผมตัดสินใจว่า Sequelize เป็น ORM ที่เหมาะสมกว่าสำหรับกรณีการใช้งานของเรา เหตุผลมีดังนี้:

ข้อดีของ Sequelize:

• เป็นโอเพนซอร์สอย่างแท้จริงและไม่ได้รับการดูแลโดยสตาร์ทอัปที่ได้รับเงินทุน
• รองรับฟีเจอร์ส่วนใหญ่ของ Postgres
• ประสิทธิภาพดีกว่า โดยเฉพาะเมื่อเปรียบเทียบกับ Prisma
• มีระบบนิเวศที่เติบโตเต็มที่ พร้อมการพัฒนามากกว่า 10 ปี
• มีการนำเสนอโมเดล/สคีมาที่ยืดหยุ่นโดยใช้คลาส JavaScript
• รองรับการ join ที่ซับซ้อนและตัวเลือกการกรอง รวมถึง Regex

ผลลัพธ์ด้านประสิทธิภาพ:

จากการทดสอบของผม Sequelize มีประสิทธิภาพเหนือกว่า Prisma อย่างมีนัยสำคัญสำหรับรายการในชุดข้อมูลขนาดใหญ่ของเรา:

• Sequelize: ประมาณ 2.26 วินาทีต่อรายการ
• Prisma: ประมาณ 11.21 วินาทีต่อรายการ

Prisma ช้ากว่า Sequelize ประมาณ 5 เท่าสำหรับกรณีการใช้งานของเรา นอกจากนี้ การลบรายการหนึ่งรายการจากชุดข้อมูลที่ใหญ่ที่สุดของเราใช้เวลาเกือบ 4 นาทีด้วย Prisma ซึ่งไม่เป็นที่ยอมรับสำหรับข้อกำหนดของเรา

ความท้าทายของ Sequelize:

• การนำเสนอโมเดลมีความซับซ้อนและมีโค้ดมากกว่า (564 บรรทัด เทียบกับ 262 บรรทัดสำหรับ Mongoose)
• ไวยากรณ์ในบางกรณีทำให้สับสน
• การย้ายฐานข้อมูลมีความซับซ้อน
• เอกสารประกอบไม่ครอบคลุมเทียบเท่า Prisma

การเปรียบเทียบข้อดีและข้อเสียของ Sequelize และ Prisma

เพื่อให้เห็นภาพที่ครบถ้วนยิ่งขึ้นว่าเหตุใดผมจึงเลือก Sequelize ผมต้องการแบ่งปันข้อดีและข้อเสียโดยละเอียดที่ผมรวบรวมไว้สำหรับ ORM ทั้งสองตัวระหว่างการประเมินของผม นอกจากนี้ ผมยังพิจารณาว่าทั้งสองตัวเปรียบเทียบกันอย่างไรในด้านการนำเสนอสคีมาและการสนับสนุนจากชุมชน ณ วันที่ 15 พฤษภาคม 2023 การเจาะลึกนี้ช่วยยืนยันการตัดสินใจของผม และผมหวังว่ามันอาจเป็นประโยชน์สำหรับคนอื่นที่กำลังเผชิญกับการตัดสินใจในลักษณะเดียวกัน

ข้อดีของ Sequelize:

• มีฟังก์ชัน sync() ที่สร้างและจัดการตารางให้คุณโดยอัตโนมัติ ช่วยลดงานที่ต้องทำด้วยตนเองได้มาก
• สามารถจัดการ join ที่ซับซ้อนสำหรับข้อมูลซ้อนกัน ซึ่งมีความสำคัญอย่างยิ่งต่อโครงสร้างของ STMS
• รองรับตัวเลือกการกรองที่หลากหลาย รวมถึง Regex ทำให้การสืบค้นมีความยืดหยุ่น
• การนำเสนอโมเดล/สคีมาดำเนินการด้วย JavaScript แบบดิบโดยใช้คลาส ซึ่งสามารถปรับแต่งได้อย่างมากเพื่อให้เหมาะกับความต้องการเฉพาะ
• จัดการการเชื่อมต่อฐานข้อมูลได้อย่างราบรื่น รวมถึงรองรับการเชื่อมต่อสำหรับการอ่านหลายรายการ
• รองรับการสืบค้น SQL แบบดิบเมื่อคุณต้องการเข้าถึงการทำงานภายใน
• สถิติชุมชน ณ วันที่ 15 พฤษภาคม 2023: บน NPM อัปเดตล่าสุดเมื่อ 14 วันที่แล้ว มียอดดาวน์โหลดรายสัปดาห์ 1,505,835 ครั้ง; บน GitHub อัปเดตล่าสุดเมื่อวานนี้ มี Forks 4.2k รายการและ Stars 27.9k ดวง โดยเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT มานานกว่า 10 ปี ดังนั้นผมมั่นใจว่ามันจะยังคงเป็นเช่นนั้นต่อไป

ข้อเสียของ Sequelize:

• การนำเสนอโมเดล/สคีมาอาจซับซ้อนและมีโค้ดมากเกินไป ตัวอย่างเช่น ในขณะที่การนำเสนอชุดข้อมูลขนาดใหญ่ของเราด้วย Mongoose มีประมาณ 262 บรรทัด (รวมช่องว่าง) ชุดข้อมูลเดียวกันใน Sequelize กลับเพิ่มขึ้นเป็น 564 บรรทัด
• ไวยากรณ์อาจทำให้สับสนและซับซ้อนในบางสถานการณ์ ซึ่งบางครั้งทำให้การทำงานของผมช้าลง
• การย้ายหรือแก้ไขฐานข้อมูลเป็นเรื่องยุ่งยาก แม้ sequelize-cli จะสร้างสคริปต์การย้ายให้ แต่ก็ยังคงลำบากอยู่ดี แม้ว่าผมจะสังเกตว่านี่เป็นปัญหาที่พบบ่อยใน ORM ส่วนใหญ่
• เอกสารประกอบยังไม่ดีนัก แม้ว่าจะกำลังพัฒนาให้ดีขึ้น โชคดีที่เครื่องมืออย่าง ChatGPT มีความเข้าใจ Sequelize เป็นอย่างดีเนื่องจากมีประวัติยาวนาน ซึ่งช่วยเติมเต็มช่องว่างต่าง ๆ ได้
• ไม่ไวต่อประเภทข้อมูลเท่า Prisma ซึ่งอาจนำไปสู่ปัญหาในบางโครงการ
• รองรับ TypeScript อย่างจำกัด แม้เรื่องนี้จะไม่ใช่ข้อกังวลสำหรับ STMS แต่ก็อาจเป็นปัจจัยที่ทำให้คนอื่นตัดสินใจไม่เลือกใช้

ข้อดีของ Prisma:

• ใช้ภาษาสคีมาของตัวเอง ทำให้การสร้างโมเดลสะอาดและกระชับยิ่งขึ้น เมื่อเปรียบเทียบกันแล้ว ในขณะที่ Mongoose ใช้ 262 บรรทัดสำหรับชุดข้อมูลขนาดใหญ่ของเรา Prisma จัดการได้ในเพียง 221 บรรทัด
• มาพร้อมเครื่องมือ CLI ที่ช่วยทำให้การสร้างและการย้ายฐานข้อมูลง่ายขึ้น ซึ่งเป็นสิ่งที่ดีที่สุดที่ผมเคยเห็นจาก ORM จนถึงตอนนี้ แม้ว่าจะยังไม่สมบูรณ์แบบก็ตาม
• รองรับการสืบค้น SQL แบบดิบ มอบความยืดหยุ่นเมื่อต้องการ
• ไวยากรณ์ของโค้ดสะอาดและเข้าใจง่ายกว่าเมื่อเทียบกับ Sequelize ทำให้เรียนรู้ได้ง่ายกว่า
• สร้างตัวสร้างการสืบค้นสำหรับ Node.js และ TypeScript ผ่านไคลเอนต์โดยอัตโนมัติ ซึ่งเป็นรายละเอียดที่ดี
• มีเอกสารประกอบที่ยอดเยี่ยมและสะอาดตา ChatGPT อาจมีข้อมูลเกี่ยวกับ Prisma ที่ไม่อัปเดตเท่าไร แต่เอกสารทางการมักช่วยชดเชยได้
• สถิติชุมชน ณ วันที่ 15 พฤษภาคม 2023: บน NPM อัปเดตล่าสุดเมื่อ 6 วันที่แล้ว มียอดดาวน์โหลดรายสัปดาห์ 1,344,705 ครั้ง; บน GitHub อัปเดตล่าสุดเมื่อ 3 ชั่วโมงที่แล้ว มี Forks 1.1k รายการและ Stars 31.3k ดวง

ข้อเสียของ Prisma:

• ไม่รองรับการกรองด้วย Regex สำหรับ Postgres แม้ว่าจะมีทางเลือกอื่น เช่น “contains”, “includes” และ “startsWith”
• ประสิทธิภาพเป็นปัญหาสำคัญในการทดสอบของผม การสร้างรายการสำหรับชุดข้อมูลขนาดใหญ่ของเราใช้เวลาประมาณ 11.21 วินาทีต่อรายการด้วย Prisma เมื่อเทียบกับ 2.26 วินาทีของ Sequelize หรือช้ากว่าประมาณ 5 เท่า
• การลบรายการเดียวจากชุดข้อมูลขนาดใหญ่ใช้เวลาเกือบ 4 นาที ซึ่งเป็นปัจจัยที่ทำให้ไม่สามารถเลือกใช้ได้สำหรับความต้องการของเรา
• แม้จะเปรียบเทียบกันอย่างเป็นธรรมบนชุดข้อมูลความสัมพันธ์ที่ซับซ้อนและลึกสามชั้น Sequelize ก็ยังเร็วกว่าอย่างมีนัยสำคัญในการลบข้อมูล
• Prisma ได้รับการสนับสนุนโดยสตาร์ทอัปที่มีเงินทุน 56.5 ล้านดอลลาร์ แม้โค้ด ORM หลักจะเป็นโอเพนซอร์สภายใต้ Apache-2.0 แต่ผมกังวลว่าอาจมีการเปลี่ยนแปลงใบอนุญาตในอนาคต เช่นเดียวกับที่เกิดขึ้นกับ MongoDB

การเปรียบเทียบโดยละเอียดเหล่านี้ทำให้เห็นอย่างชัดเจนว่า Sequelize สอดคล้องกับความต้องการของ STMS ได้ดีกว่า โดยเฉพาะในด้านประสิทธิภาพและความน่าเชื่อถือในระยะยาว แต่ผมคิดว่าการแจกแจงรายละเอียดในลักษณะนี้อาจช่วยผู้อื่นที่กำลังต่อสู้กับการตัดสินใจแบบเดียวกันสำหรับโครงการของตนได้

กระบวนการย้ายระบบ

การแปลงโครงสร้างข้อมูล

การแปลงจากโครงสร้างเอกสารของ MongoDB ไปเป็นโครงสร้างเชิงสัมพันธ์ของ Postgres จำเป็นต้องมีการวางแผนอย่างรอบคอบ ฉันต้อง:

1. วิเคราะห์ความสัมพันธ์: ระบุว่าเอกสารใน MongoDB มีความสัมพันธ์กันอย่างไร และออกแบบความสัมพันธ์ของ foreign key ที่เหมาะสม
2. ทำข้อมูลให้อยู่ในรูปแบบมาตรฐาน: แยกเอกสารที่ซ้อนกันออกเป็นตารางแยกต่างหากตามความเหมาะสม
3. รักษาความสามารถของ JSON: ใช้คอลัมน์ JSONB สำหรับข้อมูลที่ไม่มีโครงสร้างอย่างแท้จริงและจำเป็นต้องคงความยืดหยุ่นไว้
4. ออกแบบดัชนี: สร้างดัชนีที่เหมาะสมเพื่อประสิทธิภาพในการค้นคืนข้อมูล

โซลูชันแบบกำหนดเอง

การย้ายระบบจำเป็นต้องพัฒนาโซลูชันแบบกำหนดเองหลายประการ:

1. สคริปต์การย้ายข้อมูล
ฉันสร้างสคริปต์ที่ครอบคลุมเพื่อ:

• ดึงข้อมูลจากคอลเลกชันของ MongoDB
• แปลงโครงสร้างเอกสารเป็นรูปแบบเชิงสัมพันธ์
• นำเข้าข้อมูลลงในตารางของ Postgres พร้อมความสัมพันธ์ที่ถูกต้อง

2. เลเยอร์ความเข้ากันได้ของ API
เพื่อคงการให้บริการโดยไม่มีช่วงหยุดทำงาน ฉันสร้างเลเยอร์ความเข้ากันได้ที่สามารถ:

• กำหนดเส้นทางคำขอไปยัง MongoDB หรือ Postgres ตามสถานะการย้ายระบบ
• รับรองความสอดคล้องของข้อมูลในช่วงเปลี่ยนผ่าน
• จัดเตรียมกลไกสำรอง

3. มิดเดิลแวร์แบบกำหนดเอง
พัฒนามิดเดิลแวร์เพื่อจัดการความแตกต่างในวิธีที่ MongoDB และ Postgres จัดการการดำเนินการบางอย่าง เพื่อให้ endpoint ของ API เดิมยังคงทำงานได้โดยไม่ต้องแก้ไข

การเอาชนะความท้าทายทางเทคนิค

การจัดการความสัมพันธ์ที่ซับซ้อน

หนึ่งในความท้าทายที่ใหญ่ที่สุดคือการแปลงเอกสารที่ฝังอยู่ภายในของ MongoDB ให้เป็นความสัมพันธ์ใน Postgres ตัวอย่างเช่น เอกสาร MongoDB หนึ่งรายการอาจประกอบด้วย:

• คุณสมบัติพื้นฐาน
• อ็อบเจ็กต์ที่ซ้อนกันซึ่งแสดงถึงเอนทิตีที่เกี่ยวข้อง
• อาร์เรย์ของเอกสารที่ฝังอยู่

สิ่งนี้ต้องถูกแยกองค์ประกอบอย่างรอบคอบออกเป็น:

• ตารางหลักสำหรับเอนทิตีสำคัญ
• ตารางเชื่อมโยงสำหรับความสัมพันธ์แบบหลายต่อหลาย
• ความสัมพันธ์ของ foreign key สำหรับความสัมพันธ์แบบหนึ่งต่อหลาย

การเพิ่มประสิทธิภาพคำค้น

รูปแบบการค้นคืนข้อมูลของ MongoDB ไม่สามารถแปลงเป็น SQL ได้โดยตรง ฉันต้อง:

• เขียน aggregation pipeline ที่ซับซ้อนใหม่ให้เป็น SQL join
• ปรับแต่งดัชนีให้เหมาะสมกับรูปแบบการค้นคืนข้อมูลใหม่
• รับรองว่าประสิทธิภาพของคำค้นเป็นไปตามหรือดีกว่าประสิทธิภาพของ MongoDB

ความถูกต้องครบถ้วนของข้อมูล

การรับรองความถูกต้องครบถ้วนของข้อมูลระหว่างการย้ายระบบจำเป็นต้องมี:

• สคริปต์ตรวจสอบความถูกต้องที่ครอบคลุม
• ขั้นตอนการย้อนกลับ
• การซิงโครไนซ์ข้อมูลแบบเรียลไทม์ในช่วงเปลี่ยนผ่าน

ผลลัพธ์และผลกระทบ

การย้ายระบบ STMS จาก MongoDB ไปยัง Postgres เสร็จสมบูรณ์โดยไม่มีช่วงหยุดทำงาน พร้อมทั้งยังคงรักษาฟีเจอร์และฟังก์ชันการทำงานเกือบทั้งหมดไว้ ผลลัพธ์ดีกว่าที่คาดการณ์ไว้:

การปรับปรุงประสิทธิภาพ:

• ประสิทธิภาพของคำค้นดีขึ้นสำหรับคำค้นเชิงสัมพันธ์ที่ซับซ้อน
• ความสอดคล้องและความถูกต้องครบถ้วนของข้อมูลดีขึ้น
• การใช้พื้นที่จัดเก็บมีประสิทธิภาพมากขึ้น

ประโยชน์ด้านการปฏิบัติการ:

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

ผลกระทบต่อทีม:

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

ทักษะทางเทคนิคที่ได้รับ

โครงการนี้ขยายความเชี่ยวชาญด้านเทคนิคของฉันอย่างมาก:

เทคโนโลยีฐานข้อมูล:

• ความเข้าใจอย่างลึกซึ้งเกี่ยวกับฟีเจอร์และการปรับประสิทธิภาพของ Postgres
• การปรับประสิทธิภาพคำค้น SQL และการปรับแต่งประสิทธิภาพ
• รูปแบบการออกแบบฐานข้อมูลและการทำข้อมูลให้อยู่ในรูปแบบมาตรฐาน
• การกำหนดค่าฐานข้อมูลแบบหลัก-สำรอง

เครื่องมือสำหรับการพัฒนา:

• Sequelize ORM และการสร้างคำค้น
• กลยุทธ์การย้ายฐานข้อมูล
• วิธีการทดสอบประสิทธิภาพ
• การตรวจสอบความถูกต้องและความถูกต้องครบถ้วนของข้อมูล

รูปแบบสถาปัตยกรรม:

• กลยุทธ์การย้ายระบบโดยไม่มีช่วงหยุดทำงาน
• เลเยอร์ความเข้ากันได้ของ API
• รูปแบบการแยกส่วนฐานข้อมูล
• ระบบตรวจสอบและแจ้งเตือน

การเติบโตส่วนบุคคลและวิชาชีพ

โครงการย้ายระบบนี้เปลี่ยนแปลงเส้นทางการพัฒนาอาชีพของฉันอย่างมาก มันผลักดันให้ฉันก้าวเข้าสู่พื้นที่ที่ไม่คุ้นเคย โดยจำเป็นต้องมี:

ทักษะความเป็นผู้นำ:

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

ความสามารถในการแก้ไขปัญหา:

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

การสื่อสารและการทำงานเป็นทีม:

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

บทเรียนที่ได้รับ

บทเรียนทางเทคนิค

1. การเลือกฐานข้อมูลมีความสำคัญ: การเลือกระหว่าง NoSQL และ SQL ควรพิจารณาจากกรณีการใช้งานเฉพาะและข้อกำหนดระยะยาว
2. การทดสอบประสิทธิภาพมีความสำคัญอย่างยิ่ง: ข้อได้เปรียบในทางทฤษฎีไม่ได้แปลเป็นการเพิ่มประสิทธิภาพในโลกจริงเสมอไป
3. การวางแผนการย้ายระบบ: การวางแผนและการทดสอบอย่างครอบคลุมเป็นสิ่งจำเป็นสำหรับการย้ายระบบที่ซับซ้อน
4. การลงทุนในเครื่องมือ: การสร้างเครื่องมือที่เหมาะสมตั้งแต่ต้นช่วยประหยัดเวลาได้อย่างมากและลดข้อผิดพลาด

บทเรียนด้านการจัดการโครงการ

1. การสื่อสารกับผู้มีส่วนได้ส่วนเสีย: การอัปเดตเป็นประจำและการสื่อสารที่ชัดเจนช่วยป้องกันความเข้าใจผิด
2. การจัดการความเสี่ยง: การมีแผนสำรองและขั้นตอนการย้อนกลับเป็นสิ่งจำเป็น
3. การจัดการกำหนดเวลา: เผื่อเวลาสำหรับความท้าทายที่ไม่คาดคิดและช่วงการเรียนรู้
4. การจัดทำเอกสาร: เอกสารที่ละเอียดถี่ถ้วนช่วยให้ถ่ายโอนความรู้และบำรุงรักษาในอนาคตได้

บทสรุป

การย้ายระบบ STMS จาก MongoDB ไปยัง Postgres ถือเป็นปัญหาทางเทคนิคที่ท้าทายและให้ผลตอบแทนมากที่สุดที่ฉันเคยแก้ไขในเส้นทางอาชีพของฉัน งานนี้ไม่เพียงต้องอาศัยความเชี่ยวชาญทางเทคนิคเท่านั้น แต่ยังต้องอาศัยความเป็นผู้นำ การวางแผน และความสามารถในการปรับตัวด้วย ความสำเร็จของโครงการแสดงให้เห็นว่า ด้วยการวางแผนที่เหมาะสม การทดสอบอย่างละเอียดถี่ถ้วน และความมุ่งมั่นสู่ความเป็นเลิศ แม้แต่ความท้าทายทางเทคนิคที่ซับซ้อนที่สุดก็สามารถเอาชนะได้

ประสบการณ์นี้เปลี่ยนแปลงแนวทางการทำวิศวกรรมซอฟต์แวร์ของฉันโดยพื้นฐาน โดยเน้นย้ำถึงความสำคัญของ:

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

ความสำเร็จของการย้ายระบบไม่เพียงปรับปรุงความสามารถของ STMS เท่านั้น แต่ยังสร้างรูปแบบและกระบวนการที่ยังคงเป็นประโยชน์ต่อโครงการโครงสร้างพื้นฐานของ eBay อย่างต่อเนื่อง ประสบการณ์นี้ตอกย้ำความเชื่อของฉันว่า การยอมรับความท้าทายที่ไม่คุ้นเคยและประสบความสำเร็จผ่านความท้าทายเหล่านั้นคือกุญแจสำคัญทั้งต่อการพัฒนาส่วนบุคคลและวิชาชีพ

เมื่อมองย้อนกลับไป โครงการนี้ถือเป็นจุดเปลี่ยนในเส้นทางอาชีพของฉัน โดยเปลี่ยนฉันจากนักพัฒนาที่นำโซลูชันไปใช้งาน ไปเป็นวิศวกรที่สามารถออกแบบสถาปัตยกรรมและเป็นผู้นำโครงการริเริ่มทางเทคนิคที่ซับซ้อนได้ ความมั่นใจและทักษะที่ได้รับจากประสบการณ์นี้ยังคงชี้นำแนวทางของฉันต่อความท้าทายและโอกาสใหม่ ๆ ในงานวิศวกรรมซอฟต์แวร์ q.