การเปลี่ยนแปลงแคชคอมพิวต์ของ Lakebase Postgres ที่ Databricks ประกาศคืออะไร

Databricks ระบุว่า บริษัทเพิ่ม shared buffers ของ Postgres เป็น 75% ของ DRAM ที่มีอยู่บนโหนดประมวลผลขนาดใหญ่แบบขนาดคงที่ (CU 80 ขึ้นไป) แทนการตั้งค่าที่จำกัด shared buffers ไว้ราว 1 GB และอาศัยแคชไฟล์ภายในเครื่องเป็นชั้นรอง

Databricks รายงานว่ามีการปรับปรุงประสิทธิภาพอย่างไรบ้าง

Databricks ยกตัวอย่างจากระบบใช้งานจริงว่าอัตราการประมวลผลเพิ่มขึ้นราว 1.3–2 เท่า การอ่านจากชั้นจัดเก็บในปลายทางหนึ่งลดลงมากถึงห้าเท่า และการใช้ CPU ในอีกปลายทางหนึ่งลดลงจาก 20 คอร์เหลือ 4 คอร์

Databricks จัดการกับภาระที่เพิ่มขึ้นจากบัฟเฟอร์ที่ใช้ร่วมกันขนาดใหญ่อย่างไร

บริษัทระบุว่าได้เพิ่มการรองรับหน่วยความจำแบบ huge page ขนาด 2 MB โดยเฉพาะทั่วโครงสร้างพื้นฐานเครื่องเสมือน ซึ่งในการทดสอบเบนช์มาร์กช่วยลดเวลาแฝงของการอ่านช่วงหางได้สูงสุดราว 40% และลดการใช้ CPU ได้สูงสุดราว 30%

การเปลี่ยนแปลงนี้มีผลกับ Lakebase Postgres compute ทุกตัวหรือไม่

Databricks ระบุว่า การตั้งค่า shared buffers ขนาดใหญ่กำลังเปิดใช้งานอยู่เฉพาะกับระบบประมวลผลแบบขนาดคงที่ที่มี CU ตั้งแต่ 80 ขึ้นไป และโพสต์ที่สองซึ่งวางแผนไว้จะกล่าวถึงระบบประมวลผลแบบปรับขนาดอัตโนมัติ

เครื่องมือและผลิตภัณฑ์

Databricks เปิดเผยรายละเอียดการปรับปรุงแคชสำหรับการประมวลผล Lakebase Postgres

Databricks ระบุว่า การเพิ่มขนาด shared buffers ของ Postgres และการรองรับหน่วยความจำแบบ huge page บนโหนดประมวลผล Lakebase ขนาดใหญ่ ช่วยลดเวลาแฝงและการใช้ CPU โดยการทดสอบในระบบใช้งานจริงพบว่าอัตราการประมวลผลเพิ่มขึ้นได้สูงสุด 2 เท่า

โดย DigitalNeuron Desk11 ก.ย. 2569อ่าน 1 นาที

คำตอบโดยย่อ

Databricks ประกาศอะไรเกี่ยวกับการปรับปรุงแคชการประมวลผล (compute cache) ของ Lakebase Postgres?

Databricks ระบุว่า บริษัทเพิ่มขนาด shared buffers ของ Postgres เป็น 75% ของ DRAM บนโหนดประมวลผล Lakebase ขนาดใหญ่แบบขนาดคงที่ (CU 80 ขึ้นไป) และเพิ่มการรองรับหน่วยความจำแบบ huge page โดยเฉพาะ แทนการใช้แคชไฟล์ภายในเครื่องซึ่งจำกัด shared buffers ไว้ที่ราว 1 GB บริษัทระบุว่าอัตราการประมวลผลในระบบใช้งานจริงเพิ่มขึ้นสูงสุด 2 เท่า การอ่านจากชั้นจัดเก็บลดลง และการใช้ CPU กับเวลาแฝงลดลง

ประเด็นสำคัญ

