Đây là một vấn đề mà không có giải pháp hoàn toàn thỏa đáng vì bạn đang cố gắng kết hợp các yêu cầu về cơ bản không tương thích:
-
Chỉ gửi lượng dữ liệu cần thiết cho khách hàng theo yêu cầu, tức là bạn không thể tải xuống toàn bộ tập dữ liệu, sau đó phân trang phía máy khách.
-
Giảm thiểu lượng trạng thái của mỗi máy khách mà máy chủ phải theo dõi, để có khả năng mở rộng với số lượng lớn máy khách.
-
Duy trì trạng thái khác nhau cho từng khách hàng
Đây là một loại tình huống "chọn một trong hai". Bạn phải thỏa hiệp; chấp nhận rằng bạn không thể giữ chính xác trạng thái phân trang của từng máy khách, chấp nhận rằng bạn phải tải xuống bộ dữ liệu lớn cho máy khách hoặc chấp nhận rằng bạn phải sử dụng một lượng lớn tài nguyên máy chủ để duy trì trạng thái máy khách.
Có những biến thể trong những biến thể kết hợp các thỏa hiệp khác nhau, nhưng đó là tất cả những gì tổng hợp lại.
Ví dụ:một số người sẽ gửi cho khách hàng một số dữ liệu bổ sung, đủ để đáp ứng hầu hết các yêu cầu của khách hàng. Nếu khách hàng vượt quá mức đó, thì nó sẽ bị hỏng phân trang.
Một số hệ thống sẽ lưu trạng thái của ứng dụng khách trong bộ nhớ cache trong một thời gian ngắn (với các bảng, tệp tạm thời hoặc bất kỳ thứ gì được mở khóa tồn tại trong thời gian ngắn), nhưng nó sẽ hết hạn nhanh chóng, vì vậy nếu ứng dụng không liên tục yêu cầu dữ liệu mới thì nó sẽ bị hỏng phân trang.
Vv.
Xem thêm:
- Làm cách nào để cung cấp ứng dụng khách API với 1.000.000 kết quả cơ sở dữ liệu?
- Sử dụng "Con trỏ" để phân trang trong PostgreSQL
- Lặp lại trên db postgres bên ngoài lớn, thao tác hàng, ghi đầu ra vào đường dẫn postgres db
- tối ưu hóa hiệu suất bù đắp / giới hạn
- Nếu số lượng PostgreSQL (*) luôn chậm, làm cách nào để phân trang các truy vấn phức tạp?
- Cách trả lại từng hàng mẫu từ cơ sở dữ liệu
Tôi có thể sẽ triển khai một giải pháp kết hợp của một số dạng, như:
-
Sử dụng con trỏ, đọc và gửi ngay phần đầu tiên của dữ liệu đến máy khách.
-
Tìm nạp đủ dữ liệu bổ sung từ con trỏ ngay lập tức để đáp ứng 99% yêu cầu của khách hàng. Lưu trữ nó vào một bộ nhớ cache nhanh, không an toàn như memcached, Redis, BigMemory, EHCache, bất kỳ thứ gì dưới một khóa sẽ cho phép tôi truy xuất nó cho các yêu cầu sau của cùng một ứng dụng khách. Sau đó, đóng con trỏ để giải phóng tài nguyên DB.
-
Làm hết hạn bộ nhớ đệm trên cơ sở ít được sử dụng gần đây nhất, vì vậy nếu máy khách không tiếp tục đọc đủ nhanh, họ phải lấy một bộ dữ liệu mới từ DB và phân trang sẽ thay đổi.
-
Nếu khách hàng muốn có nhiều kết quả hơn so với đại đa số các đồng nghiệp của nó, việc phân trang sẽ thay đổi vào một thời điểm nào đó khi bạn chuyển sang đọc trực tiếp từ DB thay vì bộ nhớ cache hoặc tạo một tập dữ liệu mới lớn hơn được lưu trong bộ nhớ cache.
Bằng cách đó, hầu hết các máy khách sẽ không nhận thấy các vấn đề về phân trang và bạn không phải gửi một lượng lớn dữ liệu cho hầu hết các máy khách, nhưng bạn sẽ không làm tan máy chủ DB của mình. Tuy nhiên, bạn cần một bộ nhớ cache boofy lớn để giải quyết vấn đề này. Tính thực tế của nó phụ thuộc vào việc liệu khách hàng của bạn có thể đối phó với việc phá vỡ phân trang hay không - nếu chỉ đơn giản là không thể chấp nhận việc phá vỡ phân trang, thì bạn đang gặp khó khăn khi thực hiện nó ở phía DB với con trỏ, bảng tạm, đối phó với toàn bộ kết quả được đặt ở yêu cầu đầu tiên, v.v. Nó cũng phụ thuộc vào kích thước tập dữ liệu và lượng dữ liệu mà mỗi khách hàng thường yêu cầu.