Databricks นำการค้นหาแบบเต็มข้อความและเวกเตอร์ไปยัง Lakebase Postgres

Databricks เมื่อวันที่ 28 กันยายน 2026, เปิดตัว Lakebase Search, เป็นเครื่องมือค้นหาในตัวสำหรับฐานข้อมูล Lakebase Postgres ของบริษัทที่จัดส่งผ่านส่วนขยายสองตัว: lakebaseเวกเตอร์สำหรับการค้นหาเพื่อนใกล้ที่สุดโดยประมาณและ lakebasetext สำหรับการค้นหาแบบเต็มข้อความ BM25. ทั้งสองส่วนขยายพร้อมให้บริการทั่วไปบน AWS และ Azure.

ส่วนขยายเหล่านี้ทำให้ผู้พัฒนาสามารถเรียกใช้การค้นหาแบบเชิงความหมาย, คำสำคัญ, และแบบผสมโดยตรงภายใน Postgres ควบคู่กับข้อมูลการดำเนินงาน. Databricks กล่าวว่า ระบบ OLTP แบบดั้งเดิมไม่ได้ถูกออกแบบมาสำหรับความต้องการการค้นหาของเอเจนต์ AI ซึ่งต้องการการดึงข้อมูลที่มีความหน่วงต่ำและความแม่นยำสูงและมักทำการค้นหาแบบขนานจำนวนมาก, และการแก้ปัญหานี้จนถึงตอนนี้หมายถึงการต่อเครื่องมือค้นหาแบบสแตนด์อโลนเข้ากับฐานข้อมูลหลักผ่านกระบวนการ ETL. บริษัทกล่าวว่าพวกเขาได้สร้าง Lakebase Search ควบคู่กับข้อเสนอแนะจากลูกค้าเบตาจำนวนหลายร้อยราย.

ผลการทดสอบและการปรับใช้ Conexiom

Databricks กล่าวว่า lakebase_เวกเตอร์ ให้ปริมาณการทำงานสองเท่าของระบบที่ดีที่สุดต่อไปบนการทดสอบ VectorDBBench 100M ซึ่งใช้ชุดข้อมูล LAION, และว่ามันมีต้นทุนสี่เท่าถูกกว่าผู้ให้บริการ Postgres บนคลาวด์ที่ใช้ pgvector, ก่อนการประหยัดเพิ่มเติมจากการปรับขนาดอัตโนมัติ. บริษัทรายงานค่าแฝง P99 ที่ 71 มิลลิวินาทีที่ 97% recall, หมายความว่าเครื่องมือสามารถดึงข้อมูลเพื่อนใกล้ที่สุดที่แท้จริงได้ 97% ของเวลา, และระบุว่า pgvector และ DiskANN ถูกทดสอบเฉพาะบนอินสแตนซ์ขนาดใหญ่เดียว.

Databricks ยังรายงานผลลัพธ์จากลูกค้า Conexiom, ซึ่งดำเนินการค้นหาแบบผสม BM25 บนแถวมากกว่า 100 ล้านแถวโดยใช้ทรัพยากรคอมพิวเตอร์เพียงครึ่งหนึ่งของการตั้งค่า pgvector ก่อนหน้า. ค่าใช้จ่ายโครงสร้างพื้นฐานของ Conexiom ลดลงสามเท่าและอัตราการทำงานเพิ่มขึ้นห้าเท่าเมื่อเทียบกับ pgvector, บริษัทกล่าว.

“Lakebase Search ให้ระดับความสามารถในการขยายที่ใหม่ทั้งหมดเหนือ pgvector, และเปิดใช้งาน BM25 ในฐานข้อมูลแบบไม่มีเซิร์ฟเวอร์เดียวกัน,” กล่าวโดย Jordan Voves, สถาปนิก AI/ML ที่ Conexiom. “เราจึงใช้ Lakebase เพื่อเชื่อมต่อข้อมูลกับเอเจนต์ของเราในระดับใหญ่.”

ข้อจำกัดของ Pgvector ที่อยู่เบื้องหลังการออกแบบ

Databricks กล่าวว่า pgvector เป็นส่วนขยายที่ติดตั้งมากที่สุดใน Lakebase Postgres, และได้อธิบายจุดเจ็บปวดสามประการที่เกิดซ้ำจากลูกค้าที่ใช้งานในระดับใหญ่.

