Đi tìm một SQLite nhanh hơn

 (avi.im)
2 điểm bởi GN⁺ 2024-12-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • SQLite vốn đã là một hệ thống cơ sở dữ liệu nhanh, nhưng các nhà nghiên cứu đang tìm cách làm cho nó còn nhanh hơn
  • Các nhà nghiên cứu từ Đại học Helsinki và Cambridge đã công bố bài báo "đồng thiết kế runtime/cơ sở dữ liệu serverless thông qua I/O bất đồng bộ", cho thấy có thể giảm độ trễ đuôi (tail latency) tới 100 lần. Bài báo này trở thành nền tảng cho Limbo, một phiên bản SQLite được viết lại bằng Rust.

io_uring

  • Giải thích về io_uring: Hệ thống con io_uring của nhân Linux cung cấp giao diện cho I/O bất đồng bộ. Nó giảm overhead sao chép bộ đệm thông qua ring buffer giữa không gian người dùng và không gian nhân. Ứng dụng có thể gửi yêu cầu I/O và thực hiện công việc khác cho đến khi nhận được thông báo từ hệ điều hành rằng thao tác I/O đã hoàn tất.

  • Thực thi truy vấn của SQLite: SQLite sử dụng tệp để lưu trữ dữ liệu, mở cơ sở dữ liệu bằng hàm sqlite3_open(), và chuyển câu lệnh SQL thành bytecode bằng hàm sqlite3_prepare(). Hàm sqlite3_step() thực thi các lệnh bytecode để xử lý truy vấn.

Tiền đề

  • Sự trỗi dậy của điện toán serverless: Trong môi trường serverless, độ trễ cơ sở dữ liệu có thể trở thành vấn đề. Nếu nhúng cơ sở dữ liệu trực tiếp vào runtime ở edge thì sẽ không có độ trễ mạng, và SQLite rất phù hợp với môi trường như vậy.

  • Vấn đề của SQLite: Việc sử dụng I/O đồng bộ khiến tài nguyên không được tối ưu hóa và gây ra các vấn đề về đồng thời cũng như đa thuê bao.

  • Chuyển sang io_uring: Việc thay thế các lời gọi POSIX I/O bằng io_uring không hề đơn giản; cần phải thiết kế lại SQLite để phù hợp với mô hình I/O bất đồng bộ.

Limbo

  • Hỗ trợ I/O bất đồng bộ: Limbo sửa đổi các thành phần VM và BTree để hỗ trợ I/O bất đồng bộ, đồng thời thay thế các lệnh bytecode đồng bộ bằng lệnh bất đồng bộ. I/O bất đồng bộ loại bỏ blocking và cải thiện khả năng đồng thời.

  • Tách biệt truy vấn và storage engine: Đề xuất tách query engine và storage engine để tối đa hóa việc sử dụng tài nguyên.

Đánh giá và kết quả

  • Benchmarking: Nhóm nghiên cứu mô phỏng một runtime serverless đa thuê bao để mỗi tenant có cơ sở dữ liệu nhúng riêng. Khi so sánh độ trễ truy vấn giữa SQLite và Limbo, Limbo giảm độ trễ đuôi ở p999 tới 100 lần.

  • Công việc trong tương lai: Họ dự định thực hiện thêm benchmark với nhiều tiến trình đọc và ghi; lợi thế hiệu năng hiện chỉ nổi bật từ mốc p999 trở đi.

  • Mã nguồn mở: Mã của Limbo được phát hành mã nguồn mở tại: Limbo GitHub

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-17
Ý kiến Hacker News

  • Có thảo luận rằng một số trường hợp sử dụng cụ thể của điện toán serverless, chẳng hạn như AWS Lambda và cơ sở dữ liệu trung tâm, không phải lúc nào cũng phù hợp với các ứng dụng được xây dựng theo cách serverless

    • Có kinh nghiệm từng xử lý một bài toán cách đây 6-7 năm, trong đó cần xử lý các tệp phân cấp phức tạp và trích xuất thông tin cụ thể
    • FaaS tốn kém đối với các tác vụ đòi hỏi nhiều tính toán, và việc tải rồi phân tích các tệp XML lớn mỗi lần là không hiệu quả
    • Giải pháp là dùng một chức năng trung tâm chạy theo bộ hẹn giờ để đọc và phân tích tệp, nạp vào cơ sở dữ liệu SQLite, lập chỉ mục rồi lưu tệp lên S3
    • Hàm Lambda sẽ tải tệp từ S3 và thực hiện truy vấn khi tệp mới hơn bản sao cục bộ hoặc khi cold start
    • Nhận ra rằng Lambda có thư mục cục bộ /tmp, và runtime Python đã bao gồm SQLite nên không cần tải lên mã nào ngoài chính hàm đó
    • Cảm thấy thú vị khi đang có những nỗ lực giúp kiểu giải pháp này có thể nhanh hơn nữa

  • Có lẽ nên nêu rõ rằng một trong hai nhà nghiên cứu là sếp của tác giả

    • Đã hiểu nhầm rằng tác giả và nhà nghiên cứu không có liên hệ với nhau

  • Đồng ý với nhận định rằng "chỉ từ p999 trở lên mới thấy lợi ích rõ rệt, còn ở p90 và p99 thì hiệu năng gần như giống SQLite"

    • Rất thích SQLite và tối ưu hóa, nhưng điều này là sự thật

  • SQLite có bộ kiểm thử rất rộng nên đã được kiểm tra cực kỳ kỹ lưỡng

    • Băn khoăn liệu bản viết lại có được kiểm thử tương tự hay không, đặc biệt khi dùng những tính năng nhanh nhưng khó viết và có thể dễ lỗi như io_uring

  • Để benchmark, họ mô phỏng một runtime serverless đa tenant, trong đó mỗi tenant có cơ sở dữ liệu nhúng riêng

    • SQLite có một luồng riêng cho mỗi tenant và đo bằng cách chạy truy vấn trong từng luồng
    • Thắc mắc liệu cấu hình SQLite serverless có dùng một tiến trình SQLite cho mỗi request hay không

  • Trước đây từng có nỗ lực đưa async I/O vào Postgres nhưng đã bị dừng lại

    • Đề xuất gần đây là cho phép thay thế tùy biến storage manager mà không cần fork codebase
    • Rất quan tâm đến đề xuất mới này, và nó liên quan đến xu hướng tách biệt storage với compute

  • Có câu hỏi về ý tưởng rằng khi async I/O đang chạy thì có thể làm việc khác

    • Thắc mắc rằng khi làm việc với cơ sở dữ liệu thì có phải vẫn phải chờ giao dịch hoàn tất hay không

  • Với tư cách là tác giả bài blog, không ngờ bài này lại lên trang nhất

    • Đang làm việc tại Turso, bài báo được công bố vào tháng 4 năm 2024 và từ đó đã có nhiều cải tiến

  • SQLite là mã nguồn mở, nhưng test harness quan trọng thì không

    • Có câu hỏi về cách các phương án thay thế sẽ đảm bảo tính tương thích

  • Từng cố tìm một cách đơn giản để tạo ra một định dạng giống JSON như một tập con nghiêm ngặt của định dạng tệp SQLite nhưng không thành công

    • Định dạng tệp có quá nhiều yếu tố tùy ý nên đã mất hứng thú, nhưng có thể người khác sẽ thành công