Câu hỏi mô tả một tình huống trong đó Bigtable đang gặp phải hiệu suất đọc/ghi kém với dữ liệu terabyte tăng nhanh. Bigtable là cơ sở dữ liệu NoSQL phân tán được tối ưu hóa cho các khối lượng công việc có thông lượng cao và độ trễ thấp, nhưng hiệu suất của nó phụ thuộc rất nhiều vào thiết kế khóa hàng (row key design).

Lựa chọn A: "Redefine the schema by evenly distributing reads and writes across the row space of the table." (Định nghĩa lại lược đồ bằng cách phân phối đều các lượt đọc và ghi trên không gian hàng của bảng.) Đây là giải pháp chính xác nhất. Trong Bigtable, hiệu suất tốt nhất đạt được khi dữ liệu được phân phối đều trên tất cả các node trong cụm. Nếu dữ liệu được nhóm lại (hotspotting) do các khóa hàng tuần tự hoặc không được phân phối tốt, nó sẽ gây ra tắc nghẽn ở một số node nhất định, dẫn đến hiệu suất kém. Phân phối đều các lượt đọc và ghi giúp tận dụng tối đa khả năng mở rộng song song của Bigtable. Điều này thường được thực hiện bằng cách chọn các khóa hàng có tính ngẫu nhiên hóa hoặc bằng cách thêm tiền tố băm vào các khóa hàng tuần tự.

Lựa chọn B: "The performance issue should be resolved over time as the site of the BigDate cluster is increased." (Vấn đề hiệu suất sẽ được giải quyết theo thời gian khi kích thước của cụm Bigtable được tăng lên.) Mặc dù việc tăng kích thước cụm Bigtable (tăng số lượng node) có thể cải thiện hiệu suất tổng thể, nhưng nếu vấn đề gốc là do thiết kế khóa hàng kém (gây ra hotspotting), việc tăng kích thước cụm sẽ không giải quyết được vấn đề cơ bản. Các hotspot vẫn sẽ tồn tại và chỉ một phần cụm được sử dụng hiệu quả, dẫn đến chi phí cao hơn mà không đạt được hiệu suất mong muốn.

Lựa chọn C: "Redesign the schema to use a single row key to identify values that need to be updated frequently in the cluster." (Thiết kế lại lược đồ để sử dụng một khóa hàng duy nhất để nhận dạng các giá trị cần được cập nhật thường xuyên trong cụm.) Việc sử dụng một khóa hàng duy nhất cho các giá trị được cập nhật thường xuyên là một mô hình thiết kế rất tệ trong Bigtable. Điều này sẽ tạo ra một điểm nóng (hotspot) nghiêm trọng, nơi tất cả các thao tác đọc và ghi sẽ tập trung vào một node duy nhất, làm giảm đáng kể hiệu suất và khả năng mở rộng. Bigtable được thiết kế để phân tán dữ liệu và khối lượng công việc.

Lựa chọn D: "Redesign the schema to use row keys based on numeric IDs that increase sequentially per user viewing the offers." (Thiết kế lại lược đồ để sử dụng các khóa hàng dựa trên ID số tăng tuần tự cho mỗi người dùng xem ưu đãi.) Các khóa hàng tăng tuần tự là một vấn đề phổ biến gây ra hotspotting trong Bigtable. Khi dữ liệu được ghi với các khóa tăng tuần tự, tất cả các bản ghi mới sẽ được gửi đến cùng một node hoặc một nhóm node hạn chế (node chịu trách nhiệm cho các khóa hàng cao nhất), gây ra tắc nghẽn ở các node đó và không tận dụng được khả năng phân phối của toàn bộ cụm. Để tránh điều này, nên sử dụng các khóa hàng có tính ngẫu nhiên cao hoặc tiền tố băm để phân tán các lượt ghi.

(Đáp án được gợi ý bởi AI)