Vector là JSON mới của PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

Vector là một cấu trúc toán học đã được nghiên cứu kỹ, còn JSON là một định dạng trao đổi dữ liệu Nhưng trong thế giới lưu trữ và truy xuất dữ liệu, cả hai cách biểu diễn dữ liệu này đã trở thành ngôn ngữ chung và sẽ sớm trở thành yếu tố thiết yếu trong phát triển ứng dụng hiện đại Nếu xu hướng hiện tại tiếp tục, vector cũng sẽ trở nên quan trọng đối với việc xây dựng ứng dụng như JSON PostgreSQL đã trở thành lựa chọn tự nhiên để lưu trữ và truy vấn kết quả của AI tạo sinh Nhưng đây không phải là một mẫu dữ liệu mới. Vector với tư cách là một khái niệm toán học đã tồn tại hàng trăm năm Mảng, cấu trúc dữ liệu cơ bản của vector, được dạy trong hầu hết các khóa nhập môn khoa học máy tính. PostgreSQL cũng đã hỗ trợ các thao tác vector hơn 20 năm Vậy điều gì là mới? Đó là mức độ "khả dụng" của các thuật toán AI/ML như vậy và việc biểu diễn một số cấu trúc trong "thế giới thực" (văn bản, hình ảnh, video) dưới dạng vector, rồi dùng chúng sau này trong ứng dụng, đã trở nên "dễ thực hiện" đến mức nào Ngoài ra, việc lưu đầu ra của các hệ thống này ("embedding") vào kho dữ liệu cũng có thể nói là không mới, nhưng mẫu mới nằm ở "khả dụng" của việc truy vấn và trả về dữ liệu này gần như theo thời gian thực trong mọi ứng dụng Vậy điều này liên quan gì đến PostgreSQL? Một mẫu chung để lưu trữ và truy xuất kiểu dữ liệu một cách hiệu quả đã đơn giản hóa đáng kể việc phát triển ứng dụng, đồng thời cho phép mọi người lưu dữ liệu trong cùng một nơi và làm việc với chúng bằng các công cụ hiện có Chúng ta đã thấy điều này với JSON cách đây 10 năm, và giờ đang thấy lại mẫu đó với dữ liệu vector Lịch sử ngắn gọn của JSON trong PostgreSQL (Hãy tham khảo bài gốc) Sự trỗi dậy của vector, "một kiểu JSON mới" Gần đây mức độ phổ biến tăng rất nhanh Trường hợp sử dụng phổ biến là xây dựng mô hình trên dữ liệu đã lưu, chuyển nó sang dạng vector rồi dùng cho "tìm kiếm ngữ nghĩa" Trong trường hợp này, đầu vào mới đi vào tìm kiếm sẽ được chuyển sang định dạng vector rồi cơ sở dữ liệu sẽ tìm ra mục giống nhất Độ tương đồng được tính bằng các hàm khoảng cách như Euclid/cosine, và kết quả thường bị giới hạn ở k-NN (Nearest Neighbors) hoặc k đối tượng giống nhất Vì việc mã hóa tập huấn luyện của vector có thể tốn rất nhiều thời gian, nên tốt hơn là cache nó ở nơi như DB rồi chạy truy vấn k-NN tại đó Việc có sẵn một tập vector đã chuẩn bị để truy vấn cho tìm kiếm ngữ nghĩa thường mang lại trải nghiệm tốt hơn cho người dùng, nên nhu cầu về "cơ sở dữ liệu vector" đã xuất hiện Lưu trữ vector không phải điều mới đối với PostgreSQL Thực ra đây là một cách gọi chưa thật chuẩn, vì PostgreSQL có thể lưu dữ liệu nhiều chiều (ví dụ: matrix) Mặc định, mảng trong PostgreSQL có bao gồm một số chức năng hạn chế cho vector, chẳng hạn như tính "khoảng cách" giữa hai mảng Có thể viết stored procedure, nhưng điều đó đòi hỏi nhà phát triển phải làm thêm việc May mắn là kiểu dữ liệu cube khắc phục được những hạn chế này cube đã được dùng hơn 20 năm và được thiết kế để thực hiện các thao tác trên vector nhiều chiều cube bao gồm hầu hết các hàm khoảng cách phổ biến dùng trong tìm kiếm độ tương đồng vector, bao gồm cả khoảng cách Euclid Cũng có thể thực hiện truy vấn K-NN hiệu quả bằng chỉ mục GiST Nhưng cube chỉ có thể lưu vector tối đa 100 chiều, trong khi các hệ thống AI/ML hiện đại yêu cầu nhiều hơn thế pgvector: tiện ích mở rộng mã nguồn mở để lưu trữ và truy xuất vector trong PostgreSQL Với pgvector, có thể lưu vector và thực hiện truy vấn k-NN bằng nhiều metric khoảng cách khác nhau (Euclid, cosine, inner product, v.v.) Hiện tại pvector đi kèm một chỉ mục ivfflat, triển khai phương pháp IVR FLAT cho lập chỉ mục vector Việc truy vấn dữ liệu vector đã được lập chỉ mục có thể khác với truy vấn dữ liệu thông thường Do chi phí của việc tìm kiếm láng giềng gần nhất trên vector nhiều chiều, nhiều phương pháp lập chỉ mục vector tìm câu trả lời "xấp xỉ" và "đủ gần" với đáp án đúng Điều này dẫn đến lĩnh vực tìm kiếm "ANN (Approximate Nearest Neighbor)" Hai khía cạnh mọi người thường xem xét với truy vấn ANN là sự cân bằng giữa hiệu năng và "recall" (tỷ lệ phần trăm kết quả liên quan được trả về) Lấy ivfflat làm ví dụ, khi tạo chỉ mục ivfflat ta quyết định sẽ bao gồm bao nhiêu danh sách Mỗi danh sách đại diện cho một "tâm", và các tâm này được tính bằng thuật toán k-means Khi tất cả các tâm đã được xác định, ivfflat sẽ xác định tâm gần nhất với từng vector và thêm nó vào chỉ mục Khi đến lúc truy vấn dữ liệu vector, tùy theo biến ivfflat.probes mà hệ thống quyết định cần kiểm tra bao nhiêu tâm Ở đây có thể thấy trade-off giữa hiệu năng và recall của ANN. Càng ghé thăm nhiều tâm thì kết quả càng chính xác, nhưng hiệu năng giảm đi Các bước tiếp theo để hỗ trợ vector tốt hơn trong PostgreSQL Cũng giống như thời PostgreSQL 9.2 chính thức hỗ trợ kiểu JSON, hiện chúng ta đang ở giai đoạn đầu của cách lưu dữ liệu vector trong PostgreSQL PostgreSQL và pgvector đã rất tốt, nhưng sẽ còn tốt hơn nữa pgvector đã có thể xử lý các trường hợp dữ liệu AI/ML phổ biến. Nhiều người dùng đã triển khai và sử dụng Bước tiếp theo là hỗ trợ cải tiến và mở rộng, và phần lớn đã đang được tiến hành Bổ sung thêm khả năng song song hóa Hỗ trợ vector có hơn 2.000 chiều Tận dụng tăng tốc phần cứng để nâng cao tốc độ tính toán Có rất nhiều kỳ vọng vào việc dùng PostgreSQL như một "cơ sở dữ liệu" vector Như có thể thấy từ lịch sử của JSON, cộng đồng PostgreSQL sẽ tìm ra cách hỗ trợ theo hướng có thể mở rộng và an toàn

(jkatz05.com)

26 điểm bởi xguru 2023-06-28 | 7 bình luận | Chia sẻ qua WhatsApp

Vector là một cấu trúc toán học đã được nghiên cứu kỹ, còn JSON là một định dạng trao đổi dữ liệu
Nhưng trong thế giới lưu trữ và truy xuất dữ liệu, cả hai cách biểu diễn dữ liệu này đã trở thành ngôn ngữ chung và sẽ sớm trở thành yếu tố thiết yếu trong phát triển ứng dụng hiện đại
Nếu xu hướng hiện tại tiếp tục, vector cũng sẽ trở nên quan trọng đối với việc xây dựng ứng dụng như JSON
PostgreSQL đã trở thành lựa chọn tự nhiên để lưu trữ và truy vấn kết quả của AI tạo sinh
Nhưng đây không phải là một mẫu dữ liệu mới. Vector với tư cách là một khái niệm toán học đã tồn tại hàng trăm năm
Mảng, cấu trúc dữ liệu cơ bản của vector, được dạy trong hầu hết các khóa nhập môn khoa học máy tính. PostgreSQL cũng đã hỗ trợ các thao tác vector hơn 20 năm
Vậy điều gì là mới? Đó là mức độ "khả dụng" của các thuật toán AI/ML như vậy và việc biểu diễn một số cấu trúc trong "thế giới thực" (văn bản, hình ảnh, video) dưới dạng vector, rồi dùng chúng sau này trong ứng dụng, đã trở nên "dễ thực hiện" đến mức nào
Ngoài ra, việc lưu đầu ra của các hệ thống này ("embedding") vào kho dữ liệu cũng có thể nói là không mới, nhưng mẫu mới nằm ở "khả dụng" của việc truy vấn và trả về dữ liệu này gần như theo thời gian thực trong mọi ứng dụng
Vậy điều này liên quan gì đến PostgreSQL?
- Một mẫu chung để lưu trữ và truy xuất kiểu dữ liệu một cách hiệu quả đã đơn giản hóa đáng kể việc phát triển ứng dụng, đồng thời cho phép mọi người lưu dữ liệu trong cùng một nơi và làm việc với chúng bằng các công cụ hiện có
- Chúng ta đã thấy điều này với JSON cách đây 10 năm, và giờ đang thấy lại mẫu đó với dữ liệu vector

