Kiến trúc truyền thống trên AWS, cụ thể là cách thức các ứng dụng truyền thống sử dụng các thành phần như RDBMS (Relational Database Management System), Elastic Load Balancer, và EC2 Instances. Đây là một phần rất quan trọng trong các khái niệm về AWS mà bạn cần hiểu rõ khi chuẩn bị cho kỳ thi AWS Associate Developer Certification.

Hãy cùng đi qua từng thành phần và phân tích chi tiết cách chúng hoạt động trên AWS:

Clients (Khách hàng/Người dùng) Giải thích: Đây là các người dùng hoặc các thiết bị bên ngoài (client) thực hiện các yêu cầu đến ứng dụng của bạn. Ví dụ: Khi bạn mở một trang web hoặc ứng dụng trên điện thoại và yêu cầu thông tin, bạn chính là một client gửi request đến hệ thống.
Elastic Load Balancer (ELB) Giải thích: Elastic Load Balancer là một dịch vụ của AWS giúp phân phối đều lưu lượng truy cập đến nhiều EC2 Instances. Điều này đảm bảo rằng không có instance nào bị quá tải và giúp tăng tính sẵn sàng của hệ thống. Ví dụ: Giả sử bạn có một ứng dụng web có nhiều người dùng truy cập cùng lúc. ELB sẽ điều phối các yêu cầu này đến các máy chủ (EC2 Instances) khác nhau, giúp tránh tình trạng một máy chủ bị quá tải.
Application Layer (Tầng Ứng Dụng) Giải thích: Đây là nơi xử lý các yêu cầu từ client. Các máy chủ trong Application Layer thường là các EC2 Instances (máy ảo) chạy ứng dụng của bạn. AWS có cơ chế Auto Scaling để tự động tăng hoặc giảm số lượng EC2 Instances dựa trên nhu cầu thực tế. Ví dụ: Khi số lượng người dùng truy cập vào ứng dụng tăng đột biến (ví dụ vào giờ cao điểm), tính năng Auto Scaling sẽ tự động khởi tạo thêm các EC2 Instances để phục vụ tốt hơn. Ngược lại, khi lượng truy cập giảm, các instance không cần thiết sẽ được tự động tắt để tiết kiệm chi phí.
EC2 Instances (Amazon Elastic Compute Cloud) Giải thích: EC2 là dịch vụ cung cấp máy chủ ảo trên AWS. Các ứng dụng của bạn sẽ chạy trên các máy ảo này. Bạn có thể cấu hình EC2 theo nhu cầu như số lượng CPU, bộ nhớ (RAM), dung lượng ổ cứng và lựa chọn hệ điều hành. Ví dụ: Bạn cần một máy chủ để chạy một ứng dụng web bằng Node.js. Bạn có thể khởi tạo một EC2 Instance chạy hệ điều hành Linux, cài đặt Node.js, và triển khai ứng dụng của bạn lên đó.
Auto Scaling Group Giải thích: Auto Scaling Group là một nhóm các EC2 Instances có khả năng tự động thay đổi số lượng máy chủ ảo dựa trên tải hệ thống. Điều này đảm bảo hệ thống của bạn luôn có đủ tài nguyên để xử lý yêu cầu của khách hàng nhưng cũng không tiêu tốn quá nhiều chi phí khi nhu cầu giảm. Ví dụ: Vào các dịp mua sắm lớn như Black Friday, lưu lượng truy cập vào trang web của bạn tăng đột ngột. Auto Scaling sẽ tự động thêm các EC2 Instances để đáp ứng nhu cầu, và sau khi dịp này kết thúc, nó sẽ giảm số lượng instance để tiết kiệm chi phí.
Database Layer (Tầng Cơ Sở Dữ Liệu) Giải thích: Tầng cơ sở dữ liệu thường sử dụng Amazon RDS (Relational Database Service), đây là dịch vụ cơ sở dữ liệu quan hệ (RDBMS) của AWS. Các hệ quản trị cơ sở dữ liệu phổ biến như MySQL, PostgreSQL, và Oracle đều được hỗ trợ. Ví dụ: Bạn có một ứng dụng thương mại điện tử, và mọi thông tin về sản phẩm, đơn hàng, và người dùng đều được lưu trữ trong một cơ sở dữ liệu MySQL trên Amazon RDS.
Vertical Scaling (Mở rộng theo chiều dọc) Giải thích: Vertical Scaling là quá trình tăng cường tài nguyên cho một máy chủ duy nhất, chẳng hạn như thêm CPU, RAM, hoặc ổ cứng để cải thiện hiệu suất. Ví dụ: Nếu một EC2 Instance của bạn không đủ mạnh để xử lý yêu cầu, bạn có thể nâng cấp nó từ một instance nhỏ lên một instance lớn hơn với nhiều CPU và RAM hơn.
Horizontal Scaling (Mở rộng theo chiều ngang) Giải thích: Horizontal Scaling là quá trình tăng số lượng máy chủ để chia sẻ tải. Trên AWS, bạn có thể thêm nhiều EC2 Instances hoặc sử dụng các RDS Read Replicas để tăng khả năng xử lý yêu cầu. Ví dụ: Khi ứng dụng của bạn có quá nhiều người dùng truy cập, bạn có thể triển khai thêm các EC2 Instances để đảm bảo mỗi máy chủ chỉ xử lý một phần nhỏ của tổng số yêu cầu. Tóm lại: Kiến trúc truyền thống này tập trung vào việc sử dụng các dịch vụ như RDBMS, EC2, Elastic Load Balancer, và Auto Scaling để đảm bảo tính sẵn sàng, khả năng mở rộng, và hiệu suất cho các ứng dụng. Hiểu rõ cách hoạt động của các thành phần này là rất quan trọng trong việc chuẩn bị cho kỳ thi AWS Associate Developer Certification.

Bạn nên thử triển khai các thành phần này bằng cách:

Tạo và cấu hình một EC2 Instance trên AWS.
Thiết lập một Elastic Load Balancer.
Cấu hình Auto Scaling để mở rộng hoặc thu hẹp số lượng EC2 Instances tự động.
Tạo một RDS và kết nối ứng dụng của bạn với cơ sở dữ liệu này.

Amazon DynamoDB – một cơ sở dữ liệu NoSQL phổ biến trên AWS.

