OpenAI: ก้าวข้ามขีดจำกัดการขยายระบบของ PostgreSQL

 (pixelstech.net)
35 คะแนน โดย GN⁺ 2025-05-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenAI ได้แบ่งปันที่งาน PGConf.dev 2025 ว่าพวกเขา ใช้งาน PostgreSQL โดยไม่ทำ sharding แต่ยังรองรับทราฟฟิกจากผู้ใช้หลายร้อยล้านคนได้อย่างมีประสิทธิภาพ
  • เพื่อแก้ปัญหา คอขวดด้านการเขียน จึงนำแนวทางหลากหลายมาใช้ เช่น การกระจายงานเขียน การปรับแต่งคิวรี และการจัดการสคีมา
  • ประเด็นสำคัญที่กล่าวถึงคือข้อจำกัดเชิงโครงสร้างและความยากในการปฏิบัติการของ PostgreSQL เช่น ตาราง/ดัชนีบวมจากการออกแบบ MVCC และ ความล่าช้าในการทำ replication จาก WAL
  • กลยุทธ์การปรับแต่งคิวรีที่เป็นหัวใจสำคัญ ได้แก่ การกระจายโหลดการอ่าน การจำกัดทรานแซกชันที่ยาวนาน และการลดการใช้ ORM ให้น้อยที่สุด
  • OpenAI บรรลุ 1 ล้าน QPS ผ่าน replica ที่กระจายอยู่มากกว่า 40 ตัวในหลายพื้นที่ทางภูมิศาสตร์ และยังคงรับประกันความพร้อมใช้งานสูงได้แม้เกิดเหตุขัดข้อง

กรณีศึกษาการขยาย PostgreSQL ขนาดใหญ่ของ OpenAI

ภูมิหลัง

  • บริการหลักจำนวนมากของ OpenAI พึ่งพา PostgreSQL
  • หากฐานข้อมูลขัดข้อง จะส่งผลกระทบโดยตรงต่อบริการทั้งหมด
  • ในอดีตบริการสำคัญอย่าง ChatGPT เคยเกิดการหยุดชะงักจากปัญหา PostgreSQL มาแล้ว
  • OpenAI ดำเนินงานบน ฐานข้อมูลแบบจัดการโดย Azure ด้วยสถาปัตยกรรม Primary-Replica (Primary เดียว + Replicas มากกว่า 40 ตัว)
  • ในสภาพแวดล้อมที่รองรับผู้ใช้งานต่อเดือน 500 ล้านคน ความสามารถในการขยายระบบ เป็นปัจจัยสำคัญต่อความสำเร็จทางธุรกิจ

ความท้าทายหลัก

  • ทราฟฟิกการอ่าน สามารถกระจายไปยัง replica หลายตัวได้ แต่ คำขอเขียน จะไปรวมที่ Primary เพียงตัวเดียวจนเกิดคอขวด
  • จุดปรับปรุงหลัก
    • offload คำขอเขียนทุกอย่างที่สามารถทำได้เพื่อกระจายภาระ
    • ลดการเชื่อมต่อเพิ่มเติมจากบริการใหม่เข้าสู่ Primary DB ให้เหลือน้อยที่สุด
  • ด้วยโครงสร้าง MVCC (Multi-Version Concurrency Control) จึงมีข้อเสียอย่างตาราง/ดัชนีบวม การปรับแต่ง garbage collection ที่ซับซ้อน และการตรวจสอบ visibility ของดัชนี
  • เมื่อจำนวน replica เพิ่มขึ้น ทราฟฟิก WAL (Write-Ahead Logging) ก็เพิ่มขึ้นอย่างมากเช่นกัน ทำให้แบนด์วิดท์เครือข่ายกลายเป็นคอขวดอีกจุด

แนวทางรับมือ

การกระจายภาระของฐานข้อมูล Primary

  • การคาดการณ์และบรรเทาภาระงานเขียน:
    • offload งานเขียนทุกอย่างที่ทำได้
    • ป้องกันการเขียนในระดับแอปพลิเคชันที่ไม่จำเป็น
    • ใช้ Lazy Write และปรับรอบการทำ data backfill
  • ภาระการอ่านถูกกระจายไปยัง replica ให้มากที่สุด ส่วนกรณีที่เลี่ยงไม่ได้ต้องประมวลผลบน Primary จะต้องมีประสิทธิภาพสูง

