Những sự thật thú vị về SQLite

 (avi.im)
23 điểm bởi GN⁺ 2024-12-31 | 7 bình luận | Chia sẻ qua WhatsApp

  • SQLite là cơ sở dữ liệu được phân phối và sử dụng nhiều nhất

    • Có hơn 1 nghìn tỷ cơ sở dữ liệu SQLite đang được sử dụng, và chỉ có ba người bảo trì nó
    • Không cho phép đóng góp từ bên ngoài

  • SQLite được sử dụng nhiều hơn tất cả các hệ quản trị cơ sở dữ liệu khác cộng lại

    • Có hàng tỷ bản sao SQLite tồn tại và nó có mặt ở khắp nơi

  • SQLite là một trong những mô-đun phần mềm được phân phối nhiều nhất

  • Hwaci là công ty phát triển SQLite và cũng quan tâm đến âm nhạc

    Quảng cáo

  • SQLite bắt đầu từ một chiến hạm của Mỹ

    • D. Richard Hipp (DRH) khi đó đang phát triển phần mềm cho tàu khu trục hải quân USS Oscar Austin
    • Mỗi khi máy chủ gặp sự cố, phần mềm hiện có lại ngừng hoạt động
    • DRH đã hình dung ra một cơ sở dữ liệu có thể hoạt động mà không cần máy chủ

  • SQLite không phải là mã nguồn mở theo nghĩa pháp lý

    • Mã nguồn mở đòi hỏi một định nghĩa cụ thể và giấy phép được OSI phê duyệt
    • Thay vào đó, SQLite thuộc phạm vi public domain và có ít ràng buộc hơn giấy phép mã nguồn mở

  • Không cho phép đóng góp từ bên ngoài

    • Chỉ những người được mời mới có thể đóng góp, và các đóng góp phải được hiến tặng vào public domain

  • Mã kiểm thử của SQLite

    Quảng cáo
    • SQLite có hơn 600 dòng mã kiểm thử cho mỗi dòng mã nguồn
    • Các bài kiểm thử bao phủ 100% mọi nhánh của thư viện

  • Một số bài kiểm thử của SQLite là độc quyền

    • Bộ kiểm thử tên là TH3 là độc quyền, và để truy cập cần tham gia SQLite Consortium

  • Mô hình kinh doanh của SQLite

    • Tạo doanh thu thông qua hỗ trợ trả phí, dịch vụ bảo trì, tư cách thành viên consortium và các phần mở rộng thương mại

  • SQLite có bộ quy tắc đạo đức thay vì bộ quy tắc ứng xử

    Quảng cáo

  • SQLite rất nhanh, và trong một số trường hợp sử dụng còn nhanh hơn hệ thống tệp 35%

  • SQLite có mô hình một người ghi

    • Không cho phép nhiều người ghi cùng lúc

  • Khác biệt với các cơ sở dữ liệu khác

    • Mặc định dùng chế độ rollback journal, và khóa ngoại ở trạng thái bị vô hiệu hóa
    • Dùng kiểu dữ liệu lỏng, còn kiểu dữ liệu chặt là tùy chọn

  • Việc SQLite không có kiểu dữ liệu cố định là một điểm bất tiện

    • Có thể chèn dữ liệu mà không có ràng buộc kiểu
    Quảng cáo

  • SQLite rất coi trọng tính tương thích

    • Mọi phiên bản SQLite 3 đều có thể đọc và ghi các tệp cơ sở dữ liệu từ những phiên bản đầu tiên

  • Tác giả của SQLite là DRH đã phát triển Fossil vì cho rằng các hệ thống quản lý phiên bản hiện có không phù hợp

  • DRH đã viết mã B-Tree trên máy bay dựa trên các thuật toán trong sách TAOCP

  • Cách phát âm được khuyến nghị của SQLite là "Ess-Cue-El-Lite", nhưng không có hướng dẫn chính thức

Bài viết liên quan

7 bình luận

 
dalinaum 2024-12-31

SQLite không phải là một cơ sở dữ liệu nhanh như nhiều người nghĩ. MongoDB Realm, nay đã ngừng hỗ trợ, nhanh hơn nhiều. Có vẻ tốc độ không phải là yếu tố lựa chọn quan trọng đến vậy đối với mọi người.
 
dalinaum 2025-01-01

Có người đã hỏi vì sao Realm nhanh và yêu cầu căn cứ, nhưng có vẻ MongoDB đã ngừng hỗ trợ và xóa bài viết đó rồi.

Vì vậy, với tư cách là người từng làm việc ở đó một thời gian, tôi muốn giải thích những lý do kỹ thuật mà tôi còn nhớ. Tôi nghĩ lý do lớn nhất là Realm dùng ít bộ nhớ hơn so với SQLite và có tỷ lệ cache hit cao hơn.

Về cơ bản, Realm chọn dung lượng được lưu trong bộ nhớ dựa trên kích thước thực tế được sử dụng. Vì thế, ngay cả khi người dùng chọn kiểu dữ liệu có kích thước lớn, trong nhiều trường hợp nó vẫn được serialize bằng kích thước nhỏ chỉ vài bit. Chỉ khi người dùng thực sự dùng dữ liệu lớn hơn thì mới thực hiện chuyển đổi.

