Phân trang Offset vs Cursor

Offset và Cursor thực sự xác định điều gì

Phân trang offset yêu cầu một collection bỏ qua một tiền tố dựa trên vị trí và trả về phần tiếp theo. Phân trang cursor yêu cầu dịch vụ tiếp tục tương đối so với một ranh giới đã được trả về trước đó. Trong phân trang offset vs cursor, khác biệt quan trọng là client ghi nhớ điều gì giữa các request. Một bên ghi nhớ đã đếm được bao xa; bên kia ghi nhớ nơi dịch vụ bảo nó tiếp tục.

Cursor là một trừu tượng API, trong khi keyset pagination là một kỹ thuật truy vấn. Một token có thể mã hoá các giá trị sắp xếp, tham chiếu tới trạng thái phía server, hoặc thậm chí bao bọc một offset. Hãy kiểm tra hành vi được ghi trong tài liệu trước khi giả định rằng một chuỗi mờ ngụ ý một thao tác tìm kiếm cơ sở dữ liệu hiệu quả. Hợp đồng token trang mờ cung cấp một mô hình hữu ích: client trả lại token mà không diễn giải nội dung của chúng.

Tại sao sắp xếp phải đến trước kích thước trang

Một lần duyệt có thể dự đoán được cần một thứ tự phân biệt từng bản ghi. Chỉ sắp xếp theo một giá trị không duy nhất sẽ để các thế hoà ranh giới chưa được giải quyết. Ví dụ, một collection bài viết có thể chứa nhiều mục có cùng dấu thời gian tạo. Một định danh duy nhất có thể phá vỡ thế hoà đó, miễn là thứ tự và quy tắc so sánh của nó vẫn nhất quán giữa các request.

Các quy tắc sắp xếp SQL khiến việc thiếu một thứ tự tường minh trở nên có ý nghĩa: cơ sở dữ liệu không hứa hẹn một chuỗi mặc định hữu ích. Hãy ghi lại đặc tả sắp xếp đầy đủ với lần chạy collection. Thay đổi thứ tự tăng dần thành giảm dần, thay đổi bộ lọc, hoặc thay đổi phép so sánh nhạy cảm locale có thể làm mất hiệu lực ý nghĩa của một điểm tiếp tục đã lưu.

Cách phân trang Offset ứng xử trong khi ghi

Ranh giới offset có thể di chuyển khi các bản ghi trước đó được chèn hoặc xoá. Hãy xem xét một danh sách giả định trong đó trang đầu tiên kết thúc tại mục D. Một mục mới được chèn trước A sẽ thay đổi vị trí của các bản ghi tiếp theo. Yêu cầu bỏ qua độ dài trang cũ có thể khiến D xuất hiện trở lại trong phần tiếp theo. Xoá một mục trước đó có thể đẩy một bản ghi chưa thấy vào phần tiền tố đã bị bỏ qua.

Những ví dụ này mô tả thay đổi vị trí, chứ không phải lỗi trong một API cụ thể. Phân trang offset vẫn hữu ích cho một danh sách quản trị nhỏ, tương đối ổn định nơi người dùng coi trọng điều hướng được đánh số. Ngữ nghĩa LIMIT và OFFSET cũng giải thích vì sao offset sâu có thể đắt đỏ: các hàng bị bỏ qua vẫn yêu cầu công việc phía server. Hãy đo lường truy vấn đã lọc thực tế của bạn trước khi đặt một giới hạn điều hướng.

Nơi Con trỏ Keyset hữu ích và nơi chúng dừng lại

Phân trang keyset có thể tiếp tục sau bộ giá trị sắp xếp cuối cùng đã quan sát thay vì đếm lại các vị trí trước đó. Với một index và kế hoạch truy vấn phù hợp, điều đó tránh được cùng một kiểu công việc bỏ qua như một offset sâu. Nó cũng tránh được một số dịch chuyển vị trí do các bản ghi được chèn trước ranh giới. Lợi ích thuộc về phần triển khai, chứ không phải về định dạng token.

