Hiểu lầm về SQLite-on-the-Server: Phù hợp với quy mô siêu lớn (Hyper-Scale) hơn là quy mô nhỏ

 (rivet.gg)
20 điểm bởi GN⁺ 2025-03-05 | 2 bình luận | Chia sẻ qua WhatsApp
  • Nhiều nhà phát triển cho rằng việc dùng SQLite trên máy chủ chỉ phù hợp với các ứng dụng quy mô nhỏ
  • Lý do là như sau:
    • Chi phí hạ tầng thấp: không cần máy chủ cơ sở dữ liệu riêng (vận hành bằng một tệp duy nhất)
    • Dễ phát triển và kiểm thử: có thể dùng cùng một tệp DB ở cả client và server
    • Giảm tối đa gánh nặng quản trị: không cần cấu hình phức tạp hay quản lý daemon
    • Độ tin cậy cao: SQLite là DB được triển khai rộng rãi nhất thế giới và có độ bền vững mạnh mẽ
  • Các công cụ như LiteFS, Litestream, rqlite, Dqlite, Bedrock bổ sung replication và tính sẵn sàng cao (HA) cho SQLite, giúp nó phù hợp với các triển khai quy mô nhỏ

Tuy nhiên, bài viết này khám phá tiềm năng của SQLite đối với các ứng dụng siêu quy mô (Hyper-Scale), chứ không chỉ quy mô nhỏ

Vấn đề mở rộng của các cơ sở dữ liệu lớn truyền thống

  • Các ứng dụng lớn thường khó duy trì PostgreSQL hay MySQL như một DB đơn lẻ, nên dùng cơ sở dữ liệu được sharding
  • Ví dụ: Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL được sharding), Citus (Postgres được sharding)
  • DB được sharding có các ưu điểm sau:
    • Tối ưu hóa batch read thông qua phân vùng dữ liệu
    • Có thể mở rộng theo chiều ngang (scalability)
    • Cung cấp hiệu năng ghi cao

Nhưng các giải pháp partitioning hiện nay có những nhược điểm sau

  • Schema cứng nhắc (Rigid Schemas): không hỗ trợ truy vấn linh hoạt như MySQL hay Postgres
  • Khó thay đổi schema: thêm index hoặc thay đổi quan hệ làm tăng gánh nặng vận hành
  • Phép toán cross-partition phức tạp: khó duy trì giao dịch ACID, cần các kỹ thuật phức tạp như two-phase commit (2PC)
  • Vấn đề không nhất quán dữ liệu: khó áp dụng các ràng buộc dữ liệu mạnh giữa các partition, nên tính toàn vẹn dữ liệu dễ bị phá vỡ

Tiềm năng của cơ sở dữ liệu hyperscale dựa trên SQLite

  • Cloudflare Durable Objects và Turso cho thấy cách thiết kế ứng dụng hyperscale dựa trên SQLite
  • Các hệ thống này mang lại những điểm mạnh sau:
    • Mở rộng động (Dynamic Scaling): tạo cơ sở dữ liệu theo từng entity để giảm độ phức tạp của hạ tầng
    • Số lượng cơ sở dữ liệu chi phí thấp gần như vô hạn: không ép buộc phân vùng dữ liệu như sharding truyền thống, mà có thể tạo instance SQLite mới bất cứ khi nào cần
    • Phân phối toàn cầu (Global Distribution): đặt cơ sở dữ liệu gần người dùng hơn để cải thiện hiệu năng
    • Replication và độ bền tích hợp sẵn (Built-in Replication & Durability): khác với SQLite truyền thống, dữ liệu được sao chép đa vùng để duy trì tính sẵn sàng cao
  • Cách thay thế sharding bằng SQLite (sử dụng Cloudflare Durable Objects & Turso)
    • Trong mô hình sharding truyền thống, nhiều nhật ký chat được lưu trong một partition cơ sở dữ liệu duy nhất
    • Với SQLite, có thể tạo cơ sở dữ liệu SQLite độc lập cho từng kênh, nhờ đó sử dụng schema linh hoạt hơn
    • Cấu trúc ví dụ
      • Sharding truyền thống: bảng nhật ký chat + khóa partition
      • Dựa trên SQLite: DB SQLite riêng cho từng kênh (bao gồm nhật ký chat, người tham gia, thông tin phản ứng)
  • Ưu điểm của cách làm này với SQLite gồm có:
    • Giữ được giao dịch ACID cục bộ: có thể thực hiện giao dịch trong từng DB riêng lẻ mà không gặp vấn đề cross-partition
    • I/O hiệu năng cao: vì SQLite là DB một tệp, hiệu năng đọc và ghi rất cao
    • Có thể tận dụng các tính năng mở rộng của SQL:
      • FTS5 (Full-Text Search): cải thiện hiệu năng tìm kiếm
      • JSON1: hỗ trợ lưu trữ và truy vấn dữ liệu JSON
      • R*Tree, SpatiaLite: có thể khai thác dữ liệu không gian
    • Hỗ trợ SQL migration: tương thích với các công cụ migration hiện có như Prisma, Drizzle
    • Hỗ trợ lazy schema migration:
      • Không cần chạy migration ngay lập tức; có thể dùng cách thực hiện migration nhẹ khi mở instance SQLite