Databricks ระบุว่า บริษัทเพิ่ม shared buffers ของ Postgres บนโหนดประมวลผล Lakebase ขนาดใหญ่แบบขนาดคงที่ (CU 80 ขึ้นไป) เป็น 75% ของ DRAM ที่มีอยู่ จากเดิมที่จำกัดไว้ราว 1 GB และปิดใช้แคชไฟล์ภายในเครื่องบนโหนดเหล่านี้
บริษัทระบุว่าได้เริ่มรองรับหน่วยความจำแบบ huge page ขนาด 2 MB โดยเฉพาะทั่วทั้งโครงสร้างพื้นฐานเครื่องเสมือนของตน เพื่อลดภาระในการแปลงที่อยู่หน่วยความจำ (memory translation) ที่เกิดจากบัฟเฟอร์ที่ใช้ร่วมกันขนาดใหญ่ขึ้น
Databricks รายงานว่า การทดสอบเบนช์มาร์กพบว่า huge pages ลดเวลาแฝงของการอ่านช่วงหางได้สูงสุดราว 40% และลดการใช้ CPU ได้สูงสุดราว 30%
ในตัวอย่างการใช้งานจริงที่ Databricks ยกมา เอนด์พอยต์หนึ่งพบว่าปริมาณการรับส่งข้อมูลของบล็อกที่ถูกเรียกใช้เพิ่มขึ้นเกือบสองเท่า ขณะที่การอ่านข้อมูลในชั้นจัดเก็บลดลงราวห้าเท่า ส่วนอีกเอนด์พอยต์หนึ่งพบว่าการใช้งาน CPU ลดลงจาก 20 คอร์ เหลือเพียง 4 คอร์
Databricks ระบุว่า การทยอยเปิดใช้งานเริ่มขึ้นเป็นรายภูมิภาคไม่กี่สัปดาห์ก่อนโพสต์วันที่ 10 กันยายน 2026 และโพสต์ที่สองซึ่งวางแผนไว้จะกล่าวถึงการทำงานเกี่ยวกับ shared buffers แบบปรับขนาดอัตโนมัติ

สิ่งที่ Databricks ประกาศ

Databricks เผยแพร่บทความบล็อกเมื่อวันที่ 10 กันยายน 2026 อธิบายถึงการเปลี่ยนแปลงวิธีที่บริการ Lakebase Postgres ของบริษัทแคชข้อมูลบนโหนดประมวลผล บทความนี้ระบุว่าเป็นตอนแรกของซีรีส์ เขียนโดย David Wein, Sunil Kamath และ Haoyu Huang Databricks ระบุว่าเป้าหมายคือการใช้ DRAM ที่มีอยู่บนหน่วยประมวลผลของ Lakebase ให้มีประสิทธิภาพมากขึ้น ด้วยการเก็บข้อมูลไว้ในชั้นหน่วยความจำที่เร็วที่สุดของ Postgres ให้ได้มากที่สุด

ความเป็นมาของระบบแคช

Databricks ระบุว่า Lakebase Postgres ใช้โมเดลสตอเรจแบบแยกส่วน (disaggregated storage) โดยมีการแคชเกิดขึ้นทั้งในระบบจัดเก็บข้อมูลแบบกระจายและบนโหนดประมวลผลเอง ในการติดตั้ง Postgres แบบมาตรฐาน ฐานข้อมูลจะแคชข้อมูลไว้ในพื้นที่หน่วยความจำที่เรียกว่า shared buffers ขณะที่ระบบปฏิบัติการก็แคชหน้าข้อมูลเดียวกันแยกต่างหากใน page cache ของตัวเอง ซึ่ง Databricks ระบุว่าการตั้งค่าเช่นนี้ก่อให้เกิดการบัฟเฟอร์ซ้ำซ้อน (double buffering) จนข้อมูลที่แคชไว้ 1 GB อาจใช้ RAM ไปถึง 2 GB นอกจากนี้ Databricks ยังชี้ว่าโดยปกติ shared buffers ของ Postgres เป็นค่าคงที่ที่ต้องรีสตาร์ทฐานข้อมูลจึงจะเปลี่ยนแปลงได้ ซึ่งบริษัทระบุว่าเป็นความท้าทายสำหรับระบบแบบ serverless ที่ปรับขนาดอัตโนมัติ

