Khi nào nên sử dụng nhiều bảng trong DynamoDB?

Các thực tiễn tốt nhất của DyanmoDB cho thấy rõ rằng:

Bạn nên duy trì càng ít bảng càng tốt trong ứng dụng DynamoDB. Hầu hết các ứng dụng được thiết kế tốt chỉ yêu cầu một bảng.

Tôi thấy thật thú vị khi mỗi bài hướng dẫn tôi từng thấy đối phó với DyanmoDB đều có thiết kế nhiều bảng.

Nhưng điều này có ý nghĩa gì trong thực tế?

Hãy xem xét một ứng dụng đơn giản với ba thực thể chính: Người dùng, Dự án và Tài liệu. Người dùng sở hữu nhiều dự án và Dự án có thể có nhiều Tài liệu. Chúng tôi thường phải truy vấn các Dự án cho Người dùng và trên Tài liệu cho Dự án. Đọc số lượng lớn hơn viết bởi một lề đáng kể.

Thiết kế bảng hướng dẫn ngây thơ sẽ sử dụng ba bảng:

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

Chúng tôi có thể dễ dàng sụp đổ Projectvà Documentvào một Documentsbảng:

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

Nhưng tại sao dừng lại ở đó? Tại sao không một bảng để thống trị tất cả? Vì đó Userlà gốc rễ của mọi thứ ...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

Sau đó, chúng tôi sẽ có một Chỉ số toàn cầu về, ví dụ, emaillĩnh vực tra cứu hồ sơ người dùng và một document-idlĩnh vực khác trên lĩnh vực tra cứu tài liệu trực tiếp.

Đó có phải là cách nó hoạt động? Có hợp pháp khi ném các loại dữ liệu khác nhau như vậy vào cùng một bảng không? Hoặc là thiết kế thứ hai, hai bàn là một cách tiếp cận tốt hơn?

Tại điểm nào sẽ là chính xác để thêm một bảng thứ hai?

Vâng, nó là hợp pháp để làm những gì bạn đang nói. Cả hai đều thực sự. Có một số biến mà bạn không có ở đây và có thể giúp hướng dẫn cách thực hiện mô hình dữ liệu.

1. Bạn đang tìm kiếm loại quy mô nào với ứng dụng và mô hình dữ liệu này?
2. Trong số các mẫu truy cập của ứng dụng, tỷ lệ đọc giữa các mẫu đó là bao nhiêu. Có nghĩa là cái nào được đánh nhiều nhất so với cái khác.
3. Trong số các mẫu truy cập bạn liệt kê, chúng được thực hiện bao nhiêu lần mỗi giây?

Ví dụ: nếu 80% tất cả các lần đọc là để tìm người dùng trong một dự án và điều đó cần xảy ra 30.000 / giây, nhưng trong ứng dụng của bạn, không có nhiều người sẽ tiến xa hơn và tìm hiểu các tài liệu cho các dự án, sau đó là 20% tổng số lần đọc và chỉ có thể là 2000 lần đọc / giây. Cái đầu tiên đó là "đường dẫn nóng" của ứng dụng của bạn và nên được tối ưu hóa cho.

Cũng nghĩ về nó theo cách này, với cơ sở dữ liệu không liên quan như DynamoDB, bạn có thể tối ưu hóa cách ứng dụng của bạn sử dụng và truy cập dữ liệu và không giống như cơ sở dữ liệu quan hệ nơi bạn phải lo lắng rất nhiều về cách lưu trữ trong cơ sở dữ liệu.