Hỏi về cách thiết kế database cho NoSQL khi tiến hành cập nhật object

[LuuPhat (Phat)]

Ví dụ mình có 2 table chẳng hạn :
_ Table Users lưu thông tin user gồm :
id, username, fullname, avatar (avatar này là 1 object gồm : id_file, path_file, name_file,…)

_ Table Files lưu thông tin các file đã upload :
id , file_name, path_file, user (user nào đã upload file này)

Note: “user” bên table Files đều lưu dưới dạng object gồm : id user, username, avatar,… (như bên table Users)

–> Khi mà table Files mình số lượng record đang quá lớn (1 triệu chẳng hạn). Vậy khi mình tiến hành update avatar hay username, fullname gì đó bên table Users thì không lẽ mình cần cập nhật lại cả triệu record bên table Files hay sao ạ. Nếu vậy thì khá mất thời gian vì update nó khá lâu.

Lý do mà table Files mình không lưu id_user cho thuộc tính “user” là khi mà mình load các files lên, nếu muốn hiện avatar hay username thì mình phải truy vấn cả triệu lần bên table User để lấy mấy giá trị kia (vì với mỗi dòng trong table Files mình lấy id_user rồi query bên table User để lấy)

Vậy cho mình hỏi có cách nào hay thiết kế nào để tối ưu 2 vấn đề trên không ạ ?
Note NoSQL hiện tại mình đang dùng là : DynamoDB

[catlord]

@LuuPhat

Lý do mà table Files mình không lưu id_user cho thuộc tính “user” là khi mà mình load các files lên, nếu muốn hiện avatar hay username thì mình phải truy vấn cả triệu lần bên table User để lấy mấy giá trị kia (vì với mỗi dòng trong table Files mình lấy id_user rồi query bên table User để lấy)

cách này đúng rồi. còn vì sao scan full table thì nên xem lại index

[LuuPhat (Phat)]

cách nào á bạn, cách lưu id_user bên table Files hả bạn.
Tại nếu mình lưu id_user thì với mỗi file bên table Files mình cần truy vấn bên table User để lấy avatar, fullname, mới dc. Vậy nếu mình lấy 100 file thì mình cần truy vấn 100 lần bên table User lận á

[catlord]

đừng bị premature optimization. lấy user_id nhưng với indexing cơ bản là giải quyết được vấn đề về tốc độ. data vài trăm gig có indexing lấy ra còn nhanh hơn chớp mắt.