Câu chuyện ít người biết về SQLite

xguru · 2021-07-05T10:21:01+09:00

Tóm tắt podcast phỏng vấn nhà phát triển SQLite Richard Hipp (38 phút, có transcript) Công việc chính của ông là lập trình viên phần mềm cho các tàu khu trục của Hải quân Mỹ → Informix dùng bên trong tàu thường xuyên gặp lỗi, server chết và kết nối bị ngắt → Vì là tàu chiến, nên ngay cả khi bị hư hại trong lúc chiến đấu cũng không thể hiện popup kiểu “Không thể kết nối tới DB” mà phải vận hành ổn định, bền bỉ. Cũng không cần transaction, nhưng trong mọi tình huống đều phải đọc được dữ liệu vào RAM → Ông tìm một SQL DB engine chạy không cần server, nhưng không có, nên quyết định tự làm SQLite V1 (năm 2000) Xem câu lệnh SQL như chương trình, rồi viết một bytecode engine để biên dịch và thực thi truy vấn Thực tế không được dùng trong dự án (khách hàng muốn dùng Informix) Ông dùng nó cho mục đích phát triển, rồi công khai lên Internet và mọi người bắt đầu sử dụng Ông thấy những lời như “Tôi đã chạy SQL DB trên Palm Pilot” và điều đó thu hút sự chú ý của nhiều người. Vì vậy ông được khích lệ để tiếp tục phát triển. Motorola Trong khoảng 2001~2002, Motorola gọi điện nói rằng họ sẽ đưa SQLite vào OS điện thoại mới của mình Họ nói sẽ trả tiền nếu SQLite hỗ trợ các tính năng cần thiết Đó là lần đầu ông biết rằng có thể kiếm tiền từ mã nguồn mở Khoảng $80,000, nếu so với bây giờ thì không phải số tiền lớn, nhưng với ông khi đó là con số cực kỳ đáng kinh ngạc Ông cùng ba người cộng sự thực hiện dự án đó, và đó là khởi đầu America Online Phones Sau đó, bên liên hệ tiếp theo là AOL Đó là thời kỳ gửi CD qua đường bưu điện, và trong chiếc CD đó cần có database Tức là họ muốn đưa SQLite vào trong CD và cần thêm các tính năng mới Symbian OS và Nokia Ông đến London vào dịp Lễ Tạ ơn để họp (vì Anh không có Lễ Tạ ơn) Họ muốn một DB cho Symbian OS, và SQLite phải cạnh tranh với các DB khác (2 mã nguồn mở, 7 thương mại) Cả 9 DB còn lại đều có cơ hội tinh chỉnh, nhưng cuối cùng SQLite thắng Bus Factor [1] và consortium Bus factor là chỉ số cho biết nếu có bao nhiêu người bị xe buýt tông thì việc phát triển sẽ dừng lại Dù ông đang làm toàn thời gian cùng nhiều người khác, phía Symbian vẫn nói cần nâng bus factor lên Ý tưởng là lập SQLite consortium để tài trợ cho dự án và khiến nhiều người tham gia lâu dài hơn Ông từng đưa ra ý tưởng điên rồ như để mọi thành viên consortium đều có quyền biểu quyết Mitchell Backer của Mozilla Foundation nghe được chuyện này ở đâu đó rồi gọi điện → “Richard, anh đang làm hoàn toàn sai rồi. Để tôi chỉ cho anh cách lập consortium.” → Bà bắt đầu đặt ra các quy tắc → “Các nhà phát triển phải nắm quyền kiểm soát. Quyết định của họ là cuối cùng. Không phải cứ tham gia là có quyền biểu quyết.” → “Các công ty sử dụng thứ này sẽ có vinh dự được đóng góp tiền, nhưng quyết định cuối cùng phải là của anh.” → Bà rất dứt khoát và sắp xếp mọi thứ đâu ra đấy. Bà là luật sư Khi Richard hỏi “Làm sao để mọi người tham gia? Động lực là gì?”, → “Đừng lo. Họ sẽ tham gia. Và thực tế, nếu làm như vậy thì Mozilla sẽ là thành viên sáng lập.” Với sự hỗ trợ của Mozilla, Symbian và Adobe, consortium bắt đầu cùng ba công ty này → Lúc đầu khi Symbian nói cần consortium, ông không biết phải làm sao. Ông cũng không biết vì sao Mitchell Baker lại nghe được chuyện đó rồi gọi điện, nhưng tất cả là một hành trình đáng kinh ngạc. Enter Android : Khởi đầu của Android Vì mọi smartphone đều dùng SQLite, Richard có thể quan sát sự phát triển smartphone giai đoạn đầu từ mọi góc độ Năm 2005 ông họp với Android. Khi đó cả Android lẫn iPhone đều chưa ra mắt Ông debug SQLite bằng cách kết nối vào một chiếc điện thoại giống BlackBerry với màn hình nhỏ ở trên và bàn phím QWERTY đầy đủ Việc debug bằng GDB trên một chiếc điện thoại đang gắn với mạng viễn thông thực sự là trải nghiệm đáng kinh ngạc Khi đó chưa ai bên Motorola, Symbian hay Nokia làm như vậy, và chính lúc đó ông biết Android sẽ trở nên khổng lồ Guy, This Is Important : Mọi người ơi, chuyện này thực sự quan trọng Thời đó các công ty khác có chu kỳ cập nhật phần cứng và phần mềm rất dài, khoảng 30 ngày, còn Android thì đưa OS mới vào điện thoại đang nối với mạng thực nhiều lần mỗi ngày. Mẫu điện thoại Android nguyên mẫu ông nhận theo NDA có vỏ trông như được in 3D, nhưng ít nhất vẫn đủ để mang theo. → Còn của các công ty khác thì là những breadboard và prototype cồng kềnh, lại không nối mạng nên cũng chẳng thể dùng như điện thoại Ông muốn nói với người bên Motorola và Symbian rằng “Cái này rất quan trọng, phải giải quyết nó”, nhưng không thể nói ra (vì NDA), và đó đã tạo nên khác biệt Testing and Aviation Standards : Kiểm thử và tiêu chuẩn hàng không Adam (người phỏng vấn): “DB của Richard hiện giờ đang ở trạng thái rất sôi động. Đội ngũ có năng lực và giàu tài năng, nhưng vẫn chỉ là một công ty tư vấn phần mềm 1~4 người hỗ trợ DB nằm trong mọi điện thoại Android. Các nhà phát triển cực kỳ nghiêm túc với DB và ghét chuyện dữ liệu gặp sự cố” Chúng tôi từng ngây thơ khoe với mọi người rằng SQLite không có bug, nhưng Android chắc chắn đã chứng minh rằng chúng tôi sai Ông từng nghĩ có thể làm ra phần mềm không lỗi, nhưng thật đáng kinh ngạc khi phần mềm được cài lên hàng triệu thiết bị thì có thể phát sinh nhiều bug đến vậy Khoảng thời gian đó, ông đang làm việc với Rockwell Collins, một công ty avionics, và họ giới thiệu cho ông khái niệm DO-178B [2] → DO-178B nói về tiêu chuẩn chất lượng cho các sản phẩm hàng không đòi hỏi độ an toàn cao, và khác với các tiêu chuẩn chất lượng khác ở chỗ nó “đọc được” → Nó chỉ tốn vài trăm đô, khá mỏng, nên ông khuyên mọi người nên đọc Họ thực sự bắt đầu làm theo quy trình của DO-178B, trong đó có 100% MCDC Test Coverage MCDC (Modified Condition / Decision Coverage) [3] nghĩa là kiểm thử phải đi qua từng nhánh riêng lẻ ít nhất một lần Để SQLite đạt 100% MCDC, ông mất một năm với cường độ 60 giờ mỗi tuần. Thực sự cực kỳ khó. Ngày nào cũng phải làm 12 tiếng và rất mệt 90~95% test coverage thì dễ, nhưng 5% còn lại mới thật sự khó. Tuy nhiên sau một năm làm như vậy và cuối cùng đạt 100%, Android không còn gửi bug report nữa Từ đó mọi thứ bắt đầu vận hành ổn định và tạo ra khác biệt lớn. Trong 8~9 năm sau đó không còn bug nữa Hàng tỷ bài test Bộ đầu tiên được viết bằng TCL (Tool Command Language), là kiểu test thường thấy của lập trình viên Bộ test TCL đầu tiên đó đến nay vẫn được bảo trì và công khai. Dù không đạt 100%, nó kiểm thử chi tiết mọi tính năng của SQLite 100% MCDC coverage được gọi là TH3 và không công khai (proprietary) Họ từng thử kiếm tiền bằng cách bán nó cho các công ty hàng không, nhưng không bán được bản nào nên chẳng có hiệu quả về mặt đó.. Nhưng nó giúp sản phẩm thực sự vững chắc và giúp thêm tính năng mới cũng như sửa bug nhanh hơn Khó mà đếm chính xác số lượng test, nhưng có 100 nghìn test riêng lẻ được tham số hóa để chạy thành hàng tỷ lượt test Có checklist, và trước mỗi lần phát hành sẽ test ít nhất 3 ngày Họ cố tình kiểm thử trên nhiều OS khác nhau → Bây giờ gần như mọi thiết bị đều little-endian, nhưng trước đây big-endian khá nhiều. Vì thế họ test big-endian trên PowerPC iBook → Họ test trên mọi nền tảng và OS có thể: nền tảng 32-bit, ARM và Intel, nền tảng 64-bit, Windows, Linux, Mac, OpenBSD... → Có nhiều test suite khác nhau, gồm bộ TCL ban đầu, cả TH3, và cả fuzzer (fuzz testing) chạy liên tục Còn có cả SQL Logic test → Là một khối lượng khổng lồ câu lệnh SQL do Shane Harrelson tạo ra 10 năm trước → Họ đã test trên mọi DB có thể chạm tới, và mọi DB engine đều từng không trả lời nổi, thậm chí bị segmentation fault. SQLite cũng vậy. Trừ Postgres. → Chỉ Postgres là luôn cho ra kết quả và không tìm thấy lỗi. Các nhà phát triển Postgres nói rằng là do chúng tôi chưa cố đủ thôi.. Có lẽ vẫn có thể làm Postgres báo lỗi, nhưng chúng tôi thực sự rất ấn tượng → Ngay cả bản thương mại của Oracle cũng crash, DB2 cũng crash → Điểm quan trọng là làm sao để SQLite cho ra cùng một đáp án với tất cả những truy vấn đó Building From First Principles Khi bắt đầu viết, ông tìm xem có tài liệu tham khảo nào về cách xây SQL DB engine không, nhưng không có. Vì thế ông phải tự làm, hoàn toàn là một nhiệm vụ độc lập Nhiều lý thuyết đang diễn ra ở MIT, Harvard và Berkeley, nhưng nếu không học ở đó thì ông thậm chí còn không biết những lý thuyết đó tồn tại, càng không biết cách tìm ra chúng Nếu nhìn kỹ, mô hình Volcano mà Postgres dùng và mô hình Byte Code mà SQLite dùng đều hội tụ về cùng một ý tưởng Bề ngoài thì bắt đầu từ những nơi rất khác nhau, nhưng khi đi vào câu hỏi làm sao để nó nhanh hơn, họ lại hội tụ về cùng một vùng Ông cho rằng đây giống như một kiểu kiểm chứng về mặt lý thuyết: hai dòng phát triển độc lập đi đến cùng một đáp án Ví dụ, ông hoàn toàn không biết về Covering Index, nhưng khi tham dự một hội nghị PHP ở Đức, David Axmark của MySQL cũng có mặt và thuyết trình → Trong bài nói đó, ông ấy giải thích cách MySQL tạo Covering Index → Khi index của DB có nhiều cột, nếu truy vấn chỉ đụng đến các cột đầu của index và câu trả lời nằm trong những cột còn lại của chính index đó, thì DB có thể dùng luôn index mà không cần truy cập bảng gốc, nên công việc sẽ nhanh hơn → Vậy là trên chuyến bay về nhà, vì trên máy bay không có nhiều người, ông mở laptop ra và triển khai covering index cho SQLite ngay trên bầu trời Đại Tây Dương B-Trees and The Art of Computer Programming Rất nhiều thứ phải tự xây. Chưa từng có ai dạy ông về B-tree. Ông chỉ từng nghe qua Khi định tự phát triển B-tree, ông có bộ TAOCP của Don Knuth trên giá sách nên tra phần B-tree và Don đã giải thích thuật toán cho ông Điều thú vị là sách mô tả rất kỹ thuật toán tìm kiếm và chèn của B-tree, nhưng không đưa thuật toán xóa. Nó nằm trong bài tập cuối chương, nên trước khi tự làm B-tree của mình, ông phải giải bài đó. “Cảm ơn Don, thực sự cảm ơn nhé.” Người thời nay ít nhất cũng nên đọc hoặc lướt qua TAOCP Freedom to Build It Yourself : Tự xây lấy đem lại tự do SQLite không phụ thuộc vào bất cứ thứ gì ngoài những gì Richard tự làm ra (trừ C compiler và libc). Ông còn tự làm cả hệ thống quản lý phiên bản và bug tracker. Điều đó đem lại cho ông sự tự do Tự do (Freedom) nghĩa là tự chăm lo được cho chính mình Những người đi phượt ba lô nói rằng họ tự do khi mang mọi thứ cần thiết trên lưng, bởi vì họ tự lo cho bản thân được Nếu bạn tự xây mọi thứ, bạn không bị ràng buộc vào ai khác, và trong đó có tự do Giả sử SQLite 2 đã chọn Berkeley DB làm storage engine → Khi đó Berkeley DB là mã nguồn mở, nhưng sau này bị bán cho Oracle và trở thành mô hình độc quyền dual-source, nên nếu không trả phí giấy phép thì không thể có source code của bản mới nhất Trình tạo parser của SQLite hiện nay không dùng Yacc hay Bison mà là Lemon do ông tự viết, nên khi cần tính năng ngôn ngữ mới, ông có thể chỉnh sửa mà không bị phụ thuộc vào chúng Đầu những năm 2000, mọi dự án đều dùng CVS nên ông cũng dùng nó, nhưng đến giữa những năm 2000, ý tưởng version control phân tán bắt đầu xuất hiện Xây Fossil Sau khi xem Git và Mercurial rồi tổng hợp yêu cầu, ông quyết định tự phát triển hệ thống version control Giờ đây Fossil hoạt động rất tốt và đã trở thành một dự án riêng Linus Torvalds tạo Git để hỗ trợ phát triển Linux Kernel, nên nếu bạn làm việc liên quan Linux Kernel thì Git là hệ thống version control hoàn hảo Fossil là hệ thống version control vừa khít cho công việc với SQLite. Vì chính ông tạo ra nó nên nó đáp ứng chính xác yêu cầu của ông Bằng cách tự phát triển, bạn kiểm soát được số phận của mình, có nhiều tự do hơn và không phải phụ thuộc vào bên thứ ba Tự cung tự cấp Người sống ngoài đô thị, tự trồng thực phẩm và tự sinh tồn được gọi là gì? Survivalist? Hay Prepper? “Như bạn cũng thấy khi liên lạc với tôi, Gmail của tôi hơi kỳ quặc. Thư cứ bị trả lại. Vì thế tôi đang định tự dựng mail server. Ngay cả lúc chúng ta sắp xếp cuộc họp này, tôi cũng đang ghi chú về chuyện đó. Có lẽ nó không khó hơn việc viết DB engine, nhưng tôi không muốn bị trói vào Gmail. Tôi không muốn họ kiểm soát số phận của tôi. Tôi không muốn họ kiểm soát toàn bộ lịch sử hội thoại của tôi. Tôi muốn tự kiểm soát, nên dù sẽ đau đầu và có rất nhiều việc phải làm, tôi vẫn muốn cố tìm một giải pháp mà mình tự kiểm soát được. Tôi có thể thuê một virtual machine trên cloud để chạy nó mà không phải phụ thuộc vào bên thứ ba.” Nếu có ai đó đến và nói sẽ giải quyết vấn đề cho bạn, bạn phải hiểu rằng họ sẽ lấy đi tự do của bạn. “Nếu muốn tự do, bạn phải tự làm.” Lời khuyên cho người khác Tôi bắt đầu từ một ý tưởng điên rồ là làm một DB engine có thể đọc và ghi trực tiếp từ đĩa mà không cần server. Nếu hỏi các chuyên gia, họ sẽ nói: “Điều đó là không thể. Nó sẽ không bao giờ chạy được. Đó là một ý tưởng ngớ ngẩn.” May mắn là tôi không quen những chuyên gia như vậy nên cứ làm, và rồi mọi chuyện đã diễn ra như thế này Đừng nghe chuyên gia quá nhiều, hãy làm điều hợp lý. Hãy giải quyết vấn đề của bạn -- [1] Bus Factor : Mức độ rủi ro mà nếu một thành viên bị xe buýt tông thì cả đội có thể lâm vào khủng hoảng. Đây là chỉ số nói về rủi ro phát sinh khi thông tin và chức năng không được chia sẻ giữa các thành viên trong nhóm. Cần nâng chỉ số này lên để thông tin được chia sẻ và công việc không tập trung vào một cá nhân cụ thể. [2] DO-178B : Các cân nhắc phần mềm trong chứng nhận hệ thống và thiết bị hàng không (Software Considerations in Airborne Systems and Equipment Certification) Được FAA chấp nhận như một phương pháp chứng minh sự phù hợp cho chứng nhận phần mềm hàng không [3] MCDC : Modified Condition / Decision Coverage Khi có nhiều biểu thức điều kiện, đây là phương pháp thiết kế test case sao cho từng điều kiện riêng lẻ có thể tác động độc lập đến kết quả của toàn bộ biểu thức, không bị ảnh hưởng bởi các điều kiện khác

