Hải Ninh Vũ

Bạn vẫn nên dùng cache để cache kết quả product recommend lại. Vì một user truy cập vào trang web rất nhiều lần mình cần hiển thị product recommend lên cho họ, với mỗi lần như vậy mà mình cần tính lại số point để tìm ra list product recommend thì xử lý sẽ rất chậm.

Mình ko rõ thuật toán tính point liên quan đến những thông tin gì, mình tạm chia phần thông tin tính point ra làm 3 thành phần:

• common attribute point, điểm các thành phần ổn định, ko phụ thuộc vào thông tin user. VD: favourite point - mức độ phổ biến product, được nhiều người quan tâm; quality point - đánh giá của user về chất lượng sản phẩm ....

• special attribute point, điểm cần một số điều kiện nhất định. VD: gender, age, ... product dùng cho nam, độ tuổi 20-30, hay đặt mua ....

• personal attribute point, VD: location như bạn đề cập đến.

Từ 3 ý trên mình sẽ cần build data structure cho product để tính point như sau:

product:

• id: 1
• common_point: 100 (điểm trung bình các thành phần common)
• favourite_point: 20
• quality_point: 5 .....
• specials: { [tag: male, point : 10], [tag: 20-30, point: 30] }

Bạn có thể thấy ý thứ nhất common attribute point mình có thể chỉ cần quan tâm đến 1 chỉ số duy nhất là common_point.

Tiếp theo đến các point cần có điều kiện mới được tính toán ra, chúng ta build ra các group user thoả mãn các điều kiện và thực hiện tính toán point cho từng nhóm này. VD:

groups: [male, 20-30] products: [id: 1, point: 423], [id: 2, point: 420] ....

thông tin về nhóm user này được cache để có thể giảm thời gian tính toán.

Với một user, mình xác định xem user đó thuộc nhóm user nào từ đó có thể lấy ra list product recommend của user đấy một cách nhanh chóng -> thoả mãn được yêu cầu về thuộc tính số 2.

Tiếp theo phần tính point cuối cùng cần match thông tin user vs sản phẩm. VD: user A thuộc groups [male, 20-30] products: [id: 1, point: 423], [id: 2, point: 420] ....

A có location (100, 100) -> ta cần tính toán điểm cho A ra được list product recommend của A. user: A (100, 100) products: [id: 2, point: 1000] ....

-> từ đây mình có thể get được list product recommend giành cho A (100, 100) nếu A chưa thay đổi toạ độ.

Khi áp dụng có thể product của bạn còn chia thành category, sub - category nữa, trong TH đấy, bạn cần tổ chức data cho phù hợp hơn. Theo mình thì việc sử dụng cache trong bài toán này là cần thiết, bạn có thể tham khảo ý trên.

Mongodb là một Nosql, được thiết kế dựa trên document. Bạn có thể hiểu nó là dạng key - value, key là giá trị để xác định đối tượng, value là các document json. Tốc độ bạn quan tâm ở trên mình tạm phân tích gồm 3 phần

• ghi dữ liệu: cấu trúc data trên mongodb là đơn giản trên Sql như Mysql nên tốc độ ghi dữ liệu của mongodb nhanh hơn Mysql, cùng cấu hình thì có thể ước lượng nhanh hơn 2x. Tại sao nhanh hơn ko nhiều vì Mongodb cũng hỗ trợ secondary index như mysql, khi insert vào thêm bản ghi mới, chi phí bỏ vào cho index của 2 bên chênh nhau ko nhiều. Mongodb do ko có schema nên chi phí insert record ít hơn, Mysql bạn có thể hiểu đó là chi phí convert data.
• đọc dữ liệu: do ko có schema, việc query để select dữ liệu có điều kiện, điều kiện này ko được đánh index chậm hơn so vs Mysql. Bạn có thể hình dung mất thêm chi phí cast object nữa. So vs Mysql thì đọc sẽ bị chậm hơn 50%.
• update dữ liệu: do cấu trúc data chỉ đơn giản là các con trỏ, trỏ đến các document, khi update data mongodb sẽ nhanh hơn rất nhiều so vs Mysql. Tuỳ tình huống thông tin mình update có liên quan đến index hay ko mà có sự khác nhau, bạn có thể hình dung là update nhanh hơn 10x so vs Mysql.

Tại sao ở trên mình chỉ phân tích ở khía cạnh data structure giữa Mongodb và Mysql, vì 2 database này tương đồng nhau về thao tác đọc ghi đĩa cứng, quản lý index, sự khác biệt giữa 2 database trên là ko nhiều. Điểm khác biệt lớn nhất là một bên yêu cầu schema cho data được xác định rõ ràng, một bên thì data linh hoạt.

Để đáp ứng cho 10k users thì vấn đề performance của bạn sẽ xoay quanh việc bạn thiết kế index cho database như thế nào. Các query của bạn có sử dụng được index để tăng tốc độ truy vấn hay không.