Hạn chế khi dùng SQLite trên máy chủ

  • Thiếu các giải pháp mã nguồn mở, có thể tự host
  • Không hỗ trợ truy vấn cross-database → cần một data lake riêng cho mục đích phân tích
  • Hệ sinh thái công cụ cơ sở dữ liệu còn hạn chế (SQL browser, ETL pipeline, giám sát, sao lưu)
    • StarbaseDB đang giải quyết vấn đề này dựa trên Cloudflare Durable Objects + SQLite
  • Thiếu giao thức chuẩn thống nhất
    • PostgreSQL, MySQL, Cassandra dùng các giao thức đã được chuẩn hóa, nhưng SQLite server vẫn thiếu một giao thức mạng chuẩn hóa
  • Thiếu các trường hợp triển khai quy mô lớn dùng SQLite ở mức hyperscale
    • Dù còn thiếu các case study như Cassandra hay DynamoDB, điều này có thể thay đổi theo thời gian

Kết luận: SQLite không chỉ là DB cục bộ đơn giản mà còn là một lựa chọn mạnh mẽ cho ứng dụng siêu quy mô

  • SQLite không chỉ là DB cho các dự án nhỏ đơn giản, mà còn là công cụ mạnh mẽ có thể thay thế cách sharding truyền thống trong các ứng dụng siêu quy mô
  • Khi sử dụng Cloudflare Durable Objects & Turso, có thể phân tách cơ sở dữ liệu theo từng entity và vẫn giữ được sức mạnh của SQL cùng giao dịch ACID trong khi mở rộng
  • Đây nhiều khả năng sẽ trở thành một lựa chọn thay thế linh hoạt hơn và dễ quản lý hơn so với các cơ sở dữ liệu sharding truyền thống

Bài viết liên quan

2 bình luận

 
pcj9024 2025-03-05

Ai đủ can đảm để sẵn sàng dùng sqlite ở quy mô siêu lớn phải gánh rất nhiều request chứ...
 
GN⁺ 2025-03-05
Ý kiến Hacker News

  • Một người dùng đang cân nhắc thay thế cơ sở dữ liệu tùy chỉnh bằng SQL

    • Sqlite3 được xem là một ứng viên vì chạy trên một máy chủ đơn
    • Cơ sở dữ liệu chủ yếu có khối lượng công việc đọc nhiều, nên Sqlite3 có lợi thế
    • Cơ sở dữ liệu tùy chỉnh rất nhanh trong một số tác vụ nhất định, nhưng đây là một quyết định phức tạp
    • Đã thực hiện benchmark để so sánh Sqlite3 với PostgreSQL
    • Sqlite3 nhanh gần gấp đôi PostgreSQL trong mọi tác vụ
    • Cơ sở dữ liệu tùy chỉnh nhanh hơn Sqlite3 từ 100 đến 1.000 lần khi truy cập từng bản ghi đơn lẻ

  • Một người dùng đang phát triển ứng dụng web local-first và cho rằng SQLite là phù hợp

    • Muốn có cách dễ dàng để đồng bộ trạng thái cơ sở dữ liệu SQLite với dịch vụ đám mây
    • Turso và SQLite Cloud có vẻ là những lựa chọn đầy hứa hẹn
    • Đang cân nhắc một cách tiếp cận đơn giản cho phép người dùng đẩy lên bộ nhớ lưu trữ S3

  • Thảo luận về lợi ích của mô hình SQLite-per-partition

    • Có những giới hạn trong các tình huống cần bảng toàn cục
    • Chia sẻ kinh nghiệm từ nhiều dự án khác nhau sử dụng SQLite

  • Trong môi trường nhiều người dùng, SQLite gặp khó khăn do thiếu MVCC

    • Thắc mắc về các triển khai và phần mở rộng tương thích với SQLite có bổ sung MVCC

  • Bản phát hành 8.0 của Ruby on Rails mở rộng hỗ trợ SQLite

    • Thay thế các thành phần cache và hàng đợi công việc, đồng thời khiến nó phù hợp với các ứng dụng web thông thường

  • Một người dùng không quen với Vitess hay Citus thấy khó hiểu nội dung bài viết

    • Thắc mắc về sự khác biệt giữa Sharded SQLite và Sharded Postgres

  • Một người dùng không muốn dùng VPS hosting nên đã tạo một trang web sử dụng SQLite

    • Tải cơ sở dữ liệu xuống thiết bị của người dùng để sử dụng

  • Một người dùng gặp khó khăn khi thiết lập bộ điều khiển Ubiquiti đã đề xuất dùng SQLite

    • Cho rằng dùng SQLite thay vì MongoDB có thể mang lại trải nghiệm tốt hơn

  • Tính đến năm 2022, Apple vận hành khoảng 300.000 instance Cassandra/ScyllaDB

    • Đánh giá cách tiếp cận DB-per-tenant đang đi theo hướng tốt hơn

  • TDLib (thư viện cơ sở dữ liệu của Telegram) sử dụng SQLite

    • Mỗi instance TDLib xử lý đồng thời hơn 24.000 bot đang hoạt động