Ngân hàng đề — Microsoft Azure Data Fundamentals

Tìm thấy 328 câu.

Câu 11 Analytics
What is the concept of NORMALIZATION when it comes to relational databases?
  1. A Regenerating a table's indexes to increase performance
  2. B Removing duplicate rows from a table
  3. C Compressing a data table to it's smallest possible size
  4. D The process of eliminating redundancy in data tables by splitting large tables up into several smaller tables, establishing relationships between those tables, and reducing the size of the overall database.
Xem giải thích

Đáp án

D — Quá trình LOẠI BỎ DƯ THỪA dữ liệu bằng cách tách bảng lớn thành nhiều bảng nhỏ và thiết lập quan hệ giữa chúng.

Vì sao đúng

⚠ Chuẩn hoá là kỹ thuật thiết kế lược đồ:

⚠ TRƯỚC — một bảng
⚠ | DonHang | TenKH | DiaChiKH | SanPham | Gia |
   ⚠ tên và địa chỉ khách LẶP LẠI ở mỗi đơn
        ↓ ⚠ chuẩn hoá
⚠ SAU — ba bảng
⚠ KhachHang | DonHang | SanPham
   ⚠ nối nhau bằng khoá ngoại
        ↓
⚠ Sửa địa chỉ khách: sửa MỘT chỗ
Lợi ích Nội dung
⚠ Không lặp dữ liệu ⚠ tiết kiệm chỗ
⚠ Tránh dị thường khi cập nhật ⚠ lợi ích lớn nhất
⚠ Toàn vẹn dữ liệu tốt hơn
⚠ Ghi nhanh hơn ⚠ ghi ít chỗ hơn

Vì sao các phương án khác sai

  • B (xoá các dòng TRÙNG trong bảng) — ⚠ bẫy gần đúng: ⚠ đó là ⚠ làm sạch dữ liệu (deduplication), ⚠ một thao tác trên DỮ LIỆU; ⚠ chuẩn hoá là việc trên ⚠ THIẾT KẾ bảng.

  • A (dựng lại chỉ mục để tăng hiệu năng) — ⚠ là bảo trì chỉ mục.

  • C (nén bảng xuống kích thước nhỏ nhất) — ⚠ là nén dữ liệu, một tính năng lưu trữ.

Ghi nhớ

⚠ Ba dạng chuẩn hoá đầu — bảng phải thuộc: | Dạng | Yêu cầu | |---|---| | ⚠ 1NF | ⚠ mỗi ô một giá trị ĐƠN, không có nhóm lặp | | ⚠ 2NF | ⚠ 1NF + mọi cột phụ thuộc TOÀN BỘ khoá chính | | ⚠ 3NF | ⚠ 2NF + không có phụ thuộc bắc cầu giữa các cột không khoá | | ⚠ Thực tế | ⚠ 3NF là mức phổ biến cho hệ thống giao dịch |

Từ khoá nhận diện:

"tách bảng, loại dư thừa, khoá ngoại" → ⚠ chuẩn hoá "gộp bảng lại cho truy vấn nhanh" → ⚠ phi chuẩn hoá "xoá dòng trùng" → ⚠ làm sạch dữ liệu "star schema, fact và dimension" → ⚠ thiết kế kho dữ liệu, phi chuẩn hoá có chủ đích

⚠ Cái giá của chuẩn hoá Cái giá
⚠ Truy vấn phải JOIN nhiều bảng
⚠ Càng nhiều JOIN càng chậm
⚠ Báo cáo phức tạp trở nên khó viết
⚠ Vì vậy ⚠ kho dữ liệu phân tích thường PHI CHUẨN HOÁ có chủ đích
⚠ OLTP và OLAP — hai thế giới ngược nhau So sánh
⚠ OLTP: ghi nhiều, chuẩn hoá cao ⚠ hệ thống giao dịch
⚠ OLAP: đọc nhiều, phi chuẩn hoá ⚠ kho dữ liệu, báo cáo
⚠ Star schema ⚠ bảng fact ở giữa, các bảng dimension quanh nó
⚠ Vì sao khác nhau ⚠ tối ưu cho ghi và tối ưu cho đọc là hai mục tiêu đối nghịch
⚠ Dị thường mà chuẩn hoá ngăn được Dị thường
⚠ Cập nhật: sửa một chỗ quên chỗ khác → dữ liệu mâu thuẫn
⚠ Chèn: không thêm được sản phẩm nếu chưa có đơn hàng
⚠ Xoá: xoá đơn hàng cuối làm mất luôn thông tin khách
⚠ Ba dị thường này ⚠ là lý do chuẩn hoá ra đời

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống này thiên về ghi hay về đọc | ⚠ quyết định mức chuẩn hoá | | Có dữ liệu nào đang lặp ở nhiều bảng không | | | Truy vấn quan trọng phải JOIN mấy bảng | |

Và lý do thật sự khiến chuẩn hoá ra đời, quan trọng hơn cả chuyện tiết kiệm dung lượng: ngăn dữ liệu tự mâu thuẫn với chính nó. Khi địa chỉ khách hàng chỉ tồn tại ở một chỗ, không có cách nào để hai chỗ ghi khác nhau.

Câu 12 Non-relational data
Why would someone choose Azure Table Storage instead of Azure Cosmos DB Table API?
  1. A Lowest-cost option
  2. B Complete indexing of on all properties by default
  3. C Scalable to any number of regions
  4. D Guaranteed single-digit millisecond latency for reads and writes
Xem giải thích

Đáp án

A — Vì đó là lựa chọn CÓ CHI PHÍ THẤP NHẤT.

Vì sao đúng

⚠ Table Storage và Cosmos DB Table API dùng chung API nhưng khác hẳn về chi phí và năng lực: | Tiêu chí | Table Storage | Cosmos Table API | |---|---|---| | ⚠ Chi phí | ⚠ RẺ NHẤT | ⚠ cao hơn nhiều | | ⚠ Độ trễ | ⚠ không cam kết | ⚠ cam kết dưới 10ms | | ⚠ Nhân bản toàn cầu | ⚠ giới hạn: LRS, GRS | ⚠ đa vùng chủ động | | ⚠ Chỉ mục | ⚠ chỉ khoá chính | ⚠ mọi thuộc tính, tự động | | ⚠ Thông lượng | ⚠ giới hạn theo tài khoản | ⚠ cấp phát theo RU |

⚠ Ba phương án B, C, D
   ⚠ đều là ưu điểm của COSMOS
        ↓
⚠ Lý do chọn Table Storage
   ⚠ chỉ còn lại: RẺ

Vì sao các phương án khác sai

  • B (đánh chỉ mục mọi thuộc tính mặc định), C (co giãn ra bao nhiêu vùng cũng được), D (cam kết độ trễ một chữ số mili giây) — ⚠ cả ba đều là đặc điểm của COSMOS DB, ⚠ tức là lý do để chọn ⚠ ngược lại.

Ghi nhớ

⚠ Dạng câu "vì sao chọn A thay vì B" — chiến thuật: | Bước | Cách | |---|---| | ⚠ Liệt kê ưu điểm của B | | | ⚠ Loại mọi phương án nêu ưu điểm của B | | | ⚠ Phương án còn lại là đáp án | | | ⚠ Ở đây | ⚠ ba phương án là ưu điểm của Cosmos → loại cả ba |

Từ khoá nhận diện:

"rẻ nhất, tiết kiệm chi phí" → ⚠ Table Storage "độ trễ cam kết, toàn cầu, chỉ mục đầy đủ" → ⚠ Cosmos DB "cùng API, nâng cấp sau được" → ⚠ bắt đầu bằng Table Storage

⚠ Khi nào Table Storage là lựa chọn đúng Khi nào
⚠ Dữ liệu lớn, truy cập bằng khoá
⚠ Không cần độ trễ cam kết
⚠ Không cần đa vùng chủ động
⚠ Ngân sách là ràng buộc chính
⚠ Ví dụ điển hình ⚠ log thiết bị, dữ liệu telemetry, bảng tra cứu lớn
⚠ Khi nào phải nâng lên Cosmos Khi nào
⚠ Cần SLA về độ trễ
⚠ Người dùng ở nhiều châu lục
⚠ Truy vấn theo trường không phải khoá
⚠ Cần thông lượng cấp phát ổn định
⚠ Thuận lợi ⚠ API tương thích nên mã nguồn thay đổi ít
⚠ Nguyên tắc chọn dịch vụ trong đề thi Nguyên tắc
⚠ Không có dịch vụ nào "tốt nhất" tuyệt đối
⚠ Đề luôn nêu ràng buộc: chi phí, độ trễ, phạm vi
⚠ Ràng buộc quyết định đáp án
⚠ Đọc kỹ ⚠ ràng buộc thường nằm ở câu cuối của đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ràng buộc chính là chi phí hay hiệu năng | | | Truy vấn có luôn dùng khoá không | | | Người dùng ở một vùng hay nhiều vùng | |

Và chiến thuật hiệu quả nhất cho dạng câu "vì sao chọn dịch vụ rẻ hơn": nhận ra rằng mọi phương án ca ngợi năng lực đều đang mô tả dịch vụ đắt hơn. Lý do chọn cái rẻ gần như luôn chỉ có một, và đó chính là giá.

Câu 13 Relational data
Which of the follwing is a consequnce of having a foreign key relationship between two relational data tables?
  1. A An INSERT statement will fail if the value of the foreign key column, other than NULL, doesn't exist in the other table.
  2. B You can DELETE a row of a data table that has several other rows in other tables dependent on it as a foreign key.
  3. C If the user attempts to INSERT data into one table, and the foreign key doesn't exist in the other table, the database will insert a new row for it to maintain intregity.
Xem giải thích

Đáp án

A — Câu lệnh INSERT sẽ THẤT BẠI nếu giá trị của cột khoá ngoại (khác NULL) không tồn tại ở bảng kia.

Vì sao đúng

⚠ Khoá ngoại thực thi TOÀN VẸN THAM CHIẾU:

⚠ Bảng KhachHang: id = 1, 2, 3
⚠ INSERT DonHang (khachHangId = 99)
        ↓
⚠ CSDL kiểm: có khách 99 không?
        ↓ KHÔNG
⚠ TỪ CHỐI — lỗi vi phạm ràng buộc
Quy tắc Nội dung
⚠ Giá trị khoá ngoại phải TỒN TẠI ở bảng cha
⚠ NULL được phép ⚠ nếu cột cho phép NULL
⚠ Xoá dòng cha đang được tham chiếu bị CHẶN ⚠ trừ khi khai CASCADE

Vì sao các phương án khác sai

  • B (xoá được dòng cha dù có dòng con phụ thuộc) — ⚠ SAI với mặc định: ⚠ CSDL sẽ ⚠ chặn; ⚠ chỉ khi khai ⚠ ON DELETE CASCADE mới xoá theo.

  • C (CSDL sẽ tự CHÈN dòng mới vào bảng cha) — ⚠ hoàn toàn không có cơ chế này: ⚠ tự bịa dữ liệu là điều CSDL không bao giờ làm.

