SQLite là gì? Giải thích cơ sở dữ liệu SQL nhúng

SQLite là cơ sở dữ liệu nằm trong chương trình của bạn

Phần lớn cơ sở dữ liệu bạn từng nghe tới, như MySQL, Postgres, SQL Server, đều chạy như một chương trình riêng. Bạn khởi động một máy chủ, nó lắng nghe trên một cổng, và ứng dụng kết nối qua mạng để gửi truy vấn tới nó. SQLite gạt bỏ toàn bộ mô hình đó.

SQLite là một thư viện. Bạn liên kết nó vào chương trình, và nó cho bạn một cơ sở dữ liệu SQL nằm trong một tệp duy nhất trên đĩa. Không máy chủ, không cổng, không daemon, không pg_ctl start. Ứng dụng mở một tệp, và tệp đó chính là cơ sở dữ liệu.

sqlite3 mydata.db

Lệnh đó mở (hoặc tạo) một tệp tên mydata.db và cho bạn một dấu nhắc SQL. Mọi thứ bạn làm, như bảng, hàng, index, đều được lưu trong tệp đó. Sao chép nó sang máy khác thì cơ sở dữ liệu đi theo. Xóa nó thì cơ sở dữ liệu cũng mất.

Điểm qua nhanh phần SQL

Bản thân SQL trông giống SQL ở bất cứ đâu. Nếu bạn đã dùng một cơ sở dữ liệu khác, gần như mọi thứ đều quen thuộc:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

SQL chuẩn: CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite hỗ trợ những phần của chuẩn SQL mà bạn thực sự dùng hằng ngày, cùng các tiện ích hiện đại như CTE, window function và các hàm JSON. Khác biệt so với Postgres hay MySQL chủ yếu nằm ở kiểu dữ liệu và vài điểm lạ trong cú pháp, sẽ được nói ở phần sau.

"Nhúng" và "không cần máy chủ" thực sự nghĩa là gì

Có hai từ luôn xuất hiện khi nói về SQLite. Hiểu rõ chúng là việc đáng làm.

Nhúng (embedded) nghĩa là SQLite chạy trong cùng tiến trình với ứng dụng của bạn. Không có tiến trình cơ sở dữ liệu riêng. Khi script Python gọi sqlite3.connect("data.db"), engine SQL chạy bên trong tiến trình Python, đọc và ghi tệp trực tiếp.

Không cần máy chủ (serverless) nghĩa là không có máy chủ nào phải cài đặt, cấu hình, chạy, bảo mật hay sao lưu. So sánh các bước để bắt đầu dùng một cơ sở dữ liệu:

• Postgres: cài Postgres, khởi động dịch vụ, tạo người dùng, tạo cơ sở dữ liệu, cấu hình pg_hba.conf, kết nối qua TCP.
• SQLite: mở một tệp.

Khác biệt chỉ có vậy. Ít sức mạnh hơn, nhưng ít thủ tục hơn rất nhiều.

Toàn bộ cơ sở dữ liệu là một tệp

Đây là điều khiến nhiều người ngạc nhiên. Định dạng tệp được tài liệu hóa và ổn định: một tệp .db (hoặc .sqlite, hoặc .sqlite3, phần mở rộng chỉ là quy ước) mà bạn có thể:

• Gửi email cho đồng nghiệp.
• Commit vào git (ít nhất là các tệp nhỏ).
• Sao chép bằng cp để có ngay một bản sao lưu.
• Mở bằng bất kỳ công cụ SQLite nào trên bất kỳ hệ điều hành nào.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Tệp duy nhất đó chứa bảng, index, schema và dữ liệu của bạn. Cơ sở dữ liệu SQLite trên đĩa giống hệt nhau đến từng byte trên Windows, macOS, Linux, iOS và Android. Định dạng này ổn định đến mức Thư viện Quốc hội Mỹ khuyến nghị dùng nó để lưu trữ dữ liệu lâu dài.

Nơi bạn đang dùng SQLite mà không biết