NoSQL databases are non-relational databases and are distributed
- Giải thích: NoSQL là loại cơ sở dữ liệu không tuân theo mô hình quan hệ (non-relational). Điều này có nghĩa là dữ liệu không được lưu trữ theo các bảng với hàng và cột như trong SQL. Thay vào đó, NoSQL lưu trữ dữ liệu dưới nhiều dạng khác nhau như dạng document (tài liệu), key-value (khóa-giá trị), column-family (cột nhóm) hoặc graph (đồ thị). NoSQL thường là các cơ sở dữ liệu phân tán. Điều này có nghĩa là dữ liệu được lưu trữ trên nhiều máy chủ khác nhau, giúp hệ thống có khả năng chịu tải cao và dễ dàng mở rộng quy mô.
- Ví dụ: Amazon DynamoDB là một cơ sở dữ liệu NoSQL phân tán theo dạng key-value. Nó tự động phân phối dữ liệu trên nhiều máy chủ để đảm bảo hiệu suất cao và khả năng mở rộng linh hoạt.
NoSQL databases include MongoDB, DynamoDB, …
- Giải thích: Một số cơ sở dữ liệu NoSQL phổ biến gồm MongoDB và Amazon DynamoDB. MongoDB sử dụng cấu trúc document-based, trong đó dữ liệu được lưu trữ dưới dạng các tài liệu JSON hoặc BSON. Amazon DynamoDB là dịch vụ NoSQL của AWS, sử dụng cấu trúc key-value để lưu trữ dữ liệu, rất phù hợp với các ứng dụng có khối lượng truy cập lớn và cần hiệu suất cao.
- Ví dụ: Nếu bạn đang xây dựng một ứng dụng mạng xã hội và muốn lưu trữ dữ liệu của hàng triệu người dùng, bạn có thể sử dụng DynamoDB để lưu trữ thông tin về tài khoản và bài đăng của người dùng.
NoSQL databases do not support query joins (or just limited support) Giải thích: Khác với cơ sở dữ liệu quan hệ (SQL), NoSQL không hỗ trợ hoặc chỉ hỗ trợ rất hạn chế khả năng join (kết nối dữ liệu giữa nhiều bảng). Điều này là do NoSQL thiết kế để giảm thiểu sự phức tạp trong việc liên kết dữ liệu giữa nhiều bảng, thay vào đó, mọi dữ liệu cần thiết cho một truy vấn thường được lưu trữ trong một hàng hoặc tài liệu duy nhất. Ví dụ: Trong một cơ sở dữ liệu SQL, bạn có thể cần thực hiện một join để kết hợp dữ liệu từ bảng Users và bảng Orders. Nhưng trong NoSQL, toàn bộ thông tin về người dùng và đơn hàng có thể được lưu trữ trong một tài liệu duy nhất, giúp giảm thiểu thời gian truy vấn và tăng hiệu suất.
All the data that is needed for a query is present in one row Giải thích: Một trong những đặc điểm chính của NoSQL là dữ liệu thường được thiết kế để lưu trữ toàn bộ thông tin cần thiết cho một truy vấn trong một hàng hoặc tài liệu duy nhất. Điều này giúp tối ưu hóa tốc độ truy vấn và giảm thiểu số lần truy cập vào cơ sở dữ liệu. Ví dụ: Trong DynamoDB, nếu bạn có một ứng dụng thương mại điện tử, thay vì lưu dữ liệu sản phẩm và dữ liệu người dùng ở hai bảng khác nhau như trong SQL, bạn có thể lưu trữ tất cả thông tin sản phẩm và khách hàng trong một hàng duy nhất của DynamoDB.
NoSQL databases don’t perform aggregations such as “SUM”, “AVG”, ... Giải thích: NoSQL không hỗ trợ tốt hoặc không hỗ trợ các phép tổng hợp như SUM (tổng), AVG (trung bình), COUNT, và các phép toán khác mà SQL thường hỗ trợ. Nếu cần tính toán các phép này, bạn có thể phải xử lý chúng trong ứng dụng của mình, thay vì yêu cầu cơ sở dữ liệu xử lý. Ví dụ: Trong DynamoDB, nếu bạn muốn tính tổng giá trị đơn hàng của một người dùng, bạn có thể phải lấy tất cả các bản ghi đơn hàng và tính tổng trong mã nguồn của ứng dụng thay vì dựa vào cơ sở dữ liệu như trong SQL.
NoSQL databases scale horizontally Giải thích: Horizontal scaling có nghĩa là mở rộng bằng cách thêm nhiều máy chủ vào hệ thống để xử lý nhiều yêu cầu hơn. Điều này khác với Vertical scaling (mở rộng bằng cách nâng cấp phần cứng cho máy chủ hiện tại). NoSQL được thiết kế để dễ dàng mở rộng theo chiều ngang, cho phép bạn thêm nhiều máy chủ để xử lý khối lượng công việc lớn hơn mà không gặp vấn đề về hiệu suất. Ví dụ: Với DynamoDB, khi số lượng người dùng truy cập vào ứng dụng tăng lên, hệ thống sẽ tự động thêm các tài nguyên máy chủ mới để đáp ứng nhu cầu mà không cần can thiệp thủ công.
There’s no “right or wrong” for NoSQL vs SQL, they just require to model the data differently and think about user queries differently
- Giải thích: Việc chọn SQL hay NoSQL không có đúng hay sai, mà phụ thuộc vào yêu cầu cụ thể của ứng dụng. Nếu ứng dụng của bạn cần xử lý các truy vấn phức tạp với nhiều phép tính toán và cần đảm bảo tính toàn vẹn dữ liệu cao, SQL có thể là lựa chọn tốt hơn. Nếu ứng dụng của bạn yêu cầu mở rộng quy mô nhanh chóng và không cần các phép toán phức tạp, NoSQL sẽ phù hợp hơn.
- Ví dụ: Một ứng dụng mạng xã hội như Facebook có thể sử dụng NoSQL để lưu trữ các bài viết và thông tin người dùng vì yêu cầu về mở rộng rất cao. Trong khi đó, một ứng dụng tài chính có thể cần SQL để đảm bảo tính toàn vẹn dữ liệu và thực hiện các phép toán phức tạp.

Kết luận: Khi làm việc với AWS, việc hiểu rõ sự khác biệt giữa NoSQL và SQL sẽ giúp bạn lựa chọn đúng công nghệ cho ứng dụng của mình. Amazon DynamoDB là một trong những dịch vụ NoSQL phổ biến trên AWS, trong khi Amazon RDS cung cấp các dịch vụ SQL. Tùy vào nhu cầu của ứng dụng mà bạn có thể chọn dịch vụ phù hợp nhất để đảm bảo hiệu suất, độ sẵn sàng và chi phí.

Amazon DynamoDB là gì? DynamoDB là dịch vụ NoSQL được quản lý hoàn toàn bởi AWS, cung cấp khả năng lưu trữ phân tán và tự động mở rộng quy mô. Nó được thiết kế để xử lý khối lượng công việc lớn và đáp ứng nhu cầu về hiệu suất cao, độ tin cậy, và tính sẵn sàng.