การปรับแต่งคิวรี

  • ทรานแซกชันระยะยาวยึดทรัพยากรของระบบไว้นาน และทำให้ garbage collection ล่าช้า
  • ตั้งค่า Timeout แยกตาม session/query/client และจำกัด session แบบ Idle in transaction
  • ระบุว่าการใช้ ORM อาจเพิ่มความไม่มีประสิทธิภาพ จึงแนะนำให้ใช้อย่างระมัดระวัง
  • มีการปรับแต่งคิวรี multi-join ที่ซับซ้อน (เช่น join 12 ตาราง)

การรับมือจุดล้มเหลวจุดเดียว (SPOF)

  • หาก Primary ล่มจะไม่สามารถเขียนได้ ขณะที่ Replicas แม้จะล่มบางส่วนก็ยังคงความต่อเนื่องของการอ่านได้
  • คำขอสำคัญ (ลำดับความสำคัญสูง) ถูกส่งไปยัง replica เฉพาะทาง เพื่อลดการรบกวนจากคำขอลำดับความสำคัญต่ำ

การจัดการสคีมา

  • การสร้างตารางใหม่และการนำ workload ใหม่เข้าคลัสเตอร์ถูกจำกัด
  • การเพิ่ม/ลบคอลัมน์ อนุญาตเฉพาะงานเบาที่เสร็จได้ภายใน 5 วินาที ส่วนงานที่ต้อง rewrite ทั้งตารางไม่สามารถทำได้
  • การสร้าง/ลบดัชนีอนุญาตเฉพาะเมื่อใช้ตัวเลือก CONCURRENTLY เท่านั้น
  • มีปัญหาที่คิวรีระยะยาวซึ่งใช้เวลามากกว่า 1 วินาทีบล็อกการเปลี่ยนสคีมาอย่างต่อเนื่อง จึงต้องปรับแต่งหรือ offload คิวรีเหล่านี้ในระดับแอปพลิเคชัน

ผลลัพธ์ในการปฏิบัติการ

  • ทั้งคลัสเตอร์รองรับ 1 ล้าน QPS (อ่าน+เขียน) เพื่อสนับสนุนบริการหลักของ OpenAI
  • แม้เพิ่ม replica กว่า 40 ตัว ก็ไม่พบว่าความล่าช้าในการ replication เพิ่มขึ้น
  • มีการวาง Read-only Replica ในหลาย Region เพื่อรักษา latency ให้ต่ำ
  • ในช่วง 9 เดือนที่ผ่านมาเกิด เหตุขัดข้องระดับ SEV0 ที่เกี่ยวข้องกับ PostgreSQL เพียง 1 ครั้ง
  • มีการสำรองความจุไว้รองรับการเติบโตในอนาคต

กรณีเหตุขัดข้อง

  • ความล้มเหลวของแคช ที่ก่อให้เกิด cascading effect
  • บั๊กที่ทำให้เมื่อ CPU ใช้งานสูง โปรเซส WALSender หยุดส่ง WAL และติดอยู่ในลูป → เกิดความล่าช้าในการ replication

คำขอปรับปรุงฟีเจอร์ที่เสนอให้ PostgreSQL

  1. การจัดการดัชนี: เสนอฟังก์ชัน Disable เพื่อปิดใช้งานดัชนีที่ไม่จำเป็นอย่างปลอดภัย (เพื่อลดความเสี่ยงก่อนลบ)
  2. Observability: ขอให้มีเมตริกแบบ latency histogram/quantile เช่น p95, p99
  3. ประวัติการเปลี่ยนสคีมา: ต้องการฟังก์ชันสำหรับเก็บประวัติการเปลี่ยนสคีมา เช่น DDL
  4. ทำความหมายของ monitoring view ให้ชัดเจน: สอบถามสาเหตุและแนวทางรับมือกรณีที่บาง session อยู่ในสถานะ ClientRead เป็นเวลานาน
  5. การปรับพารามิเตอร์เริ่มต้นให้เหมาะสมขึ้น: ค่าเริ่มต้นของ PostgreSQL ค่อนข้างอนุรักษนิยมเกินไป จึงขอค่าเริ่มต้นหรือ heuristic ที่ดีกว่านี้

