Richard Hipp muốn một cơ sở dữ liệu không cần máy chủ, nên chẳng có gì để sập. Giờ SQLite có mặt gần như khắp nơi.

08/10/2026 · VietTechies · Biên tập

Năm 2000, D. Richard Hipp đang viết phần mềm kiểm soát thiệt hại cho một tàu khu trục mang tên lửa dẫn đường của Hải quân Mỹ, chiếc DDG-79 Oscar Austin, với tư cách nhà thầu trong một dự án của Bath Iron Works. Ứng dụng lưu dữ liệu trong một cơ sở dữ liệu Informix chạy như một máy chủ riêng. Khi máy chủ đó không sẵn sàng, phần mềm không thể hoạt động. Người dùng thấy một hộp thoại báo lỗi không kết nối được, và nhóm phát triển ứng dụng là bên bị đổ lỗi.

Phản ứng của Hipp trở thành một trong những câu hỏi thiết kế có hệ quả lớn nhất của phần mềm hiện đại: tại sao một chương trình như thế lại cần đến máy chủ cơ sở dữ liệu?

Một cơ sở dữ liệu chỉ là một thư viện

Phần lớn cơ sở dữ liệu thời đó đi theo mô hình client-server. Bộ máy cơ sở dữ liệu chạy thành một tiến trình riêng, thường trên một máy riêng, và ứng dụng giao tiếp với nó qua một kết nối. Kiến trúc này rất tốt cho nhiều hệ thống dùng chung, nhiều người dùng. Nhưng nó cũng tạo ra sự phụ thuộc. Nếu máy chủ, mạng hoặc cấu hình gặp sự cố, ứng dụng cũng sập theo.

Giải pháp thay thế của Hipp là đặt bộ máy SQL vào ngay bên trong ứng dụng. Không còn tiến trình máy chủ nào phải cài đặt, khởi động, quản trị hay bị mất kết nối. Chương trình sẽ đọc và ghi một file bình thường trên ổ đĩa, thông qua một thư viện được liên kết trực tiếp vào code của chính nó.

Một đợt gián đoạn ngân sách của chính phủ khiến Hipp không có hợp đồng trong vài tháng, và một đồng nghiệp gợi ý ông cứ tự viết luôn cái bộ máy mà ông vẫn hay mô tả. Theo Hipp, đoạn code đầu tiên được check-in ngày 29 tháng 5 năm 2000. Bản phát hành công khai đầu tiên ra đời vào tháng 8 năm 2000. Phiên bản đầu này lưu dữ liệu bằng GDBM, trình quản lý cơ sở dữ liệu của GNU. SQLite 2.0, phát hành năm 2001, thay GDBM bằng tầng lưu trữ B-tree do chính Hipp viết và bổ sung giao dịch (transaction).

Vì sao phạm vi công cộng lại quan trọng

Do phiên bản 1.0 phụ thuộc vào GDBM, nó trên thực tế chịu ràng buộc của giấy phép GPL. Khi viết lại bộ máy lưu trữ, Hipp quyết định không dùng bất kỳ giấy phép mã nguồn mở nào. Code và tài liệu của SQLite được hiến tặng vào phạm vi công cộng (public domain).

Quyết định đó hạ rào cản cho các công ty xuống mức hiếm thấy. Một nhà sản xuất có thể đưa SQLite vào điện thoại, trình duyệt hay hệ thống trên ô tô mà không cần đàm phán giấy phép hay theo dõi các điều khoản ghi công. Với những tổ chức có bộ phận pháp lý vẫn muốn một văn bản chính thức, công ty Hwaci của Hipp bán một “Warranty of Title”, tức một bảo đảm pháp lý rằng các tác giả có quyền hiến tặng code vào phạm vi công cộng. Số tiền đó dùng để nuôi việc phát triển. Bản thân code vẫn miễn phí.

Từ dự án tay trái đến điện thoại

Mối quan tâm thương mại nghiêm túc đầu tiên đến từ ngành di động. Hipp kể rằng khoảng năm 2001 hoặc 2002, Motorola gọi điện hỏi về việc dùng SQLite trong một hệ điều hành điện thoại, và ông báo giá khoảng 80.000 đô la, con số mà khi đó ông thấy như cả gia tài. AOL cũng muốn dùng. Sau đó, Symbian so sánh một loạt bộ máy cơ sở dữ liệu cho nền tảng di động của mình và chọn SQLite.

