LanceDB โหลด OpenAI embeddings จำนวน 100k ได้เร็วกว่า pgvector ถึง 22 เท่า ในขณะที่ pgvector สามารถตอบสนองเวิร์กโหลดเดียวกันจากไคลเอนต์ 8 รายพร้อมกันได้เร็วกว่า 1.8 เท่า ช่องว่างด้านความหน่วงแบบ single-thread และประสิทธิภาพการจัดเก็บข้อมูลยังเอนเอียงไปทาง LanceDB ซึ่งช่วยให้นักพัฒนาสามารถเลือก vector store ได้โดยอิงจากข้อมูลจริง

ทำไมการทำ benchmark ถึงสำคัญในตอนนี้

การค้นหาแบบ vector ได้เปลี่ยนจากห้องวิจัยไปสู่บริการระดับ production เช่น recommendation engines และ retrieval-augmented generation (RAG) ทีมส่วนใหญ่มักใช้งาน PostgreSQL อยู่แล้ว ดังนั้นส่วนขยาย pgvector จึงช่วยให้สามารถทำ similarity search ได้โดยไม่ต้องเพิ่มโครงสร้างพื้นฐานใหม่ อย่างไรก็ตาม vector store เฉพาะทางอย่าง LanceDB อ้างว่ามีความหน่วงต่ำกว่าและมีค่าใช้จ่ายในการจัดเก็บข้อมูลที่ถูกกว่า ทีมต่างๆ จึงต้องเลือกระหว่าง "เพิ่มเข้าไปในสิ่งที่มีอยู่แล้ว" กับ "รันเอนจินที่สร้างขึ้นมาเพื่อวัตถุประสงค์เฉพาะ" ซึ่งเป็นการตัดสินใจที่ส่งผลต่อต้นทุนและประสิทธิภาพเมื่อชุดข้อมูลขยายใหญ่ขึ้นและอัตราการเรียกใช้งานเพิ่มสูงขึ้น

วิธีการตั้งค่าการทดสอบ

ทั้งสองระบบทำ index ของ vector จำนวน 100k ชุดที่เหมือนกัน โดยแต่ละชุดมี 1536 มิติ ซึ่งสร้างโดย embedding model ของ OpenAI เราได้วัดความเร็วในการนำข้อมูลเข้า (ingestion speed), การใช้งานดิสก์, ความหน่วงในการคิวรีแบบ single-thread และ throughput ด้วยไคลเอนต์ 8 รายที่ทำงานพร้อมกัน

ผลลัพธ์การเปรียบเทียบแบบตัวต่อตัว

  • ความเร็วในการนำข้อมูลเข้า (Ingestion speed) – LanceDB ทำได้ดีกว่าถึง 22 เท่า
  • การใช้พื้นที่ดิสก์ (Disk footprint) – LanceDB จัดเก็บ vector โดยใช้พื้นที่เพียงประมาณหนึ่งในสามของที่ pgvector ใช้
  • ความหน่วงแบบ single-thread (Single-thread latency) – การคิวรีบน LanceDB ทำได้เร็วกว่าประมาณสองเท่า
  • การขยายตัวเมื่อทำงานพร้อมกัน (Concurrency scaling) – เมื่อมีไคลเอนต์ทำงานขนานกัน 8 ราย pgvector ให้ throughput สูงกว่า LanceDB ถึง 1.8 เท่า

รากฐานทางสถาปัตยกรรมที่ทำให้เกิดความแตกต่าง

LanceDB เป็น embedded library ที่ทำงานอยู่ภายใน Python process ที่โฮสต์แอปพลิเคชัน การทำงานทั้งหมดจะอยู่ภายใน process เดียวกัน ดังนั้นข้อมูลจึงไม่ต้องข้ามขอบเขตเครือข่าย และการอัปเดต index ก็มี overhead ต่ำมาก การออกแบบนี้โดดเด่นสำหรับเวิร์กโหลดแบบงานเดียว (single-task) แต่จะถึงขีดจำกัดเมื่อมี Python threads หลายตัวแย่งชิง Global Interpreter Lock (GIL) ซึ่งจะขัดขวางการทำงานแบบขนานที่แท้จริงของ Python bytecode