Realm nhóm các kiểu dữ liệu giống nhau lại và lưu chúng liền kề nhau. Người dùng thường không truy cập toàn bộ dữ liệu của bảng mà chỉ truy cập liên tục một phần dữ liệu. Nhờ cách mã hóa kích thước nhỏ đã nói ở trên, lượng dữ liệu có thể lấy từ cache trong một lần sẽ tăng lên rất nhiều.

Realm không hydrate vào đối tượng POJO mà truyền dữ liệu khi cần trong getter và setter. Để làm được điều này, trong trường hợp Java, nó thao tác ở mức bytecode. Lý do các kiểu dữ liệu như Protobuf được dùng trong ứng dụng Facebook của Meta vào thời điểm đó là vì quá trình hydrate này là một bất lợi lớn về hiệu năng, còn việc chỉ truy cập dữ liệu cần thiết thì có lợi thế.

Realm nhanh hơn SQLite rất nhiều trong hầu hết các kịch bản, nhưng tôi không nghĩ điều này là yếu tố lớn trên thị trường.

Tôi nhớ đối thủ lớn nhất của Realm là Parse do Facebook tạo ra. Sau đó, đối thủ lại là Firebase của Google. Cả hai đều không phải cơ sở dữ liệu di động cục bộ mà là dịch vụ giúp lưu dữ liệu lên máy chủ từ xa một cách đơn giản. Nghe thì có vẻ lạ khi Realm lại cạnh tranh với hai dịch vụ này, nhưng trên thực tế người dùng có lẽ chỉ cần lưu được ở đâu đó là đủ, còn tốc độ thì không quá quan trọng.

Và sau đó, khi Ericsson đầu tư, phạm vi của Realm đã bị thu hẹp. Ericsson thấy Realm đã có mức độ hiện diện nhất định trên iOS nên không hiểu vì sao còn phải tiếp tục phát triển thêm tính năng. Họ đánh giá cao giá trị của Realm như một giải pháp đồng bộ hóa hơn. Sau đó Realm đã được sáp nhập vào MongoDB.
 
aer0700 2024-12-31

Có lẽ 80% lý do tôi chọn SQLite là vì nó rất dễ xử lý.
 
dalinaum 2025-01-01

Tôi cũng cho rằng đây là một trong những lý do quan trọng. Realm cung cấp cách sử dụng dựa trên thread-local, hỗ trợ tự động cập nhật, và nói rằng khi truy vấn lại ở thread khác thì có thể truyền cùng một dữ liệu với chi phí rất thấp; họ cũng khuyến nghị không truyền dữ liệu sang thread khác, nhưng không dễ để giải thích những điều này.
 
sanggi 2024-12-31

Có vẻ như SQLite được sử dụng ở rất nhiều nơi thú vị!
 
GN⁺ 2024-12-31
Ý kiến Hacker News

  • Có ý kiến cho rằng OSI không phải là tiêu chuẩn của mã nguồn mở. Định nghĩa mã nguồn mở của OSI hữu ích nhưng cũng có phê phán và tranh cãi. Nói rằng SQLite về mặt pháp lý không phải là mã nguồn mở là một khẳng định sai

    • Không nên phụ thuộc vào việc được OSI phê duyệt. Danh sách giấy phép được OSI phê duyệt chỉ phản ánh lịch sử mang tính thực dụng và chính trị
    • Có tranh cãi về việc SQLite có phải là mã nguồn mở hay không. Việc hiến tặng vào phạm vi công cộng không phải là giấy phép nên không đáp ứng OSD, nhưng lại cởi mở hơn

  • Blog này có vẻ đang cố dùng lại những luận điểm cũ được tái chế về một chủ đề phổ biến để kéo lượt xem và tương tác

    • Các bài đăng trước đó của blog thiếu chiều sâu kỹ thuật và có nhiều nội dung cường điệu

  • SQLite có bộ quy tắc đạo đức (CoE) chứ không phải bộ quy tắc ứng xử (CoC). CoC được dùng như một công cụ để kiểm soát hành vi của người đóng góp bên ngoài, còn CoE là tuyên bố về cách hành xử mà các nhà phát triển SQLite muốn thể hiện với người khác

  • Có sự nhầm lẫn về cách phát âm của SQLite. Người ta nói nó được phát âm là "Ess-Cue-El-Lite", nhưng cũng có người phát âm là "S-Q-L-ite"

  • SQLite hỗ trợ bảng nghiêm ngặt một cách tùy chọn. Có thể ép kiểu bằng cách dùng CREATE TABLE name (stuff TEXT) STRICT

  • SQLite không chỉ là cơ sở dữ liệu SQL mà còn có thể được dùng như cơ sở dữ liệu NoSQL. Cách lưu dữ liệu bằng cột JSON khá hữu ích

  • Có người từng làm dự án cùng Richard Hipp. Ông ấy có nguồn thu ổn định thông qua các hợp đồng hỗ trợ

  • Trong một bản phát hành của SQLite, hiệu năng đã tăng 50% nhờ rất nhiều tối ưu hóa vi mô

  • SQLite được dùng cho tạo mẫu nhanh và dump log, nhưng khi cần nhiều writer thì gặp khó khăn. Đây là một trong những lý do chính khiến người ta rời khỏi SQLite

  • SQLite có mô hình một writer duy nhất. Redis cũng là mô hình đơn luồng

  • Một trong những sự thật thú vị về SQLite là khi người dùng bắt đầu gọi điện cho nhà phát triển vào giữa đêm, họ đã phải đổi tiền tố mặc định từ sqlite_ sang etilqs_