เพื่อแก้ปัญหานี้ Databricks ระบุว่าได้สร้างแคชไฟล์ในเครื่อง หรือ LFC (local file cache) ซึ่งทำงานอยู่บนหน่วยประมวลผลของ Lakebase ทุกตัวมาตั้งแต่เปิดตัว LFC อยู่บนสตอเรจ NVMe ในเครื่องของโหนดประมวลผล ทำหน้าที่เป็นชั้นสำรองรองจาก shared buffers ซึ่ง Databricks ได้ปรับแต่งไว้อย่างระมัดระวัง โดยจำกัดไว้ที่ประมาณ 1 GB ไม่ว่าหน่วยประมวลผลนั้นจะมีหน่วยความจำรวมเท่าใดก็ตาม

Shared Buffers ที่ใหญ่ขึ้นและ Huge Pages

Databricks ระบุว่าขณะนี้ได้ยกเลิกเพดานประมาณ 1 GB ดังกล่าวสำหรับหน่วยประมวลผลขนาดใหญ่แบบคงที่แล้ว สำหรับหน่วยประมวลผลที่มีค่า CU ตั้งแต่ 80 ขึ้นไป บริษัทระบุว่าจะปิดการทำงานของ LFC และตั้งค่า shared buffers ของ Postgres ไว้ที่ 75% ของ DRAM ที่มีอยู่ เพื่อเก็บหน้าข้อมูลที่ถูกเข้าถึงบ่อยไว้ในชั้นหน่วยความจำที่เร็วที่สุด แทนที่จะปล่อยให้ตกไปยังแคชในเครื่องที่ช้ากว่า Databricks ระบุว่าลูกค้าสามารถตรวจสอบการตั้งค่านี้ได้ด้วยคำสั่ง "show shared_buffers" ในการเชื่อมต่อ Postgres โดยเอนด์พอยต์ขนาด 80 CU ควรได้ค่ากลับมาเป็น 20971520

เนื่องจาก shared buffers ที่ใหญ่ขึ้นจะเพิ่มภาระในการแปลงที่อยู่หน่วยความจำ (memory-translation overhead) ภายใต้สถาปัตยกรรมแบบหนึ่งโพรเซสต่อหนึ่งการเชื่อมต่อของ Postgres Databricks ระบุว่าจึงได้นำระบบรองรับหน่วยความจำแบบ huge page ขนาด 2 MB โดยเฉพาะมาใช้ทั่วทั้งโครงสร้างพื้นฐานเครื่องเสมือนของบริษัท โดยเลือกใช้ HugeTLB pages แบบระบุชัดเจน แทนที่จะพึ่งพา transparent huge pages ซึ่งทำงานแบบพยายามที่สุดเท่าที่จะทำได้ บริษัทระบุว่าการดำเนินการนี้ต้องอาศัยการรองรับที่สอดคล้องกันตลอดทั้งสาย ตั้งแต่ระดับโฮสต์ ผ่านไฮเปอร์ไวเซอร์ ไปจนถึงเคอร์เนลของเกสต์ ลูกค้าสามารถตรวจสอบการตั้งค่านี้ได้ด้วยคำสั่ง "show huge_pages" ซึ่ง Databricks ระบุว่าควรได้ค่ากลับมาเป็น "on" สำหรับเอนด์พอยต์ขนาด 80 CU

ผลลัพธ์ที่รายงาน

