CobbleDB: Xây dựng lại bộ nhớ tìm kiếm AI để giảm độ trễ và chi phí

Tìm kiếm gốc AI đặt ra các yêu cầu khác nhau về cách nội dung web cần được xử lý, lưu trữ và phục vụ. Để đáp ứng các nhu cầu đó ở quy mô lớn, chúng tôi đã xây dựng lại toàn bộ ngăn xếp từ đầu nhằm cải thiện hiệu suất và giảm chi phí.

Chúng tôi đã xây dựng riênghạ tầng thu thập dữ liệu, lập chỉ mục và xếp hạng, các mô hình nhúng và các công cụ suy luận để vận hành quá trình xử lý hiệu quả và phục vụ nhanh. Giờ đây, chúng tôi đang mở rộng cách tiếp cận đó sang lưu trữ, lớp kết nối mà quá trình xử lý ghi vào và dịch vụ đọc từ đó.

Các cơ sở dữ liệu được quản lý như DynamoDB cung cấp bộ nhớ đáng tin cậy, nhưng chúng tôi có quyền kiểm soát hạn chế đối với cách dữ liệu được lưu trữ và các lượt đọc được phục vụ, và định giá dựa trên mức sử dụng tăng lên cùng với kích thước chỉ mục và khối lượng truy vấn của chúng tôi. Ngoài ra, đường ống trước đây của chúng tôi kết hợp trực tiếp việc xử lý tài liệu với cơ sở dữ liệu phục vụ, khiến cho việc quản lý các bản cập nhật độc lập với các lượt đọc trực tiếp trở nên khó khăn.

Với sự trợ giúp từ một bầy tác nhân mã hóa nội bộ mới, chúng tôi đã xây dựng lại lớp này xung quanh CobbleDB, một kho nóng key-value, được hỗ trợ bởi Pillar để quản lý trạng thái tài liệu bền vững và xuất bản, cùng Lorry cho các bản cập nhật theo lô. Thiết kế lại tách biệt quá trình xử lý tài liệu khỏi việc nạp kho nóng và cho phép chúng tôi tinh chỉnh việc phục vụ theo khối lượng công việc của mình. Các phép đo trước và sau trong môi trường sản xuất cho thấy độ trễ đọc theo lô giảm khoảng 5 lần và mô hình chi phí nội bộ của chúng tôi ước tính tiết kiệm được ít nhất 20% so với DynamoDB.

Cơ sở hạ tầng lưu trữ cho tìm kiếm gốc AI

Một ngăn xếp tìm kiếm cổ điển được xây dựng cho người đọc là con người, chứ không phải mô hình ngôn ngữ. Sự khác biệt đó làm thay đổi mức độ chi tiết mà hệ thống cần để chuẩn bị, lưu trữ và phục vụ nội dung web.

Để biến HTML thô thành nội dung sẵn sàng cho mô hình, đường ống xử lý của chúng tôi làm sạch từng trang, chia nhỏ thành các đoạn có ý nghĩa ngữ nghĩa, tính toán các embedding của chúng và lưu trữ các đoạn cùng embedding đó lại với nhau trong cơ sở dữ liệu. Tại thời điểm truy vấn, đường ống phục vụ chọn văn bản có liên quan nhất đến truy vấn và chuyển nó cho mô hình.

Hai quy trình làm việc riêng biệt

Do đó, lớp lưu trữ phải hỗ trợ hai quy trình làm việc với các nhu cầu khác nhau: nạp các bản cập nhật từ đường ống xử lý và phục vụ các lượt đọc có độ trễ thấp.

Về phía ghi, các trang mới đến liên tục, các trang hiện có thay đổi và các thay đổi đối với phương pháp chia đoạn hoặc mô hình embedding có thể yêu cầu tái xử lý phần lớn tập dữ liệu. Lớp lưu trữ phải tích hợp các bản cập nhật này vào trạng thái tài liệu bền vững, theo dõi các phiên bản hiện tại, xuất bản các biểu diễn phù hợp cho các hệ thống hạ nguồn và hỗ trợ việc bổ sung dữ liệu lớn mà không cần lặp lại toàn bộ quy trình từ khâu thu thập thô.

Ngược lại, các lượt đọc tại thời điểm truy vấn yêu cầu các lô khóa trang và truy xuất văn bản đoạn văn cùng embedding tương ứng để xếp hạng và lựa chọn đoạn văn. Các lượt đọc này nằm trên đường dẫn đến câu trả lời cuối cùng, vì vậy chúng cần được hoàn thành nhanh chóng.

Các khối lượng công việc này đòi hỏi các thiết kế khác nhau. Quá trình xử lý hưởng lợi từ các hàng đợi bền vững và khả năng phân phối các bản cập nhật một cách hiệu quả, thử lại khi thất bại và cập nhật các bản ghi hiện có lên trạng thái mới nhất ở quy mô lớn. Quá trình phục vụ hưởng lợi từ các bản ghi được tính toán trước, bộ nhớ đệm ấm và các lượt đọc theo lô nhanh với công việc tối thiểu tại thời điểm truy vấn. Sự kết hợp chặt chẽ giữa hai bên có thể khiến công việc khôi phục và các bản cập nhật lớn cạnh tranh với các lượt đọc nhạy cảm với độ trễ.

Điểm thiếu sót của cơ sở dữ liệu được quản lý

DynamoDB cung cấp cho chúng tôi kho lưu trữ có tính sẵn sàng cao mà không gặp gánh nặng vận hành cơ sở dữ liệu phân tán. Một bảng trang được chuẩn bị chuyên dụng chứa các đoạn văn bản và embedding cho các lượt đọc tại thời điểm truy vấn, trong khi toàn bộ nội dung trang và siêu dữ liệu được lưu trữ riêng biệt. Tuy nhiên, khi khối lượng công việc tăng lên, ba ràng buộc đã trở nên quan trọng.

Thứ nhất, định giá dựa trên mức sử dụng tính phí cho mọi byte đọc hoặc ghi. Một yêu cầu Search API duy nhất chứa 100-120 khóa tương ứng với các trang chúng ta cần tìm nạp. Quá trình truy xuất dữ liệu chia một yêu cầu thành các lô nhỏ hơn gồm 10-20 khóa trang với kích thước mục trung bình khoảng 50 KB. Việc đọc lặp lại các bản ghi đó tiêu thụ dung lượng đáng kể, trong khi việc thu thập liên tục và thay đổi các mô hình phân đoạn hoặc embedding tạo ra nhiều lệnh ghi hơn. Khía cạnh kinh tế cũng phụ thuộc vào kích thước và tần suất của các bản ghi, chứ không chỉ số lượng lệnh gọi API.

Thứ hai, dịch vụ được quản lý thiếu sự linh hoạt mà chúng tôi cần để tinh chỉnh hiệu suất. Thao tác chúng tôi cần rất hẹp: với một lô mã định danh trang, hãy trả về nội dung đã chuẩn bị của chúng nhanh chóng. Chúng tôi muốn kiểm soát máy nào giữ phân vùng, bao nhiêu bộ nhớ được dành cho bộ nhớ đệm của nó và bản sao nào xử lý một yêu cầu. Các điều khiển đó rất quan trọng vì một lượt đọc không có trong bộ nhớ đệm, bước nhảy chéo vùng hoặc một bản sao chậm có thể làm chậm toàn bộ lô. DynamoDB quản lý bộ nhớ và hành vi bản sao của riêng nó đằng sau API. Chúng tôi có thể cấu hình dịch vụ, nhưng chúng tôi không thể tinh chỉnh vị trí nội bộ, bộ nhớ đệm của công cụ lưu trữ hoặc chính sách lựa chọn bản sao xung quanh khối lượng công việc của mình.

Thứ ba, quá trình xử lý gắn liền trực tiếp với các lệnh ghi vào kho nóng. Đường ống xử lý trước đây của chúng tôi ghi trực tiếp từng trang đã chuẩn bị vào DynamoDB. Do đó, một công việc tái xử lý lớn đã biến thành một loạt các bản cập nhật kho nóng riêng lẻ, và quá trình xử lý phải thích ứng với giới hạn thông lượng cũng như hành vi thử lại của kho nóng. Chúng tôi không thể chạy MapReduce trên toàn bộ cơ sở dữ liệu trong 1-2 ngày để thử một phương pháp chia đoạn mới, thay đổi mô hình embedding của mình hoặc thêm một trường mới. Không có luồng cập nhật trang đã lưu độc lập nào mà một dịch vụ riêng biệt có thể gom nhóm và phân phối đến kho nóng theo tốc độ của riêng nó.

