Laravel Vector Search hiện đã hỗ trợ MariaDB

Laravel 13 cho phép các nhà phát triển thực hiện các truy vấn tìm kiếm vector (vector-search) gốc trên MariaDB, bổ sung khả năng tìm kiếm ngữ nghĩa (semantic-search) vào hệ sinh thái Laravel mà không bắt buộc phải chuyển sang PostgreSQL.

Sự hỗ trợ mới này thay thế cho bản triển khai chỉ dành riêng cho PostgreSQL trước đây của framework, vì vậy phương thức whereVectorSimilarTo quen thuộc giờ đây có thể hoạt động trực tiếp với kết nối MariaDB. Nếu bạn đang xây dựng các công cụ gợi ý (recommendation engines), công cụ so sánh độ tương đồng tài liệu, hoặc bất kỳ tính năng nào dựa trên logic "láng giềng gần nhất" (nearest-neighbor), thay đổi này sẽ loại bỏ một rào cản lớn.

Tại sao sự thay đổi này lại quan trọng

Trước đây, bộ xây dựng truy vấn (query builder) của Laravel phát hiện nhu cầu tìm kiếm vector bằng một kiểm tra instanceof vốn chỉ nhận diện các kết nối PostgreSQL. Cách tiếp cận đó đã gắn chặt tính năng này vào một driver duy nhất và làm cho mã nguồn trở nên rườm rà với các câu lệnh điều kiện dành riêng cho từng cơ sở dữ liệu.

Bản phát hành 13 chuyển logic này vào lớp ngữ pháp (grammar layer) và thêm hai phương thức dành riêng cho driver:

  • supportsVectorDistance() – cho Laravel biết liệu kết nối hiện tại có thể tính toán khoảng cách vector hay không.
  • compileVectorDistanceExpression() – xây dựng đoạn mã SQL thực hiện việc tính toán.

Bằng cách giao các trách nhiệm này cho từng driver, framework đã loại bỏ thủ thuật "kiểm tra kiểu" (type-checking) và mở đường cho các phần mở rộng trong tương lai. Việc thêm hỗ trợ cho một cơ sở dữ liệu khác giờ đây chỉ đơn giản là triển khai một vài phương thức driver thay vì phải rải rác các khối lệnh điều kiện.

MariaDB có các hàm gốc, còn MySQL thì không

MariaDB đi kèm với các hàm vector gốc. MySQL tiêu chuẩn thiếu các hàm này trừ khi bạn sử dụng một dịch vụ đám mây chuyên dụng có bổ sung các tiện ích mở rộng AI.

Laravel chủ động tránh việc tính toán độ tương đồng ở phía PHP. Việc tính toán vector trong PHP sẽ làm hỏng tính năng phân trang và làm chậm ứng dụng mà không có cảnh báo trước. Việc ném ra một lỗi khi driver không thể xử lý thao tác sẽ cung cấp một chế độ xử lý lỗi an toàn hơn.

Người dùng MySQL có thể làm gì vào lúc này

Nếu stack của bạn đang chạy MySQL thuần túy, bạn có ba hướng đi khả thi:

  1. Chuyển sang MariaDB – một sự thay thế tương đương cho hầu hết các khối lượng công việc MySQL, cung cấp hỗ trợ vector gốc trong khi vẫn giữ nguyên hệ sinh thái.
  2. Thêm một dịch vụ tìm kiếm chuyên dụng – chạy một thực thể PostgreSQL nhẹ song song với MySQL chỉ dành riêng cho các truy vấn so sánh độ tương đồng.
  3. Sống không cần nó – tìm kiếm ngữ nghĩa là tùy chọn đối với nhiều ứng dụng; nếu lợi ích không vượt quá chi phí vận hành, việc tiếp tục sử dụng MySQL có thể là một lựa chọn thực tế.

Mỗi lựa chọn đều đi kèm với những đánh đổi về độ phức tạp vận hành, độ trễ và chi phí bảo trì. Quyết định phụ thuộc vào việc tìm kiếm vector đóng vai trò quan trọng như thế nào đối với giá trị cốt lõi của sản phẩm của bạn.

Bài học cho thiết kế API

Thay đổi của Laravel minh họa cho một nguyên tắc thiết kế rộng lớn hơn: tránh rải rác các kiểm tra dành riêng cho cơ sở dữ liệu trong suốt logic cốt lõi. Khi một tính năng phụ thuộc vào khả năng của một engine cụ thể, hãy đóng gói sự phụ thuộc đó đằng sau một giao diện driver (driver interface). Cách tiếp cận dựa trên ngữ pháp mới thực hiện chính xác điều đó, chuẩn bị cho framework các phần mở rộng trong tương lai mà không cần phải xem xét lại bộ xây dựng truy vấn cốt lõi.

Các nhà phát triển đang xây dựng các package của riêng mình nên lưu ý. Nếu bạn thấy các kiểm tra instanceof cho một loại cơ sở dữ liệu bên trong lớp dịch vụ (service layer), hãy chuyển trách nhiệm đó sang driver hoặc một adapter chuyên dụng. Điều này giúp giữ cho API công khai luôn sạch sẽ và giúp mã nguồn của bạn sẵn sàng cho tương lai.