Databricks ระบุว่าผลการทดสอบเบนช์มาร์กพบว่า huge pages ช่วยลด tail read latency ได้สูงสุดประมาณ 40% และลดการใช้งาน CPU ได้สูงสุดประมาณ 30% บริษัทระบุว่าเริ่มทยอยเปิดใช้งานทีละภูมิภาคตั้งแต่ไม่กี่สัปดาห์ก่อนการเผยแพร่บทความนี้ และยกตัวอย่างจากการใช้งานจริง 3 กรณีที่วัดผลหลังการรีสตาร์ทหน่วยประมวลผล ในเอนด์พอยต์ขนาดใหญ่รายหนึ่ง Databricks ระบุว่าจำนวนบล็อก Postgres ที่ถูกเข้าถึงต่อวินาทีเพิ่มขึ้นเป็นสองเท่า และการอ่านข้อมูลจากชั้นสตอเรจลดลงจากประมาณ 8,000 ครั้งต่อวินาที เหลือประมาณ 1,500 ครั้ง ขณะที่ลูกค้ารายงานว่าค่า latency ทั้ง p50 และ p99 ต่ำกว่าของวันก่อนหน้า สัปดาห์ก่อนหน้า และเดือนก่อนหน้า ในเอนด์พอยต์ที่สอง Databricks ระบุว่าปริมาณงานเพิ่มขึ้นประมาณ 43% และอัตราการฮิตแคชของหน่วยประมวลผลเข้าใกล้ 100% ส่วนในเอนด์พอยต์ที่สาม Databricks ระบุว่าการใช้งาน CPU ลดลงจาก 20 คอร์เหลือ 4 คอร์หลังการเปลี่ยนแปลง พร้อมกับปริมาณงานที่เพิ่มขึ้นเป็นสองเท่า

Databricks ระบุว่าการเปลี่ยนแปลงในปัจจุบันใช้ได้กับหน่วยประมวลผลขนาดคงที่เท่านั้น เนื่องจาก shared buffers ยังไม่สามารถปรับขนาดแบบไดนามิกได้ และบทความตอนที่สองที่วางแผนไว้ในซีรีส์นี้จะกล่าวถึงการทำงานของบริษัทเกี่ยวกับการปรับขนาด shared buffers แบบอัตโนมัติ

ที่มา: Databricks Blog, "Improving Lakebase Postgres compute cache," เผยแพร่เมื่อวันที่ 10 กันยายน 2026

คำถามที่พบบ่อย

การเปลี่ยนแปลงแคชคอมพิวต์ของ Lakebase Postgres ที่ Databricks ประกาศคืออะไร: Databricks ระบุว่า บริษัทเพิ่ม shared buffers ของ Postgres เป็น 75% ของ DRAM ที่มีอยู่บนโหนดประมวลผลขนาดใหญ่แบบขนาดคงที่ (CU 80 ขึ้นไป) แทนการตั้งค่าที่จำกัด shared buffers ไว้ราว 1 GB และอาศัยแคชไฟล์ภายในเครื่องเป็นชั้นรอง
Databricks รายงานว่ามีการปรับปรุงประสิทธิภาพอย่างไรบ้าง: Databricks ยกตัวอย่างจากระบบใช้งานจริงว่าอัตราการประมวลผลเพิ่มขึ้นราว 1.3–2 เท่า การอ่านจากชั้นจัดเก็บในปลายทางหนึ่งลดลงมากถึงห้าเท่า และการใช้ CPU ในอีกปลายทางหนึ่งลดลงจาก 20 คอร์เหลือ 4 คอร์
Databricks จัดการกับภาระที่เพิ่มขึ้นจากบัฟเฟอร์ที่ใช้ร่วมกันขนาดใหญ่อย่างไร: บริษัทระบุว่าได้เพิ่มการรองรับหน่วยความจำแบบ huge page ขนาด 2 MB โดยเฉพาะทั่วโครงสร้างพื้นฐานเครื่องเสมือน ซึ่งในการทดสอบเบนช์มาร์กช่วยลดเวลาแฝงของการอ่านช่วงหางได้สูงสุดราว 40% และลดการใช้ CPU ได้สูงสุดราว 30%
การเปลี่ยนแปลงนี้มีผลกับ Lakebase Postgres compute ทุกตัวหรือไม่: Databricks ระบุว่า การตั้งค่า shared buffers ขนาดใหญ่กำลังเปิดใช้งานอยู่เฉพาะกับระบบประมวลผลแบบขนาดคงที่ที่มี CU ตั้งแต่ 80 ขึ้นไป และโพสต์ที่สองซึ่งวางแผนไว้จะกล่าวถึงระบบประมวลผลแบบปรับขนาดอัตโนมัติ

แหล่งข้อมูล

Improving Lakebase Postgres compute cache | Databricks Blog — Databricks

แท็กdatabrickslakebasepostgresdatabase-performancecachingengineering