Các khóa sắp xếp có thể thay đổi vẫn là một vấn đề. Nếu một mục thay đổi điểm xếp hạng sau khi bạn đã đi qua vị trí ban đầu của nó, nó có thể di chuyển vào hoặc ra khỏi vùng chưa được truy cập. Một thao tác xóa có thể làm biến mất bản ghi ở ranh giới. Một dịch vụ đúng đắn phải định nghĩa cách token của nó hoạt động trong các trường hợp đó. Đối với một lượt xuất yêu cầu tập thành viên lịch sử chính xác, hãy yêu cầu một snapshot hoặc một ranh giới nhất quán rõ ràng khác.

Đọc Hợp đồng Tiếp tục với tư cách Người tiêu thụ

Hợp đồng phản hồi quyết định khi nào người tiêu thụ dừng lại. Một dịch vụ có thể trả về một next token chuyên biệt, một next link, hoặc thông tin trang có cấu trúc. Đừng suy luận việc hoàn tất chỉ dựa trên một trang ngắn trừ khi API định nghĩa rõ ràng hành vi đó. Giữ nguyên token từng byte một, bao gồm cả mã hóa của chúng, và đừng tự tạo next token từ các ID bản ghi hiển thị.

Mô hình kết nối GraphQL tách riêng các cạnh bản ghi, con trỏ và thông tin trang. Các tham số tiến và lùi của nó minh họa rằng điều hướng bằng con trỏ có thể hỗ trợ cả hai hướng. Hỗ trợ đó không có nghĩa là có sẵn các bước nhảy số trang tùy ý. Hãy thiết kế giao diện xoay quanh các thao tác mà dịch vụ thực tế cung cấp, bao gồm hết hạn token và mọi hạn chế trong việc thay đổi bộ lọc.

Ghi bền Bản ghi Trước khi Tiến điểm Checkpoint

Một checkpoint chỉ hữu ích khi nó tương ứng với đầu ra bền vững. Hãy lưu trang hiện tại và nguồn gốc của nó trước khi đánh dấu con trỏ tiếp theo là đã cam kết. Nếu không, một tiến trình dừng lại giữa các thao tác đó có thể tiếp tục vượt qua những bản ghi chưa bao giờ được lưu. Hãy coi checkpoint và ranh giới đầu ra là một vấn đề nhất quán ở cấp ứng dụng.

Một phong bì bản ghi thực tiễn chứa truy vấn nguồn, danh tính tập hợp, yêu cầu sắp xếp, thời gian thu nhận, danh tính bản ghi và trạng thái tiếp tục. Giữ thông tin xác thực bên ngoài phong bì đó. Khi một token hết hạn, hãy giữ lại đầu ra đã hoàn tất và làm theo lộ trình khởi động lại được tài liệu hóa. Khử trùng lặp bằng danh tính bản ghi ổn định có thể bảo vệ đích đến khỏi việc quan sát lặp lại, nhưng không thể khôi phục một mục chưa bao giờ được quan sát.

Áp dụng Mô hình vào Phân trang Trình duyệt

Phân trang trình duyệt yêu cầu khám phá cơ chế tiếp tục thực sự đằng sau giao diện. Một điều khiển đánh số có thể thay đổi URL, gửi biểu mẫu, cập nhật một yêu cầu JSON hoặc nối thêm bản ghi vào DOM. Một nút Next trông giống hệt có thể đại diện cho một cơ chế khác trên một trang web khác. Hãy xác định hành động nào thay đổi tập bản ghi nền tảng trước khi tự động hóa trang.

Trình duyệt Tác tử Scrapeless cung cấp lớp trình duyệt khi điều hướng yêu cầu các điều khiển đã render. Nó không chuyển đổi một trang web dựa trên offset thành một snapshot API. Các mẫu thu nhận phân trang bao gồm các trang đánh số, liên kết tiếp theo và cuộn. Giữ trạng thái điều hướng nguồn tách biệt với checkpoint đích của bạn, đặc biệt khi trình duyệt hiển thị các bản ghi đã được thu thập.

Tách Biên Hoàn tất Trang khỏi Biên Hoàn tất Thu thập

