Khi bảng dữ liệu to lên cỡ chục triệu đến hàng trăm triệu record, nếu vẫn dùng OFFSET/LIMIT truyền thống thì càng bấm sang trang sâu (deep pagination) query càng "lết", chưa kể quả query COUNT(*) để tính tổng số trang cũng thành nút thắt cổ chai luôn. Với case này, bạn ưu tiên chuyển hẳn sang xài Cursor-based (Keyset Pagination), hay có trick nào tối ưu ở tầng DB/Cache mà vẫn giữ được UX cho user (kiểu user vẫn muốn nhảy phát sang trang n) không
Sẵn tiện cho mình hỏi chút. Giả sử hệ thống đang xài chung Group ID để share tải xử lý luồng log, mà đùng một cái lưu lượng tăng vọt. Mình không thể cắm thêm consumer vì đã bằng số partition rồi (scale thêm sẽ bị idle), cũng không thể tăng partition ngay lập tức. Trong case cháy nhà như vậy, bạn thường tuning tham số nào hay có trick gì ở tầng app để clear lượng message lag này nhanh nhất không
Bài viết bóc tách "ruột gan" HashMap cực kỳ chất lượng! Làm Java thì kiểu gì cũng phải hiểu sâu mấy vụ collision với rehashing này, không chỉ để đối phó lúc đi phỏng vấn mà lúc tuning performance hệ thống cũng rất cần. Cảm ơn tác giả, bài viết chất lượng
Bài viết cuốn thực sự. Đợt trước lúc tích hợp Redis vào project Spring Boot để làm quả caching với quản lý session, mình cũng loay hoay phân vân mãi vụ cấu hình làm sao để vẹn cả đôi đường: vừa giữ được tốc độ bàn thờ mà lỡ có sự cố cũng không lo bay màu data.
THẢO LUẬN
Bài hay, dễ hiểu, chi tiết
Trước giờ chỉ học thuộc lí thuyết như học vẹt, nay mới ngấm về cách sử dụng
Quá ok anh ơiii
Xịn xò thật chứ
Bài viết hayy, chi tiết
Cần thêm các bài viết về System Design, Clean Architecture
NGUYỄN HUY HOÀNG Software Engineer
📞 Phone: 0941 280 073
📧 Email: hhoang02052004@gmail.com
Proxy có nghe nhiều nhưng nay mới thực sự hiểu, thanks tác giả
Khi bảng dữ liệu to lên cỡ chục triệu đến hàng trăm triệu record, nếu vẫn dùng OFFSET/LIMIT truyền thống thì càng bấm sang trang sâu (deep pagination) query càng "lết", chưa kể quả query COUNT(*) để tính tổng số trang cũng thành nút thắt cổ chai luôn. Với case này, bạn ưu tiên chuyển hẳn sang xài Cursor-based (Keyset Pagination), hay có trick nào tối ưu ở tầng DB/Cache mà vẫn giữ được UX cho user (kiểu user vẫn muốn nhảy phát sang trang n) không
Cách viết bài rất dễ hiểu, đọc tới đâu thấm tới đó, cảm ơn tg
Hayy, cảm ơn tác giả vì chia sẻ rất thiết thực
Đúng lúc đang ôn luyện thì đọc được bài này, cách viết rất dễ hiểu, đúng cái mình cần thanks tác giả
Chi tiết quá, thanks tác giả
Cách viết hay, dễ hiểu
Sẵn tiện cho mình hỏi chút. Giả sử hệ thống đang xài chung Group ID để share tải xử lý luồng log, mà đùng một cái lưu lượng tăng vọt. Mình không thể cắm thêm consumer vì đã bằng số partition rồi (scale thêm sẽ bị idle), cũng không thể tăng partition ngay lập tức. Trong case cháy nhà như vậy, bạn thường tuning tham số nào hay có trick gì ở tầng app để clear lượng message lag này nhanh nhất không
Bài viết bóc tách "ruột gan" HashMap cực kỳ chất lượng! Làm Java thì kiểu gì cũng phải hiểu sâu mấy vụ collision với rehashing này, không chỉ để đối phó lúc đi phỏng vấn mà lúc tuning performance hệ thống cũng rất cần. Cảm ơn tác giả, bài viết chất lượng
Bài viết cuốn thực sự. Đợt trước lúc tích hợp Redis vào project Spring Boot để làm quả caching với quản lý session, mình cũng loay hoay phân vân mãi vụ cấu hình làm sao để vẹn cả đôi đường: vừa giữ được tốc độ bàn thờ mà lỡ có sự cố cũng không lo bay màu data.
Thêm nhiều bài viết về System Design đi tác giả ơi, cách viết bài rất hay và chỉn chu
Bài viết hay, đúng thực tế mình đang gặp trong quá trình làm việc, căn bản là hay vị vội nên cứ có yêu cầu là lao vào làm
Hay quá bạn ơi, hóng phân tích thêm các design pattern khác