Evan Klitzke จาก Uber เขียนบล็อกเล่าถึงสถาปัตยกรรมภายในของ Uber ที่แต่เดิมพัฒนาระบบหลังบ้านด้วย Python และ PostgreSQL ทั้งระบบ แต่ระบบใหม่ๆ กลับหันไปใช้ Schemaless บน MySQL แทน

บล็อกของ Uber ลงลึกระดับสถาปัตยกรรมของระบบฐานข้อมูลบนดิสก์ที่ PostgreSQL และ MySQL ต่างกัน (ในกรณี MySQL เปลี่ยน storage engine ได้ แต่กรณีนี้พูดถึง InnoDB เท่านั้น) ที่เมื่อเราสร้าง index บนตารางใดๆ แล้ว PostgreSQL จะสร้างตาราง index ขึ้นมาใหม่เพื่อชี้ตรงไปยังแถวของข้อมูลบนดิสก์ทันที ขณะที่ MySQL จะชี้ตำแหน่งบนดิสก์ด้วยตาราง primary index เท่านั้น การสร้าง index อื่นๆ จะต้องชี้มายัง primary index อีกชั้น นอกจากนี้ แนวคิดของ PostgreSQL ยังไม่แก้ข้อมูลเดิมบนดิสก์แต่อาศัยการสร้างแถวใหม่เพื่อวางข้อมูลใหม่ลงไป

ความต่างของสถาปัตยกรรมเช่นนี้มีเหตุผลคนละแบบ แต่ในกรณีของ Uber ที่ระบบฐานข้อมูลมีการอัพเดตจำนวนมาก สถาปัตยกรรมของ PostgreSQL จะทำให้เมื่ออัพเดตข้อมูลใดๆ ในตารางจะต้องอัพเดต index ทั้งหมด ไม่ว่าข้อมูลในหลัก (column) ที่กำลังแก้จะเกี่ยวข้องกับ index เหล่านั้นหรือไม่ก็ตาม เพราะเมื่ออัพเดตแล้วข้อมูลจะหลายเป็นแถวใหม่ และทุกๆ index ต้องชี้ตรงมายังตำแหน่งของแถวบนดิสก์โดยตรง

ระบบ index ของ PostgreSQL จะสร้างตารางสำหรับทุก index และชี้ตรงไปยังตำแหน่งบนดิสก์

ระบบ index ของ MySQL (InnoDB) จะสร้างตาราง index เพื่อชี้ไปยัง primary index อีกครั้ง

Klitzke ชี้ว่า PostgreSQL อาศัยการซิงก์ข้ามเครื่องผ่าน write-ahead-log (WAL) ที่ทำหน้าที่คือรักษาข้อมูลบนดิสก์ให้ตรงกับทั้งเครื่องต้นทางและปลายทางเท่านั้น PostgreSQL เลือกแนวทางนี้เพราะประสิทธิภาพในการอัพเดตที่เร็วกว่า แต่ก็มีข้อจำกัดในกรณีของ Uber ที่ข้อมูลมี index มากทำให้ข้อมูลที่ต้องเปลี่ยนแปลงมากไปด้วย ส่งผลไปถึงแบนวิดท์เพื่อใช้ในการซิงก์ฐานข้อมูลสูงขึ้นเป็นเงาตามตัว

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

ทางฝั่ง PostgreSQL มี Simon Riggs จาก 2ndQuadrant ออกมาเขียนบล็อกชี้แจง ระบุว่าแนวทางของ PostgreSQL มีความได้เปรียบในกรณีส่วนใหญ่ กระบวนการชี้ index ตรงไปยังข้อมูลทำให้การเข้าถึงเร็วกว่า และกระบวนการออปติไมซ์ เช่น Heap Only Tuple (HOT) ของ PostgreSQL ก็ควรจะลดปัญหาที่ Uber พบไปแล้ว

ประเด็นสำคัญที่ PostgreSQL เสียเปรียบคือการไม่มีทางเลือกสำหรับซิงก์ข้ามเครื่องแบบ logical ซึ่ง Riggs ระบุว่า pglogical ของ 2ndQuadrant เข้ามาแก้ปัญหานี้แล้ว และรองรับตั้งแต่ PostgreSQL รุ่น 9.4 ขึ้นไป ส่วน 9.1 ทาง 2ndQuadrant มีบริการให้เฉพาะ และ 9.2/9.3 จะเปิดให้บริการปีหน้า รวมถึง pglogical จะรวมไว้ในโครงการหลักของ PostgreSQL ตั้งแต่รุ่น 10.0 เป็นต้นไป

ที่มา - Uber Engineering, 2ndQuadrant