Lịch sử ngắn gọn của JSON trong PostgreSQL

(Hãy tham khảo bài gốc)

Sự trỗi dậy của vector, "một kiểu JSON mới"

Gần đây mức độ phổ biến tăng rất nhanh
Trường hợp sử dụng phổ biến là xây dựng mô hình trên dữ liệu đã lưu, chuyển nó sang dạng vector rồi dùng cho "tìm kiếm ngữ nghĩa"
- Trong trường hợp này, đầu vào mới đi vào tìm kiếm sẽ được chuyển sang định dạng vector rồi cơ sở dữ liệu sẽ tìm ra mục giống nhất
- Độ tương đồng được tính bằng các hàm khoảng cách như Euclid/cosine, và kết quả thường bị giới hạn ở k-NN (Nearest Neighbors) hoặc k đối tượng giống nhất
- Vì việc mã hóa tập huấn luyện của vector có thể tốn rất nhiều thời gian, nên tốt hơn là cache nó ở nơi như DB rồi chạy truy vấn k-NN tại đó
- Việc có sẵn một tập vector đã chuẩn bị để truy vấn cho tìm kiếm ngữ nghĩa thường mang lại trải nghiệm tốt hơn cho người dùng, nên nhu cầu về "cơ sở dữ liệu vector" đã xuất hiện
Lưu trữ vector không phải điều mới đối với PostgreSQL
- Thực ra đây là một cách gọi chưa thật chuẩn, vì PostgreSQL có thể lưu dữ liệu nhiều chiều (ví dụ: matrix)
- Mặc định, mảng trong PostgreSQL có bao gồm một số chức năng hạn chế cho vector, chẳng hạn như tính "khoảng cách" giữa hai mảng
- Có thể viết stored procedure, nhưng điều đó đòi hỏi nhà phát triển phải làm thêm việc
May mắn là kiểu dữ liệu cube khắc phục được những hạn chế này
- cube đã được dùng hơn 20 năm và được thiết kế để thực hiện các thao tác trên vector nhiều chiều
- cube bao gồm hầu hết các hàm khoảng cách phổ biến dùng trong tìm kiếm độ tương đồng vector, bao gồm cả khoảng cách Euclid
- Cũng có thể thực hiện truy vấn K-NN hiệu quả bằng chỉ mục GiST
- Nhưng cube chỉ có thể lưu vector tối đa 100 chiều, trong khi các hệ thống AI/ML hiện đại yêu cầu nhiều hơn thế

pgvector: tiện ích mở rộng mã nguồn mở để lưu trữ và truy xuất vector trong PostgreSQL