Fully managed, highly available with replication across multiple AZs (Hoàn toàn được quản lý và có tính sẵn sàng cao với việc sao chép dữ liệu trên nhiều AZ) Giải thích: DynamoDB là một dịch vụ fully managed, có nghĩa là AWS sẽ quản lý toàn bộ quá trình vận hành, bảo trì, vá lỗi và mở rộng của cơ sở dữ liệu. DynamoDB tự động sao chép dữ liệu trên nhiều Availability Zones (AZs) trong một Region, giúp tăng tính sẵn sàng và bảo vệ dữ liệu khỏi sự cố ở cấp độ hạ tầng. Ví dụ: Giả sử bạn có một ứng dụng thương mại điện tử sử dụng DynamoDB, nếu có một AZ gặp sự cố (như mất điện hoặc lỗi phần cứng), DynamoDB vẫn tiếp tục hoạt động vì dữ liệu đã được sao chép và có sẵn ở các AZ khác.
NoSQL database - not a relational database (Là cơ sở dữ liệu NoSQL - không phải cơ sở dữ liệu quan hệ) Giải thích: DynamoDB là một NoSQL database, không tuân theo các quy tắc nghiêm ngặt của cơ sở dữ liệu quan hệ. Điều này có nghĩa là dữ liệu không được lưu trong các bảng với hàng và cột cố định, thay vào đó, nó sử dụng cấu trúc key-value hoặc document. Ví dụ: Khi lưu trữ thông tin khách hàng và đơn hàng, thay vì tạo nhiều bảng và thực hiện các truy vấn JOIN phức tạp như trong cơ sở dữ liệu quan hệ, DynamoDB cho phép lưu tất cả dữ liệu liên quan trong một đối tượng duy nhất.
Scales to massive workloads, distributed database (Có khả năng mở rộng cho khối lượng công việc lớn, là cơ sở dữ liệu phân tán) Giải thích: DynamoDB có khả năng tự động mở rộng quy mô theo nhu cầu sử dụng, từ việc xử lý hàng triệu yêu cầu mỗi giây đến việc lưu trữ hàng terabyte (TB) dữ liệu. Hệ thống phân tán cho phép dữ liệu được lưu trữ trên nhiều máy chủ và vị trí khác nhau. Ví dụ: Nếu ứng dụng của bạn có sự gia tăng đột ngột về lượng người dùng, DynamoDB sẽ tự động mở rộng quy mô để xử lý tất cả các yêu cầu mà không cần sự can thiệp của bạn.
Millions of requests per seconds, trillions of rows, hundreds of terabytes of storage (Xử lý hàng triệu yêu cầu mỗi giây, hàng nghìn tỷ hàng, hàng trăm terabyte lưu trữ) Giải thích: DynamoDB được thiết kế để có thể xử lý khối lượng lớn dữ liệu và yêu cầu đồng thời với hiệu suất cao. Nó có thể lưu trữ và quản lý một lượng dữ liệu khổng lồ, phù hợp với các ứng dụng có yêu cầu về dữ liệu và hiệu suất cao. Ví dụ: Các công ty lớn như Amazon, Netflix sử dụng DynamoDB để quản lý lượng dữ liệu khổng lồ từ hàng triệu người dùng truy cập đồng thời.
Fast and consistent in performance (Hiệu suất nhanh và nhất quán) Giải thích: DynamoDB cung cấp độ trễ rất thấp khi truy xuất dữ liệu, giúp đảm bảo hiệu suất ổn định và nhanh chóng, ngay cả khi số lượng yêu cầu lớn. Ví dụ: Trong một ứng dụng mạng xã hội, khi người dùng yêu cầu xem thông tin bài viết, DynamoDB trả về dữ liệu gần như ngay lập tức, đảm bảo trải nghiệm người dùng mượt mà.
Integrated with IAM for security, authorization and administration (Tích hợp với IAM để quản lý bảo mật, ủy quyền và quản trị) Giải thích: DynamoDB tích hợp với AWS Identity and Access Management (IAM), cho phép bạn kiểm soát quyền truy cập và bảo mật ở mức độ cao. Bạn có thể tạo các chính sách chi tiết để xác định ai có quyền đọc, ghi hoặc xóa dữ liệu. Ví dụ: Bạn có thể thiết lập để chỉ những người dùng cụ thể mới có quyền chỉnh sửa dữ liệu sản phẩm trong DynamoDB, trong khi người dùng khác chỉ có thể xem dữ liệu.
Enables event-driven programming with DynamoDB Streams (Hỗ trợ lập trình theo sự kiện với DynamoDB Streams) Giải thích: DynamoDB Streams cho phép theo dõi các thay đổi trong bảng DynamoDB theo thời gian thực. Mỗi khi có dữ liệu được thêm, sửa hoặc xóa, DynamoDB Streams sẽ ghi lại sự kiện này, và bạn có thể sử dụng sự kiện đó để kích hoạt các hành động tiếp theo (ví dụ: kích hoạt một AWS Lambda function). Ví dụ: Khi một khách hàng đặt hàng trên trang web của bạn, DynamoDB Streams có thể ghi lại sự kiện này và kích hoạt một Lambda function để gửi email xác nhận đơn hàng cho khách hàng.
Low cost and auto-scaling capabilities (Chi phí thấp và khả năng tự động mở rộng) Giải thích: DynamoDB có mức chi phí thấp nhờ vào mô hình thanh toán dựa trên số lượng yêu cầu và dung lượng lưu trữ thực tế mà bạn sử dụng. Bên cạnh đó, DynamoDB tự động mở rộng hoặc thu hẹp quy mô dựa trên lưu lượng truy cập mà không cần bạn phải cấu hình thủ công. Ví dụ: Nếu bạn đang khởi nghiệp và có một ứng dụng với lượng người dùng nhỏ, bạn sẽ chỉ phải trả tiền cho những tài nguyên mà bạn sử dụng. Khi ứng dụng phát triển và lượng người dùng tăng lên, DynamoDB sẽ tự động mở rộng để đáp ứng nhu cầu mà không cần tăng chi phí đột ngột.
Standard & Infrequent Access (IA) Table Class (Lớp bảng truy cập tiêu chuẩn và ít truy cập) Giải thích: DynamoDB cung cấp hai lớp bảng: Standard (truy cập tiêu chuẩn) và Infrequent Access (IA) (truy cập không thường xuyên). IA Table Class là lớp bảng dành cho dữ liệu ít được truy cập thường xuyên nhưng vẫn cần sẵn sàng khi cần, giúp tiết kiệm chi phí. Ví dụ: Nếu bạn lưu trữ dữ liệu của các giao dịch cũ trong nhiều năm trước và không cần truy cập thường xuyên, bạn có thể chuyển dữ liệu này sang IA Table Class để giảm chi phí.

Tóm tắt: Amazon DynamoDB là một dịch vụ NoSQL mạnh mẽ trên AWS, lý tưởng cho các ứng dụng cần xử lý khối lượng lớn dữ liệu với hiệu suất cao và khả năng mở rộng tốt. Khi chuẩn bị cho kỳ thi AWS Associate Developer Certification, bạn nên nắm vững các khái niệm về DynamoDB, bao gồm tính sẵn sàng cao, tích hợp với IAM, DynamoDB Streams, và khả năng mở rộng tự động.

Hình ảnh bạn đã cung cấp tóm tắt các khái niệm cơ bản về Amazon DynamoDB, một dịch vụ cơ sở dữ liệu NoSQL được quản lý hoàn toàn bởi AWS. Đây là những kiến thức nền tảng quan trọng đối với bất kỳ ai đang chuẩn bị cho kỳ thi AWS Associate Developer Certification. Dưới đây là lời giải thích chi tiết từng phần của nội dung trong ảnh, kèm theo ví dụ minh họa giúp bạn dễ hiểu hơn.

DynamoDB is made of Tables Giải thích: DynamoDB lưu trữ dữ liệu trong các đơn vị gọi là "Tables". Mỗi bảng là một tập hợp của dữ liệu và có cấu trúc lưu trữ linh hoạt, không giống như cơ sở dữ liệu quan hệ truyền thống. Ví dụ: Bạn có thể tạo một bảng Customers để lưu trữ thông tin về khách hàng bao gồm tên, địa chỉ email, và số điện thoại.
Each table has a Primary Key Giải thích: Mỗi bảng trong DynamoDB phải có một khóa chính (Primary Key), được xác định khi tạo bảng. Khóa chính này có thể là một khóa đơn (Partition Key) hoặc một khóa phức hợp (Partition Key và Sort Key). Ví dụ: Trong bảng Customers, bạn có thể dùng email làm Partition Key.
Each table can have an infinite number of items (= rows) Giải thích: Mỗi bảng có thể chứa vô số "items" (tương đương với hàng trong SQL). Không giới hạn số lượng items có thể lưu trong một bảng, chỉ phụ thuộc vào nhu cầu và dung lượng lưu trữ của bạn. Ví dụ: Bảng Orders có thể chứa hàng triệu đơn hàng, mỗi đơn hàng là một item.
Each item has attributes (can be added over time – can be null) Giải thích: Mỗi item trong DynamoDB có các thuộc tính, tương đương với các trường trong cơ sở dữ liệu quan hệ. Các thuộc tính này có thể được thêm vào sau và có thể là null. Ví dụ: Một item trong bảng Customers có thể ban đầu chỉ có tên và email, sau đó có thể thêm thuộc tính địa chỉ.
Maximum size of an item is 400KB Giải thích: Kích thước tối đa của một item trong DynamoDB là 400KB. Điều này bao gồm tất cả các thuộc tính và cả khóa chính. Ví dụ: Nếu một item trong bảng Products chứa hình ảnh có dung lượng lớn, bạn cần đảm bảo dung lượng tổng thể không vượt quá 400KB.
Data types supported Giải thích: DynamoDB hỗ trợ nhiều loại dữ liệu khác nhau, bao gồm: Scalar Types: Các kiểu đơn giản như String, Number, Binary, Boolean, Null. Document Types: Các kiểu phức tạp hơn như List (danh sách) và Map (bản đồ). Set Types: Các tập hợp không cho phép trùng lặp như String Set, Number Set, và Binary Set. Ví dụ: Trong bảng Products, thuộc tính categories có thể là một String Set gồm các danh mục sản phẩm như ["electronics", "home_appliances"].

Bạn đã cung cấp hình ảnh liên quan đến các khái niệm về khóa chính (Primary Keys) trong DynamoDB, bao gồm cả các lựa chọn cho khóa phân vùng (Partition Key) và khóa phân vùng kết hợp với khóa sắp xếp (Partition Key + Sort Key), cũng như một bài tập thực hành xác định khóa phân vùng cho một cơ sở dữ liệu phim. Dưới đây là giải thích chi tiết và các ví dụ minh họa để giúp bạn hiểu rõ hơn:

DynamoDB – Primary Keys Option 1: Partition Key (HASH) Partition Key: Là khóa chính duy nhất cho mỗi item trong bảng. Khóa này phải đảm bảo tính đa dạng để phân tán dữ liệu một cách hiệu quả trên các nút lưu trữ của DynamoDB, giúp tránh hiện tượng "hot spot" (nơi một nút phải xử lý quá nhiều yêu cầu). Ví dụ: Một bảng Users sử dụng User_ID làm Partition Key. Mỗi User_ID là duy nhất và đại diện cho một hàng dữ liệu trong bảng, bao gồm tên, họ, và tuổi của người dùng.

Option 2: Partition Key + Sort Key (HASH + RANGE) Partition Key và Sort Key: Kết hợp này tạo nên một Primary Key composite, nơi Partition Key định danh một nhóm dữ liệu, và Sort Key đảm bảo mỗi item trong nhóm đó là duy nhất. Ví dụ: Một bảng User_Games có User_ID làm Partition Key và Game_ID làm Sort Key. Một user có thể chơi nhiều game, mỗi game được xác định bởi một Game_ID khác nhau, và thông tin chi tiết của mỗi game như điểm số, kết quả được lưu trong các thuộc tính tương ứng.

DynamoDB – Partition Keys (Exercise) Bài tập: Xác định khóa phân vùng tối ưu cho cơ sở dữ liệu phim. Các lựa chọn: movie_id: Mỗi phim có một ID duy nhất, làm cho nó trở thành ứng cử viên tốt nhất cho Partition Key do tính đa dạng và khả năng phân phối đều dữ liệu. producer_name, leader_actor_name: Các giá trị này có thể không đảm bảo tính đa dạng và duy nhất tương tự như movie_id. movie_language: Sử dụng ngôn ngữ phim làm khóa phân vùng không phải là một lựa chọn tốt do số lượng giá trị bị giới hạn và có thể bị lệch lớn về ngôn ngữ phổ biến như tiếng Anh.

Quản lý dung lượng đọc/ghi (read/write throughput) cho các bảng.

2. Các chế độ dung lượng đọc/ghi

DynamoDB cung cấp hai chế độ dung lượng chính để quản lý throughput:

a. Provisioned Mode (Chế độ định trước)

Chế độ này yêu cầu bạn tự chỉ định số lượng đọc và ghi tối đa mỗi giây mà bảng có thể xử lý. Đây là chế độ mặc định khi bạn tạo bảng trong DynamoDB.

Đặc điểm chính:
1. Bạn tự chỉ định dung lượng: Bạn phải dự đoán trước số lượng yêu cầu đọc/ghi cần thiết (Ví dụ: 100 đọc/giây và 50 ghi/giây).
2. Cần lên kế hoạch: Phải tính toán dựa trên nhu cầu của ứng dụng, nếu chọn sai dung lượng (quá thấp), các yêu cầu sẽ bị từ chối khi quá tải.
3. Chi phí: Bạn trả tiền theo mức dung lượng mà bạn đã chỉ định, bất kể có sử dụng hết hay không.
Ví dụ minh họa: Bạn có một ứng dụng e-commerce với lưu lượng truy cập ổn định:
- Ban ngày: Trung bình 500 đọc/giây và 200 ghi/giây.
- Ban đêm: Giảm xuống còn 100 đọc/giây và 50 ghi/giây. Nếu bạn dùng chế độ Provisioned, bạn phải thiết lập mức cao nhất (500 đọc và 200 ghi), dẫn đến lãng phí tài nguyên vào ban đêm.

b. On-Demand Mode (Chế độ theo yêu cầu)

Chế độ này tự động điều chỉnh dung lượng đọc/ghi dựa trên tải công việc thực tế, không cần bạn dự đoán hay quản lý trước.

