Laravel Vector Search รองรับ MariaDB แล้ว

Laravel 13 ช่วยให้นักพัฒนาสามารถรันคิวรีการค้นหาแบบเวกเตอร์ (vector-search) บน MariaDB ได้โดยตรง ซึ่งเป็นการเพิ่มความสามารถในการค้นหาเชิงความหมาย (semantic-search) ให้กับระบบนิเวศของ Laravel โดยไม่จำเป็นต้องเปลี่ยนไปใช้ PostgreSQL

การรองรับใหม่นี้จะเข้ามาแทนที่การทำงานแบบเดิมที่รองรับเฉพาะ PostgreSQL เท่านั้น ดังนั้นเมธอด whereVectorSimilarTo ที่คุ้นเคยจึงสามารถทำงานร่วมกับการเชื่อมต่อ MariaDB ได้โดยตรง หากคุณกำลังสร้างระบบแนะนำ (recommendation engines), เครื่องมือหาความคล้ายคลึงของเอกสาร (document-similarity tools) หรือฟีเจอร์ใดๆ ที่ต้องพึ่งพาตรรกะแบบ “nearest-neighbor” การเปลี่ยนแปลงนี้จะช่วยลดอุปสรรคสำคัญในการทำงานลงได้

ทำไมการเปลี่ยนแปลงนี้ถึงสำคัญ

ก่อนหน้านี้ Query Builder ของ Laravel จะตรวจหาความต้องการในการค้นหาแบบเวกเตอร์ด้วยการทดสอบ instanceof ซึ่งจะรับรู้เฉพาะการเชื่อมต่อแบบ PostgreSQL เท่านั้น แนวทางดังกล่าวทำให้ฟีเจอร์นี้ผูกติดอยู่กับไดรเวอร์เพียงตัวเดียว และทำให้โค้ดเต็มไปด้วยเงื่อนไข (conditionals) ที่เจาะจงเฉพาะฐานข้อมูล

ในเวอร์ชัน 13 นี้ ได้มีการย้ายตรรกะดังกล่าวไปยังเลเยอร์ของ grammar และเพิ่มเมธอดเฉพาะสำหรับไดรเวอร์อีกสองเมธอด:

  • supportsVectorDistance() – บอก Laravel ว่าการเชื่อมต่อปัจจุบันสามารถคำนวณระยะห่างของเวกเตอร์ (vector distances) ได้หรือไม่
  • compileVectorDistanceExpression() – สร้าง SQL fragment ที่ใช้ในการคำนวณ

การมอบหมายความรับผิดชอบเหล่านี้ให้แก่ไดรเวอร์แต่ละตัว ทำให้เฟรมเวิร์กสามารถยกเลิกการใช้เทคนิค "type-checking" แบบเดิม และเปิดทางสำหรับการขยายความสามารถในอนาคต การเพิ่มการรองรับฐานข้อมูลอื่นในตอนนี้จึงหมายถึงการเขียนเมธอดสำหรับไดรเวอร์เพียงไม่กี่เมธอด แทนที่จะต้องกระจายบล็อกเงื่อนไขไปทั่วโค้ด

MariaDB มีฟังก์ชันพื้นฐาน (native functions) แต่ MySQL ไม่มี

MariaDB มาพร้อมกับฟังก์ชันเวกเตอร์แบบ native ในขณะที่ MySQL มาตรฐานจะไม่มีฟังก์ชันเหล่านี้ เว้นแต่คุณจะใช้บริการคลาวด์เฉพาะทางที่มีการเพิ่ม AI extensions เข้ามา

Laravel จงใจหลีกเลี่ยงการคำนวณความคล้ายคลึงในฝั่ง PHP เนื่องจากการคำนวณเวกเตอร์ใน PHP จะทำให้การแบ่งหน้า (pagination) ผิดพลาดและทำให้แอปพลิเคชันช้าลงโดยไม่มีการแจ้งเตือนล่วงหน้า การแจ้งข้อผิดพลาด (error) เมื่อไดรเวอร์ไม่สามารถจัดการการทำงานได้ จึงเป็นวิธีการรับมือกับความล้มเหลว (failure mode) ที่ปลอดภัยกว่า

สิ่งที่ผู้ใช้ MySQL สามารถทำได้ในตอนนี้

หาก Stack ของคุณใช้ MySQL แบบปกติ คุณมี 3 ทางเลือกที่เป็นไปได้:

  1. ย้ายไปใช้ MariaDB – เป็นตัวแทนที่สามารถนำมาใช้แทนที่ MySQL ส่วนใหญ่ได้ทันที (drop-in replacement) โดยให้การรองรับเวกเตอร์แบบ native ในขณะที่ยังคงอยู่ในระบบนิเวศเดิม
  2. เพิ่มบริการค้นหาเฉพาะทาง – รัน PostgreSQL instance ขนาดเล็กควบคู่ไปกับ MySQL เพื่อใช้สำหรับการค้นหาความคล้ายคลึงโดยเฉพาะ
  3. ใช้งานโดยไม่มีฟีเจอร์นี้ – การค้นหาเชิงความหมายเป็นเพียงทางเลือกสำหรับหลายแอปพลิเคชัน หากประโยชน์ที่ได้รับไม่คุ้มกับค่าใช้จ่ายในการดำเนินงาน (operational cost) การใช้ MySQL ต่อไปอาจเป็นทางเลือกที่เหมาะสมที่สุดในเชิงปฏิบัติ

แต่ละทางเลือกมีข้อดีข้อเสียที่แตกต่างกันในด้านความซับซ้อนในการดำเนินงาน, ความหน่วง (latency) และภาระในการบำรุงรักษา การตัดสินใจขึ้นอยู่กับว่าการค้นหาแบบเวกเตอร์มีความสำคัญต่อคุณค่าหลัก (value proposition) ของผลิตภัณฑ์คุณมากน้อยเพียงใด

บทเรียนสำหรับการออกแบบ API

การเปลี่ยนแปลงของ Laravel แสดงให้เห็นถึงหลักการออกแบบที่กว้างขึ้น นั่นคือการหลีกเลี่ยงการกระจายการตรวจสอบที่เจาะจงเฉพาะฐานข้อมูลไปทั่วตรรกะหลัก (core logic) เมื่อฟีเจอร์ใดขึ้นอยู่กับความสามารถของเอนจินเฉพาะทาง ควรทำการห่อหุ้ม (encapsulate) ความพึ่งพานั้นไว้ภายใต้ driver interface ซึ่งแนวทางใหม่ที่ใช้ grammar-based นี้ทำหน้าที่ดังกล่าวพอดี ช่วยเตรียมความพร้อมให้เฟรมเวิร์กสำหรับการขยายความสามารถในอนาคตโดยไม่ต้องกลับไปแก้ไข query builder หลัก

นักพัฒนาที่สร้างแพ็กเกจของตัวเองควรนำเรื่องนี้ไปปรับใช้ หากคุณพบการตรวจสอบ instanceof สำหรับประเภทฐานข้อมูลภายใน service layer ของคุณ ให้ย้ายความรับผิดชอบนั้นไปยังไดรเวอร์หรือ adapter เฉพาะทาง วิธีนี้จะช่วยให้ public API สะอาดและทำให้โค้ดของคุณรองรับการเปลี่ยนแปลงในอนาคต (future-proof)