Rồi Symbian nêu ra một mối lo nghiêm túc: một dự án do quá ít người duy trì thì có “bus factor” thấp, tức chỉ cần vài người rời đi là dự án gặp nguy. Câu trả lời là SQLite Consortium. Theo lời khuyên của Mitchell Baker bên Mozilla, consortium được tổ chức sao cho các thành viên tài trợ phát triển, còn các nhà phát triển vẫn giữ quyền kiểm soát code. Mozilla, Symbian và Adobe nằm trong số các thành viên sáng lập.

Khoảng năm 2005, Hipp được xem một nguyên mẫu ban đầu của Android trong một buổi gỡ lỗi. Sau này ông nói rằng mình đã biết nền tảng đó sẽ rất lớn. Android về sau đưa SQLite lên mọi thiết bị chạy hệ điều hành này.

Học cách kiểm thử như ngành hàng không

Việc được triển khai rộng khắp làm lộ ra một vấn đề khác: bug đến tay hàng triệu thiết bị. Bước ngoặt đến qua Rockwell Collins, công ty đã giới thiệu cho Hipp chuẩn DO-178B, một tiêu chuẩn dùng cho phần mềm hàng không có yêu cầu an toàn trọng yếu. Trong số các yêu cầu của nó có độ phủ kiểm thử MC/DC 100%, nghĩa là mọi điều kiện trong mọi quyết định đều phải được chứng minh là có thể tác động độc lập đến kết quả.

Hipp mất khoảng một năm, với những tuần làm việc kéo dài, để đưa bộ kiểm thử của SQLite lên mức đó. Ông kể rằng sau đó, báo cáo bug từ phía Android gần như không còn nữa.

Văn hóa kiểm thử vẫn là đặc điểm nổi bật nhất của SQLite. Tài liệu của chính dự án cho biết, tính đến phiên bản 3.42.0, thư viện có khoảng 155.800 dòng mã C, trong khi code kiểm thử và script kiểm thử nhiều gấp khoảng 590 lần. Các bộ kiểm thử cố ý giả lập lỗi hết bộ nhớ, lỗi I/O, chương trình sập và mất điện giữa lúc đang ghi, rồi kiểm tra xem file cơ sở dữ liệu có bị hỏng hay không.

Một ý tưởng nhỏ đã đi xa đến đâu

Dự án SQLite tự mô tả mình, với cách diễn đạt rất thận trọng, là cơ sở dữ liệu có lẽ được triển khai rộng rãi nhất. Tài liệu của dự án kể ra, trong số những nơi đang dùng SQLite, mọi thiết bị Android và iOS, mọi máy Mac và mọi bản cài Windows 10/11, cùng các trình duyệt web lớn. Dự án ước tính có lẽ đang có hơn một nghìn tỷ cơ sở dữ liệu SQLite được sử dụng. Con số đó được suy ra từ số lượng điện thoại thông minh chứ không phải đo đạc, nhưng dù chỉ là ước lượng thô, nó vẫn đặt SQLite vào nhóm những thành phần phần mềm được dùng rộng rãi nhất thế giới.

Bộ máy này không thay thế được cơ sở dữ liệu client-server trong mọi trường hợp. Những hệ thống lớn, nhiều người dùng, truy cập đồng thời cao vẫn có lý do chính đáng để chạy một máy chủ riêng. Chính tài liệu của SQLite cũng nói rõ điều đó. Thế mạnh của nó nằm ở chỗ khác: với vô số ứng dụng cần lưu trữ dữ liệu có cấu trúc một cách tin cậy trên một thiết bị duy nhất, máy chủ bền bỉ nhất hóa ra lại là không có máy chủ.

Bài học thiết kế

Hipp không đặt mục tiêu xây dựng cơ sở dữ liệu phổ biến nhất thế giới. Ông chỉ muốn loại bỏ một kiểu hỏng hóc khỏi một ứng dụng trên tàu chiến. Ý tưởng có giá trị lâu dài là: hãy coi một sự phụ thuộc là rủi ro trước khi coi nó là tính năng.

Nhiều vấn đề phần mềm được giải quyết bằng cách thêm một thành phần: một lớp cache, một service, một hàng đợi, một máy chủ. Câu chuyện SQLite nhắc chúng ta rằng đôi khi nước đi bền vững hơn là tự hỏi thành phần nào có thể bỏ đi, rồi kiểm thử phần còn lại như thể tính mạng con người phụ thuộc vào nó.

Đọc bằng ngôn ngữ khác: English · Español · Deutsch · Français · Português (Brasil) · Tiếng Việt