Đặc điểm chính:
1. Tự động điều chỉnh: DynamoDB sẽ tăng/giảm dung lượng đọc/ghi một cách linh hoạt theo nhu cầu thực tế.
2. Không cần lập kế hoạch: Phù hợp cho các ứng dụng có lưu lượng truy cập không ổn định hoặc khó đoán trước.
3. Chi phí: Bạn chỉ trả tiền cho số lượng đọc/ghi thực tế mà bạn sử dụng, nhưng chi phí cao hơn so với Provisioned Mode.
Ví dụ minh họa: Bạn có một ứng dụng livestream bán hàng:
- Thông thường: Ít người truy cập (10 đọc/giây, 5 ghi/giây).
- Khi có sự kiện: Tăng đột biến (10,000 đọc/giây, 2,000 ghi/giây). Với On-Demand Mode, DynamoDB tự động tăng khả năng xử lý trong sự kiện và giảm xuống mức thấp khi sự kiện kết thúc, giúp bạn tiết kiệm chi phí.

3. Sự khác biệt chính giữa hai chế độ

Đặc điểm	Provisioned Mode	On-Demand Mode
Quản lý dung lượng	Bạn phải dự đoán trước	AWS tự động quản lý
Khả năng mở rộng	Hạn chế nếu cấu hình không đủ	Tự động mở rộng theo nhu cầu
Chi phí	Rẻ hơn nếu dự đoán chính xác	Cao hơn nhưng linh hoạt
Ứng dụng phù hợp	Lưu lượng ổn định	Lưu lượng không ổn định

4. Chuyển đổi giữa các chế độ

Bạn có thể chuyển đổi giữa hai chế độ một lần mỗi 24 giờ. Ví dụ:
- Trong thời gian bình thường, dùng Provisioned Mode để tiết kiệm chi phí.
- Trong mùa lễ hội (khi lưu lượng tăng cao đột ngột), chuyển sang On-Demand Mode để đảm bảo hiệu năng.

5. Lựa chọn chế độ nào?

Provisioned Mode:
- Phù hợp nếu bạn biết trước nhu cầu sử dụng và lưu lượng truy cập ổn định.
- Ví dụ: Một hệ thống ERP nội bộ trong công ty có số lượng người dùng cố định.
On-Demand Mode:
- Phù hợp với ứng dụng có lưu lượng truy cập không thể đoán trước hoặc thay đổi liên tục.
- Ví dụ: Một ứng dụng mạng xã hội với người dùng hoạt động theo sự kiện.

6. Kết luận

Khi làm việc với DynamoDB, việc lựa chọn đúng chế độ quản lý dung lượng là rất quan trọng, đặc biệt với ứng dụng thực tế. Hãy luôn cân nhắc:

Nhu cầu sử dụng ổn định hay không?
Dự toán chi phí để tối ưu ngân sách.

chế độ dung lượng đọc/ghi định trước (Provisioned Mode) trong DynamoDB.

1. Tổng quan về Provisioned Mode

Provisioned Mode yêu cầu bạn chỉ định số lượng đơn vị dung lượng đọc (RCU - Read Capacity Units) và ghi (WCU - Write Capacity Units) mà bạn muốn bảng DynamoDB hỗ trợ. Điều này giúp quản lý tài nguyên và chi phí một cách cố định, nhưng cũng đòi hỏi bạn phải lên kế hoạch cẩn thận.

2. Các khái niệm quan trọng

a. Read Capacity Units (RCU): Throughput cho đọc

Định nghĩa: RCU xác định số lượng read mà bảng có thể xử lý mỗi giây.
1 RCU cho phép:
- Đọc 1 item có kích thước tối đa 4 KB theo kiểu đọc nhất quán eventual consistency.
- Đối với kiểu đọc strongly consistent, bạn cần gấp 2 RCU cho cùng một kích thước.
Ví dụ:

Bạn có một bảng chứa dữ liệu người dùng:
- Mỗi bản ghi có kích thước 8 KB.
- Bạn cần 10 lần đọc/giây (eventual consistency). => Số RCU cần = ⌈48⌉×10=20.
- $⌈84⌉×10=20\lceil \frac{8}{4} \rceil \times 10 = 20$

b. Write Capacity Units (WCU): Throughput cho ghi

Định nghĩa: WCU xác định số lượng ghi mà bảng có thể xử lý mỗi giây.
1 WCU cho phép:
- Ghi 1 item có kích thước tối đa 1 KB.
Ví dụ: Bạn cần ghi 50 bản ghi mỗi giây, mỗi bản ghi có kích thước 2 KB. => Số WCU cần = ⌈21⌉×50=100\lceil \frac{2}{1} \rceil \times 50 = 100⌈12⌉×50=100.

3. Auto-Scaling

DynamoDB hỗ trợ tự động mở rộng (auto-scaling) khi nhu cầu thay đổi. Bạn có thể cấu hình để tự động điều chỉnh RCU/WCU lên xuống trong giới hạn mà bạn đặt ra.
Ví dụ: Bạn đặt mức auto-scaling:
- Tối thiểu: 10 RCU.
- Tối đa: 200 RCU. Khi lưu lượng tăng đột ngột (ví dụ: Black Friday), DynamoDB sẽ tăng dung lượng đọc lên đến 200 RCU để đáp ứng yêu cầu.

4. Burst Capacity (Dung lượng tăng cường)

DynamoDB cho phép vượt mức dung lượng định trước tạm thời nhờ dung lượng dự phòng tích lũy (burst capacity). Dung lượng này được sử dụng khi bảng có lưu lượng tăng đột ngột, nhưng không kéo dài quá lâu.
Ví dụ: Bảng của bạn được cấu hình 50 RCU. Nếu một đợt lưu lượng bất thường yêu cầu 100 RCU, DynamoDB sẽ xử lý bằng dung lượng dự phòng, miễn là bạn chưa tiêu hao hết khả năng burst.

5. ProvisionedThroughputExceededException

Khi dung lượng của bảng vượt quá mức Provisioned RCU/WCU và dung lượng burst đã tiêu hao, bạn sẽ nhận lỗi ProvisionedThroughputExceededException.
Lỗi này thường xuất hiện trong trường hợp:
- Lưu lượng tăng đột biến mà bạn không có đủ burst capacity.
- Bạn cấu hình quá ít RCU/WCU.
Giải pháp:
1. Tăng dung lượng: Điều chỉnh mức provisioned RCU/WCU.
2. Sử dụng auto-scaling: Để tự động điều chỉnh.
3. Retry theo exponential backoff:
  - Tăng dần khoảng thời gian giữa các lần retry (ví dụ: 1 giây, 2 giây, 4 giây, ...).
  - Điều này giảm áp lực lên DynamoDB trong trường hợp có lưu lượng cao.

6. Exponential Backoff Retry

Exponential Backoff là chiến lược xử lý lỗi khi gặp ProvisionedThroughputExceededException:
- Sau mỗi lần lỗi, bạn đợi một khoảng thời gian dài hơn trước khi thử lại.
- Điều này cho DynamoDB thời gian để phục hồi và xử lý các yêu cầu khác.
Ví dụ:
1. Lần retry 1: Đợi 1 giây.
2. Lần retry 2: Đợi 2 giây.
3. Lần retry 3: Đợi 4 giây. => Giảm áp lực lên hệ thống và tăng khả năng thành công.

7. Khi nào nên dùng Provisioned Mode?

Ứng dụng ổn định: Phù hợp với các ứng dụng có lưu lượng ổn định và có thể dự đoán trước.
Ví dụ:
- Một hệ thống quản lý tồn kho, xử lý 1,000 yêu cầu đọc/giây đều đặn.
- Một ứng dụng CRM nội bộ với số lượng người dùng cố định.

8. Kết luận

Provisioned Mode là một lựa chọn tuyệt vời nếu bạn:

Hiểu rõ nhu cầu sử dụng của ứng dụng.
Muốn tối ưu chi phí cho các ứng dụng có lưu lượng ổn định.

1. WCU là gì?

Write Capacity Unit (WCU): Là đơn vị dùng để tính toán số lượng ghi mà bảng DynamoDB có thể xử lý mỗi giây.
1 WCU cho phép:
- Ghi 1 mục (item) có kích thước tối đa 1 KB mỗi giây.
- Nếu kích thước của item vượt quá 1 KB, số lượng WCU cần thiết sẽ tăng lên, dựa trên kích thước làm tròn lên bội số của 1 KB.

2. Nguyên tắc tính WCU

Kích thước item: DynamoDB tính toán số WCU dựa trên kích thước của mỗi item được ghi.
Số item mỗi giây: Số lượng mục bạn ghi vào bảng trong mỗi giây cũng ảnh hưởng đến số WCU cần thiết.

3. Các ví dụ minh họa

Example 1:

Yêu cầu: Ghi 10 mục mỗi giây, mỗi mục có kích thước 2 KB.
Cách tính:
- Mỗi mục cần ⌈12⌉=2 WCU (do 2 KB vượt quá 1 KB).
  
  ⌈21⌉=2\lceil \frac{2}{1} \rceil = 2
- Tổng WCU = 10×2=20.
  
  10×2=2010 \times 2 = 20
Kết quả: Bạn cần 20 WCU để hỗ trợ 10 ghi/giây, với mỗi mục 2 KB.

Example 2:

Yêu cầu: Ghi 6 mục mỗi giây, mỗi mục có kích thước 4.5 KB.
Cách tính:
- Mỗi mục cần ⌈14.5⌉=5 WCU (kích thước được làm tròn lên 5 KB).
  
  ⌈4.51⌉=5\lceil \frac{4.5}{1} \rceil = 5
- Tổng WCU = 6×5=30.
  
  6×5=306 \times 5 = 30
Kết quả: Bạn cần 30 WCU để hỗ trợ 6 ghi/giây, với mỗi mục 4.5 KB.

Example 3:

Yêu cầu: Ghi 120 mục mỗi phút, mỗi mục có kích thước 2 KB.
Cách tính:
- Số mục mỗi giây = 60120=2 mục/giây.
  
  12060=2\frac{120}{60} = 2
- Mỗi mục cần ⌈12⌉=2 WCU.
  
  ⌈21⌉=2\lceil \frac{2}{1} \rceil = 2
- Tổng WCU = 2×2=4.
  
  2×2=42 \times 2 = 4
Kết quả: Bạn cần 4 WCU để hỗ trợ 2 ghi/giây, với mỗi mục 2 KB.

4. Lưu ý khi tính toán WCU

DynamoDB luôn làm tròn kích thước item lên bội số của 1 KB. Điều này có nghĩa là:
- Một item 1.1 KB cần 2 WCU.
- Một item 4.5 KB cần 5 WCU.
Hãy luôn xác định:
1. Số item ghi/giây.
2. Kích thước item trung bình.

5. Tình huống thực tế

Tình huống 1: Ứng dụng E-commerce

Bạn có một bảng lưu đơn hàng:
- Trung bình, mỗi đơn hàng có kích thước 2.5 KB.
- Dự kiến có 50 đơn hàng được ghi mỗi giây.
Tính toán:
- Mỗi item cần ⌈12.5⌉=3 WCU.
  
  ⌈2.51⌉=3\lceil \frac{2.5}{1} \rceil = 3
- Tổng WCU cần = 50×3=150.
  
  50×3=15050 \times 3 = 150
Kết quả: Bảng cần 150 WCU để đáp ứng yêu cầu.

Tình huống 2: Ứng dụng Mạng xã hội

Bảng lưu các bài đăng, trung bình mỗi bài viết là 1.2 KB.
- Dự kiến có 10 bài viết được ghi mỗi giây.
Tính toán:
- Mỗi bài viết cần ⌈11.2⌉=2 WCU.
  
  ⌈1.21⌉=2\lceil \frac{1.2}{1} \rceil = 2
- Tổng WCU cần = 10×2=20.
  
  10×2=2010 \times 2 = 20
Kết quả: Bảng cần 20 WCU để đáp ứng yêu cầu.

6. Kết luận

WCU (Write Capacity Unit) rất quan trọng khi bạn thiết kế bảng DynamoDB trong chế độ Provisioned Mode.
Hãy luôn tính toán chính xác dựa trên:
1. Số item ghi mỗi giây.
2. Kích thước trung bình của item.
Nếu không chắc chắn về lưu lượng ghi, bạn có thể sử dụng:
- Auto-scaling: Tự động điều chỉnh dung lượng WCU.
- On-Demand Mode: DynamoDB tự quản lý dung lượng ghi.

Eventually Consistent Read (đọc nhất quán dần dần) và Strongly Consistent Read (đọc nhất quán mạnh mẽ). Đây là kiến thức quan trọng khi bạn thiết kế ứng dụng và cần tối ưu hóa hiệu suất hoặc tính chính xác dữ liệu.

1. Eventually Consistent Read (ECR) - Đọc nhất quán dần dần

Mô tả:
- Đây là chế độ đọc mặc định của DynamoDB.
- Khi bạn ghi dữ liệu vào bảng, dữ liệu được sao chép sang các bản sao (replication) trên các server khác nhau. Việc sao chép này mất thời gian.
- Nếu bạn thực hiện đọc ngay sau khi ghi, dữ liệu có thể chưa được đồng bộ đầy đủ trên tất cả các bản sao. Kết quả, bạn có thể nhận dữ liệu cũ (stale data).
Ưu điểm:
- Nhanh và rẻ: Chế độ này sử dụng ít tài nguyên hơn (tiết kiệm chi phí RCU).
- Phù hợp cho các ứng dụng không cần đảm bảo dữ liệu chính xác 100% ngay lập tức.
Ví dụ thực tế:
- Một ứng dụng thương mại điện tử hiển thị danh sách sản phẩm:
  - Người dùng A vừa cập nhật giá sản phẩm.
  - Người dùng B thực hiện xem danh sách sản phẩm ngay sau đó.
  - Do dữ liệu chưa đồng bộ xong, người dùng B có thể nhìn thấy giá cũ.

2. Strongly Consistent Read (SCR) - Đọc nhất quán mạnh mẽ

Mô tả:
- Trong chế độ này, DynamoDB đảm bảo rằng:
  - Khi bạn đọc ngay sau khi ghi, dữ liệu trả về luôn là mới nhất (cập nhật đầy đủ).
- Điều này yêu cầu DynamoDB phải kiểm tra tất cả các bản sao để chắc chắn dữ liệu là chính xác.
Cách sử dụng:
- Bạn cần bật tham số ConsistentRead = True trong các API như:
  - GetItem
  - BatchGetItem
  - Query
  - Scan
