Asked Jul 26th, 2019 8:45 AM 243 0 2
  • 243 0 2
+2

Thiết kế Redis Data sao cho phù hợp

Share
  • 243 0 2

Nhờ mọi người giúp mình vấn đề bên dưới
Chẳng hạn giờ hệ thống của mình có 1 bảng products khoảng > 1tr record. Mình muốn làm chức năng show recommend products cho người dùng. Có thuật toán tính point cho mỗi product (có join đến nhiều bảng liên quan để lấy thông tin). Nhưng point này lại có 1 yếu tố distance liên quan đến location người dùng gửi lên. => Mỗi người dùng sẽ có 1 list product recommend riêng . Mình đang k biết nên lưu data vào redis ntn cho phù hợp . Nhờ mng có kinh nghiệm hướng cho mình follow . Xin cảm ơn mng.

2 ANSWERS


Answered Jul 27th, 2019 12:18 PM
Accepted
0

Bạn có thể nói rõ hơn về cách tính point của bạn đc không? Thuật toán tính point cho từng products của bạn có mất thời gian để chạy không ? Recommend thì mình nghĩ k nên cache lại. Vì point của từng product hầu như là cập nhật liên tục và có khi với mỗi user thì product lại có points khác nhau.
Kiểu như product 1 với user A là 10p nhưng user B lại là 15p 😄

Share
Aug 16th, 2019 4:00 AM
Aug 16th, 2019 4:01 AM
Answered Aug 16th, 2019 4:01 AM
0

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.

Share
Viblo
Let's register a Viblo Account to get more interesting posts.