ความเห็นของ Lao Feng

  • กลยุทธ์การขยายระบบของ OpenAI ภายใต้สภาพแวดล้อมสุดขั้วเช่นนี้มีคุณค่าต่อผู้พัฒนาแกนหลักของ PostgreSQL ในฐานะกรณีใช้งานจริง
  • บริการขนาดใหญ่ เช่น Tantan ของจีน ก็มีประสบการณ์คล้ายกัน (replica 33 ตัว, 400,000 QPS, ใช้ sharding ฝั่งแอปพลิเคชัน)
  • ในยุคนี้ที่ฮาร์ดแวร์สมรรถนะสูง การขยายระบบเชิงรุกด้วย PostgreSQL คลัสเตอร์เดียว แบบ OpenAI ก็เป็นจริงได้ แสดงว่าฐานข้อมูลแบบกระจายไม่จำเป็นเสมอไป
  • OpenAI ใช้ Azure Managed PostgreSQL, replica มากกว่า 40 ตัว, การ deploy ข้าม region และ Kubernetes + PgBouncer
  • แม้จะได้รับการสนับสนุนอย่างเข้มข้นจากทีม Azure PostgreSQL แต่ก็ยังต้องอาศัย ทักษะด้านปฏิบัติการของแอปพลิเคชัน/DBA และ observability อย่างมาก
  • มีการกล่าวถึงการมอนิเตอร์ผ่าน Datadog รวมถึงภาระด้านประสิทธิภาพและต้นทุน
  • ความรู้เชิงปฏิบัติการ ประสบการณ์ความล้มเหลว และทรัพย์สินด้าน DBA เป็นหัวใจของคุณภาพบริการ

Q&A ของ Lao Feng

ฟังก์ชันปิดใช้งานดัชนี

  • ภายใน PostgreSQL สามารถปิดใช้งานดัชนีได้ผ่านฟิลด์ indisvalid (แต่ ต้องใช้สิทธิ์ superuser และมีข้อจำกัดในสภาพแวดล้อม RDS)
  • ทางเลือกที่ใช้ได้จริงคือมอนิเตอร์การใช้งานดัชนีก่อน แล้วจึงลบอย่างปลอดภัย

การขยาย observability: P95/P99 latency

  • การรองรับเมตริก quantile ใน pg_stat_statements ทำได้ยากเพราะมี memory overhead แต่ยังมีทางอ้อม เช่น pg_stat_monitor/eBPF/การมอนิเตอร์ latency ในชั้นแอปพลิเคชัน
  • ในสภาพแวดล้อม Azure Managed PostgreSQL บางตัวเลือก (เช่น การเข้าถึงเซิร์ฟเวอร์, eBPF) ไม่รองรับ

ประวัติการเปลี่ยนสคีมา

  • สามารถใช้ log file, pgaudit, CREATE EVENT TRIGGER, pg_ddl_historization เป็นต้นได้ (แต่ ต้องใช้สิทธิ์ superuser และ Azure RDS รองรับจำกัด)
  • รูปแบบที่ต้องการคือการเก็บประวัติในลักษณะ system view/table ที่ query ได้

ความหมายของ monitoring view

  • ชุดสถานะ State=Active + WaitEvent=ClientRead หมายถึงอยู่ระหว่างรัน statement แต่กำลังรออินพุตจากไคลเอนต์ ซึ่งอาจเกิดได้จากหลายสาเหตุและไม่ได้เป็นบั๊กเสมอไป
  • สามารถลดผลข้างเคียงได้ด้วยการจำกัดอายุการเชื่อมต่อ (เช่น ตั้งค่า connection expiry ในชั้นเครือข่ายอย่าง HAProxy หรือจัดการอายุของ client connection pool) แต่ใน Azure ยังไม่แน่ชัดว่ารองรับหรือไม่

พารามิเตอร์เริ่มต้น

  • แม้ค่าเริ่มต้นของ PostgreSQL จะอนุรักษนิยมเกินไป แต่สามารถชดเชยได้ด้วย heuristic เฉพาะบริการหรือการปรับพารามิเตอร์อัตโนมัติ (เช่น RDS, Pigsty)
  • หากในอนาคตมีฟังก์ชันในเครื่องมือ PostgreSQL ที่ตรวจจับและปรับใช้ตามสเปกฮาร์ดแวร์อัตโนมัติได้ ก็จะช่วยลดภาระหน้างานลง