- Chi phí: Chế độ này tiêu thụ gấp đôi RCU so với Eventually Consistent Read.
Ưu điểm:
- Đảm bảo tính toàn vẹn của dữ liệu (dữ liệu luôn chính xác).
- Phù hợp cho các ứng dụng yêu cầu tính chính xác cao.
Ví dụ thực tế:
- Ứng dụng ngân hàng:
  - Người dùng A chuyển 10 triệu vào tài khoản của người dùng B.
  - Người dùng B thực hiện kiểm tra số dư ngay sau đó.
  - Chế độ SCR sẽ đảm bảo số dư mới (đã thêm 10 triệu) được hiển thị chính xác.

3. So sánh ECR và SCR

Đặc điểm	Eventually Consistent Read	Strongly Consistent Read
Tính nhất quán	Có thể trả về dữ liệu cũ	Luôn trả về dữ liệu chính xác
Hiệu suất	Nhanh hơn, rẻ hơn	Chậm hơn, đắt hơn (gấp 2 RCU)
Ứng dụng phù hợp	Dữ liệu không yêu cầu chính xác ngay lập tức	Dữ liệu yêu cầu chính xác cao

4. Hình minh họa

Hãy nhìn vào sơ đồ trên ảnh:

Eventual Consistency:
- Ứng dụng gửi yêu cầu đọc dữ liệu.
- Nếu đọc ngay sau khi ghi, các server (replicas) chưa đồng bộ dữ liệu hoàn toàn, có thể trả về dữ liệu cũ.
Strong Consistency:
- Ứng dụng gửi yêu cầu đọc dữ liệu.
- DynamoDB kiểm tra và trả về dữ liệu từ bản ghi chính xác (sau khi đã đồng bộ xong).

5. Lựa chọn chế độ đọc nào?

a. Sử dụng Eventually Consistent Read nếu:

Ứng dụng của bạn không yêu cầu dữ liệu chính xác tức thì.
Bạn muốn tiết kiệm chi phí RCU.
Ví dụ: Ứng dụng mạng xã hội, hiển thị các bài đăng, danh sách sản phẩm.

b. Sử dụng Strongly Consistent Read nếu:

Ứng dụng của bạn yêu cầu dữ liệu chính xác ngay lập tức.
Bạn chấp nhận chi phí cao hơn để đảm bảo tính toàn vẹn dữ liệu.
Ví dụ: Ứng dụng tài chính, ngân hàng, hoặc các hệ thống giao dịch quan trọng.

6. Kết luận

Eventually Consistent Read: Phù hợp với các ứng dụng ưu tiên hiệu suất và chi phí thấp hơn, không cần dữ liệu chính xác ngay lập tức.
Strongly Consistent Read: Phù hợp với các ứng dụng yêu cầu dữ liệu chính xác, ưu tiên độ tin cậy hơn hiệu suất.

1. Read Capacity Unit (RCU) là gì?

RCU là đơn vị dùng để tính toán số lần đọc dữ liệu mà bảng DynamoDB có thể xử lý mỗi giây.
1 RCU cho phép:
- 1 lần đọc nhất quán mạnh mẽ (Strongly Consistent Read) mỗi giây, với kích thước item tối đa là 4 KB.
- 2 lần đọc nhất quán dần dần (Eventually Consistent Read) mỗi giây, với kích thước item tối đa là 4 KB.

Nếu kích thước item lớn hơn 4 KB?

DynamoDB sẽ làm tròn lên bội số của 4 KB.
Ví dụ:
- Một item 6 KB sẽ được làm tròn lên 8 KB.
- Một item 12 KB sẽ được làm tròn lên 16 KB.

2. Nguyên tắc tính RCU

Khi dùng Strongly Consistent Read:
- Số RCU cần = soˆˊ lượng đọc/giaˆy×4 KBkıˊch thước item.
  
  soˆˊ lượng đọc/giaˆy×kıˊch thước item4 KB\text{số lượng đọc/giây} \times \frac{\text{kích thước item}}{4 \text{ KB}}
Khi dùng Eventually Consistent Read:
- Số RCU cần = 2soˆˊ lượng đọc/giaˆy×4 KBkıˊch thước item.
  
  soˆˊ lượng đọc/giaˆy2×kıˊch thước item4 KB\frac{\text{số lượng đọc/giây}}{2} \times \frac{\text{kích thước item}}{4 \text{ KB}}

3. Các ví dụ minh họa

Example 1:

Yêu cầu: 10 lần đọc nhất quán mạnh mẽ mỗi giây, mỗi item có kích thước 4 KB.
Cách tính:
- Mỗi lần đọc cần 1 RCU (do kích thước item = 4 KB).
- Tổng RCU = 10×1=10.
  
  10×1=1010 \times 1 = 10
Kết quả: Bạn cần 10 RCU để hỗ trợ 10 lần đọc mạnh mẽ, mỗi item 4 KB.

Example 2:

Yêu cầu: 16 lần đọc nhất quán dần dần mỗi giây, mỗi item có kích thước 12 KB.
Cách tính:
- Mỗi lần đọc dần dần cần 0.5 RCU (do RCU chia đôi với đọc dần dần).
- Kích thước item 12 KB được làm tròn lên 3 lần 4 KB (tức 3 RCU mỗi item).
- Tổng RCU = 216×3=24.
  
  162×3=24\frac{16}{2} \times 3 = 24
Kết quả: Bạn cần 24 RCU để hỗ trợ 16 lần đọc dần dần, mỗi item 12 KB.

Example 3:

Yêu cầu: 10 lần đọc nhất quán mạnh mẽ mỗi giây, mỗi item có kích thước 6 KB.
Cách tính:
- Kích thước item 6 KB được làm tròn lên 8 KB (tức 2 RCU mỗi lần đọc).
- Tổng RCU = 10×2=20.
  
  10×2=2010 \times 2 = 20
Kết quả: Bạn cần 20 RCU để hỗ trợ 10 lần đọc mạnh mẽ, mỗi item 6 KB.

4. Lưu ý quan trọng

Kích thước item ảnh hưởng lớn nhất đến RCU: Hãy luôn tối ưu hóa kích thước item để giảm chi phí.
Đọc nhất quán mạnh mẽ (Strongly Consistent Read):
- Luôn đảm bảo dữ liệu chính xác nhưng tốn gấp đôi tài nguyên so với đọc dần dần.
Đọc nhất quán dần dần (Eventually Consistent Read):
- Hiệu quả về tài nguyên, phù hợp với ứng dụng không yêu cầu dữ liệu chính xác ngay lập tức.

5. Ứng dụng thực tế

Tình huống 1: Hệ thống báo cáo

Hệ thống báo cáo đọc dữ liệu hàng giờ, không cần chính xác tức thì.
Dữ liệu đọc là danh sách báo cáo, kích thước trung bình mỗi báo cáo là 2 KB.
Yêu cầu: 100 lần đọc/giây.
Tính toán:
- Đọc dần dần (Eventually Consistent Read): 2100×42=25 RCU.
  
  1002×24=25\frac{100}{2} \times \frac{2}{4} = 25