(corecursive.com)

47 điểm bởi xguru 2021-07-05 | 16 bình luận | Chia sẻ qua WhatsApp

Tóm tắt podcast phỏng vấn nhà phát triển SQLite Richard Hipp (38 phút, có transcript)
Công việc chính của ông là lập trình viên phần mềm cho các tàu khu trục của Hải quân Mỹ
→ Informix dùng bên trong tàu thường xuyên gặp lỗi, server chết và kết nối bị ngắt
→ Vì là tàu chiến, nên ngay cả khi bị hư hại trong lúc chiến đấu cũng không thể hiện popup kiểu “Không thể kết nối tới DB” mà phải vận hành ổn định, bền bỉ.
Cũng không cần transaction, nhưng trong mọi tình huống đều phải đọc được dữ liệu vào RAM
→ Ông tìm một SQL DB engine chạy không cần server, nhưng không có, nên quyết định tự làm

SQLite V1 (năm 2000)

Xem câu lệnh SQL như chương trình, rồi viết một bytecode engine để biên dịch và thực thi truy vấn
Thực tế không được dùng trong dự án (khách hàng muốn dùng Informix)
Ông dùng nó cho mục đích phát triển, rồi công khai lên Internet và mọi người bắt đầu sử dụng
Ông thấy những lời như “Tôi đã chạy SQL DB trên Palm Pilot” và điều đó thu hút sự chú ý của nhiều người. Vì vậy ông được khích lệ để tiếp tục phát triển.