Việc giải quyết các ràng buộc này đòi hỏi nhiều hơn việc thay thế cơ sở dữ liệu. Chúng tôi cần tách trạng thái tài liệu bền vững và phân phối cập nhật khỏi bộ nhớ tại thời điểm truy vấn, sau đó tối ưu hóa kho nóng đặc biệt cho các lượt đọc theo lô nhanh.

Tách biệt trạng thái tài liệu, phân phối cập nhật và phục vụ

Kiến trúc mới phân công từng trách nhiệm cho một thành phần khác nhau. Pillar duy trì trạng thái tài liệu bền vững và quyết định những gì cần xuất bản. Lorry biến các bản xuất đó thành các lô được phân vùng. CobbleDB nạp các lô và phục vụ các bản ghi đã chuẩn bị theo khóa trang.

Phóng to

CobbleDB: đường dẫn đọc có thể tinh chỉnh

CobbleDB là kho nóng của chúng tôi được tối ưu hóa để phục vụ các bản ghi đã chuẩn bị tại thời điểm truy vấn. Đây là một cơ sở dữ liệu key-value phân tán: các khóa là mã định danh trang (URL được băm) và các giá trị là biểu diễn đã xử lý của trang (các đoạn văn bản được chia đoạn trước và embedding véc-tơ trên mỗi đoạn).

Sự thay đổi quan trọng là quyền kiểm soát của chúng tôi đối với cấu hình lưu trữ.

Dữ liệu được phân vùng và chia nhỏ trên các nút dữ liệu. Định dạng phân tán này đảm bảo rằng cơ sở dữ liệu có thể mở rộng theo chiều ngang để chứa một tập hợp khổng lồ các trang đã được xử lý. Mỗi phân vùng có ba bản sao trên ba nút khác nhau; nếu một bản sao không khả dụng, các bản sao khác có thể tiếp tục phục vụ các lượt đọc.

Mỗi nút dữ liệu được chỉ định một tập hợp con các phân vùng. Nút lưu trữ dữ liệu của mình bằng RocksDB, một công cụ lưu trữ key-value nhúng mã nguồn mở rất phù hợp với khối lượng công việc nặng về đọc do quá trình nạp theo lô cung cấp.

Dữ liệu được lưu vào bộ nhớ đệm có thể được phục vụ từ bộ nhớ, trong khi các lượt đọc không có trong bộ nhớ đệm sử dụng bộ nhớ NVMe cục bộ. Điều này cung cấp cho chúng ta một cách trực tiếp để tinh chỉnh sự cân bằng giữa bộ nhớ và đĩa cho khối lượng công việc được quan sát, thay vì chấp nhận chính sách bộ nhớ đệm nội bộ của dịch vụ được quản lý.

Bộ định tuyến truy vấn phi trạng thái băm các khóa thành các phân vùng và định tuyến các yêu cầu đến các nút song song. Kiến trúc này cũng bao gồm dịch vụ siêu dữ liệu được hỗ trợ bởi PostgreSQL và bộ lưu trữ đối tượng bền vững.

Thiết kế này hỗ trợ các mô hình đọc mà khối lượng công việc của chúng ta yêu cầu. Sau khi truy vấn trải qua quá trình truy xuất và xếp hạng để có được tập hợp các trang ứng viên có liên quan, kho nóng sẽ được truy vấn hàng loạt để lấy nội dung của các trang đó. Các yêu cầu đọc này đến bộ định tuyến và được định tuyến đến một nút dữ liệu tương ứng. Bộ định tuyến ưu tiên gửi yêu cầu đến một nút trong cùng vùng sẵn sàng để giảm thiểu độ trễ chéo vùng, nếu có thể. Mỗi nút dữ liệu có thể tìm nạp nội dung trang bằng MultiGet, một API đọc theo lô của RocksDB được thiết kế để tìm nạp nhiều khóa đồng thời ở độ trễ thấp. Nếu một nút phản hồi chậm, hệ thống cũng có thể truy vấn một bản sao phân vùng khác trên một nút khác, qua đó cải thiện độ trễ đuôi.

