Database Indexing, Archiving & Purging

Database Indexing, Archiving & Purging
Index thôi chưa đủ, nhanh hay chậm cũng còn tùy vào cách xử lý?

Nếu bạn là một backend engineer thì 80% khả năng là bạn sẽ được hỏi về database index. Ví dụ như:
Database index là gì?
Ưu điểm và nhược điểm khi sử dụng index là gì?
Sự khác nhau giữa Clustered và Non-clustered indexes là gì?

Ở bài này mình muốn chia sẻ với các bạn một số điều xoay quanh chủ đề về database index. Vì database là rất rộng nên chỉ nên tập trung vào những cái cốt yếu và hay sử dụng nhất thôi.

1. Database index là một cách tổ trức lưu trữ data theo cấu trúc B-Tree (xem ảnh B-Tree) để đạt được kết quả truy vấn nhanh nhất.

Hãy hình dung nếu bạn đi du lịch đền Hùng mà lạc mất người thân xong không có phương tiện gì để liên lạc, tìm thì sẽ tìm được thôi nhưng chắc chắn là mất không ít thời gian. Index giống việc bạn có một thiết bị định vị chỗ mà người thân của bạn đang đứng và mau chóng tìm ra họ

2. Ưu và nhược điểm khi sử dụng index.
Ưu điểm là truy vấn rất nhanh trên các table có số lượng bản ghi lớn vài triệu thậm trí vài trăm triệu bản ghi.

3. Nhược điểm là giảm tốc độ ghi, do nó phải đánh index nên lúc ghi performance sẽ chậm hơn, với những table thường xuyên phải đọc ghi và có một lượng lớn bản ghi thì việc đánh index sẽ làm cho tốc độ của table đó giảm đi rõ rệt.

4. Khác nhau giữa Clustered và Non-Clustered indexes là:
Clustered chỉ được thiết lập ở trên một table, cho kết quả đọc nhanh hơn non-clustered

Non-Clustered có thể thiết lập trên nhiều table (nó sẽ có tác dụng khi bạn xây dựng View, Aggregate functions). Ưu điểm là tốc độ ghi nhanh hơn Clustered.

Clustered & Non-clustered indexes

5. Có tới trên 95% SQL server sử dụng index cho mục đích query.

6. Đối với việc quản lý các sector trên HDD thì việc phân mảnh cũng sẽ làm giảm tốc độ query của index, SSD thì tốt hơn. Tuy nhiên việc cần rebuild lại index đôi khi là cần thiết, có những table lớn vài trăm triệu records thì việc rebuild lại index có thể mất tới cả giờ (thường thực hiện việc này vào thời điểm maintain định kỳ, hoặc thông qua một vài job chạy tự động)

Database purge và Database Archive
—————————————————-
Khái niệm này cũng cũ rồi, nhưng nó vẫn đang phát huy hiệu quả nên mình vẫn muốn đề cập ở đây vì biết đâu có ai đó cần.
Việc để một table với vài trăm triệu records đôi khi không phải là giải pháp hay, index thì cũng vẫn ì ạch và chậm chạp. Nên thường thì họ sẽ chia thành Historical data và Production data, nơi historical data là các data cũ (thời gian có thể thiết lập, ví dụ cũ hơn 1 ngày, cũ hơn 1 tuần, hơn 1 tháng… tùy vào nghiệp vụ) data cũ này sẽ được tách riêng hẳn ra. Production data là những data mới nhất, các yêu cầu này sẽ đòi hỏi một số kỹ thuật xây dựng Archiving hoặc Purging cho database.

Data purge & Archive

Lưu ý một vài database đã support automatic purge/archive rồi chỉ cần setup và một vài thứ đáp ứng cho nghiệp vụ của bạn. Tuy nhiên khi truy vấn lại dữ liệu cũ thì chúng ta sẽ phải handle để có thể query được kết quả ở nhiều file data purged khác nhau, các nghiệp vụ truy vấn dữ liệu cũ như: báo cáo năm, báo cáo quý, khảo sát và lập kế hoạch dài hạn…

Luôn định kỳ lưu lại kết quả phân tích hay báo cáo để không phải chạy lại query. Ví dụ 1 năm bạn có 12 lần báo cáo tương ứng với mỗi tháng 1 lần. Đến tháng thứ 12 bạn chỉ cần tổng lại của 12 báo cáo trước là OK, chứ không cần phải chạy 12 truy vấn báo cáo rồi ngồi đợi cả ngày chờ báo cáo generate. Hãy hình dung nhân viên phải nộp báo cáo trong ngày mà cuối ngày rồi vẫn chưa thấy cái báo cáo chạy xong đến khi hết giờ làm việc thì nó xảy ra lỗi … điều gì sẽ xảy ra?

Gravity Model rất hy vọng qua chuỗi các bài về database sẽ giúp các bạn phần nào có được những góc nhìn tốt hơn khi làm việc với database

Chúc các bạn học tập tốt và công tác tốt và luôn yêu code.
Nhớ Like/Comment/Share/follow Gravity Model để đọc thêm những series mới nhé!

Cảm ơn các bạn đã đọc bài

Y Hoang
#Database index
#Database purge
#Database archive
#Clustered indexes
#Non-Clustered indexes

Please follow and like us:

2 thoughts on “Database Indexing, Archiving & Purging

  1. Mình đang hiểu là cluster index sẽ là khoá chính của bảng đó và 1 bảng chỉ có 1 cluster index, trong 1 bảng có thể có nhiều non-cluster, non-cluster có thể bao gồm một hoặc nhiều trường trên bảng đó, NHờ bạn giải thích lại

  2. Hi Văn Sỹ,

    Clustered Index
    Mỗi table chỉ có thể tạo một clustered index nên thông thường hay dùng cho primary key (kiểu số nguyên tự tăng hoặc timestamp)

    Non-Clustered Index
    Maximum là có thể đánh được 249 non-clustered indexs cho mỗi table (các version mới có thể support nhiều hơn nên tới hàng nghìn) thường đánh cho bất kỳ key nào.

Leave a Reply

Your email address will not be published. Required fields are marked *