pgvector เป็นส่วนขยายของ PostgreSQL ในฝั่งเซิร์ฟเวอร์ การเชื่อมต่อของไคลเอนต์แต่ละรายจะเริ่มการทำงานของ server process แยกกัน ซึ่งเป็นการหลีกเลี่ยง GIL โดยสิ้นเชิง PostgreSQL planner จะตัดสินใจว่าจะตอบสนองการทำ similarity search อย่างไร และเซิร์ฟเวอร์สามารถสร้างขึ้นมาหลาย process เพื่อรองรับคำขอที่เกิดขึ้นพร้อมกันได้ การแยกส่วนกันเช่นนี้อธิบายได้ว่าทำไมมันจึงขยายตัว (scaling) ได้ดีกว่าเมื่อมีภาระงานหนัก

ความแปลกประหลาดของการกรองข้อมูลและการวางแผนคิวรี

RAG pipeline ในโลกความเป็นจริงมักจะรวมความคล้ายคลึงของ vector เข้ากับการกรองข้อมูลแบบดั้งเดิม (เช่น WHERE user_id = 42) LanceDB ใช้ prefilter ที่ทำงานได้อย่างคาดเดาได้ในการรันแต่ละครั้ง ส่วน pgvector จะพึ่งพา query planner ของ PostgreSQL ซึ่งอาจเลือกใช้การทำ index scan ที่รวดเร็ว หรือถอยกลับไปใช้การทำ exact scan ที่ช้ากว่า ทั้งนี้ขึ้นอยู่กับสถิติ (statistics) การรัน ANALYZE หลังจากโหลดข้อมูลจำนวนมากเข้าสู่ตาราง pgvector จะช่วยรีเฟรชสถิติเหล่านั้น หากไม่ทำเช่นนั้น ค่า recall อาจลดลงจนเกือบเป็นศูนย์ ซึ่งจะทำให้การค้นหาล้มเหลวโดยสิ้นเชิง

เมื่อไหร่ที่ควรเลือกแต่ละตัวเลือก

เลือก pgvector หาก

  • stack ของคุณมี PostgreSQL อยู่แล้วและคุณต้องการหลีกเลี่ยงการเพิ่มบริการอื่น
  • คุณคาดว่าจะมีผู้ใช้งานหรือการเรียก API พร้อมกันจำนวนมาก
  • การรับประกัน ACID และเครื่องมือ DBA ที่คุ้นเคยเป็นสิ่งสำคัญ

เลือก LanceDB หาก

  • เวิร์กโฟลว์ของคุณเป็น ML pipeline ที่มีการนำเข้า embeddings ใหม่ๆ อยู่บ่อยครั้ง
  • คุณต้องการเส้นทางการเขียนข้อมูลที่เร็วที่สุดและความหน่วงต่ำสำหรับ agent ที่รับคำขอเดี่ยว (เช่น chat bots)
  • กังวลเรื่องต้นทุนดิสก์และสามารถยอมรับขีดจำกัดของประสิทธิภาพแบบ single-thread ได้

สรุป: หากความเร็วในการนำข้อมูลเข้าดิบๆ การใช้พื้นที่จัดเก็บขั้นต่ำ และความหน่วงต่อหนึ่งคำขอเป็นสิ่งที่สำคัญที่สุด LanceDB คือผู้ชนะ แต่หากคุณต้องให้บริการผู้ใช้จำนวนมากพร้อมกันและพึ่งพาการติดตั้ง PostgreSQL ที่มีอยู่แล้ว ความได้เปรียบด้าน concurrency ของ pgvector จะทำให้มันเป็นตัวเลือกที่ปลอดภัยกว่า จงใช้ตัวเลขจาก benchmark นี้เพื่อเลือก vector store ให้สอดคล้องกับตัวชี้วัดที่สำคัญที่สุดของผลิตภัณฑ์คุณ