Gần như chắc chắn có hàng trăm cơ sở dữ liệu SQLite trên thiết bị bạn đang dùng để đọc trang này. Nó chạy bên trong:

• Bộ nhớ hệ thống của iOS và Android, cùng nhiều ứng dụng trên cả hai nền tảng.
• Firefox, Chrome và Safari (lịch sử, dấu trang, cookie).
• macOS (Mail, Photos, dock).
• Phần lớn ứng dụng desktop trên Linux cần lưu trữ cục bộ.
• Skype, WhatsApp, Signal: lịch sử trò chuyện.
• Catalog của Adobe Lightroom, siêu dữ liệu của Dropbox, thư viện game của Steam.

Nó được gọi là engine cơ sở dữ liệu được triển khai rộng rãi nhất thế giới, và có lẽ điều đó đúng. Lý do rất đơn giản: khi một ứng dụng cần lưu trữ cục bộ có cấu trúc, SQLite là con đường ít trở ngại nhất.

SQLite không phải là gì

Nó không phải cơ sở dữ liệu máy khách và máy chủ. Hai chương trình trên hai máy khác nhau không thể cùng kết nối tới một cơ sở dữ liệu SQLite qua mạng, vì không có lớp mạng nào để kết nối. Nếu cần điều đó, bạn nên dùng Postgres hoặc MySQL.

Nó không được xây dựng cho mức ghi đồng thời cao. SQLite dùng khóa ở cấp tệp (với vài tối ưu thông minh trong chế độ WAL), nên dù nhiều tiến trình đọc có thể chạy song song, mỗi lúc chỉ một tiến trình ghi được commit. Với ứng dụng một người dùng hay trang web ít truy cập, điều này không thành vấn đề. Với một SaaS nhiều khách hàng nhận hàng nghìn lệnh ghi mỗi giây, đây là công cụ sai.

Nó không quản lý người dùng hay quyền truy cập. Quyền truy cập cơ sở dữ liệu chính là quyền truy cập tệp: ai đọc được tệp thì đọc được dữ liệu. Điều đó ổn với một ứng dụng sở hữu tệp cơ sở dữ liệu của riêng nó. Nhưng không ổn với một hệ thống dùng chung cho nhiều khách hàng.

Vì sao bạn chọn nó

Bạn đổi một phần khả năng mở rộng mà có thể bạn sẽ không bao giờ cần lấy sự đơn giản:

• Không cần cài đặt. Không có dịch vụ nào phải chạy. Không lệch phiên bản giữa môi trường dev và production. Không có chuyện "cơ sở dữ liệu bị sập" vì chẳng có máy chủ cơ sở dữ liệu nào cả.
• Nhanh. Với phần lớn khối lượng công việc, đặc biệt là đọc nhiều, SQLite nhanh hơn cơ sở dữ liệu qua mạng, vì không phải đi qua socket ở mỗi truy vấn.
• Đáng tin cậy. Nó được kiểm thử cực kỳ kỹ lưỡng. Dự án SQLite có lượng code kiểm thử nhiều hơn mã nguồn rất nhiều, và định dạng tệp ổn định từ năm 2004.
• Phạm vi công cộng. Miễn phí cho mọi mục đích, kể cả thương mại. Không có giấy phép nào phải đọc.
• Di động. Một tệp, mọi nền tảng.

Với ứng dụng cục bộ, bản mẫu, thiết bị nhúng, công cụ dòng lệnh, bộ test, script phân tích dữ liệu và các trang web vừa và nhỏ, SQLite thường là lựa chọn mặc định đúng đắn, không phải bước đệm để lên một cơ sở dữ liệu "thực thụ".

Tiếp theo: SQLite so với MySQL

Câu hỏi tự nhiên tiếp theo là SQLite so với các máy chủ cơ sở dữ liệu mà bạn có lẽ nghe nhiều hơn thì thế nào. Ta sẽ bắt đầu với MySQL: mỗi bên mạnh ở đâu, và làm sao biết cái nào hợp với dự án trước mặt bạn.