Kiến trúc cơ sở dữ liệu SQL Server vs Oracle
I. Kiến trúc cơ sở dữ liệu Oracle
A. Tổng quanKiến trúc: Mối quan hệ và vai trò của các thành phần trong Database, luồng đi của dữ liệu
Cấu trúc: là các thành phần trong Database
Một hệ thống Oracle Database bao gồm ít nhất một Database và một Instance.
Instance (Thực thể): Là sự kết hợp giữa bộ nhớ và các tiến trình (processes) đang chạy.
Database (Cơ sở dữ liệu): Là tập hợp các tệp tin (files) lưu trữ dữ liệu thực tế.
Instance: là lớp trung gian, xử lý dữ liệu từ dưới Storage (các bit nhị phân) và thể hiện ra cho mọi người hiểu được giá trị của dữ liệu (Instance ở đây sử dụng đến Memory (RAM - xử lý và lưu trữ dữ liệu tạm thời)
Lấy các dữ liệu từ Storage lên Memory, được các process xử lý -> trả ra kết quả truy vấn
Lưu ý: Database có thể tồn tại mà không cần Instance (dưới dạng các tệp tin trên đĩa), nhưng lúc đó nó sẽ không thể sử dụng được.
B. Phân tích chi tiết kiến trúc Oracle Database
1. Kiến trúc Memory
1.1. PGA (Program Global Area)
PGA: Vùng bộ nhớ riêng tư, được cấp phát cho mỗi phiên làm việc (session) của người dùng và giải phóng khi phiên đó kết thúc (Sort, Hash join, Session variables)
1.2. SGA (System Global Area)
1.2.1. Shared pool: Xử lý các câu lệnh truy vấn
Câu lệnh được load đến Library cache
Phân tích câu lệnh dựa vào Data dictionary cache: cú pháp câu lệnh, phân tích đối tượng xuất hiện trong câu lệnh, phân tích quyền đối với các đối tượng trong câu lệnh
Xác định Execution plan (đường đi tối ưu nhất để lấy được dữ liệu) -> lưu ngược lại vào Library cache (tối ưu hiệu năng truy vấn cho các câu lệnh sau)
1.2.2. Database buffer cache: Dữ liệu từ disk được đẩy lên để xử lý và lưu tạm
Sau khi câu lệnh được xử lý qua Shared pool -> truy vấn dữ liệu trên Database buffer cache
Nếu dữ liệu đã tồn tại: trả ra dữ liệu được truy vấn
Nếu dữ liệu chưa tồn tại: thực hiện đẩy dữ liệu từ disk lên để xử lý, sau đó trả ra kết quả dữ liệu được truy vấn -> tối ưu hiệu năng truy xuất cho các câu lệnh sau (vì việc đọc/ghi trên Memory nhanh hơn so với đọc/ghi trên Disk)
1.2.3. Redo log buffer: Lưu trữ các thay đổi trong hệ thống, khi thực hiện các lệnh DDL, DML (delete, update, insert)
1.2.4. Java pool: lưu trữ code Java
1.2.5. Streams pool: phục vụ các công cụ đồng bộ dữ liệu
1.2.6. Large pool: dùng riêng cho những hoạt động cần nhiều tài nguyên (Backup/Restore)
2. Kiến trúc Process
2.1. Các loại Process
User process: Các process do người dùng/ứng dụng tạo ra, kết nối đến Instance, nằm ngoài DatabaseServer process: Các process sinh ra tại Database để phục vụ các User process, mỗi Server process được gán cho từng PGA riêng biệt, và dùng chung SGA
Background process: Các process chạy nền, bắt buộc để Database có thể hoạt động
2.2. Các background process quan trọng
2.2.1. Database Writer (DBWn): Tiến trình ghi các dữ liệu từ Database Buffer Cache xuống Disk (Datafiles)Điều kiện xay ra DBWn:
- Quá nhiều Dirty Block : khi mà load các Bock dữ liệu từ Datafiles lên, dữ liệu đó sau này sẽ bị sửa đổi -> mỗi block bị sửa đổi thì chuyển thành Dirty bock -> khi có quá nhiều Dirty bock trên Buffer Cache thì ghi xuống Datafiles
- LGWR được ghi xuống Disk (Redo Log files) trước
- Khi tiến trình Checkpoint xảy ra
Điều kiện xảy ra LGWR:
- Khi bạn thực hiện lệnh commit
- Khi xảy ra hiện tượng Switch log: Giả sử bạn có 3 log group: 1-> 2->3, khi mà 1 đẩy-> ghi vào 2 (ở đây gọi là switch log)
- Khi đầy ⅓ Redo log buffer
- Xảy ra trước khi DBWR ghi
- Chu kỳ 3s ghi 1 lần
2.2.4. Process Monitor (PMON): Giám sát các tiến trình khác, dọn dẹp các kết nối lỗi và đăng ký Instance với bộ lắng nghe (listener).
2.2..5 Server Monitor (SMON): Thực hiện dọn dẹp cấp hệ thống, phục hồi Instance tự động khi có lỗi (như mất điện).
2.2.6. Archiving (ARCn): tiến trình đẩy log từ Redo Log files xuống Archived Log files (bản sao của Redo Log files)
Điều kiện xảy ra: Khi mà các log group của Redo Log files đầy
Giả sử bạn có 3 log group: 1->2->3, khi mà 1 đẩy-> ghi vào 2 -> 2 đầy -> ghi vào 3 -> 3 đầy -> xoay vòng ghi lại vào 1 -> lúc này cần đẩy 1 xuống Archived Log files để 1 trống và nhận dữ liệu mới
2.2.7. MMON: Thu thập các chỉ số hiệu suất (performance metrics).
3. Kiến trúc Storage
3.1. Cấu trúc lưu trữ vật lý
Data blocks: Đơn vị nhỏ nhất, tương ứng với một số byte nhất định trên đĩa.
Extents: Một tập hợp các data blocks liên tiếp nhau.
Segments: Một tập hợp các extents được cấp phát cho một đối tượng cụ thể (ví dụ: một bảng hoặc một chỉ mục).
Tablespaces: Đơn vị lưu trữ logic cao nhất, chứa các segments. Mỗi tablespace bao gồm một hoặc nhiều data files.
Datafiles (nhiều các OS Block tạo thành) tối đa là 32G (nếu block 8K) -> có thể tăng lên tuỳ vào cấu hình block, 1 datafiles chỉ thuộc về 1 tablespace
3.2. Cấu trúc lưu trữ vật lý - Các loại file trong Database Oracle
3.2.1. Parameter file: lưu trữ các cấu hình của Database (thống số process, thông số tối ưu database)
3.2.2. Password file: lưu trữ thông tin của User quản trị
Tại sao phải lưu riêng -> vì nếu thông tin User quản trị lưu vào chính database khi database bị tắt thì không xác thực được User quản trị- > cần cơ chế xác thực bên ngoài cho các User quản trị
3.2.3. Control files: cực kì quan trọng, như tấm bản đồ, lưu các thông tin quan trọng: tên database, đường dẫn chi tiết của các Datafiles /Redo Log file/… -> dung lượng file nhỏ
3.2.4. Datafiles: lưu trữ các thông tin về database -> nó chính là nói Load dữ liệu lên Database Buffer Cache để xử lý trên Memory
3.2.5. Redo Log Files: lưu trữ các thay đổi do người dùng tạo ra và các thay đổi do chính database sinh ra
3.2.6. Archived Log files: bản sao thông tin của Redo Log Files
3.2.7. Backup file: lưu trữ các file backup
4. Trạng thái khởi động của Database Oracle
4.1. Shutdown4.2. Nomount: Parameter file được đọc (đọc các thông tin cấu hình, các đường dẫn đến control file....) -> Cấp phát memory -> khởi động các background process
4.3. Mount: Đọc file Control files từ đường dẫn lấy được từ Parameter file (chứa các thông tin đường dẫn đến Datafiles/Redo log files)
4.4. Open: Đọc các Datafiles, so sánh SCN trong Datafiles và Control files
Nếu bằng nhau thì mở file bình thường
Nếu không bằng nhau thì gọi Redo Log File -> thực hiện Instance Recovery -> open
5. Các thành phần quan trọng
1. InstanceMemory:SGA, PGA
Processes: DBWn, LGWR, CKPT, SMON, PMON, ARCn
2. Cấu trúc Database (là các file vật lý lưu trữ trên Disk): Datafiles, Control files, Redo log files, Archive log files
II. Kiến trúc cơ sở dữ liệu SQL Server
A. System Database
Sau khi cài đặt xong SQL Server thì hệ thống tạo ra các database sau:5 cơ sở dữ liệu hệ thống (System Database) được tạo sẵn
Master Database: lưu trữ system catalogs (thông tin cấu hình, thông tin các database trên instance, thông tin Datafiles. Login Account)
Bản chất không nằm ở System Database -> dữ liệu nằm ở Resource Database, được ánh xạ để truy vấn từ System Database
Model Database: đây là template để tạo database mới
TempDB Database: lưu trữ các thông tin dùng tạm trong quá trình thực hiện câu lệnh, mỗi lần khởi tạo database thì sẽ được khởi tạo lại -> không cần backup/restore, ảnh hướng đến hiệu năng của câu lệnh
MSDB: sử dụng cho SQL Server Agent trong 1 số services quản trị (Scheduler, Log Shipping, Database Email)
Database “ẩn” - Resource database: chỉ đọc, chứa các system objects (system store procedure, function)
B. Phân tích kiến trúc
1. Protocol Layer - SQL Server Network Interface (SNI)
Xử lý giao thức kết nối giữa client (application, user) với database server
Thực hiện các nhiệm vụ: tiếp nhận yêu cầu từ client, quản lý kết nối, tối ưu hoá truyền dữ liệu, xử lý các giao thức khác nhau
SQL server có 3 giao thức kết nối
Shared Memory: client -SQL Server chạy trên cùng một máy, giao tiếp với nhau bằng shared memory protocol
TCP/IP: client -SQL Server tương tác với nhau ở mạng LAN, WAN, Internet
Named Pipes: client - SQL Server giao tiếp với nhau thông qua mạng cục bộ (LAN)
2. Relational Engine
Bộ xử lý truy vấn
Lớp này chứa các thành phần xác định chính xác những gì một truy vấn phải làm và cách thực hiện nó một cách tốt nhất
Nó thực hiện các truy vấn của người dùng bằng cách yêu cầu dữ liệu từ Storage engine và xử lý các kết quả trả về
Chia làm 3 phần chính:
CMD parser: có nhiệm vụ kiểm tra câu query có đúng ngữ nghĩa và cú pháp không -> tạo ra Query Tree (biểu diễn cấu trúc logic của truy vấn SQL dưới dạng Tree)
Optimizer: sử dụng các thuật toán để tối uy thời gian truy vấn và tạo chiến lược thực thi (table scan, index usage, join) -> tìm ra Query Plan tiết kiệm chi phí nhất (ít sử dụng tài nguyên CPU, I/O, bộ nhớ)
Query Executor: thực thi các lệnh mà Query Plan trả ra, lấy dữ liệu từ Storage Engine và trả kết quả ra Protocol Layer
3. Storage Engine
Nơi lưu trữ dữ liệu, nơi mà Query Executor sẽ lấy kết quả và trả về cho người dùng, nếu mà ở đây chưa tìm được kết quả thì nó sẽ lấy dữ liệu từ ổ đĩa vật lý lên
3.1. Cấu trúc vật lý (Lưu trữ dữ liệu)
1 Database Dữ liệu lưu ở 2 loại file: Data File và Transaction Log
Data File: lưu trữ các dữ liệu được tạo ra
Master Database file /Primary Database file (.mdf): file mặc định do hệ thống tạo ra, lưu trữ các thông tin Internal configuration, internal system, cũng có thể chứa các thông tin của các Data File khác (nếu hệ thống có nhiều Data File)
Secondary Database file (.ndf): file do người dùng tạo ra để lưu trữ dữ liệu
Nhóm các file (.ndf) thành các FileGroup
Hệ thống tạo ra FileGroup mặc định: Primary (chỉ chứa file .mdf của hệ thống)
Transaction Log file (.ldf): lưu lại các thay đổi (delete, update, insert) -> thực hiện khôi phục khi có sự cố
3.2. Access method
Đóng vai trò làm giao diện giữa query executor và Buffer Manager/Transaction manager (điều phối)
Nếu truy vấn là DDL (Select Statement), truy vấn sẽ được chuyển đến Buffer manager
Ví dụ: lấy dữ liệu ở bảng A, B:
Gửi đến buffer manager (chuyển quản lý bộ nhớ) -> xem trên bộ nhớ Buffer Pool đã có nội dung truy vấn chưa, nếu chưa thì lấy từ ổ cứng vật lý lên, nếu có rồi thì chỉ cần trả về kết quả
Nếu truy vấn là Non-Select Statement (thiên về ghi dữ liệu chứ không phải là lấy dữ liệu ra) (DDL & DML), truy vấn sẽ được chuyển đến Transaction Manager
Ví dụ: Insert, Delete
Trước khi thực hiện nó chuyển đến Transaction manager để ghi log lại thông tin thay đổi vào Transaction Log file-> sau khi ghi xong thì mới chuyển lại Buffer Manager -> kiểm tra dữ liệu cần ghi (dữ liệu mới ) này được load từ Disk lên các Data Cache chưa, nếu chưa thì Load lên, sau đó tiến hành sửa đổi -> các Data Cache sẽ chuyển hành Dirty page -> rồi được chuyển lại xuống dưới Disk (.mdf/.ndf)
3.3. Buffer manager
Quản lý các module Plan Cache, Buffer Pool, Data cache, Dirty page
Plan Cache: bộ nhớ tạm về các câu lệnh truy vấn (giống Cache Library của Oracle)
Data Cache: dữ liệu được đẩy từ Disk lên và được xử lý, lưu trữ tạm ở đây (giống với các block bên Oracle), Các dữ liệu mà bị thay đổi trên RAM thì chuyển thành Dirty Page (giống với Dirty block bên Oracle) -> Dirty Page sau này sẽ được lưu xuống Disk để lưu trữ lâu dài
Buffer Pool (giống Data buffer cache trên Oracle): xem dữ liệu cần truy vấn đã có trên Memory chưa -> nếu chưa có thì load từ các .mdf/.ndf từ Disk lên
Nếu truy vấn rơi vào trường hợp Transaction Manager -> ghi lại log và Transaction log file-> sau đó dữ liệu được đẩy đến Buffer manager -> dữ liệu mới được sửa đổi trên các Data Cache và chuyển thành các Dirty page (sau này khi nhiều thì các Dirty page này được lưu xuống ổ đĩa vật lý)
Lazy Writes: là background process để ghi Dirty page xuống disk
3.4. Transaction Manager
Ghi lại các thay đổi dữ liệu vào Transaction Log file -> hỗ trợ recovery khi gặp sự cố
Sử dụng Lock Manager: giúp quản lý việc khoá các bản ghi hoặc các đối tượng để đảm bảo không can thiệp sâu
Checkpoint: Bản sao dữ liệu tại thời điểm nào?
Write-Ahead Logging (WAL): đảm bảo các thay đổi được ghi vào Transaction Log file trước khi thực hiện sửa đổi dữ liệu theo các lệnh truy vấn
Sửa lần cuối: