Bài 15: Performance Engineering 🐳

Khi ứng dụng của bạn tăng trưởng, lượng dữ liệu ghi nhận mỗi giây có thể tăng lên hàng nghìn bản ghi. Một lỗi lập trình kinh điển về I/O đĩa hoặc parse câu lệnh có thể khiến tốc độ ghi giảm đi hàng trăm lần, gây nghẽn hệ thống. Bài viết này hướng đến khía cạnh kỹ thuật hiệu năng (Performance Engineering) của cơ sở dữ liệu: cách SQLite biên dịch câu lệnh, tại sao Transaction lại thay đổi hoàn toàn tốc độ ghi hàng loạt (Batch Insert), các cấu hình PRAGMA tuning chuyên sâu, và một bài thực hành đo đạc hiệu năng I/O trực quan.

1. Prepared Statements: Tối Ưu Hóa Chi Phí Phân Tích Cú Pháp SQL

Mỗi khi bạn gửi một câu lệnh SQL dạng văn bản thô tới cơ sở dữ liệu (ví dụ: INSERT INTO logs VALUES (1, 'info')), engine cơ sở dữ liệu phải trải qua một quy trình biên dịch nghiêm ngặt:

1. Parser: Phân tích cú pháp chuỗi văn bản để phát hiện lỗi chính tả.
2. Semantic Analyzer: Kiểm tra xem các bảng và cột có tồn tại thực sự hay không.
3. Optimizer: Lập kế hoạch tối ưu (Query Plan).
4. Code Generator: Biên dịch câu lệnh thành mã bytecode của máy ảo VDBE (Virtual Database Engine) trong SQLite.

Quá trình biên dịch này chiếm từ 30% đến 50% tổng thời gian thực thi của một truy vấn đơn giản. Nếu bạn ghi 10.000 bản ghi bằng 10.000 câu lệnh văn bản khác nhau, bạn đang lãng phí hàng tỷ chu kỳ CPU chỉ để parse và compile cùng một cấu trúc lệnh lặp đi lặp lại.

Prepared Statements (Câu lệnh chuẩn bị) giải quyết bài toán này bằng cách gửi cấu trúc lệnh chứa các tham số động (placeholders ? hoặc $name) lên database trước:

-- Khai báo cấu trúc câu lệnh một lần duy nhất
INSERT INTO techmart_logs (log_id, message) VALUES (?, ?);

SQLite sẽ parse, biên dịch và lưu trữ cấu trúc máy ảo VDBE đã được dịch sẵn. Khi thực thi ghi dữ liệu, ứng dụng chỉ cần gửi các giá trị liên kết (Parameter Binding) trực tiếp vào máy ảo, bỏ qua hoàn toàn các bước Parser/Compile.

Cách viết tối ưu trong JavaScript sử dụng thư viện SQLite-WASM:

// Chuẩn bị câu lệnh một lần
const stmt = db.prepare("INSERT INTO techmart_logs (message) VALUES (?);");

// Binding và thực thi nhiều lần
for (let i = 0; i < 1000; i++) {
  stmt.run([`Log event #${i}`]); // Chỉ truyền mảng tham số, tốc độ cực nhanh
}

// Giải phóng bộ nhớ của statement khi dùng xong
stmt.free();

2. Sức Mạnh Của Transactions Đối Với Ghi Hàng Loạt (Batch Insert)

Nhiều lập trình viên ngạc nhiên khi thấy chèn 1.000 dòng vào SQLite mất tới 10-15 giây ở cấu hình mặc định. Họ đổ lỗi cho SQLite chậm chạp. Nhưng thực tế, đây là hành vi bảo vệ dữ liệu mặc định của hệ điều hành và cơ sở dữ liệu.

Theo mặc định, SQLite chạy ở chế độ **Auto-commit**. Nghĩa là mỗi câu lệnh INSERT riêng lẻ được coi là một giao dịch độc lập. Để đảm bảo tính bền vững (Durability - chữ D trong ACID), mỗi khi một câu lệnh kết thúc, SQLite bắt buộc phải thực hiện quy trình sau:

1. Tạo và mở file nhật ký giao dịch (journal file).
2. Ghi thay đổi vào đĩa vật lý.
3. Gọi hàm hệ thống fsync().

Hàm fsync() yêu cầu hệ điều hành đẩy toàn bộ dữ liệu đang nằm trong RAM (OS page cache) xuống bề mặt vật lý của đĩa cứng hoặc chip nhớ flash SSD. Đây là một thao tác phần cứng rất chậm (mất khoảng 10ms đối với SSD thông thường). Do đó, chèn 1.000 dòng riêng biệt đồng nghĩa với 1.000 lần gọi fsync(), tiêu tốn ít nhất: \[ 1000 \times 10\text{ms} = 10\text{giây} \]

Khi chúng ta bọc toàn bộ khối lệnh trong một **Transaction** duy nhất:

BEGIN TRANSACTION;
INSERT INTO techmart_logs (message) VALUES ('Log #1');
INSERT INTO techmart_logs (message) VALUES ('Log #2');
...
INSERT INTO techmart_logs (message) VALUES ('Log #1000');
COMMIT;

SQLite sẽ ghi toàn bộ các thay đổi này vào bộ nhớ đệm và chỉ thực hiện **một lần gọi fsync() duy nhất** tại thời điểm từ khóa COMMIT được chạy. Thời gian xử lý lập tức giảm từ 10 giây xuống còn vỏn vẹn **chưa đầy 20 mili-giây**!

3. PRAGMA Tuning: Tinh Chỉnh Hiệu Năng SQLite

SQLite cung cấp một loạt các tham số PRAGMA để thay đổi cách thức cơ sở dữ liệu tương tác với đĩa cứng và bộ nhớ đệm. Dưới đây là các cấu hình tuning hiệu năng quan trọng nhất:

Cú pháp cấu hình tối ưu hiệu năng ghi hàng loạt điển hình:

-- Chuyển sang chế độ WAL để tăng tốc ghi và cho phép đọc ghi song song
PRAGMA journal_mode = WAL;

-- Giảm mức độ đồng bộ xuống NORMAL (vẫn an toàn cao nếu mất điện)
PRAGMA synchronous = NORMAL;

-- Tăng bộ nhớ đệm lên 40MB (khoảng 10000 trang 4KB)
PRAGMA cache_size = -10000;

4. Đo Lường Hiệu Năng Thực Tế (Benchmark Sandbox)

Để thấy rõ sự khác biệt của các kỹ thuật trên, chúng ta sẽ thực hiện một thực nghiệm đo lường (Benchmark) ngay trên trình duyệt. Chúng ta sẽ ghi 500 bản ghi vào bảng và so sánh 3 phương pháp:

1. Autocommit (Không Transaction): Chạy từng lệnh INSERT riêng rẽ.
2. Với Transaction: Bọc toàn bộ các lệnh INSERT thô trong một Transaction.
3. Transaction + Prepared Statement: Kết hợp bọc Transaction và biên dịch sẵn câu lệnh.

5. Thực Hành Nâng Cao Với Docker: Đo Lường Disk I/O & fsync Thật

Môi trường WASM trên trình duyệt chạy hoàn toàn trên bộ nhớ RAM ảo của sandbox, do đó các lệnh hệ thống như fsync() chỉ được giả lập bằng lệnh ghi vào RAM. Để kiểm chứng hiệu năng I/O thực tế dưới sự tác động của đĩa cứng và hệ điều hành, bạn hãy thực hành lab tại nhà bằng Docker.

docker run --name techmart-pg -e POSTGRES_PASSWORD=secret -d -p 5432:5432 postgres