Motorola

Trong khoảng 2001~2002, Motorola gọi điện nói rằng họ sẽ đưa SQLite vào OS điện thoại mới của mình
Họ nói sẽ trả tiền nếu SQLite hỗ trợ các tính năng cần thiết
Đó là lần đầu ông biết rằng có thể kiếm tiền từ mã nguồn mở
Khoảng $80,000, nếu so với bây giờ thì không phải số tiền lớn, nhưng với ông khi đó là con số cực kỳ đáng kinh ngạc
Ông cùng ba người cộng sự thực hiện dự án đó, và đó là khởi đầu

America Online Phones

Sau đó, bên liên hệ tiếp theo là AOL
Đó là thời kỳ gửi CD qua đường bưu điện, và trong chiếc CD đó cần có database
Tức là họ muốn đưa SQLite vào trong CD và cần thêm các tính năng mới

Symbian OS và Nokia

Ông đến London vào dịp Lễ Tạ ơn để họp (vì Anh không có Lễ Tạ ơn)
Họ muốn một DB cho Symbian OS, và SQLite phải cạnh tranh với các DB khác (2 mã nguồn mở, 7 thương mại)
Cả 9 DB còn lại đều có cơ hội tinh chỉnh, nhưng cuối cùng SQLite thắng

Bus Factor [1] và consortium

Bus factor là chỉ số cho biết nếu có bao nhiêu người bị xe buýt tông thì việc phát triển sẽ dừng lại
Dù ông đang làm toàn thời gian cùng nhiều người khác, phía Symbian vẫn nói cần nâng bus factor lên
Ý tưởng là lập SQLite consortium để tài trợ cho dự án và khiến nhiều người tham gia lâu dài hơn
Ông từng đưa ra ý tưởng điên rồ như để mọi thành viên consortium đều có quyền biểu quyết
Mitchell Backer của Mozilla Foundation nghe được chuyện này ở đâu đó rồi gọi điện
→ “Richard, anh đang làm hoàn toàn sai rồi. Để tôi chỉ cho anh cách lập consortium.”
→ Bà bắt đầu đặt ra các quy tắc
→ “Các nhà phát triển phải nắm quyền kiểm soát. Quyết định của họ là cuối cùng. Không phải cứ tham gia là có quyền biểu quyết.”
→ “Các công ty sử dụng thứ này sẽ có vinh dự được đóng góp tiền, nhưng quyết định cuối cùng phải là của anh.”
→ Bà rất dứt khoát và sắp xếp mọi thứ đâu ra đấy. Bà là luật sư
Khi Richard hỏi “Làm sao để mọi người tham gia? Động lực là gì?”,
→ “Đừng lo. Họ sẽ tham gia. Và thực tế, nếu làm như vậy thì Mozilla sẽ là thành viên sáng lập.”
Với sự hỗ trợ của Mozilla, Symbian và Adobe, consortium bắt đầu cùng ba công ty này
→ Lúc đầu khi Symbian nói cần consortium, ông không biết phải làm sao. Ông cũng không biết vì sao Mitchell Baker lại nghe được chuyện đó rồi gọi điện, nhưng tất cả là một hành trình đáng kinh ngạc.