Ghi nhớ

⚠ Bốn hành vi ON DELETE / ON UPDATE: | Hành vi | Nội dung | |---|---| | ⚠ NO ACTION / RESTRICT | ⚠ MẶC ĐỊNH — chặn thao tác | | ⚠ CASCADE | ⚠ xoá hoặc sửa lan sang dòng con | | ⚠ SET NULL | ⚠ đặt khoá ngoại thành NULL | | ⚠ SET DEFAULT | ⚠ đặt về giá trị mặc định |

Từ khoá nhận diện:

"giá trị phải tồn tại ở bảng cha" → ⚠ toàn vẹn tham chiếu "xoá cha thì xoá luôn con" → ⚠ CASCADE "không cho xoá khi còn con" → ⚠ mặc định "mỗi giá trị chỉ xuất hiện một lần" → ⚠ UNIQUE, không phải khoá ngoại

⚠ Vì sao CASCADE cần thận trọng Lý do
⚠ Xoá một khách hàng có thể xoá hàng nghìn đơn hàng
⚠ Lan truyền qua nhiều tầng bảng
⚠ Không có xác nhận, không hỏi lại
⚠ An toàn hơn ⚠ xoá mềm bằng cột trạng thái, không xoá thật
⚠ Khoá ngoại và hiệu năng Điểm
⚠ Mỗi INSERT phải kiểm tra bảng cha ⚠ tốn thêm một lần tra
⚠ Nên có CHỈ MỤC trên cột khoá ngoại ⚠ hay bị quên
⚠ Thiếu chỉ mục làm việc xoá cha rất chậm
⚠ Đánh đổi ⚠ chậm hơn một chút để đổi lấy dữ liệu luôn nhất quán
⚠ Năm loại ràng buộc trong SQL Ràng buộc
⚠ PRIMARY KEY ⚠ duy nhất, không NULL
⚠ FOREIGN KEY ⚠ toàn vẹn tham chiếu
⚠ UNIQUE ⚠ không trùng, cho phép NULL
⚠ CHECK ⚠ điều kiện giá trị
⚠ NOT NULL ⚠ bắt buộc có giá trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột khoá ngoại đã có chỉ mục chưa | | | Có CASCADE nào có thể xoá lan rộng không | | | Cột khoá ngoại có được phép NULL không | |

Và điều cần cân nhắc kỹ trước khi bật CASCADE trên một quan hệ khoá ngoại: một lệnh DELETE trông vô hại có thể lan qua nhiều tầng bảng và không có bước xác nhận nào. Xoá mềm bằng cột trạng thái an toàn hơn hẳn trong hệ thống nghiệp vụ.

Câu 14 Non-relational deployment
Which of the following metrics affect how much an Azure Redis Cache instance costs?
  1. A Region, pricing tier, hours
  2. B Region, Consumed storage, pricing tier
  3. C Region, Pricing tier
  4. D Per transaction
Xem giải thích

Đáp án

A — Vùng (region), bậc giá (pricing tier) và số giờ chạy.

Vì sao đúng

⚠ Redis tính tiền như một tài nguyên được CẤP PHÁT, không theo lượt dùng: | Yếu tố | Nội dung | |---|---| | ⚠ Vùng | ⚠ giá khác nhau giữa các vùng Azure | | ⚠ Bậc giá | ⚠ Basic, Standard, Premium + kích thước bộ nhớ | | ⚠ Số giờ | ⚠ tính theo thời gian instance TỒN TẠI |

⚠ Instance đang chạy
        ↓
⚠ Tính tiền theo GIỜ
        ↓
⚠ KHÔNG có request nào cũng vẫn tính
        ↓
⚠ Khác hẳn mô hình serverless

Vì sao các phương án khác sai

  • D (theo từng giao dịch) — ⚠ SAI: ⚠ Redis ⚠ không tính theo số lệnh.

  • B (vùng, dung lượng đã DÙNG, bậc giá) — ⚠ SAI ở "dung lượng đã dùng": ⚠ bạn trả cho dung lượng ⚠ đã cấp phát theo bậc, ⚠ dùng hết hay không cũng vậy.

  • C (chỉ vùng và bậc giá) — ⚠ thiếu yếu tố THỜI GIAN, ⚠ mà đó chính là cách nhân ra hoá đơn.

Ghi nhớ

⚠ Ba bậc chính của Azure Cache for Redis: | Bậc | Đặc điểm | |---|---| | ⚠ Basic | ⚠ một node, KHÔNG SLA — chỉ cho dev/test | | ⚠ Standard | ⚠ hai node chính-phụ, có SLA | | ⚠ Premium | ⚠ phân cụm, bền vững, VNet, geo-replication | | ⚠ Bậc mới hơn | ⚠ Enterprise và Enterprise Flash |

Từ khoá nhận diện:

"tính theo giờ, theo bậc" → ⚠ Redis, VM, App Service Plan "tính theo lượt gọi" → ⚠ Functions Consumption, Logic Apps "tính theo RU cấp phát" → ⚠ Cosmos DB "tính theo GB lưu và thao tác" → ⚠ Storage

⚠ Vì sao Basic không dùng cho môi trường thật Lý do
⚠ Chỉ MỘT node
⚠ Bảo trì hoặc lỗi là mất toàn bộ cache
⚠ KHÔNG có SLA
⚠ Hậu quả ⚠ cache trống đồng nghĩa dồn toàn bộ tải xuống CSDL
⚠ Cache stampede — rủi ro cần biết Rủi ro
⚠ Cache mất hoặc hết hạn đồng loạt
⚠ Hàng nghìn yêu cầu cùng lúc đổ xuống CSDL
⚠ CSDL quá tải và sập
⚠ Giảm thiểu ⚠ thời gian hết hạn NGẪU NHIÊN hoá, khoá khi nạp lại
⚠ Ứng dụng phổ biến của Redis Ứng dụng
⚠ Cache dữ liệu đọc nhiều
⚠ Lưu session ⚠ giúp bỏ session affinity ở load balancer
⚠ Hàng đợi và pub/sub nhẹ
⚠ Bảng xếp hạng, đếm lượt
⚠ Khoá phân tán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bậc đang dùng có SLA không | | | Ứng dụng có chạy được khi cache trống không | ⚠ phải chạy được | | Thời gian hết hạn có bị đồng loạt không | |

Và nguyên tắc thiết kế quan trọng nhất khi đưa cache vào kiến trúc, thường chỉ được kiểm chứng vào lúc sự cố: ứng dụng phải hoạt động đúng khi cache trống rỗng. Cache là tối ưu hoá, không phải nguồn sự thật.

Câu 15 Azure Storage
What feature of Azure Blob Storage, if enabled, allows you to retrieve files that have previously been deleted within a time period?
  1. A Change Feed
  2. B Immutable blobs
  3. C Azure Policy
  4. D Soft Delete
Xem giải thích

Đáp án

D — Soft Delete (xoá mềm).

Vì sao đúng

⚠ Soft delete giữ lại blob đã xoá trong thời gian lưu giữ đặt trước:

⚠ Xoá blob
        ↓ ⚠ soft delete đang BẬT
⚠ Blob chuyển sang trạng thái "đã xoá mềm"
   ⚠ không hiện trong danh sách thông thường
        ↓ ⚠ trong thời hạn (1-365 ngày)
⚠ Khôi phục được bằng Undelete
        ↓ ⚠ hết hạn
⚠ Xoá vĩnh viễn
Ba mức soft delete Bảo vệ
⚠ Blob soft delete ⚠ từng blob
⚠ Container soft delete ⚠ cả container
⚠ Account-level (Storage) ⚠ có ở Recovery Services vault

Vì sao các phương án khác sai

  • B (Immutable blobs) — ⚠ NGĂN xoá và sửa ngay từ đầu: ⚠ chính sách WORM cho tuân thủ; ⚠ nó ⚠ phòng ngừa, không ⚠ khôi phục.

  • A (Change Feed) — ⚠ nhật ký thay đổi có thứ tự: ⚠ cho biết đã có gì thay đổi, ⚠ không khôi phục nội dung.

  • C (Azure Policy) — ⚠ quản trị và tuân thủ, ⚠ không liên quan tới khôi phục dữ liệu.

Ghi nhớ

⚠ Bốn tính năng bảo vệ dữ liệu Blob — bảng phải thuộc: | Tính năng | Nội dung | |---|---| | ⚠ Soft delete | ⚠ khôi phục sau khi xoá | | ⚠ Versioning | ⚠ giữ mọi phiên bản khi GHI ĐÈ | | ⚠ Snapshot | ⚠ ảnh chụp thủ công tại một thời điểm | | ⚠ Immutability (WORM) | ⚠ KHÔNG cho xoá hay sửa trong thời hạn | | ⚠ Point-in-time restore | ⚠ khôi phục cả container về mốc thời gian |

Từ khoá nhận diện:

"khôi phục file đã xoá" → ⚠ soft delete "khôi phục nội dung bị GHI ĐÈ" → ⚠ versioning "không được phép xoá, tuân thủ pháp lý" → ⚠ immutable / WORM "theo dõi mọi thay đổi theo thứ tự" → ⚠ change feed

⚠ Soft delete và versioning — khác nhau Khác nhau
⚠ Soft delete cứu khi XOÁ
⚠ Versioning cứu khi GHI ĐÈ
⚠ Ghi đè cũng làm mất dữ liệu như xoá ⚠ điểm hay bị quên
⚠ Nên bật ⚠ CẢ HAI cho dữ liệu quan trọng
⚠ Vì sao chúng quan trọng với mã độc tống tiền Lý do
⚠ Mã độc thường GHI ĐÈ file bằng bản mã hoá
⚠ Chỉ soft delete thôi không cứu được ⚠ vì không phải thao tác xoá
⚠ Versioning giữ lại bản gốc trước khi bị ghi đè
⚠ Thêm ⚠ immutability chặn cả việc ghi đè
⚠ Cái giá Cái giá
⚠ Dữ liệu giữ lại vẫn TÍNH TIỀN lưu trữ
⚠ Versioning trên dữ liệu ghi nhiều rất tốn
⚠ Cân bằng ⚠ đặt thời hạn hợp lý, dùng lifecycle để dọn phiên bản cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật cả soft delete lẫn versioning chưa | | | Thời hạn giữ lại là bao nhiêu ngày | | | Chi phí lưu bản cũ có được kiểm soát không | |

Và lỗ hổng hay gặp trong kế hoạch bảo vệ dữ liệu blob, chỉ lộ ra khi thật sự cần: bật soft delete mà quên versioning. Mã độc tống tiền không xoá file của bạn — nó ghi đè lên chúng.

Câu 16 Non-relational DB
Which of the following is considered a downside to using a non-relational data store compared to a relational database?
  1. A An non-relational data store does not enforce a consistent data state within the database.
  2. B Non-relational data store does not support different data storage types
  3. C Relational data stores are better for extremely high-throughput
  4. D It's harder to modify the data schema of a non-relational data store
Xem giải thích

Đáp án

A — Kho dữ liệu phi quan hệ KHÔNG cưỡng chế một trạng thái dữ liệu NHẤT QUÁN bên trong cơ sở dữ liệu.

Vì sao đúng

⚠ Đây là đánh đổi nền tảng giữa hai mô hình: | CSDL quan hệ | CSDL phi quan hệ | |---|---| | ⚠ Ràng buộc khoá ngoại | ⚠ thường KHÔNG có | | ⚠ Giao dịch ACID mạnh | ⚠ thường chỉ trong phạm vi hẹp | | ⚠ Schema cưỡng chế | ⚠ schema linh hoạt | | ⚠ CSDL bảo đảm nhất quán | ⚠ ỨNG DỤNG phải tự bảo đảm |

⚠ Quan hệ
   ⚠ CSDL từ chối dữ liệu sai
⚠ Phi quan hệ
   ⚠ CSDL nhận hết
        ↓
⚠ Trách nhiệm chuyển sang ỨNG DỤNG

Vì sao các phương án khác sai

  • D (khó sửa schema của kho phi quan hệ) — ⚠ NGƯỢC: ⚠ linh hoạt schema là ⚠ ưu điểm lớn nhất của phi quan hệ.

  • C (quan hệ tốt hơn cho thông lượng RẤT CAO) — ⚠ NGƯỢC: ⚠ phi quan hệ thường co giãn ngang tốt hơn.

  • B (phi quan hệ không hỗ trợ nhiều kiểu lưu trữ) — ⚠ SAI: ⚠ có tới năm mô hình khác nhau.

Ghi nhớ

⚠ Đánh đổi quan hệ và phi quan hệ — bảng cân bằng: | Tiêu chí | Quan hệ | Phi quan hệ | |---|---|---| | ⚠ Nhất quán | ⚠ mạnh, CSDL cưỡng chế | ⚠ yếu hơn, ứng dụng lo | | ⚠ Schema | ⚠ cứng, an toàn | ⚠ linh hoạt | | ⚠ Co giãn | ⚠ chủ yếu theo chiều DỌC | ⚠ theo chiều NGANG | | ⚠ Truy vấn phức tạp | ⚠ mạnh: JOIN, tổng hợp | ⚠ hạn chế hơn | | ⚠ Thông lượng cực cao | ⚠ khó hơn | ⚠ thiết kế cho việc đó |

Từ khoá nhận diện:

"nhất quán mạnh, giao dịch tài chính" → ⚠ quan hệ "schema thay đổi, thông lượng cao, toàn cầu" → ⚠ phi quan hệ "báo cáo phức tạp nhiều bảng" → ⚠ quan hệ "ứng dụng phải tự đảm bảo tính đúng đắn" → ⚠ phi quan hệ

⚠ Định lý CAP — nền lý thuyết Nội dung
⚠ Consistency, Availability, Partition tolerance
⚠ Khi mạng bị chia cắt, chỉ giữ được HAI trong ba
⚠ CSDL phân tán buộc phải chịu chia cắt
⚠ Nên phải chọn ⚠ nhất quán hay sẵn sàng
⚠ Cosmos DB ⚠ cho phép chọn qua năm mức nhất quán
⚠ Hệ quả thực tế của nhất quán yếu Hệ quả
⚠ Đọc ngay sau khi ghi có thể ra dữ liệu CŨ
⚠ Hai bản sao có thể lệch nhau tạm thời
⚠ Ứng dụng phải xử lý được tình huống đó
⚠ Mức Session của Cosmos ⚠ đảm bảo bạn luôn đọc được thứ chính bạn vừa ghi
⚠ Xu hướng hiện nay Xu hướng
⚠ Ranh giới đang mờ dần
⚠ CSDL quan hệ hỗ trợ cột JSON
⚠ CSDL NoSQL thêm giao dịch trong phạm vi hẹp
⚠ Chọn theo ⚠ bài toán cụ thể, không theo nhãn công nghệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu sai một chút có gây hậu quả nghiêm trọng không | | | Ứng dụng có xử lý được dữ liệu đọc ra hơi cũ không | | | Truy vấn có cần JOIN nhiều bảng không | |

Và điều thật sự thay đổi khi chuyển từ cơ sở dữ liệu quan hệ sang phi quan hệ, quan trọng hơn cú pháp truy vấn: trách nhiệm giữ dữ liệu đúng đắn chuyển từ cơ sở dữ liệu sang mã ứng dụng của bạn.

Câu 17 Data warehouse
Which of the following data types can be called unstructured data?
  1. A Azure Table Storage
  2. B SQL Database table
  3. C Contents of a Blob storage container
  4. D JSON data
Xem giải thích

Đáp án

C — Nội dung của một Blob storage container.

Vì sao đúng

⚠ Blob lưu ĐỐI TƯỢNG tuỳ ý, không có schema: | Nội dung blob điển hình | Loại | |---|---| | ⚠ Ảnh, video, âm thanh | ⚠ phi cấu trúc | | ⚠ PDF, tài liệu Word | ⚠ phi cấu trúc | | ⚠ Tệp sao lưu, ảnh đĩa | ⚠ phi cấu trúc | | ⚠ Log dạng văn bản tự do | ⚠ phi cấu trúc |

⚠ Azure hiểu blob như một CHUỖI BYTE
        ↓
⚠ Không biết bên trong là gì
⚠ Không truy vấn theo trường được
        ↓
⚠ PHI CẤU TRÚC

Vì sao các phương án khác sai

  • D (dữ liệu JSON) — ⚠ bẫy đáng chú ý: ⚠ JSON là ⚠ BÁN cấu trúc — ⚠ có khoá, có giá trị, có phân cấp.

  • A (Azure Table Storage) — ⚠ bán cấu trúc: ⚠ có thực thể và thuộc tính.

  • B (bảng SQL Database) — ⚠ CÓ cấu trúc: ⚠ schema cố định.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19497 trong cùng lô.

Câu Hỏi gì Khoá
⚠ #19497 ⚠ dữ liệu thiếu trường thuộc loại nào ⚠ bán cấu trúc
⚠ #19507 (câu này) ⚠ cái nào là PHI cấu trúc ⚠ nội dung blob
⚠ Bổ sung nhau ⚠ hai câu vẽ đủ ba loại dữ liệu
⚠ Điểm chốt ⚠ JSON là BÁN cấu trúc, không phải phi cấu trúc

⚠ Ba loại dữ liệu — bảng ví dụ đầy đủ: | Loại | Ví dụ | Kho Azure | |---|---|---| | ⚠ Có cấu trúc | ⚠ bảng SQL, CSV có schema | ⚠ Azure SQL | | ⚠ Bán cấu trúc | ⚠ JSON, XML, Table Storage | ⚠ Cosmos DB, Table Storage | | ⚠ Phi cấu trúc | ⚠ ảnh, video, PDF, âm thanh | ⚠ Blob Storage, Data Lake |

Từ khoá nhận diện:

"ảnh, video, tệp nhị phân" → ⚠ phi cấu trúc "JSON, XML, có khoá và giá trị" → ⚠ bán cấu trúc "bảng có cột cố định" → ⚠ có cấu trúc "Data Lake" → ⚠ chứa được cả ba loại

⚠ Ba loại blob Loại
⚠ Block blob ⚠ phổ biến nhất: tệp, ảnh, sao lưu
⚠ Append blob ⚠ chỉ ghi thêm cuối: log
⚠ Page blob ⚠ truy cập ngẫu nhiên: đĩa máy ảo
⚠ Chọn sai loại ⚠ không đổi được, phải sao chép sang blob mới
⚠ Data Lake Storage Gen2 — mở rộng của Blob Nội dung
⚠ Là Blob Storage có bật NAMESPACE PHÂN CẤP
⚠ Có thư mục thật, đổi tên thư mục là thao tác nguyên tử
⚠ Phân quyền POSIX ở mức thư mục và tệp
⚠ Dùng cho ⚠ phân tích dữ liệu lớn
⚠ Bật khi tạo ⚠ không bật được sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có schema để truy vấn không | | | Có cần namespace phân cấp không | ⚠ quyết định lúc tạo tài khoản | | Loại blob nào phù hợp | |

Và ranh giới hay bị vượt nhầm khi phân loại dữ liệu: JSON nằm ở nhóm bán cấu trúc, không phải phi cấu trúc. Nó không có schema cứng, nhưng nó hoàn toàn có cấu trúc để máy đọc và truy vấn được.

Câu 18 Non-relational data
What type of storage is Azure Table Storage?
  1. A Column-family storage
  2. B Document storage
  3. C Object storage
  4. D Key-value storage
Xem giải thích

Đáp án

D — Lưu trữ KHOÁ-GIÁ TRỊ (key-value storage).

Vì sao đúng

⚠ Table Storage định danh mỗi thực thể bằng cặp khoá:

⚠ PartitionKey + RowKey  →  Thực thể
   ⚠ "2026-09" + "user1024" → {tên, email, hạng}
        ↓
⚠ Tra bằng cặp khoá: cực nhanh
⚠ Truy vấn theo trường khác: quét bảng
Đặc điểm Nội dung
⚠ Không schema cố định ⚠ mỗi thực thể có bộ thuộc tính riêng
⚠ Chỉ mục chỉ trên khoá chính
⚠ Không JOIN, không giao dịch chéo phân vùng
⚠ Rất rẻ
⚠ Giới hạn ⚠ 1MB mỗi thực thể, 255 thuộc tính

Vì sao các phương án khác sai

  • A (column-family) — ⚠ là mô hình của Cassandra và HBase; ⚠ tên "Table" dễ gây nhầm nhưng cấu trúc khác.

  • B (document storage) — ⚠ là Cosmos DB NoSQL, MongoDB: ⚠ tài liệu JSON lồng nhau, truy vấn được theo mọi trường.

  • C (object storage) — ⚠ là Blob Storage.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về Table Storage trong cùng lô.

Câu Hỏi gì Khoá
⚠ #19496 ⚠ cái nào là kho khoá-giá trị ⚠ Table Storage, Redis, Cosmos Table API
⚠ #19502 ⚠ vì sao chọn Table Storage ⚠ rẻ nhất
⚠ #19508 (câu này) ⚠ Table Storage thuộc loại nào ⚠ khoá-giá trị
⚠ Ba câu ⚠ cùng một dịch vụ, ba góc hỏi, không mâu thuẫn

⚠ Năm mô hình lưu trữ — bảng đối chiếu tên dịch vụ: | Mô hình | Dịch vụ | |---|---| | ⚠ Khoá-giá trị | ⚠ Table Storage, Redis | | ⚠ Tài liệu | ⚠ Cosmos NoSQL, MongoDB API | | ⚠ Cột rộng | ⚠ Cassandra API | | ⚠ Đồ thị | ⚠ Gremlin API | | ⚠ Đối tượng | ⚠ Blob Storage | | ⚠ Cẩn thận | ⚠ tên "Table" KHÔNG có nghĩa là quan hệ |

Từ khoá nhận diện:

"PartitionKey và RowKey" → ⚠ Table Storage "tài liệu JSON lồng nhau" → ⚠ document store "cột rộng, hàng triệu cột" → ⚠ column-family "tệp nhị phân" → ⚠ object store

⚠ Thiết kế PartitionKey — quyết định quan trọng nhất Nguyên tắc
⚠ Truy vấn có cả PartitionKey và RowKey: nhanh nhất
⚠ Có PartitionKey, quét trong phân vùng: chấp nhận được
⚠ Không có PartitionKey: QUÉT TOÀN BẢNG — rất chậm
⚠ Cân bằng ⚠ phân vùng đủ nhỏ để nhanh, đủ lớn để giao dịch nhóm được
⚠ Giao dịch trong Table Storage Giới hạn
⚠ Entity Group Transaction chỉ trong CÙNG một phân vùng
⚠ Tối đa 100 thực thể mỗi giao dịch
⚠ Nghĩa là ⚠ PartitionKey quyết định phạm vi giao dịch của bạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn chính có PartitionKey không | | | Các thực thể cần giao dịch chung có cùng phân vùng không | | | Có cần truy vấn theo trường không phải khoá không | ⚠ thì Table Storage không hợp |

Và điều quyết định toàn bộ hiệu năng của một bảng trong Table Storage, cần chốt trước khi ghi dòng dữ liệu đầu tiên: thiết kế PartitionKey. Nó vừa định đoạt tốc độ truy vấn, vừa định đoạt phạm vi giao dịch bạn có thể thực hiện.

Câu 19 Non-relational DB
What do you get when you use Cool access tier for Azure Blob Storage?
  1. A Less expensive per GB to store the file, and more expensive to access the file
  2. B The fastest way to retrieve files in Azure for high-performance needs
  3. C A way to archive files that are needed only in emergency, but take a few hours to recover if you need them
  4. D The lease expensive way to store files per GB in Azure
Xem giải thích

Đáp án

A — Rẻ hơn khi LƯU mỗi GB, và đắt hơn khi TRUY CẬP tệp.

Vì sao đúng

⚠ Đây chính là nguyên tắc đánh đổi của mọi tầng lưu trữ: | Tầng | Giá lưu | Giá truy cập | Thời gian tối thiểu | |---|---|---|---| | ⚠ Hot | ⚠ cao nhất | ⚠ thấp nhất | ⚠ không | | ⚠ Cool | ⚠ thấp hơn | ⚠ cao hơn | ⚠ 30 ngày | | ⚠ Cold | ⚠ thấp hơn nữa | ⚠ cao hơn nữa | ⚠ 90 ngày | | ⚠ Archive | ⚠ rẻ nhất | ⚠ đắt nhất + phải rã đông | ⚠ 180 ngày |

Vì sao các phương án khác sai

  • D (rẻ nhất mỗi GB) — ⚠ SAI: ⚠ Archive mới là rẻ nhất.

  • C (lưu trữ khẩn cấp, khôi phục mất vài giờ) — ⚠ đó là ARCHIVE: ⚠ Cool truy cập ⚠ ngay lập tức, không cần rã đông.

  • B (cách lấy tệp nhanh nhất, hiệu năng cao) — ⚠ đó là Hot hoặc Premium.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng nguyên lý với #19498 trong lô — ⚠ #19498 hỏi về tầng của Azure Files, ⚠ câu này hỏi tầng của Blob; ⚠ cùng một đánh đổi lưu / truy cập.

⚠ Điểm phân biệt then chốt giữa Cool và Archive: | Tiêu chí | Cool | Archive | |---|---|---| | ⚠ Truy cập | ⚠ NGAY LẬP TỨC | ⚠ phải RÃ ĐÔNG | | ⚠ Thời gian rã đông | ⚠ không cần | ⚠ vài giờ (standard) hoặc dưới 1 giờ (high) | | ⚠ Thời gian tối thiểu | ⚠ 30 ngày | ⚠ 180 ngày | | ⚠ Nhầm hai cái này | ⚠ là lỗi thiết kế đắt giá |

Từ khoá nhận diện:

"rẻ hơn để lưu, đắt hơn để đọc" → ⚠ Cool "rẻ nhất, chấp nhận chờ hàng giờ" → ⚠ Archive "truy cập thường xuyên" → ⚠ Hot "độ trễ thấp, IOPS cao" → ⚠ Premium

⚠ Phí rút sớm — cái bẫy chi phí Nội dung
⚠ Chuyển ra khỏi Cool trước 30 ngày bị phạt
⚠ Archive trước 180 ngày bị phạt nặng hơn
⚠ Phạt tính theo số ngày CÒN THIẾU
⚠ Hậu quả ⚠ đưa dữ liệu xuống tầng lạnh rồi lại cần dùng là tốn gấp bội
⚠ Lifecycle management — cách làm đúng Cách
⚠ Đặt luật theo TUỔI của blob
⚠ Ví dụ: sau 30 ngày sang Cool, sau 180 ngày sang Archive
⚠ Sau 7 năm thì xoá
⚠ Lọc theo tiền tố hoặc thẻ blob
⚠ Ưu điểm ⚠ tự động, không phụ thuộc trí nhớ của ai
⚠ Đặt tầng ở đâu Nơi
⚠ Tầng mặc định của tài khoản ⚠ Hot hoặc Cool
⚠ Tầng của từng blob ⚠ ghi đè mặc định
⚠ Archive chỉ đặt ở mức BLOB ⚠ không đặt được ở mức tài khoản

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu này sẽ được đọc mấy lần trong 30 ngày tới | | | Có chịu được chờ vài giờ để lấy không | ⚠ quyết định Archive có dùng được không | | Đã có luật lifecycle chưa | |

Và cái bẫy chi phí đứng sau nhiều quyết định "tiết kiệm" phản tác dụng: phí rút sớm khi chuyển dữ liệu ra khỏi tầng lạnh trước thời hạn tối thiểu. Chuyển xuống Archive rồi cần dùng lại sau một tháng tốn hơn nhiều so với việc cứ để ở Hot.

Câu 20 Relational DB Management
You have a production application that reads and writes to an Azure SQL Database around 100 times per second. Ocassionally, you get an exception inside your application, "40501 - The service is currently busy." What is the likely cause of this type of error? And what is the mitigation for that?
  1. A Azure SQL Database has per DTU IOPS limits. Increase the DTUs to a higher level, or retry the request after a few seconds delay.
  2. B Azure SQL Database has IOPS limits. Move the database to a SQL Server in a VM or a Managed SQL Instance.
  3. C Azure SQL Database runs on the same server as other Azure clients, and sometimes their usage will affect yours. Move to an isolated DB instance.
  4. D Azure SQL Database has per DTU IOPS limits. Those limits can be increased by opening a support ticket with Azure.
Xem giải thích

Đáp án

A — Azure SQL Database có giới hạn IOPS theo DTU. Hãy tăng DTU lên bậc cao hơn, hoặc thử lại sau vài giây.

Vì sao đúng

⚠ Lỗi 40501 "The service is currently busy" là lỗi ĐIỀU TIẾT (throttling):

⚠ Ứng dụng đẩy 100 thao tác/giây
        ↓
⚠ Vượt giới hạn IOPS của bậc DTU hiện tại
        ↓
⚠ Azure SQL từ chối tạm thời
        ↓
⚠ Trả về 40501
Hai hướng xử lý Nội dung
⚠ Ngắn hạn ⚠ thử lại với backoff — lỗi TẠM THỜI
⚠ Dài hạn ⚠ nâng bậc DTU hoặc chuyển sang vCore
⚠ Kèm theo ⚠ tối ưu truy vấn và chỉ mục để giảm IOPS

Vì sao các phương án khác sai

  • D (mở ticket hỗ trợ để tăng giới hạn) — ⚠ SAI: ⚠ giới hạn gắn với bậc dịch vụ, ⚠ ⚠ bạn tự nâng bậc được ngay, không cần ticket.

  • B (phải chuyển sang SQL trên VM hoặc Managed Instance) — ⚠ phản ứng thái quá: ⚠ nâng bậc là đủ.

  • C (bị khách hàng khác ảnh hưởng, cần instance cách ly) — ⚠ SAI: ⚠ Azure SQL ⚠ cách ly tài nguyên theo bậc đã mua, không phải "hàng xóm ồn ào".

Ghi nhớ

⚠ Lỗi tạm thời trong Azure SQL — phải biết: | Mã | Ý nghĩa | |---|---| | ⚠ 40501 | ⚠ dịch vụ đang bận — điều tiết | | ⚠ 40197 / 40613 | ⚠ CSDL đang di chuyển hoặc không sẵn sàng | | ⚠ 49918 / 49919 / 49920 | ⚠ không đủ tài nguyên để xử lý yêu cầu | | ⚠ 10928 / 10929 | ⚠ vượt giới hạn tài nguyên | | ⚠ Tất cả | ⚠ là lỗi TẠM THỜI, phải có logic thử lại |

Từ khoá nhận diện:

"service is currently busy" → ⚠ điều tiết, thử lại và nâng bậc "login failed" → ⚠ xác thực, không phải tài nguyên "cannot open server ... requested by the login" → ⚠ tường lửa "deadlock victim" → ⚠ xung đột khoá, cũng nên thử lại

⚠ Logic thử lại đúng cách Nguyên tắc
⚠ Exponential backoff ⚠ 1s, 2s, 4s, 8s...
⚠ Thêm jitter ngẫu nhiên ⚠ tránh mọi client thử lại cùng lúc
⚠ Giới hạn số lần thử
⚠ CHỈ thử lại lỗi tạm thời ⚠ đừng thử lại lỗi cú pháp hay lỗi quyền
⚠ Thư viện ⚠ Polly, EF Core có sẵn cơ chế này
⚠ Trước khi nâng bậc, hãy xem Xem gì
⚠ Truy vấn nào tốn tài nguyên nhất ⚠ Query Store
⚠ Có chỉ mục nào bị thiếu không
⚠ Có quét toàn bảng không cần thiết không
⚠ Thường ⚠ một chỉ mục đúng chỗ rẻ hơn nhiều so với nâng bậc vĩnh viễn
⚠ DTU và vCore Chọn
⚠ DTU gộp CPU, bộ nhớ, IO thành một số ⚠ khó biết nút thắt ở đâu
⚠ vCore tách riêng ⚠ chẩn đoán dễ hơn, co giãn linh hoạt hơn
⚠ Gặp điều tiết thường xuyên ⚠ cân nhắc chuyển sang vCore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng đã có logic thử lại chưa | | | Truy vấn nào đang ngốn tài nguyên nhất | ⚠ xem trước khi nâng bậc | | Có chỉ mục nào đang thiếu không | |

Và phản xạ nên có trước khi nâng bậc dịch vụ để chữa lỗi điều tiết: mở Query Store xem truy vấn nào đang ngốn tài nguyên nhất. Rất thường xuyên, một chỉ mục thiếu là nguyên nhân thật, và nâng bậc chỉ là trả tiền để che giấu nó.