ตัวเลือกการดูแลเอง (self-hosting)

  • ปัญหาเชิงปฏิบัติการที่แท้จริงส่วนใหญ่ไม่ได้มาจาก PostgreSQL เอง แต่เกิดจาก ข้อจำกัดของ Azure Managed
  • หากสร้าง PostgreSQL คลัสเตอร์บน NVMe SSD ด้วยตนเองในสภาพแวดล้อม IaaS (เช่น Pigsty) จะได้ความยืดหยุ่นทั้งด้านฟังก์ชันและการปฏิบัติการมากขึ้น
  • มีการระบุว่าหากใช้โซลูชันอย่าง Pigsty ก็สามารถแก้โจทย์ส่วนใหญ่ของ OpenAI ได้ล่วงหน้า จึงน่าพิจารณาตามขนาดและความต้องการ

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

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

 
GN⁺ 2025-05-24
ความคิดเห็นจาก Hacker News

  • สัปดาห์ที่แล้วได้ไปร่วมงาน PGConf และประทับใจที่เซสชันนี้เป็นหนึ่งในเซสชันที่มีคนแน่นที่สุด โดยเฉพาะเมื่อเป็นงานประชุมที่ค่อนข้างเน้นคนในวงการและหลายเซสชันโฟกัสที่การพัฒนา Postgres เอง จึงยิ่งทำให้กรณีศึกษานี้รู้สึกสดใหม่ ยิ่งตอกย้ำว่าหลายทีมไม่ได้เข้าใจลึกซึ้งตั้งแต่แรกว่าเมื่อโปรดักต์เติบโตสำเร็จแล้วจะขยายส่วนใดของสแตกอย่างไร และพรีเซนเทชันนี้ก็เป็นเรื่องราวที่ยอดเยี่ยมที่แสดงให้เห็นว่าทีมเล็ก ๆ เรียนรู้และฝ่าปัญหาไปได้อย่างไร แทนที่จะตอบแบบง่าย ๆ ว่า "ทำแบบนี้ไม่ได้เหรอ" มันกลับถ่ายทอดการเติบโตและความนิยมอย่างสูงของโปรดักต์ผ่านเรื่องราวของผู้ใช้จริงได้อย่างมีชีวิตชีวา จึงรู้สึกว่าเป็นเซสชันที่เหมาะกับงานที่มีนักพัฒนาภายในเป็นกลุ่มหลักมาก ใจความสำคัญของพรีเซนเทชันนี้คือ ถ้างานเขียนไม่ได้มากนัก ก็สามารถสเกล Postgres ไปสู่ปริมาณงานอ่านมหาศาลได้ด้วยโหนดอ่านอย่างเดียว (read replicas) และสถาปัตยกรรม single master เพียงเท่านั้น และนี่แหละคือข้อความที่ใช้ได้กับแอปส่วนใหญ่จริง ๆ ช่วง Q&A ก็ส่วนใหญ่เป็นคำถามจาก core developer ของ Postgres ที่อยากเรียนรู้ use case มากกว่าจะวิจารณ์ ทำให้รู้สึกว่าคอมมูนิตี้ Postgres เป็นมิตรและเปิดกว้างมาก

    • สำหรับข้อความที่ว่า "ถ้างานเขียนไม่ได้มาก ก็สามารถสเกลปริมาณงานอ่านของ Postgres ได้มากด้วย single master และ read-only replicas" สิ่งที่รู้สึกจากการสัมภาษณ์ system design คือมีผู้สมัครมากเกินไปที่พยายามใส่โครงสร้างกระจายขนาดมหึมาหรือระบบที่สุดท้ายก็เสียความสอดคล้องกันตั้งแต่ต้น แม้แต่ระบบง่าย ๆ ที่มีการอ่านแค่ 5 ครั้งต่อวินาทีก็ตาม มีความเห็นด้วยว่าผู้ใช้สิบล้านคนจริง ๆ แล้วก็ไม่ได้ถือว่าใหญ่ขนาดนั้น อยากให้คนในวงการตระหนักมากขึ้นว่าระหว่างที่ทั้งอุตสาหกรรมหมกมุ่นกับการขยายแบบแนวนอน ฮาร์ดแวร์จริงกลับเร็วขึ้นและใหญ่ขึ้นกว่าที่คนส่วนใหญ่จินตนาการไว้มาก ทุกวันนี้สามารถเช่าเซิร์ฟเวอร์ RAM 32TB จาก Amazon ได้แล้ว และแม้ในระบบที่สเกลใหญ่ขึ้น การรับประกันแบบ ACID ก็ยังมีคุณค่ามหาศาล

    • ขอบคุณที่จับประเด็นแกนหลักที่พรีเซนเทชันนี้อยากสื่อได้จริง ๆ (Bohan)

    • มีที่ไหนให้ดูสไลด์หรือวิดีโอบันทึกของพรีเซนเทชันนี้ไหม

    • มีความเห็นว่ากระทู้นี้ดูจะให้คะแนนทีมนี้ค่อนข้างแรงเกินไป ผู้ใช้ HN ที่มีประสบการณ์สูงในสายนี้สนใจว่าเซอร์วิสขนาดใหญ่อย่าง ChatGPT ถูกขยายเชิงสถาปัตยกรรมอย่างไร และบริษัทที่มีทรัพยากรแทบไม่จำกัดแบบนี้จ้างคนอย่างไร การที่สารของพรีเซนเทชันคือ "ถ้าใช้ ORM ก็อาจเกิด query ที่ไม่มีประสิทธิภาพได้ง่าย จึงต้องระวัง" ถูกตีความว่าเป็นหลักฐานว่าทีมนี้ยังมีประสบการณ์กับการรันอินฟราขนาดใหญ่ระดับนี้ไม่มากนัก

  • ในแง่ความยืดหยุ่น การ self-hosting postgres น่าสนใจมาก (เช่น การได้สิทธิ์ superuser หรือใช้ฟีเจอร์ขั้นสูง) แต่พอจะต้องดูแลเองจริง ๆ ก็ชวนกังวล หวังว่าผู้ให้บริการคลาวด์จะรองรับฟังก์ชันปิดการใช้งานดัชนีใน query planner แบบมาตรฐานก่อนจะลบดัชนีจริง ๆ และถ้าเป็นบริษัทใหญ่ การเลือก self-hosting เพื่อคัสตอมสแตกก็ดูสมเหตุสมผลมากพอ

    • ใน Postgres มีหลายวิธีอยู่แล้วที่จะบังคับใช้หรือปิดการใช้ดัชนีเฉพาะตัว และยังใช้ได้บนอินสแตนซ์ Postgres แบบ managed ของคลาวด์ด้วย เช่น ปรับค่าของ query planner เป็นราย query (เช่น enable_indexscan=off) หรือใส่เลขคณิตง่าย ๆ ใน where clause เพื่อจงใจไม่ให้ใช้ดัชนี รวมถึงส่วนขยาย pg_hintplan (สามารถใส่ hint ในคอมเมนต์เพื่อระบุว่าจะให้ใช้ดัชนีใด ดูเพิ่ม: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)

    • ขอระบุไว้ก่อนว่าอยู่ทีม Azure Postgres: OpenAI ไม่ได้ self-host แต่ใช้ PostgreSQL แบบ managed ของ Azure (Flexible Server)

    • ผู้บรรยายจาก OpenAI (Bohan) ออกมายืนยันเองว่าไม่ได้ใช้สภาพแวดล้อมแบบ self-host แต่ใช้ Azure Database for PostgreSQL โดยในพรีเซนเทชันมีการพูดว่า "Azure Postgres" หลายครั้ง แต่ขออภัยที่ไม่ได้ทำให้ชัดเจนกว่านี้ว่าเป็นบริการที่ Microsoft จัดการให้

    • มีความเห็นว่าน่าแปลกที่ MySQL หรือ MariaDB มี DDL สำหรับทำให้ดัชนีเป็น INVISIBLE หรือ IGNORED เพื่อให้ query planner มองข้ามได้ แต่ Postgres กลับไม่มีฟีเจอร์คล้ายกัน

    • เป็นเพียงการอ้างประโยคต้นฉบับว่า "ข้อดีของการ self-hosting postgres คือความยืดหยุ่น…"

  • เมื่อมีการขอฟีเจอร์เก็บประวัติเหตุการณ์เปลี่ยนสคีมา (เช่น เพิ่ม/ลบคอลัมน์) ก็มีคำตอบว่าสามารถทำแบบเรียลไทม์ได้อยู่แล้วด้วย EVENT TRIGGER และยกตัวอย่างให้ดูจาก Aquameta(https://github.com/aquametalabs/aquameta)

    • มีคำอธิบายว่าเราก็กำลังทำระบบจัดการประวัติการเปลี่ยนแปลง DDL บนสภาพแวดล้อม Postgres ของเราเองอยู่ Postgres เองทรงพลังมากจึงทำได้หลายแบบ แต่การเก็บประวัติและ log การปฏิบัติการของฐานข้อมูลขนาดใหญ่หรือสำคัญก็เป็นความต้องการที่พบบ่อยมาก หลายคนมักไม่รู้ว่ามันสำคัญแค่ไหนจนกว่าจะเจอกับตัว ไม่ใช่แค่การเปลี่ยน DDL เท่านั้น แต่เมื่อมีการเปลี่ยนนโยบายการดำเนินงานสำคัญ (เช่น การเปลี่ยนโมเดลราคา การคัสตอม SKU/ราคา ฯลฯ) ก็ต้องทำให้ตรวจสอบย้อนหลังได้เสมอ หากออกแบบตาม relational model อย่างเต็มตัว จะพบว่าในแอปจริงมีเพียงบางตารางที่เปลี่ยนบ่อย ส่วนใหญ่เป็นตาราง "static" ที่แทบไม่เปลี่ยนเลย และเมื่อมีการเปลี่ยนตารางเหล่านี้ การเก็บประวัติอย่างละเอียดจะช่วยทั้งการตีความข้อมูลเก่าและการ rollback

    • เรา (Xata) ใช้ทั้ง pgroll(https://github.com/xataio/pgroll) และ pgstream(https://github.com/xataio/pgstream) โดยทั้งคู่ตรวจจับการเปลี่ยน DDL ด้วย EVENT TRIGGER เพื่อเก็บประวัติ schema migration หรือรวมเหตุการณ์เปลี่ยนสคีมาเข้าไปใน logical replication stream ทั้งนี้ DBaaS ที่อิง Postgres ส่วนใหญ่มักจำกัด EVENT TRIGGER บางส่วนเพราะสิทธิ์ superuser แต่ RDS/Aurora และ Xata รองรับแล้ว ส่วน Supabase ก็กำลังเตรียมรองรับ

    • ขอบคุณที่ยังจำ Aquameta ได้ และขอแย้มว่าจะมีฟีเจอร์ใหม่เจ๋ง ๆ ออกมาเร็ว ๆ นี้

  • มีความเห็นว่าเนื้อหาเหล่านี้ (การสร้างดัชนีพร้อมกันในระบบขนาดใหญ่ การหลีกเลี่ยง table rewrite การกระจายทราฟฟิก transaction timeout read replica ฯลฯ) แทบเป็นเรื่องจำเป็นพื้นฐานแม้กับระบบที่เล็กกว่า OpenAI มากก็ตาม สิ่งที่เรียกร้องจาก Postgres ก็เป็นเรื่องที่คนขอมากันมานานแล้ว และแม้จะใช้ชื่อว่า "Next Level" แต่จริง ๆ ดูคล้ายกับการพยายามยื้อสถาปัตยกรรม single master ไว้อย่างสุดกำลังภายใต้ข้อจำกัดของ workload ใหม่มากกว่า ประเด็นสำคัญคือมันรับภาระการอ่านมหาศาลได้อย่างมั่นคง ซึ่งตัวมันเองก็เป็นสูตรมาตรฐานของ read replica และการกระจายแนวนอนอยู่แล้ว วิธีปิดการใช้ดัชนีด้วยการแก้ฟิลด์ภายใน (indisvalid) ก็เป็นเทคนิคที่ไม่ได้รองรับอย่างเป็นทางการ และการไปปรับ system catalog แบบนี้ก็มีความเสี่ยง การบอกให้ดูการใช้งานดัชนีจาก monitoring view แล้วค่อยลบก็ไม่ใช่คำตอบที่สมบูรณ์ เพราะถ้าจะตัดสินให้มั่นใจว่าดัชนีใดจำเป็นหรือไม่จำเป็น ควรต้องดู query plan ด้วย

    • TFA (บทความต้นทาง) บอกว่า OpenAI ประมวลผลได้ 1 ล้าน query ต่อวินาทีบน Azure ซึ่งถือว่าน่าประทับใจมากในสภาพแวดล้อมคลาวด์จริง โดยเฉพาะเมื่อใช้สตอเรจผ่านเครือข่าย แต่ถ้ามองว่าเป็นค่าที่กระจายไปยัง read replica ราว 40 ตัว ก็จะตกประมาณ 25,000 QPS ต่ออินสแตนซ์ จึงอาจไม่ได้เหนือความคาดหมายมากนัก ส่วนประเด็นถกเถียงเรื่องการใช้ดัชนีนั้น หากรู้สถิติล่าสุดและลักษณะของฐานข้อมูลดีพอ ก็พอจะตัดสินได้แล้วว่าควรใช้ดัชนีใด และเพียงตรวจว่าค่าเงื่อนไข/โปรเจกชันของ query สอดคล้องกับ left-most prefix ของดัชนีหรือไม่ก็เพียงพอ

    • มีการชี้ว่าพรีเซนเทชันไม่ได้อธิบายเลยว่าทำไม OpenAI ถึงไม่ทำ PostgreSQL sharding ซึ่งน่าหงุดหงิดอยู่เหมือนกัน เพราะแค่ sharding ตามผู้ใช้ก็น่าจะทำให้หลายปัญหาแก้ง่ายขึ้นมาก จึงสงสัยว่าทำไมยังยึด single master อยู่

  • ดูเหมือนจะใช้ physical replication อยู่ ส่วนตัวกำลังคิดจะเปลี่ยนไปใช้ logical replication เพื่อลดต้นทุน (เช่น ลดทราฟฟิกขาออกข้ามรีเจียน) หลัง PostgreSQL 17 ฟีเจอร์ logical replication แบบ native ดูพัฒนาไปมากแล้ว เลยอยากรู้ว่าถ้าใช้จริงใน production มันคุ้มแค่ไหน

  • มีคนตั้งข้อสังเกตว่าถ้าต้องรองรับ query หลากหลาย ก็น่าจะใช้ storage engine อื่นร่วมด้วย เช่น key-value, search, vector search, cache ฯลฯ แต่ในพรีเซนเทชันกลับโฟกัสที่ Postgres อย่างเดียว ซึ่งดูแปลก จึงคาดว่าน่าจะมีหลายกลยุทธ์ภายในสำหรับการกระจายทราฟฟิกและกระจายโหลดด้วย

  • มีคนสงสัยว่าถ้าจัดให้ write instance รันเองบนเซิร์ฟเวอร์เฉพาะที่ติด local high-speed SSD แล้วให้ฝั่งอ่านไปอยู่บน managed service อย่างเดียว จะได้ประสิทธิภาพดีกว่าหรือไม่

  • มีความเห็นแรง ๆ ว่า "ไป shard DB ซะ" แค่ shard ตามผู้ใช้หรือองค์กรก็น่าจะแก้ปัญหาหลักที่เจออยู่ตอนนี้ได้แบบตรงไปตรงมา การพยายามอ้อมไปหลายชั้นกลับยิ่งเสียเวลาเปล่า

    • ในพรีเซนเทชัน ประเด็นสำคัญคือแม้ไม่ทำ sharding ก็ยังสามารถสเกลไปถึงปริมาณงานมหาศาลได้ด้วยสถาปัตยกรรม single master และแน่นอนว่าก็เคยพิจารณา sharding แล้ว แต่ trade-off ไม่คุ้ม และโครงสร้างปัจจุบันก็ยังสเกลได้อยู่

    • ผู้บรรยายจาก OpenAI (Bohan) ตอบเองว่า workload นี้ไม่ได้เป็นแบบที่ shard ได้ง่าย อีกทั้ง workload ที่เขียนหนักก็ถูกแยกออกจาก PostgreSQL ไปจัดการเป็น shard แล้ว สิ่งที่เหลืออยู่เกือบทั้งหมดเป็นงานอ่านอย่างเดียว ดังนั้นการนำ sharding เข้ามาจะต้องใช้ความพยายามอย่างมาก ปัจจุบันมองว่า Azure Database for PostgreSQL เพียงอย่างเดียวก็ให้ scalability ที่พอและยังมีเผื่อสำหรับอนาคต อย่างไรก็ดี ในระยะยาวก็ไม่ได้ตัด sharding ทิ้งไปเลย เพียงแต่ไม่ใช่ลำดับความสำคัญระยะสั้น

    • มีความเห็นว่า sharding ไม่ได้ง่ายอย่างที่คิด เหตุผลที่เลือกใช้ฐานข้อมูลทรงพลังเพราะต้องการทำการวิเคราะห์และ query ข้อมูลที่ซับซ้อน ถ้าเป้าหมายมีแค่เก็บและกระจายข้อมูลธรรมดา การใช้ NFS mount หลายตัวอาจง่ายกว่าเสียอีก

    • มีความเห็นเชิงจริงจังว่าการบอกให้เอา sharding ไปใช้กับฐานข้อมูลมหึมาระดับ 1 ล้าน query ต่อวินาทีไม่ใช่เรื่องง่าย แม้การใช้องค์กรเป็น shard key จะดูเป็นธรรมชาติก็ตาม แต่เมื่อมาถึงสเกลระดับนี้ก็ไม่มีอะไรเรียบง่ายอีกแล้ว

    • เห็นด้วยกับประเด็นข้างต้นอย่างมาก

  • สำหรับคำพูดในพรีเซนเทชันที่เตือนให้ใช้ ORM อย่างระวัง เจ้าตัวมองว่าปัญหาอยู่ที่ ORM ทุกตัว โดยเฉพาะ ORM ที่พยายามรองรับหลายฐานข้อมูล เพราะมันทำให้คนคิดเรื่องรูปแบบข้อมูลแค่ในระดับโค้ดแอปพลิเคชัน และสุดท้ายก็แทบใช้ความสามารถอันทรงพลังเฉพาะของแต่ละฐานข้อมูลไม่ได้เลย เจ้าตัวไม่ใช้ ORM เลย และใช้ query/ฟีเจอร์เฉพาะของ Postgres อย่างเต็มที่ โดยเชื่อว่าการโฟกัสที่พลังของฐานข้อมูลมากกว่าภาษาโปรแกรมหรือความสะดวกนั้นคุ้มกว่า สุดท้ายแล้วการเขียน SQL ดี ๆ ด้วยตัวเองต่างหากที่ทำให้ทั้งระบบมีความสุข

    • มีประสบการณ์ว่าตอนย้ายจาก DB2 ไป psql ในอดีต ORM ช่วยได้มากในการลด downtime เพราะทำให้การสลับฐานข้อมูลโปร่งใส และแทบไม่ต้องแตะ logic ส่วนใหญ่เลย อีกทั้งไม่ใช่นักพัฒนาทุกคนจะถนัดเขียน query เอง และถ้า query ปะปนอยู่ในโค้ดมาก ๆ การรีแฟกเตอร์และทำความเข้าใจก็จะยากมาก สุดท้าย SQL เองก็คงจะถูก abstract เป็นไลบรารีเช่นกัน

    • ใช้ Django ORM มานานและคิดว่าเป็นซอฟต์แวร์ที่ยอดเยี่ยมมาก แต่พอได้ใช้ sqlc ในช่วงหลัง กลับรู้สึกว่าวิธีที่แปลง query เป็นโค้ด Go โดยตรงนั้นเป็นจุดกึ่งกลางที่เหมาะสมระหว่าง ORM กับ raw SQL

    • มีความเห็นว่าอาจเป็นเพียงเพราะอีกฝ่ายยังไม่เคยเจอ ORM ที่ดีจริง ๆ (เช่น Entity Framework Core)

  • มีคอมเมนต์เบา ๆ ว่าชื่อที่ตรงกับพรีเซนเทชันจริงน่าจะเป็น "Scaling PostgreSQL to the Next Level at OpenAI"
 
ddogi 2025-05-25

ดูเหมือนว่าผลิตภัณฑ์เชิงพาณิชย์อย่าง Oracle RAC หรือ DB2 pureScale ที่รองรับการเขียนแบบหลายจุดจะไม่ได้ถูกนำมาพิจารณาด้วยนะ