Enter Android : Khởi đầu của Android

Vì mọi smartphone đều dùng SQLite, Richard có thể quan sát sự phát triển smartphone giai đoạn đầu từ mọi góc độ
Năm 2005 ông họp với Android. Khi đó cả Android lẫn iPhone đều chưa ra mắt
Ông debug SQLite bằng cách kết nối vào một chiếc điện thoại giống BlackBerry với màn hình nhỏ ở trên và bàn phím QWERTY đầy đủ
Việc debug bằng GDB trên một chiếc điện thoại đang gắn với mạng viễn thông thực sự là trải nghiệm đáng kinh ngạc
Khi đó chưa ai bên Motorola, Symbian hay Nokia làm như vậy, và chính lúc đó ông biết Android sẽ trở nên khổng lồ

Guy, This Is Important : Mọi người ơi, chuyện này thực sự quan trọng

Thời đó các công ty khác có chu kỳ cập nhật phần cứng và phần mềm rất dài, khoảng 30 ngày, còn Android thì đưa OS mới vào điện thoại đang nối với mạng thực nhiều lần mỗi ngày.
Mẫu điện thoại Android nguyên mẫu ông nhận theo NDA có vỏ trông như được in 3D, nhưng ít nhất vẫn đủ để mang theo.
→ Còn của các công ty khác thì là những breadboard và prototype cồng kềnh, lại không nối mạng nên cũng chẳng thể dùng như điện thoại
Ông muốn nói với người bên Motorola và Symbian rằng “Cái này rất quan trọng, phải giải quyết nó”, nhưng không thể nói ra (vì NDA), và đó đã tạo nên khác biệt

Testing and Aviation Standards : Kiểm thử và tiêu chuẩn hàng không

Adam (người phỏng vấn): “DB của Richard hiện giờ đang ở trạng thái rất sôi động. Đội ngũ có năng lực và giàu tài năng, nhưng vẫn chỉ là một công ty tư vấn phần mềm 1~4 người hỗ trợ DB nằm trong mọi điện thoại Android. Các nhà phát triển cực kỳ nghiêm túc với DB và ghét chuyện dữ liệu gặp sự cố”
Chúng tôi từng ngây thơ khoe với mọi người rằng SQLite không có bug, nhưng Android chắc chắn đã chứng minh rằng chúng tôi sai
Ông từng nghĩ có thể làm ra phần mềm không lỗi, nhưng thật đáng kinh ngạc khi phần mềm được cài lên hàng triệu thiết bị thì có thể phát sinh nhiều bug đến vậy
Khoảng thời gian đó, ông đang làm việc với Rockwell Collins, một công ty avionics, và họ giới thiệu cho ông khái niệm DO-178B [2]
→ DO-178B nói về tiêu chuẩn chất lượng cho các sản phẩm hàng không đòi hỏi độ an toàn cao, và khác với các tiêu chuẩn chất lượng khác ở chỗ nó “đọc được”
→ Nó chỉ tốn vài trăm đô, khá mỏng, nên ông khuyên mọi người nên đọc
Họ thực sự bắt đầu làm theo quy trình của DO-178B, trong đó có 100% MCDC Test Coverage
MCDC (Modified Condition / Decision Coverage) [3] nghĩa là kiểm thử phải đi qua từng nhánh riêng lẻ ít nhất một lần
Để SQLite đạt 100% MCDC, ông mất một năm với cường độ 60 giờ mỗi tuần. Thực sự cực kỳ khó. Ngày nào cũng phải làm 12 tiếng và rất mệt
90~95% test coverage thì dễ, nhưng 5% còn lại mới thật sự khó. Tuy nhiên sau một năm làm như vậy và cuối cùng đạt 100%, Android không còn gửi bug report nữa
Từ đó mọi thứ bắt đầu vận hành ổn định và tạo ra khác biệt lớn. Trong 8~9 năm sau đó không còn bug nữa

Hàng tỷ bài test

Bộ đầu tiên được viết bằng TCL (Tool Command Language), là kiểu test thường thấy của lập trình viên
Bộ test TCL đầu tiên đó đến nay vẫn được bảo trì và công khai. Dù không đạt 100%, nó kiểm thử chi tiết mọi tính năng của SQLite
100% MCDC coverage được gọi là TH3 và không công khai (proprietary)
Họ từng thử kiếm tiền bằng cách bán nó cho các công ty hàng không, nhưng không bán được bản nào nên chẳng có hiệu quả về mặt đó..
Nhưng nó giúp sản phẩm thực sự vững chắc và giúp thêm tính năng mới cũng như sửa bug nhanh hơn
Khó mà đếm chính xác số lượng test, nhưng có 100 nghìn test riêng lẻ được tham số hóa để chạy thành hàng tỷ lượt test
Có checklist, và trước mỗi lần phát hành sẽ test ít nhất 3 ngày
Họ cố tình kiểm thử trên nhiều OS khác nhau
→ Bây giờ gần như mọi thiết bị đều little-endian, nhưng trước đây big-endian khá nhiều. Vì thế họ test big-endian trên PowerPC iBook
→ Họ test trên mọi nền tảng và OS có thể: nền tảng 32-bit, ARM và Intel, nền tảng 64-bit, Windows, Linux, Mac, OpenBSD...
→ Có nhiều test suite khác nhau, gồm bộ TCL ban đầu, cả TH3, và cả fuzzer (fuzz testing) chạy liên tục
Còn có cả SQL Logic test
→ Là một khối lượng khổng lồ câu lệnh SQL do Shane Harrelson tạo ra 10 năm trước
→ Họ đã test trên mọi DB có thể chạm tới, và mọi DB engine đều từng không trả lời nổi, thậm chí bị segmentation fault. SQLite cũng vậy. Trừ Postgres.
→ Chỉ Postgres là luôn cho ra kết quả và không tìm thấy lỗi. Các nhà phát triển Postgres nói rằng là do chúng tôi chưa cố đủ thôi.. Có lẽ vẫn có thể làm Postgres báo lỗi, nhưng chúng tôi thực sự rất ấn tượng
→ Ngay cả bản thương mại của Oracle cũng crash, DB2 cũng crash
→ Điểm quan trọng là làm sao để SQLite cho ra cùng một đáp án với tất cả những truy vấn đó

Building From First Principles

Khi bắt đầu viết, ông tìm xem có tài liệu tham khảo nào về cách xây SQL DB engine không, nhưng không có. Vì thế ông phải tự làm, hoàn toàn là một nhiệm vụ độc lập
Nhiều lý thuyết đang diễn ra ở MIT, Harvard và Berkeley, nhưng nếu không học ở đó thì ông thậm chí còn không biết những lý thuyết đó tồn tại, càng không biết cách tìm ra chúng
Nếu nhìn kỹ, mô hình Volcano mà Postgres dùng và mô hình Byte Code mà SQLite dùng đều hội tụ về cùng một ý tưởng
Bề ngoài thì bắt đầu từ những nơi rất khác nhau, nhưng khi đi vào câu hỏi làm sao để nó nhanh hơn, họ lại hội tụ về cùng một vùng
Ông cho rằng đây giống như một kiểu kiểm chứng về mặt lý thuyết: hai dòng phát triển độc lập đi đến cùng một đáp án
Ví dụ, ông hoàn toàn không biết về Covering Index, nhưng khi tham dự một hội nghị PHP ở Đức, David Axmark của MySQL cũng có mặt và thuyết trình
→ Trong bài nói đó, ông ấy giải thích cách MySQL tạo Covering Index
→ Khi index của DB có nhiều cột, nếu truy vấn chỉ đụng đến các cột đầu của index và câu trả lời nằm trong những cột còn lại của chính index đó, thì DB có thể dùng luôn index mà không cần truy cập bảng gốc, nên công việc sẽ nhanh hơn
→ Vậy là trên chuyến bay về nhà, vì trên máy bay không có nhiều người, ông mở laptop ra và triển khai covering index cho SQLite ngay trên bầu trời Đại Tây Dương

B-Trees and The Art of Computer Programming

Rất nhiều thứ phải tự xây. Chưa từng có ai dạy ông về B-tree. Ông chỉ từng nghe qua
Khi định tự phát triển B-tree, ông có bộ TAOCP của Don Knuth trên giá sách nên tra phần B-tree và Don đã giải thích thuật toán cho ông
Điều thú vị là sách mô tả rất kỹ thuật toán tìm kiếm và chèn của B-tree, nhưng không đưa thuật toán xóa. Nó nằm trong bài tập cuối chương, nên trước khi tự làm B-tree của mình, ông phải giải bài đó. “Cảm ơn Don, thực sự cảm ơn nhé.”
Người thời nay ít nhất cũng nên đọc hoặc lướt qua TAOCP

Freedom to Build It Yourself : Tự xây lấy đem lại tự do

SQLite không phụ thuộc vào bất cứ thứ gì ngoài những gì Richard tự làm ra (trừ C compiler và libc). Ông còn tự làm cả hệ thống quản lý phiên bản và bug tracker. Điều đó đem lại cho ông sự tự do
Tự do (Freedom) nghĩa là tự chăm lo được cho chính mình
Những người đi phượt ba lô nói rằng họ tự do khi mang mọi thứ cần thiết trên lưng, bởi vì họ tự lo cho bản thân được
Nếu bạn tự xây mọi thứ, bạn không bị ràng buộc vào ai khác, và trong đó có tự do
Giả sử SQLite 2 đã chọn Berkeley DB làm storage engine
→ Khi đó Berkeley DB là mã nguồn mở, nhưng sau này bị bán cho Oracle và trở thành mô hình độc quyền dual-source, nên nếu không trả phí giấy phép thì không thể có source code của bản mới nhất
Trình tạo parser của SQLite hiện nay không dùng Yacc hay Bison mà là Lemon do ông tự viết, nên khi cần tính năng ngôn ngữ mới, ông có thể chỉnh sửa mà không bị phụ thuộc vào chúng
Đầu những năm 2000, mọi dự án đều dùng CVS nên ông cũng dùng nó, nhưng đến giữa những năm 2000, ý tưởng version control phân tán bắt đầu xuất hiện

Xây Fossil

Sau khi xem Git và Mercurial rồi tổng hợp yêu cầu, ông quyết định tự phát triển hệ thống version control
Giờ đây Fossil hoạt động rất tốt và đã trở thành một dự án riêng
Linus Torvalds tạo Git để hỗ trợ phát triển Linux Kernel, nên nếu bạn làm việc liên quan Linux Kernel thì Git là hệ thống version control hoàn hảo
Fossil là hệ thống version control vừa khít cho công việc với SQLite. Vì chính ông tạo ra nó nên nó đáp ứng chính xác yêu cầu của ông
Bằng cách tự phát triển, bạn kiểm soát được số phận của mình, có nhiều tự do hơn và không phải phụ thuộc vào bên thứ ba

Tự cung tự cấp

Người sống ngoài đô thị, tự trồng thực phẩm và tự sinh tồn được gọi là gì? Survivalist? Hay Prepper?
“Như bạn cũng thấy khi liên lạc với tôi, Gmail của tôi hơi kỳ quặc. Thư cứ bị trả lại. Vì thế tôi đang định tự dựng mail server. Ngay cả lúc chúng ta sắp xếp cuộc họp này, tôi cũng đang ghi chú về chuyện đó. Có lẽ nó không khó hơn việc viết DB engine, nhưng tôi không muốn bị trói vào Gmail. Tôi không muốn họ kiểm soát số phận của tôi. Tôi không muốn họ kiểm soát toàn bộ lịch sử hội thoại của tôi. Tôi muốn tự kiểm soát, nên dù sẽ đau đầu và có rất nhiều việc phải làm, tôi vẫn muốn cố tìm một giải pháp mà mình tự kiểm soát được. Tôi có thể thuê một virtual machine trên cloud để chạy nó mà không phải phụ thuộc vào bên thứ ba.”
Nếu có ai đó đến và nói sẽ giải quyết vấn đề cho bạn, bạn phải hiểu rằng họ sẽ lấy đi tự do của bạn. “Nếu muốn tự do, bạn phải tự làm.”