Một trang đã hoàn tất là bằng chứng về một phản hồi, trong khi một tập hợp đã hoàn tất là một tuyên bố về hợp đồng duyệt. Một vùng DOM trống có thể có nghĩa là việc tải chưa hoàn tất, bộ lọc đã thay đổi hoặc nguồn thực sự không có bản ghi. Hãy xác nhận danh tính trang dự kiến và vùng chứa tập hợp trước khi coi sự vắng mặt là điểm kết thúc.

Đối với một lượt chạy trình duyệt, hãy ghi lại bộ lọc và thứ tự sắp xếp đang hoạt động cùng với các danh tính bản ghi cuối cùng quan sát được. Đối với một lượt chạy API, hãy lưu trạng thái tiếp tục kết thúc được tài liệu hóa. Nếu nguồn cung cấp tổng số lượng, hãy xác định xem nó có thuộc cùng snapshot và bộ lọc hay không. Một con số tổng quát thay đổi là ngữ cảnh hữu ích, nhưng nó không nên ghi đè một tín hiệu tiếp tục có tính xác thực.

Chọn theo Điều hướng và Yêu cầu Nhất quán

Chọn phân trang offset khi người dùng cần truy cập trực tiếp bằng số trang và tập hợp đủ giới hạn để hỗ trợ điều đó. Chọn một thiết kế con trỏ keyset được tài liệu hóa khi duyệt tuần tự qua một tập hợp lớn, thay đổi là khối lượng công việc chính. Nếu bạn tiêu thụ một dịch vụ hiện có, hãy thích ứng với hợp đồng của nó thay vì dán nhãn lại cơ chế của nó để khớp với kiến trúc ưa thích.

Đối với một API mới, hãy ghi rõ liệu các bản ghi có thể thay đổi vị trí sắp xếp hay không, liệu các con trỏ có hết hạn hay không, và liệu người đọc có cần tính nhất quán lịch sử hay không. Một giao diện duyệt và một lượt xuất phục vụ kế toán có thể cần các endpoint khác nhau. Do đó, phân trang offset so với con trỏ là một quyết định sản phẩm cũng như quyết định truy vấn: câu trả lời đúng phụ thuộc vào thao tác người dùng mà bạn cam kết.

Xác nhận một Lượt duyệt trước khi Mở rộng Quy mô

Một bài kiểm tra lượt duyệt nên xác minh thành viên và ranh giới, không chỉ các phản hồi thành công. Hãy sử dụng một bộ dữ liệu kiểm soát với các giá trị sắp xếp trùng nhau, trường tùy chọn bị thiếu và các chỉnh sửa giữa các yêu cầu. So sánh các danh tính thu thập được với tập dự kiến. Bao gồm một lượt khởi động lại sau một lần ghi đầu ra để hành vi checkpoint được thực thi thay vì chỉ được mô tả.

Đo độ trễ trang ở các độ sâu khác nhau, sự trùng lặp đầu ra, các danh tính bị thiếu và chi phí lưu trữ checkpoint. Giữ ví dụ giả định tách biệt khỏi số đo trong môi trường sản xuất. Khi việc thu nhận qua trình duyệt là một phần của thiết kế, hãy tham khảo mô hình khả năng của Agent Browser và so sánh cơ sở sử dụng liên quan trên bảng giá Scrapeless. Nhiều worker hơn không thể sửa một thứ tự mơ hồ hoặc một quy tắc hoàn tất bị hỏng.

Kết luận

Phân trang theo offset phù hợp với truy cập trực tiếp đến các vị trí; phân trang theo cursor phù hợp với việc tiếp tục duyệt qua một tập hợp. Hãy bắt đầu bằng cách cố định thứ tự và xác định yêu cầu về tính nhất quán. Sau đó kiểm tra cách chèn, xóa, hết hạn token và ghi bị gián đoạn ảnh hưởng đến tập bản ghi đã thu thập. Một điểm kiểm tra bền vững và tín hiệu hoàn thành được ghi rõ ràng quan trọng hơn giao diện điều khiển phân trang trông như thế nào.

Tài liệu tham khảo

• Scrapeless Agent Browser: khả năng và phạm vi
• Tổng quan sản phẩm Scrapeless Agent Browser
• Mẫu phân trang cho việc thu thập dữ liệu web