Chúng tôi cũng có thể tránh việc triển khai các tính năng phổ biến mà quy trình làm việc của chúng tôi không yêu cầu. Ví dụ, hầu hết các cơ sở dữ liệu đều cung cấp đảm bảo tính nhất quán và hỗ trợ giao dịch, nhưng kho nóng của chúng tôi không yêu cầu giao dịch hay các bản sao đồng bộ. Việc có một khoảng thời gian ngắn giữa thời điểm tài liệu được ghi và thời điểm nó có sẵn để đọc là hoàn toàn có thể chấp nhận được, và việc một bản sao nạp dữ liệu nhanh hơn bản sao khác cũng không có vấn đề gì. Việc lược bỏ các tính năng không cần thiết sẽ làm giảm chi phí và chi phí chung của hệ thống.

Phóng to

Pillar và Lorry: đường dẫn ghi bền vững

Một lớp lưu trữ riêng biệt theo dõi mọi nội dung chúng ta thu thập và xử lý, hợp nhất các bản cập nhật vào trạng thái tài liệu có phiên bản và xuất bản các bản thể hiện cần thiết lên CobbleDB cùng chỉ mục tìm kiếm. Chúng tôi đã xây dựng Pillar, lớp trạng thái và xuất bản tài liệu của mình, cho mục đích này.

Pillar được hỗ trợ bởi YTsaurus. Nó lưu trữ các thành phần trang (như siêu dữ liệu, các khối và embedding) trong các nhóm bảng YTsaurus riêng biệt. Nó cũng theo dõi các phiên bản của các khối và embedding, cho phép nhiều bản thể hiện cùng tồn tại mà không ghi đè lên nhau để các mô hình bên dưới có thể thay đổi. Vì Pillar và YTsaurus sử dụng bộ nhớ HDD giá rẻ, chúng ta có thể lưu trữ nhiều tài liệu hơn rất nhiều so với trước đây trong DynamoDB.

Pillar theo dõi các tập hợp con, hoặc các nhóm trang được xác định theo chính sách như các trang mới hoặc các trang có giá trị cao. Thành viên tập hợp con xác định những bản cập nhật nào cần được chuyển cho các thành phần hạ nguồn như CobbleDB. CobbleDB sử dụng bộ nhớ NVMe đắt tiền hơn, vì vậy chúng tôi chỉ xuất các tài liệu mà chúng tôi thực sự muốn sử dụng trong kết quả tìm kiếm. Khi nội dung của một trang được cập nhật, hoặc nếu nó được thêm vào hoặc xóa khỏi một tập hợp con, Pillar chịu trách nhiệm xếp hàng công việc xuất tương ứng.

Các giao dịch YTsaurus nguyên tử bao gồm trạng thái, ý định xuất và nội dung đầu vào đã tiêu thụ nhằm đảm bảo tính chính xác. Để một giao dịch hoàn tất thành công, hệ thống phải cập nhật trạng thái bền vững, đánh dấu đầu vào là đã ghi nhận và xếp hàng đợi tất cả các thao tác xuất bắt buộc; nếu giao dịch bị hủy, sẽ không có thay đổi nào được thực hiện ở bất kỳ lớp nào.

CobbleDB mong đợi các bản cập nhật được gom nhóm theo phân vùng. Các bản xuất Pillar được chuyển đổi sang định dạng này bởi một dịch vụ phi trạng thái mà chúng tôi gọi là Lorry. Công việc duy nhất của nó là đọc các bản ghi xuất từ một hàng đợi bền vững gắn liền với phân vùng, tích lũy chúng thành các tệp theo lô cho mỗi phân vùng và bàn giao chúng cho CobbleDB.

Giữa Lorry và Cobble, một giao thức bổ sung tách biệt mặt phẳng dữ liệu (S3) khỏi mặt phẳng điều khiển. Lorry ghi lô vào S3 dưới một mã định danh duy nhất và đăng ký lô đó trong Cobble. Các bản sao phân vùng Cobble độc lập truy vấn API mặt phẳng điều khiển hoặc lô cho lô S3 tiếp theo để nạp và áp dụng bất đồng bộ các bản cập nhật theo lô theo thứ tự thời gian. Điều này có nghĩa là một nút chậm hoặc đang phục hồi có thể bắt kịp theo tốc độ của riêng mình, thay vì làm chậm phần còn lại của hệ thống.

Phóng to

Đường dẫn mới tách giao dịch xử lý tức thời khỏi quá trình nạp kho nóng và cung cấp đường dẫn có thể phát lại cho các bản cập nhật gia tăng và xây dựng lại hàng loạt. Sự phân chia công việc này đảm bảo rằng các bản cập nhật cho trạng thái tài liệu bền vững không ảnh hưởng đến độ trễ của đường dẫn đọc.

Xác thực

Nhanh hơn 5x

Sau khi di chuyển kho nóng, độ trễ đọc theo lô trung bình đã giảm từ 31,4 ms xuống 5,60 ms. Chỉ số p90 giảm từ 56,7 ms xuống 9,77 ms và p99 giảm từ 123 ms xuống 24,2 ms. Tỷ lệ cải thiện dao động từ 5,08× đến 5,80×, với các cải tiến ở cả các yêu cầu thông thường lẫn đuôi phân phối.

Phóng to

Những con số này bắt nguồn từ các lượt đọc theo lô, trong đó mỗi truy vấn yêu cầu khoảng 10-15 khóa. Kích thước mục tải trọng trung bình là 50KB. Cả hai hệ thống đều được truy vấn ở mức khoảng 200k rps, mặc dù chúng tôi cũng chạy các bài kiểm tra tải lên tới 500k rps mà không bị suy giảm hiệu suất.

Để cô lập sự đóng góp của CobbleDB, tất cả các khía cạnh khác của thiết lập đều được giữ nguyên. Tuy nhiên, đây vẫn là một sự so sánh quan sát trước và sau; các hệ thống phục vụ lưu lượng sản xuất trực tiếp vào các thời điểm khác nhau thay vì các yêu cầu giống nhau trong các điều kiện được kiểm soát. Do đó, chúng tôi cũng đo lường hiệu suất của cả hai hệ thống trên một chuẩn mực tổng hợp. Để mô phỏng các yêu cầu trong môi trường sản xuất, chúng tôi đã truy vấn cả hai bằng các lô gồm 10-15 khóa và giá trị từ 100B đến 100 KiB.

Phóng to

DynamoDB gặp khó khăn trong bối cảnh này vì đường dẫn đọc được quản lý của nó không thể được tinh chỉnh cho các lượt đọc theo lô có kích thước này. Ngược lại, CobbleDB được tối ưu hóa chính xác cho bối cảnh này, vì chúng tôi quản lý việc bố trí, bộ nhớ đệm và các điều khiển bản sao. Nó nhóm các khóa theo phân vùng, thực thi các lượt đọc song song với các bản sao phân vùng và có thể giảm thiểu rủi ro cho các lượt đọc chậm bằng các bản sao khác. Kết quả của chúng tôi chứng minh rằng các lựa chọn thiết kế này chuyển hóa thành các lượt đọc nhanh hơn trong môi trường sản xuất.

Rẻ hơn 20%

CobbleDB cũng rẻ hơn đáng kể so với DynamoDB. Ngoài dung lượng lưu trữ, DynamoDB còn tính phí cho mọi byte đọc hoặc ghi. Ở quy mô tập dữ liệu và lưu lượng phục vụ của chúng tôi, các khoản phí dựa trên mức sử dụng này trở thành một phần đáng kể trong tổng chi phí. Các bản cập nhật liên tục tiêu thụ dung lượng ghi, trong khi mọi lô trang được chuẩn bị được tìm nạp cho một truy vấn đều tiêu thụ dung lượng đọc.

Chúng tôi đã tính toán khoản tiết kiệm chi phí dựa trên các ước tính nội bộ về dung lượng lưu trữ, đơn vị dung lượng ghi và đơn vị dung lượng đọc. Ở mọi bậc cam kết, CobbleDB rẻ hơn ít nhất 20% so với DynamoDB. Khoản tiết kiệm thực tế có thể còn cao hơn nữa, vì các kết quả này không tính đến khoản tiết kiệm sao lưu tiềm năng từ việc nén.

Một bầy tác nhân AI giúp chúng ta xây dựng nó như thế nào

Việc xây dựng CobbleDB và cơ sở hạ tầng xung quanh không hề đơn giản. Riêng cơ sở dữ liệu cốt lõi của CobbleDB đã có khoảng 40.000 dòng mã Rust, và quá trình di chuyển cũng đòi hỏi công việc EXTENSIVE để xác minh tính chính xác và hành vi lỗi ở quy mô sản xuất, tích hợp CobbleDB với cả đường dẫn xử lý và phục vụ, đồng thời chuyển đổi lưu lượng truy cập trực tiếp một cách an toàn.

Chúng tôi đã đẩy nhanh nỗ lực này bằng cách sử dụng một hệ thống nội bộ vận hành một bầy tác nhân mã hóa. Hệ thống được thiết kế để có tính bền vững cao; nó lưu giữ các mục tiêu của dự án, các rủi ro đang hoạt động, lịch sử kho lưu trữ và các quyết định trước đó qua các Phiên.

Chúng tôi đã phân công một tập hợp các tác nhân chủ động, luôn hoạt động như vậy cho dự án CobbleDB. Nhiệm vụ đầu tiên của họ là xây dựng một mô hình chính xác về công việc đang thực hiện. Họ đã kiểm tra chuỗi dự án và các luồng hoạt động, kết nối các mục chưa giải quyết với pull request và chủ sở hữu của chúng, đồng thời tạo ra một bản báo cáo cập nhật về tình trạng hệ thống và các hành động tiếp theo. Từ đó, họ hoạt động trên một số phần của vòng lặp kỹ thuật:

• Đã xem xét các thay đổi về mã và cơ sở hạ tầng.
• Đã phát hiện các tác nhân chặn dễ bị bỏ sót, bao gồm các giả định khôi phục không an toàn, các tham chiếu bản dựng cũ và các cấu hình sẽ thất bại khi chạy.
• Đã chuẩn bị các bản sửa lỗi tập trung, các bài kiểm tra, các thay đổi theo dõi và tài liệu vận hành.
• Đã theo dõi các cổng CI, đánh giá và cơ sở hạ tầng trong khi vẫn đảm bảo các hành động sản xuất do con người chịu trách nhiệm rõ ràng.
• Đã theo dõi quá trình triển khai và các bài tập sao lưu hoặc khôi phục, sau đó so sánh trạng thái hệ thống quan sát được với các tiêu chí thành công của quá trình triển khai.
• Đã duy trì các báo cáo dự án để các kỹ sư có thể thấy những gì đã được phát hành, những gì vẫn bị chặn và nơi vẫn cần sự phán đoán của con người.

Các kỹ sư vẫn thiết lập kiến trúc, xem xét các thay đổi hệ quả và ủy quyền các hoạt động sản xuất. Các tác nhân xử lý phần lớn công việc kiểm tra liên tục và theo dõi giữa các quyết định đó. Điều này cho phép một đội ngũ nhỏ thúc đẩy dự án một cách hiệu quả — cơ sở hạ tầng cốt lõi của CobbleDB được xây dựng bởi hai kỹ sư con người và hàng trăm tác nhân AI trong vòng hai tháng.

Kết luận

CobbleDB không phải là cơ sở dữ liệu đa mục đích; nó được xây dựng chuyên biệt cho khối lượng công việc cụ thể của chúng tôi là các lượt đọc theo lô lặp lại các bản ghi trang đã chuẩn bị, được cung cấp bởi một chuỗi xử lý bất đồng bộ. Bằng cách tách biệt trạng thái bền vững, phân phối cập nhật và phục vụ tại thời điểm truy vấn, chúng tôi có thể tối ưu hóa từng trách nhiệm độc lập mà không buộc một giao diện cơ sở dữ liệu duy nhất phải đáp ứng tất cả hoặc đẩy công việc bảo trì sang đường dẫn truy vấn trực tiếp. Việc chuyển sang CobbleDB đã cải thiện đáng kể cả độ trễ trung bình và đuôi đồng thời giảm chi phí cơ sở hạ tầng.

Khi tiếp tục phát triển cơ sở hạ tầng gốc AI nội bộ, chúng tôi có thể tối ưu hóa hiệu suất và chi phí theo những cách không thể đạt được khi bị ràng buộc bởi các giải pháp và mô hình định giá của bên thứ ba. Các tác nhân AI mạnh mẽ càng làm thay đổi cán cân có lợi cho việc tự xây dựng thay vì mua.

Chúng tôi dự định sẽ sớm mã nguồn mở CobbleDB, để các đội ngũ khác xây dựng hệ thống tìm kiếm gốc AI có thể hưởng lợi từ cùng một lớp lưu trữ giúp tìm kiếm nhanh hơn và rẻ hơn bên trong các sản phẩm của chúng tôi.

Trích dẫn

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}