- เข้าร่วม
- 1 มิถุนายน 2011
- ข้อความ
- 15,638
- คะแนนปฏิกิริยา
- 0
- คะแนน
- 36
OpenAI ใช้ PostgreSQL คลัสเตอร์เดียวทั้งโลก, primary เขียนเครื่องเดียว ระบุยังใช้ได้อีกไกล
Body
OpenAI รายงานถึงประสบการณ์การใช้ฐานข้อมูล PostgreSQL เพื่อให้บริการผู้ใช้แอป ChatGPT ถึง 800 ล้านคน แม้จะต้องปรับการใช้งานเพื่อให้รองรับปริมาณผู้ใช้ที่เพิ่มขึ้นเรื่อยๆ แต่แกนกลางยังคงเป็น PostgreSQL คลัสเตอร์เดียว
ทาง OpenAI ใช้ Azure PostgreSQL Flexible Server มีเครื่อง primary สำหรับเขียนเครื่องเดียว แต่มีเครื่อง read replica สำหรับอ่านเกือบ 50 เครื่องกระจายไปทั่วโลก ทีมงานไม่พยายามทำ sharding เพื่อกระจายโหลดการเขียนออกไปจากเครื่อง primary ข้อจำกัดของ PostgreSQL คือเมื่อการเขียนซ้อนกันฟีเจอร์ multiversion concurrency control (MVCC) ของ PostgreSQL จะทำให้ประสิทธิภาพการเขียนต่ำลงอย่างมาก
แนวทางแก้ไขคือการย้ายตารางที่มีการเขียนหนักๆ ออกไปยัง Azure CosmosDB แทน โดย CosmosDB มีการทำ sharding เพื่อให้รองรับการเขียนที่มากขึ้นเรื่อยๆ ตอนนี้ฐานข้อมูลใน PostgreSQL ไม่มีการเพิ่มตารางใดๆ อีกแล้ว และยังค่อยๆ ย้ายตารางที่มีการเขียนสูงๆ ออกไปยัง CosmosDB
เนื่องจากเครื่อง primary ต้องรับงานเขียนทั้งหมด ทีมงานพยายามหลีกเลี่ยงการใช้งานเครื่อง primary ในการอ่านทั้งหมดยกเว้นเป็นการอ่านเพื่อทำ transaction ที่มีการเขียนเท่านั้น และแม้จะบอกว่ามี primary เครื่องเดียวแต่ก็มี hot standby อีกเครื่องรอรับหน้าที่แทนตลอดเวลา
ปัญหาของการใช้ PostgreSQL คือการคิวรีที่ซับซ้อนมากๆ มีการ join หลายตารางเข้าด้วยกัน ทาง OpenAI พบว่าปัญหาเช่นนี้มักเกิดจากการใช้เฟรมเวิร์ค ORM สร้างคิวรีโดยนักพัฒนาไม่รู้ตัว ดังนั้นการรีวิว SQL สุดท้ายจึงสำคัญ ขณะที่งานบางประเภทจะคิวรีแบบโหลดหนักจริงๆ ในกรณีนี้ทาง OpenAI จะแยกคิวรีกลุ่มนี้ออกไปรันในเครื่องเฉพาะ ขณะที่เครื่องอ่านนั้นรองรับการเชื่อมต่อได้ 6,000 ชุดเท่านั้น จึงต้องใช้ PgBouncer มาคั่นกลาง
เทคนิคอื่น เช่น การล็อก cache ที่หากมีแอปหลายเครื่องต้องการข้อมูลจากแคชชุดเดียวกันจะมีการคิวรีจริงเพียงชุดเดียว, การซิงก์ข้อมูลจะเป็นการซิงก์ต่อๆ กัน ไม่ได้ซิงก์จาก primary ทั้งหมด, การคิวรีต่างๆ ถูกควบคุม rate limit อย่างละเอียด, และการแก้ไข schema จะถูกล็อกว่าต้องแก้ไขน้อยพอที่จะทำงานเสร็จภายใน 5 วินาที
ตอนนี้ PostgreSQL ของ OpenAI ตอบคิวรีภายในเวลาต่ำกว่า 100ms ได้ 99% และความน่าเชื่อถือระดับ 99.999% มีเหตุระบบล่มระดับ SEV-0 เพียงครั้งเดียว
ที่มา - OpenAI
lew Fri, 23/01/2026 - 21:48
Continue reading...
Body
OpenAI รายงานถึงประสบการณ์การใช้ฐานข้อมูล PostgreSQL เพื่อให้บริการผู้ใช้แอป ChatGPT ถึง 800 ล้านคน แม้จะต้องปรับการใช้งานเพื่อให้รองรับปริมาณผู้ใช้ที่เพิ่มขึ้นเรื่อยๆ แต่แกนกลางยังคงเป็น PostgreSQL คลัสเตอร์เดียว
ทาง OpenAI ใช้ Azure PostgreSQL Flexible Server มีเครื่อง primary สำหรับเขียนเครื่องเดียว แต่มีเครื่อง read replica สำหรับอ่านเกือบ 50 เครื่องกระจายไปทั่วโลก ทีมงานไม่พยายามทำ sharding เพื่อกระจายโหลดการเขียนออกไปจากเครื่อง primary ข้อจำกัดของ PostgreSQL คือเมื่อการเขียนซ้อนกันฟีเจอร์ multiversion concurrency control (MVCC) ของ PostgreSQL จะทำให้ประสิทธิภาพการเขียนต่ำลงอย่างมาก
แนวทางแก้ไขคือการย้ายตารางที่มีการเขียนหนักๆ ออกไปยัง Azure CosmosDB แทน โดย CosmosDB มีการทำ sharding เพื่อให้รองรับการเขียนที่มากขึ้นเรื่อยๆ ตอนนี้ฐานข้อมูลใน PostgreSQL ไม่มีการเพิ่มตารางใดๆ อีกแล้ว และยังค่อยๆ ย้ายตารางที่มีการเขียนสูงๆ ออกไปยัง CosmosDB
เนื่องจากเครื่อง primary ต้องรับงานเขียนทั้งหมด ทีมงานพยายามหลีกเลี่ยงการใช้งานเครื่อง primary ในการอ่านทั้งหมดยกเว้นเป็นการอ่านเพื่อทำ transaction ที่มีการเขียนเท่านั้น และแม้จะบอกว่ามี primary เครื่องเดียวแต่ก็มี hot standby อีกเครื่องรอรับหน้าที่แทนตลอดเวลา
ปัญหาของการใช้ PostgreSQL คือการคิวรีที่ซับซ้อนมากๆ มีการ join หลายตารางเข้าด้วยกัน ทาง OpenAI พบว่าปัญหาเช่นนี้มักเกิดจากการใช้เฟรมเวิร์ค ORM สร้างคิวรีโดยนักพัฒนาไม่รู้ตัว ดังนั้นการรีวิว SQL สุดท้ายจึงสำคัญ ขณะที่งานบางประเภทจะคิวรีแบบโหลดหนักจริงๆ ในกรณีนี้ทาง OpenAI จะแยกคิวรีกลุ่มนี้ออกไปรันในเครื่องเฉพาะ ขณะที่เครื่องอ่านนั้นรองรับการเชื่อมต่อได้ 6,000 ชุดเท่านั้น จึงต้องใช้ PgBouncer มาคั่นกลาง
เทคนิคอื่น เช่น การล็อก cache ที่หากมีแอปหลายเครื่องต้องการข้อมูลจากแคชชุดเดียวกันจะมีการคิวรีจริงเพียงชุดเดียว, การซิงก์ข้อมูลจะเป็นการซิงก์ต่อๆ กัน ไม่ได้ซิงก์จาก primary ทั้งหมด, การคิวรีต่างๆ ถูกควบคุม rate limit อย่างละเอียด, และการแก้ไข schema จะถูกล็อกว่าต้องแก้ไขน้อยพอที่จะทำงานเสร็จภายใน 5 วินาที
ตอนนี้ PostgreSQL ของ OpenAI ตอบคิวรีภายในเวลาต่ำกว่า 100ms ได้ 99% และความน่าเชื่อถือระดับ 99.999% มีเหตุระบบล่มระดับ SEV-0 เพียงครั้งเดียว
ที่มา - OpenAI
lew Fri, 23/01/2026 - 21:48
Continue reading...