Lời khuyên cho người khác

Tôi bắt đầu từ một ý tưởng điên rồ là làm một DB engine có thể đọc và ghi trực tiếp từ đĩa mà không cần server.
Nếu hỏi các chuyên gia, họ sẽ nói: “Điều đó là không thể. Nó sẽ không bao giờ chạy được. Đó là một ý tưởng ngớ ngẩn.”
May mắn là tôi không quen những chuyên gia như vậy nên cứ làm, và rồi mọi chuyện đã diễn ra như thế này
Đừng nghe chuyên gia quá nhiều, hãy làm điều hợp lý. Hãy giải quyết vấn đề của bạn

[1] Bus Factor : Mức độ rủi ro mà nếu một thành viên bị xe buýt tông thì cả đội có thể lâm vào khủng hoảng.

Đây là chỉ số nói về rủi ro phát sinh khi thông tin và chức năng không được chia sẻ giữa các thành viên trong nhóm.
Cần nâng chỉ số này lên để thông tin được chia sẻ và công việc không tập trung vào một cá nhân cụ thể.

[2] DO-178B : Các cân nhắc phần mềm trong chứng nhận hệ thống và thiết bị hàng không (Software Considerations in Airborne Systems and Equipment Certification)

Được FAA chấp nhận như một phương pháp chứng minh sự phù hợp cho chứng nhận phần mềm hàng không

[3] MCDC : Modified Condition / Decision Coverage

Khi có nhiều biểu thức điều kiện, đây là phương pháp thiết kế test case sao cho từng điều kiện riêng lẻ có thể tác động độc lập đến kết quả của toàn bộ biểu thức, không bị ảnh hưởng bởi các điều kiện khác

16 bình luận

enowy 2025-08-07

Không ngờ lại có một bài viết hay như vậy. Thật may vì có thể đọc qua bản dịch.

mkeasy 2021-07-08

Đây đúng là bài viết khiến người ta muốn đọc đi đọc lại nhiều lần. Cảm ơn.

Nếu muốn được tự do, hãy tự mình làm lấy.

Hãy làm những việc hợp lý.

Hãy giải quyết vấn đề của chính bạn.

edunga1 2021-07-05

Đây thực sự là một bài viết rất thú vị!

"Mức độ bao phủ kiểm thử 90~95% thì dễ, nhưng 5% còn lại thực sự rất khó. Nhưng sau khi làm như vậy trong 1 năm và cuối cùng đạt 100%, các báo cáo lỗi từ Android đã không còn gửi đến nữa"

Quả là có chuyện như vậy thật.

panarch 2021-07-05

Đã đọc rất hay. Cảm ơn bạn!

jsryu 2021-07-05

Tôi đọc rất cuốn hút. Cảm ơn bạn

falconer 2021-07-05

Đã đọc rất kỹ.

gmlwo530 2021-07-05

Đọc rất thú vị!

kwangyeol 2021-07-05

Đọc rất thú vị. Cảm ơn bạn.

baeba 2021-07-05

Tôi đã đọc rất thú vị.

Có lẽ việc tóm tắt và sắp xếp lại còn khó hơn nữa.

shaichoi 2021-07-05

Đọc rất hay. Khiến tôi suy nghĩ nhiều. Cảm ơn bạn :)

fureweb 2021-07-05

Tôi đã đọc rất kỹ. Cảm ơn bạn!

kalihman 2021-07-05

Đã đọc rất hay.

jongpak 2021-07-05

Đọc mà quên cả thời gian trôi luôn haha

Giờ nghĩ lại thấy ngại vì trước đây tôi đã đánh giá thấp nó chỉ là một DB nhúng đơn giản^^;

sixmen 2021-07-05

Tôi cứ nghĩ và dùng nó như một DBMS đơn giản chỉ để phát triển cục bộ, nhưng hóa ra nó hoàn toàn không hề đơn giản chút nào!!

nicewook 2021-07-05

Tôi đã đọc nó rất thích thú.

xguru 2021-07-05

Hiện nay, số lượng SQLite đang vận hành trên toàn thế giới đã vượt quá 1 nghìn tỷ.

Tất cả smartphone (Android, iOS) với hơn 4 tỷ thiết bị
Mac/Windows
Trình duyệt FF/Chrome/Safari
PHP/Python
Skype/iTunes/Dropbox/Turbotax
Phần lớn set-top box và TV
Hệ thống đa phương tiện trên phần lớn ô tô

https://www.sqlite.org/mostdeployed.html