- Kết quả: Hệ thống cần 25 RCU.

Tình huống 2: Ứng dụng ngân hàng

Ứng dụng ngân hàng cần hiển thị số dư tài khoản chính xác.
Dữ liệu đọc là thông tin tài khoản, kích thước trung bình mỗi mục là 8 KB.
Yêu cầu: 50 lần đọc/giây.
Tính toán:
- Đọc mạnh mẽ (Strongly Consistent Read): 50×48=100 RCU.
  
  50×84=10050 \times \frac{8}{4} = 100
- Kết quả: Ứng dụng cần 100 RCU.

6. Kết luận

Hiểu rõ cách tính RCU giúp bạn tối ưu chi phí khi thiết kế bảng DynamoDB.
Strongly Consistent Read: Đảm bảo dữ liệu chính xác, chi phí cao hơn.
Eventually Consistent Read: Tiết kiệm hơn, phù hợp với dữ liệu không yêu cầu tính chính xác ngay lập tức.

Partitions Internal

1. Tổng quan về Phân Vùng trong DynamoDB

Phân vùng (Partition) là các đơn vị lưu trữ vật lý trong DynamoDB.
Dữ liệu trong DynamoDB được lưu trữ trong các phân vùng độc lập để đảm bảo khả năng mở rộng và hiệu suất cao.
Partition Key được sử dụng với hàm băm (Hash Function) để xác định dữ liệu thuộc về phân vùng nào.

Ví dụ:

Bạn có một bảng DynamoDB với Partition Key là user_id.
Dữ liệu như sau:
- user_id = ID_13 → Lưu vào Partition 1
- user_id = ID_45 → Lưu vào Partition 2
Quá trình hoạt động:
1. Ứng dụng ghi dữ liệu vào DynamoDB.
2. Partition Key (ID_13, ID_45) được đưa vào hàm băm (Hash Function).
3. Hàm băm xác định dữ liệu được lưu vào phân vùng cụ thể nào.
Lưu ý: Phân vùng giúp chia nhỏ dữ liệu và trải tải đều để duy trì hiệu suất.

2. Cách tính số lượng phân vùng trong DynamoDB

DynamoDB tính toán số lượng phân vùng dựa trên:

Năng lực đọc/ghi (Capacity Units)
Kích thước dữ liệu (Data Size)

📊 Công thức tính toán phân vùng

Dựa trên năng lực (Capacity):

\text{# of partitions}{\text{by capacity}} = \left(\frac{RCU{\text{total}}}{3000}\right) + \left(\frac{WCU_{\text{total}}}{1000}\right)
- RCU (Read Capacity Units): Đơn vị đọc.
- WCU (Write Capacity Units): Đơn vị ghi.
- DynamoDB chia nhỏ năng lực đọc và ghi giữa các phân vùng.

Ví dụ:

RCU = 6000, WCU = 2000
Phân vùng theo năng lực:

6000/3000+2000/1000=2+2=4 phaˆn vuˋng\frac{6000}{3000} + \frac{2000}{1000} = 2 + 2 = 4 \text{ phân vùng}

3000/6000+10002000=2+2=4 phaˆn vuˋng

Dựa trên kích thước dữ liệu (Size):

\text{# of partitions}_{\text{by size}} = \frac{\text{Total Size}}{10 GB}
- Mỗi phân vùng có thể chứa tối đa 10 GB dữ liệu.

Ví dụ:

Tổng dữ liệu = 50 GB
Phân vùng theo kích thước:

5010=5 phaˆn vuˋng\frac{50}{10} = 5 \text{ phân vùng}

1050=5 phaˆn vuˋng

Số lượng phân vùng cuối cùng:

\text{# of partitions} = \lceil \max(\text{# of partitions}{\text{by capacity}}, \text{# of partitions}{\text{by size}}) \rceil

Ví dụ:
- Phân vùng theo năng lực: 4
- Phân vùng theo kích thước: 5
- Số lượng phân vùng cuối cùng: 5

⚖️ 3. WCU và RCU được phân bổ trên các phân vùng

WCU (Write Capacity Units) và RCU (Read Capacity Units) được phân bổ đồng đều giữa các phân vùng.
Điều này đảm bảo rằng không có phân vùng nào bị quá tải hoặc sử dụng không hiệu quả.

📌 Ví dụ:

5 phân vùng, tổng WCU = 1000, tổng RCU = 3000
Phân bổ mỗi phân vùng:
- WCU = 1000 ÷ 5 = 200 WCU mỗi phân vùng
- RCU = 3000 ÷ 5 = 600 RCU mỗi phân vùng

Lưu ý: Nếu một phân vùng bị quá tải (hot partition), hiệu suất của bảng DynamoDB có thể bị ảnh hưởng.

AWS DynamoDB

Table of contents

2. Các chế độ dung lượng đọc/ghi

a. Provisioned Mode (Chế độ định trước)

b. On-Demand Mode (Chế độ theo yêu cầu)

3. Sự khác biệt chính giữa hai chế độ

4. Chuyển đổi giữa các chế độ

5. Lựa chọn chế độ nào?

6. Kết luận

1. Tổng quan về Provisioned Mode

2. Các khái niệm quan trọng

a. Read Capacity Units (RCU): Throughput cho đọc

b. Write Capacity Units (WCU): Throughput cho ghi

3. Auto-Scaling

4. Burst Capacity (Dung lượng tăng cường)

5. ProvisionedThroughputExceededException

6. Exponential Backoff Retry

7. Khi nào nên dùng Provisioned Mode?

8. Kết luận

1. WCU là gì?

2. Nguyên tắc tính WCU

3. Các ví dụ minh họa

Example 1:

Example 2:

Example 3:

4. Lưu ý khi tính toán WCU

5. Tình huống thực tế

Tình huống 1: Ứng dụng E-commerce

Tình huống 2: Ứng dụng Mạng xã hội

6. Kết luận

1. Eventually Consistent Read (ECR) - Đọc nhất quán dần dần

2. Strongly Consistent Read (SCR) - Đọc nhất quán mạnh mẽ

3. So sánh ECR và SCR

4. Hình minh họa

5. Lựa chọn chế độ đọc nào?

a. Sử dụng Eventually Consistent Read nếu:

b. Sử dụng Strongly Consistent Read nếu:

6. Kết luận

1. Read Capacity Unit (RCU) là gì?

Nếu kích thước item lớn hơn 4 KB?

2. Nguyên tắc tính RCU

3. Các ví dụ minh họa

Example 1:

Example 2:

Example 3:

4. Lưu ý quan trọng

5. Ứng dụng thực tế

Tình huống 1: Hệ thống báo cáo

Tình huống 2: Ứng dụng ngân hàng

6. Kết luận

Partitions Internal

1. Tổng quan về Phân Vùng trong DynamoDB

2. Cách tính số lượng phân vùng trong DynamoDB

📊 Công thức tính toán phân vùng

⚖️ 3. WCU và RCU được phân bổ trên các phân vùng

📌 Ví dụ: