Thiết kế CSDL và Denormalizing để tối ưu hiệu năng (Phần 2)

Chuẩn hóa CSDL

Mình cóp tạm mấy cái định nghĩa cho nhanh nhé J Mình chỉ tập trung vào phần denormalize thôi

1NF: Một bảng (quan hệ) được gọi là ở dạng chuẩn 1NF nếu và chỉ nếu toàn bộ các miền giá trị của các cột có mặt trong bảng (quan hệ) đều chỉ chứa các giá trị nguyên tử (nguyên tố)

2NF: Một quan hệ ở dạng chuẩn 2NF nếu quan hệ đó:

  •  Là 1NF
  • Các thuộc tính không khoá phải phụ thuộc hàm đầy đủ vào khoá chính

3ND: Một quan hệ ở dạng chuẩn 3NF nếu quan hệ đó:

  • Là 2NF
  • Các thuộc tính không khoá phải phụ thuộc trực tiếp vào khoá chính

Denormalizing để tăng tốc ứng dụng

Một khi bạn tạo ra CSDL cho riêng mình theo chuẩn 3NF thì bạn có thể thực hiện các phương  pháp benchmark và quyết định xem sử dụng cách denormalize để cái thiện hiệu năng cho từng câu truy vấn riêng biệt hoặc cho toàn bộ ứng dụng

Quy trình áp dụng  denormalize

  • Có thể áp dụng đối với bảng hoặc cột
  • Luôn ưu tiên áp dụng normalize trước, không phải chưa chi là đã áp dụng denormalize
  • Cần phải có kiến thức sâu về cách sử dụng dữ liệu cũng như mức độ tăng trưởng của nó

Những lý do để áp dụng denormailize

  • Các câu truy vấn thường xuyên phải thực hiện câu lệnh JOIN để có thể lấy ra được dữ liệu
  • Phần lớn ứng dụng sẽ thực hiện tìm kiếm toàn bảng khi JOIN
  • Các cột dữ liệu lấy ra từ CSDL yêu cầu phải tính toán phức tạp từ các bảng tạm hoặc các câu truy vấn

Những rủi ro khi áp dụng denormalization

Denormalization phải được dựa trên sự hiểu biết rất sâu về ứng dụng và nó chỉ nên thực hiện khi các vấn đề liên quan đến hiệu năng. Chúng ta không nên áp dụng bừa bãi vừa gây ra lãng phí tài nguyên của CSDL cũng như gây khó khăn cho việc lập trình cùng với việc khó kiểm soát được dữ liệu

Ví dụ,

Hiện tại có 2 bảng là Title để chứa danh mục sách, bảng SalesDetail để chứa thông tin chi tiết về việc bán được sách. Nếu muốn biết được bán sách ta thu được bao nhiêu tiền thì thực thực hiện câu lệnh JOIN giữa 2 bảng

  select Title, sum(Quantity)

from Titles t, SalesDetail sd

where t.TitleIdId = sd.TitleIdId

group by Title

Nếu áp dụng denormailize thì ta sẽ thêm 1 cột ở trong bảng Titles luôn. Khi cần lấy ra thì chỉ cần truy vấn vào bảng Titles luôn mà không cần phải truy cập vào bảng SalesDetail.

Tất nhiên cái giá phải trả đó là bạn cần có 1 trigger cho việc insert/update/delete trên bảng SalesDetail để luôn tính toán lại giá trị cho bảng Titles. Việc thực thi trigger và thực hiện cập nhật vào bảng Titles sẽ tốn thêm  chi phí (cost) cho mỗi lần thay đổi giá trị của cột Quantity.

1

Đây cũng là ví dụ tốt cho việc phải quyết định giữa việc thường xuyên truy vấn lượng dữ liệu lớn hay việc thường xuyên chỉnh sửa dữ liệu.

Nói chung lại thì bất kì hình thức denormailization mà bạn chọn sẽ gây nên hiểm nguy cho vấn đề toàn vẹn dữ liệu cho ứng dụng của các bạn. Thế nên các bạn cần phải ghi chép lại cẩn thận và phải được giải quyết trong khâu thiết kế ứng dụng

Nhược điểm của denormalization

  • Làm tăng tốc truy vấn dữ liệu (do hạn chế các câu lệnh JOIN chỉ cần truy vấn vào 1 bảng là có thể lấy ra được hết dữ liệu) nhưng làm chậm đi quá trình chỉnh sửa dữ liệu (do áp dụng trigger làm tăng chi phí khi insert/update/delete)
  • Làm tăng kích cỡ của các bảng (vì phải thiết kế thêm cột, thêm dòng trong CSDL)
  • Luôn luôn phải thực hiện tính toán hoặc xử lý lại khi ứng dụng thay đổi
  • Đối với 1 số trường hợp thì nó là việc code đơn giản hơn nhưng cũng có thể làm phức tạp hơn (cái này thì tùy từng ứng dụng :-?)

Việc cải thiện hiệu năng của denormalization

Denormalization làm tăng hiệu năng của ứng dụng do

  • Làm giảm số lần thực hiện câu lệnh JOIN
  • Làm giảm số lượng khóa ngoại ở các bảng
  • Làm giảm số lượng index, tiết kiệm được dung lượng ổ đĩa, giảm thời gian chỉnh sửa dữ liêu
  • Thực hiện việc tính toán giá trị trước tại thời điểm chỉnh sửa dữ liệu
  • Trong 1 số trường hợp nhất định thì làm giảm số lượng bảng

Tóm lại khi đã quyết định denormalization, bạn cần phải phân tích các yêu cầu  truy cập dữ liệu của ứng dụng. Nếu không thực sự cần thiết thì không nên áp dụng vì thực ra thì nếu sử dụng index tốt cũng như tối ưu hóa lại các câu lệnh truy vấn đã giải quyết được khá nhiều các vấn đề hiệu năng

Một số vấn đề cần xem xét khi denormalization bao gồm:

  • Chỉ ra các giao dịch quan trọng và thời gian phản hồ mong đợi của các giao dịch là bao nhiêu?
  • Tần suất thực hiện của các giao dịch?
  • Những truy quan trọng thường sử dụng bảng hay cột nào? Mỗi lần truy vấn lấy ra bao nhiêu dữ liệu
  • Những câu lệnh hỗn hợp dùng cả select/insert/update/delete thường dùng ở đâu?
  • Câu lệnh ORDER thường xuyên được thực hiện là gì?
  • Những bảng thường xuyên truy cập có nhiều dữ liệu hay không?
  • Có bất kì tiến trình nào thực hiện tổng hợp dữ liệu không?
  • File vật lý của CSDL nằm ở đâu

 

Trong phần tiếp theo thì mình sẽ trình bày các kĩ thuật để áp dụng denormalization

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s