Với pgvector, có thể lưu vector và thực hiện truy vấn k-NN bằng nhiều metric khoảng cách khác nhau (Euclid, cosine, inner product, v.v.)
Hiện tại pvector đi kèm một chỉ mục ivfflat, triển khai phương pháp IVR FLAT cho lập chỉ mục vector
Việc truy vấn dữ liệu vector đã được lập chỉ mục có thể khác với truy vấn dữ liệu thông thường
Do chi phí của việc tìm kiếm láng giềng gần nhất trên vector nhiều chiều, nhiều phương pháp lập chỉ mục vector tìm câu trả lời "xấp xỉ" và "đủ gần" với đáp án đúng
Điều này dẫn đến lĩnh vực tìm kiếm "ANN (Approximate Nearest Neighbor)"
Hai khía cạnh mọi người thường xem xét với truy vấn ANN là sự cân bằng giữa hiệu năng và "recall" (tỷ lệ phần trăm kết quả liên quan được trả về)
- Lấy ivfflat làm ví dụ, khi tạo chỉ mục ivfflat ta quyết định sẽ bao gồm bao nhiêu danh sách
- Mỗi danh sách đại diện cho một "tâm", và các tâm này được tính bằng thuật toán k-means
- Khi tất cả các tâm đã được xác định, ivfflat sẽ xác định tâm gần nhất với từng vector và thêm nó vào chỉ mục
- Khi đến lúc truy vấn dữ liệu vector, tùy theo biến ivfflat.probes mà hệ thống quyết định cần kiểm tra bao nhiêu tâm
- Ở đây có thể thấy trade-off giữa hiệu năng và recall của ANN. Càng ghé thăm nhiều tâm thì kết quả càng chính xác, nhưng hiệu năng giảm đi

Các bước tiếp theo để hỗ trợ vector tốt hơn trong PostgreSQL

Cũng giống như thời PostgreSQL 9.2 chính thức hỗ trợ kiểu JSON, hiện chúng ta đang ở giai đoạn đầu của cách lưu dữ liệu vector trong PostgreSQL
PostgreSQL và pgvector đã rất tốt, nhưng sẽ còn tốt hơn nữa
pgvector đã có thể xử lý các trường hợp dữ liệu AI/ML phổ biến. Nhiều người dùng đã triển khai và sử dụng
Bước tiếp theo là hỗ trợ cải tiến và mở rộng, và phần lớn đã đang được tiến hành
- Bổ sung thêm khả năng song song hóa
- Hỗ trợ vector có hơn 2.000 chiều
- Tận dụng tăng tốc phần cứng để nâng cao tốc độ tính toán
Có rất nhiều kỳ vọng vào việc dùng PostgreSQL như một "cơ sở dữ liệu" vector
Như có thể thấy từ lịch sử của JSON, cộng đồng PostgreSQL sẽ tìm ra cách hỗ trợ theo hướng có thể mở rộng và an toàn

7 bình luận

atempest 2025-05-07

Có lẽ tính đa dụng thì cao đấy, nhưng rốt cuộc mấu chốt vẫn là tốc độ. So với những vector DB thuần túy thì chắc sẽ chậm đến mức khó chấp nhận....

nicewook 2023-06-28

Tôi tự hỏi vì sao lại kỳ vọng vào PostgreSQL trong khi đã có các cơ sở dữ liệu vector như Pinecone. @@

tkwlsrl 2023-06-28

Theo kinh nghiệm của tôi, PostgreSQL là lựa chọn dễ tiếp cận nhất.

Khi dùng những thứ như Pinecone, ChromaDB hay Weaviate, không có sự tiêu chuẩn hóa để có thể sử dụng từng cơ sở dữ liệu đó.

Nói cách khác, mỗi cơ sở dữ liệu phải dùng một SDK khác nhau, cách dùng cũng khác, nên phải viết lại mã cho từng cơ sở dữ liệu. Ngoài ra, các ngôn ngữ mà SDK chính thức hỗ trợ cũng còn hạn chế, nên đôi khi còn phải đổi cả ngôn ngữ.

Tất nhiên, ngay cả khi muốn dùng vector trong PostgreSQL thì cũng có phần tương tự, nhưng ít nhất chỉ cần bổ sung thêm một chút kiến thức trên nền cú pháp SQL sẵn có nên vẫn khá dễ tiếp cận.

Hiện tại nếu so sánh tốc độ của các cơ sở dữ liệu vector thì PostgreSQL thuộc loại khá chậm. Mong là sớm được nâng cấp hơn một chút. haha

xguru 2023-06-28

Có lẽ chỉ đơn giản là “chỉ cần cài đặt/quản lý một DB hỗ trợ đủ mọi thứ thì sẽ tiện hơn” + “dễ tích hợp với các tính năng khác” thôi nhỉ.
Càng tăng thêm instance thì lại càng thấy phiền dần..

nicewook 2023-06-28

À, tôi hiểu rồi.
Redis cũng gắn thêm đủ thứ vì lý do đó nhỉ. Gật gù gật gù

iolothebard 2023-06-28

Mở đầu kết thúc đều là... tensor...