ข้อแรกคือค่าใช้จ่ายที่เพิ่มตามปริมาณข้อมูลมากกว่าการใช้งาน. pgvector เก็บดัชนี HNSW ไว้ในหน่วยความจำของฐานข้อมูล, และเนื่องจากการค้นหา HNSW พึ่งพาการเดินกราฟแบบเข้าถึงสุ่ม, ประสิทธิภาพจะลดลงโดยอัตรา 10 ถึง 50 เท่าเมื่อดัชนีล้นไปยังดิสก์และคำค้นกลายเป็นโซ่ของการอ่านแบบสุ่ม. เวกเตอร์ float32 ขนาด 768 มิติใช้หน่วยความจำประมาณ 3.3 กิโลไบต์เมื่อรวมลิงก์กราฟและค่าโอเวอร์เฮดของ Postgres, ดังนั้นดัชนีที่มี 100 ล้านแถวต้องใช้ RAM ประมาณ 330 กิกะไบต์เพื่อคงอยู่ในหน่วยความจำ, จัดสรรเต็มแม้ว่าคำค้นจะเข้าถึงหรือไม่ก็ตาม.

ข้อที่สองคือการบำรุงรักษาดัชนี. เมื่อการสร้างดัชนีล้นไปยังดิสก์, ดัชนี pgvector ใช้เวลาประมาณ 50 ชั่วโมงในการสร้างบนอินสแตนซ์คลาวด์มาตรฐาน, Databricks กล่าว, และการเขียนข้อมูลก็ประสบกับคอขวดเดียวกันเนื่องจากการแทรกเวกเตอร์ต้องการการเดินกราฟแบบเข้าถึงสุ่มและการแก้ไขหลายชั้นของกราฟ. เนื่องจาก HNSW ไม่มีการปรับสมดุลแบบทั่วโลก, การฟื้นฟูคุณภาพการค้นหาต้องรัน REINDEX ทั้งหมด, ซึ่งเป็นการดำเนินการที่ล็อกตารางและหยุดการเขียนในสภาพการผลิต.

ข้อที่สามคือคำค้นเดียวไม่สามารถทำแบบขนานได้. คำค้น pgvector จะดำเนินการโดยกระบวนการแบ็กเอนด์ของ Postgres เพียงหนึ่งตัว, ทำให้การสแกนดัชนี HNSW ไม่มีการทำขนาน. การเพิ่ม recall ต้องเยี่ยมชมโหนดกราฟมากขึ้น, ซึ่งเพิ่มการอ่านหน่วยความจำแบบสุ่มและการเปรียบเทียบระยะทาง, ทำให้ความหน่วงเพิ่มขึ้นและจำนวนคำค้นต่อวินาทีลดลง, ดังนั้นการขยายอัตราการทำงานหมายถึงการเพิ่มการเชื่อมต่อฐานข้อมูลหรือการทำสำเนาอ่าน.

วิธีการสร้าง Lakebase_vector

Lakebase Postgres แยกการจัดเก็บข้อมูลออกจากการประมวลผล: ข้อมูลถาวรอยู่ในที่เก็บวัตถุบนคลาวด์ที่ต้นทุนต่ำ, ในขณะที่ RAM และ NVMe ท้องถิ่นทำหน้าที่เป็นแคชระยะสั้นที่เก็บชุดข้อมูลทำงานที่ใช้งานอยู่. บนพื้นฐานนั้น, Databricks ผสานเทคนิคสองอย่างเข้าด้วยกัน.

การจัดกลุ่ม IVF แบบลำดับชั้นจัดเวกเตอร์เป็นกลุ่มที่เก็บเป็นบล็อกต่อเนื่อง. คำค้นให้คะแนนศูนย์กลางของกลุ่มในหน่วยความจำ, จากนั้นอ่านเพียงไม่กี่บล็อกที่ดูมีแนวโน้มเป็นการอ่านต่อเนื่องขนาดใหญ่แทนการกระโดดแบบสุ่มหลายครั้ง. การควอนไทเซชันแบบไบนารีโดยใช้วิธี RaBitQ บีบอัดแต่ละเวกเตอร์ให้เหลือประมาณหนึ่งบิตต่อมิติ, ซึ่งเล็กกว่าฟลต32 ประมาณ 32 เท่า, ดังนั้นคำค้นจะสแกนโค้ดแบบกะทัดรัดเพื่อคัดเลือกผู้สมัครและจัดอันดับใหม่เฉพาะรายการคัดเลือกนั้นเทียบกับเวกเตอร์ความแม่นยำเต็ม.

