Mít đặc: Chào anh Tuốt, sau nhiều đêm trăn trở, tôi có rất nhiều tò mò về hệ quản trị cơ sở dữ liệu, tại sao nó lại vi diệu như vậy?
Biết tuốt: Bạn có thể nói cụ thể được không?
Mít đặc: Cách nó thực thi câu lệnh SQL, cách nó thực hiện việc select, việc join, rồi tính toán trên một loạt dữ liệu mà hiệu năng vẫn cao, đặc biệt nhiều khi dữ liệu tôi lấy vượt quá RAM, làm sao mà nó có thể kiểm soát được các transaction, làm sao mà nó có thể sống sót khi tắt máy đột ngột rồi rất nhiều cái làm sao. Về truy vấn và index tôi có biết một chút nhưng bây giờ tôi muốn sâu hơn nữa, bạn giúp tôi được chứ?
Biết tuốt: Ok anh Mít, vậy chúng ta đi từ đơn giản tới phức tạp, từ trên xuống dưới nhé! Đầu tiên chúng ta hãy tìm hiểu xem một câu SQL được chạy như thế nào? Rồi đi chi tiết từng phần tôi sẽ nói trong series này nhé!
Mít đặc: Được vậy chúng ta bắt đầu nào
Biết tuốt: Giả sử bạn chạy một câu truy vấn sẽ bắt đầu từ client, có thể là ứng dụng, hay một tool query client như dbforge, dbeaver, navicast ... Về cơ bản cơ sở dữ liệu là một cấu trúc client server
Mít đặc: Chỗ client server thì tôi hiểu rồi, nghĩa là một câu truy vấn sẽ được truyền từ client lên DB server, rồi tiếp đó?
Biết tuốt: Khi server nhận được câu SQL việc quan trọng là nó phải làm là phân tích cú pháp, và validate, sau đó sẽ tối ưu câu lệnh. Quá trình này được gọi là Parsing & Optimization
Mít đặc: Vậy là sau khi được optimize là câu lệnh SQL được chạy đúng không nó chạy như thế nào để lấy dữ liệu ra nhỉ?
Biết tuốt: Sau đó sẽ cần một trình là Relational Operators, trình này sẽ chuyển câu lệnh về các thao tác với file và record. Bạn phải hiểu là các cấu trúc vật lý của database cơ bản là các file, và các bản ghi của bạn là record
Ví dụ câu lệnh dưới đây
SELECT S.sid, S.sname, R.bid
FROM Sailors R, Reserves R
WHERE S.sid = R.sid and S.age > 30
GROUP BY age
Sẽ đưa ra cách thực thi như sau
Lúc này kiến trúc sẽ nhìn như sau
Mít đặc: Ok tôi cũng hiểu rồi, nhưng làm sao nó biết được sử dụng file nào từ câu truy vấn đúng không?
Biết tuốt: Đúng vậy, tiếp đó sẽ có một cấu trúc là Files and Index Management nó sẽ chuyển đổi các table và record như là một tập hợp các pages, trong một logical file.
Mít đặc: Bắt đầu khó khó hiểu rồi
Biết tuốt: Bạn có thể hiểu là dữ liệu được lưu trong database không phải là theo từng record mà là từng pages. Việc này giúp tăng tốc độ truy vấn và ghi hơn. Trong phần Files and Index Management này sẽ quản lý các thao tác xem các records hay bảng thuộc pages nào để xử lý. Việc tại sao thì tôi sẽ trả lời ở bài sau nhé!
Mít đặc: Vậy là các câu truy vấn của tôi sẽ qua các trình này sẽ biết được tôi ở pages nào đúng không?
Biết tuốt: Đúng thế và page có thể lưu trên RAM sẵn có cache hoặc phải vào ổ cứng để đọc. Phần quản lý RAM được gọi là Buffer Management
Mít đặc: Còn phần ổ cứng sẽ gọi là Disk Management đúng không? Tôi thông minh không?
Biết tuốt: Gần đúng, nó được gọi là Disk Space Management nhiệm vụ của nó là chuyển các page sang các bytes vật lý trên một hay nhiều thiết bị
Mít đặc: Ok vậy là có thể qua các bước để chạy được câu truy vấn từ client tới đĩa rồi.
Biết tuốt: Đúng vậy bạn có thể nhìn thấy kiến trúc của nó như hình dưới
Cấu trúc này được phân tầng, tầng trên chỉ cần biết tầng dưới nó, đây là một kiến trúc thiết kế tốt, nó vừa đảm bảo hiệu năng và đảm bảo độ phức tạp. sau này bạn mà làm một phần mềm cũng nên phân tầng như thế này.
Mít đặc: Vậy là tôi đã hiểu sơ sơ về kiến trúc tổng quan rồi, nhưng mà các câu hỏi của tôi hình như vẫn chưa được giải đáp đâu nhé!
Biết tuốt: Thực ra còn có hai phần chạy thông trên nhiều tầng, đó là việc quản lý transaction Concurrency Control và phần recovery khi có sự cố xảy ra ví dụ máy khởi động đột ngột...
Mít đặc: Ok tôi đã hiểu sơ sơ một chút. Vậy các phần sau bạn sẽ chỉ tôi chi tiết từng tầng đúng không?
Biết tuốt: Đúng vây, bài sau sẽ bắt đầu từ tầng dưới cùng là Files and Index Management.
Mít đặc: Cảm ơn bạn, một upvote cho bạn, nếu tôi muốn tìm hiểu thêm có thể tìm ở đâu
Biết tuốt: Cảm ơn upvote của bạn nhiều, vê chi tiết bạn có thể tham khảo tại link này. Hẹn gặp lại bạn buổi sau nhé!