เนื่องจากการออกแบบไม่มีสถานะ, มันสามารถขยายเป็นศูนย์ได้, และเมื่อไม่ได้ใช้งานผู้ใช้จ่ายเฉพาะค่าการจัดเก็บเท่านั้น. Databricks รายงานค่า P90 ที่วัดได้ 1.13 วินาทีสำหรับคำค้นแรกหลังจากการขยายเป็นศูนย์บนชุดข้อมูล 100 ล้านเวกเตอร์, 768 มิติ, และกล่าวว่าเวกเตอร์ 100 ล้านรายการสามารถให้บริการบน Lakebase Compute Unit หนึ่งหน่วย.

การสร้างดัชนีฝึกศูนย์กลางกลุ่มเพียงครั้งเดียวบนตัวอย่างสุ่มขนาดเล็ก; จากนั้นแต่ละเวกเตอร์จะถูกกำหนดให้กับศูนย์กลางที่ใกล้ที่สุด, ทำการควอนตาไซซ์, และเขียนลงบล็อกที่เหมาะสมเป็นการดำเนินการอิสระ, ทำให้งานกระจายไปตามจำนวนคอร์ที่มีอยู่. Databricks กล่าวว่าสถาปัตยกรรม LTAP ของมันย้ายการสร้างดัชนีออกจากฐานข้อมูลหลักไปยังเอนจินกระจายเช่น Spark, ลดระยะเวลาการสร้างลงเหลือระดับนาที, และบอกว่าจะมีการเพิ่มความสามารถนี้ต่อไป. เนื่องจากเงื่อนไขจะถูกประยุกต์ใช้ระหว่างการสแกนบล็อกเอง, คำค้นที่กรองจะหลีกเลี่ยงการดึงข้อมูลผู้สมัครเกินความจำเป็นและรักษาค่าการเรียกคืนให้สูง, และคำค้นเดียวจะทำงานแบบขนานบนคอร์ของ CPU.

การค้นหาข้อความ BM25 และการค้นหาแบบไฮบริด

Databricks กล่าวว่า การค้นหา tsvector ของ Postgres มาตรฐานไม่มีบริบทความเกี่ยวข้องทั่วทั้งคอร์ปัส. lakebase_text ให้คะแนนคำโดยใช้ความถี่เอกสารผกผันระดับโลก, ให้ความสำคัญมากขึ้นกับคำที่หายากและมีเจตนาสูงและน้อยลงกับคำเติมเต็มทั่วไป. ระบบยังตรวจสอบขอบบนของคะแนนขณะเดินทางผ่านดัชนี, กำจัดบล็อกโพสติ้งทั้งหมดที่ไม่สามารถมีผลต่อผลลัพธ์ top‑K, ซึ่งบริษัทอ้างว่าทำให้เร็วกว่า tsvector พร้อมดัชนี GIN.

การรวมส่วนขยายทั้งสองทำให้สามารถค้นหาแบบไฮบริดแบบเนทีฟภายใน Postgres: คำค้นเดียวสามารถใช้เงื่อนไขกรอง SQL ธรรมดา, เข้าร่วมตารางปฏิบัติการแบบเรียลไทม์, และผสานคะแนนเวกเตอร์เชิงความหมายกับความเกี่ยวข้องของคีย์เวิร์ด BM25. Databricks กล่าวว่า ระบบสามารถขยายจากหนึ่งแถวถึงหนึ่งพันล้านเวกเตอร์และจากหนึ่งคำค้นต่อวินาทีถึงหลายพันคำค้นโดยไม่ต้องปรับสเกลด้วยตนเอง, โดยอธิบายการออกแบบว่าออกแบบมาสำหรับเอเจนต์ AI ที่เวิร์กโฟลว์สามารถกระตุ้นคำขอการดึงข้อมูลพร้อมกันหลายพันรายการภายในไม่กี่วินาที.

Databricks วางตำแหน่ง Lakebase Search สำหรับผู้ใช้ที่ต้องการรวมข้อมูลการปฏิบัติการและการค้นหาไว้ในฐานข้อมูลเดียว, ในขณะที่ Databricks AI Search ยังคงเป็นเอนจินจัดการสำหรับการดึงข้อมูลที่พร้อมใช้งานทันที. Lakebase Search มีให้ใช้งานทั่วไปบน AWS และ Azure; ผู้ใช้ Lakebase ที่มีอยู่สามารถเปิดใช้งานส่วนขยายเหล่านี้, และผู้ใช้ใหม่สามารถลงทะเบียนใช้ Lakebase ได้.