Xây dựng Postgres bằng Rust — Cách tiếp cận tận dụng LLVM của cơ sở dữ liệu

 (turso.tech)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Turso mở rộng theo cấu trúc LLVM của cơ sở dữ liệu bằng cách gắn frontend tương thích Postgres vào lõi cơ sở dữ liệu viết bằng Rust, để một engine thực thi duy nhất xử lý nhiều ngôn ngữ cơ sở dữ liệu
  • SQL của Postgres được phân tích thành AST chung rồi biên dịch thành bytecode VDBE; dự án pgmicro dùng để kiểm chứng tính khả thi đã được hợp nhất vào cây mã chính và trở thành nền tảng phát triển chính thức
  • Lõi hiện có hỗ trợ tương thích tệp SQLite, ghi đồng thời bằng MVCC, thực thi bất đồng bộ, hệ thống kiểu dữ liệu phong phú và materialized view tự động cập nhật, đồng thời được kiểm chứng độ tin cậy bằng nhiều kỹ thuật kiểm thử
  • Thiết kế cho phép chạy nhúng hoặc dưới dạng một tệp duy nhất trên trình duyệt, di động và nhiều loại thiết bị, nhưng ứng dụng hiện có, ORM và psql vẫn có thể kết nối qua giao thức wire của Postgres
  • Thay vì nhắm tới độ tương thích 100%, dự án tập trung vào các tính năng cốt lõi được dùng rộng rãi để phần lớn ứng dụng hiện có có thể chạy mà không cần sửa đổi, đồng thời đang xem xét áp dụng WASM và lớp tương thích cho extension và PL/pgSQL, phát triển dưới giấy phép MIT

Vì sao xây Postgres trên Turso

  • Turso là một lõi cơ sở dữ liệu hiện đại viết bằng Rust, và họ đang xây một cơ sở dữ liệu tương thích Postgres trên đó từ đầu
  • Mục tiêu dài hạn không phải chỉ đơn giản chuyển Postgres hiện có sang Rust mà là tạo ra một cơ sở dữ liệu mới với kiến trúc hiện đại
    • Không dùng tiến trình riêng cho mỗi kết nối
    • Có thể chạy nhúng ngay trong trình duyệt
    • Có thể quản lý một cơ sở dữ liệu như một tệp duy nhất
    • Materialized view được tự động làm mới mà không cần tác vụ riêng
  • Dự án hướng tới kiến trúc biên dịch có thể thay thế với nhiều frontend gắn vào một lõi ổn định
    • SQLite là frontend đầu tiên
    • Postgres là frontend chính thức tiếp theo
    • Trong tương lai có thể thêm các frontend như MySQL, Redis hoặc các cơ sở dữ liệu thử nghiệm
  • Kết quả hiện tại chưa phải sản phẩm hoàn chỉnh mà là giai đoạn nền tảng phát triển đã có thể chạy thực tế

Từ tái triển khai SQLite đến lõi cơ sở dữ liệu dùng chung

  • Ban đầu Turso là dự án tái triển khai hoàn toàn SQLite bằng Rust và kiến trúc hiện đại, đồng thời vẫn giữ tính tương thích tệp để có thể mở và tạo tệp SQLite
  • Dự án cũng đã có các tính năng vượt ra ngoài phạm vi của SQLite
    • Hỗ trợ ghi đồng thời bằng MVCC như Postgres
    • Cung cấp hệ thống kiểu dữ liệu phong phú tương tự Postgres
    • Hoạt động hoàn toàn bất đồng bộ nên phù hợp với môi trường bị ràng buộc như trình duyệt cũng như khi chạy native
    • Materialized view được tự động cập nhật theo thời gian thực, nên không cần cron REFRESH MATERIALIZED VIEW hay kết hợp trigger
  • Việc thêm frontend Postgres không làm thay đổi mục tiêu hiện có của Turso và SQLite
    • Dự án vẫn tiếp tục theo đuổi khả năng tương thích hoàn toàn với SQLite và mở rộng tính năng cho các workload tương lai
    • Khi triển khai các tính năng cần thiết, có thể tận dụng cả test của Postgres để tăng tốc phát triển

Độ tin cậy và mô hình đóng góp công khai

  • Để tái tạo độ vững chắc của SQLite, dự án xem độ tin cậy là một tính năng của sản phẩm
    • Sử dụng kiểm thử mô phỏng có tính xác định
    • Thực hiện kiểm thử Antithesis
    • Đồng thời áp dụng oracle testing, fuzzing và các kỹ thuật hình thức
  • Turso hiện có hơn 260 người đóng góp và vận hành mô hình đóng góp công khai (Open Contribution), cho phép cả người ngoài tham gia vào định hướng dự án
  • Dự án hướng tới môi trường kiểu Linux kernel, lấy mã nguồn và tiêu chuẩn chất lượng cao làm trung tâm, nơi những người đóng góp bền bỉ cũng tham gia vào quyết định của dự án
  • Dự án chấp nhận cả đóng góp do AI viết, nhưng phải đạt chất lượng đủ tốt, và con người vẫn phải rà soát mã kỹ lưỡng cũng như hiểu kiến trúc

Máy ảo VDBE bên trong SQLite

  • SQLite không phải cấu trúc một tầng chạy SQL trực tiếp, mà là máy ảo biên dịch SQL theo phương ngữ SQLite thành bytecode VDBE rồi thực thi
  • VDBE không phải bytecode đa dụng như JVM, .NET hay WASM, mà cung cấp các phép toán mức cao chuyên biệt cho cơ sở dữ liệu như tìm mục trong B-tree
  • Ngôn ngữ bytecode này không có đặc tả công khai hay giao diện mô-đun hóa cho bên ngoài, nhưng nó thực sự tồn tại bên trong SQLite, và Turso cũng áp dụng cùng thiết kế đó
  • Để kiểm chứng tính tổng quát của VDBE trong Turso, nhóm đã chuyển Doom bằng một trình biên dịch C-to-VDBE nhỏ
    • Biên dịch engine Turso thực tế sang WASM để chạy bytecode VDBE của Doom trong một tab trình duyệt
    • Chạy Doom theo đúng cách cơ sở dữ liệu xử lý SELECT
    • Mỗi khung hình được xử lý như một hàng kết quả
    • Vùng nhớ được biểu diễn dưới dạng blob có thể đọc và ghi
    • Có thể xem phần triển khai tại kho turso-vdbe-doom-example

Kiến trúc biên dịch của frontend Postgres

  • Các nỗ lực trước đây nhằm kết hợp SQLite và Postgres chủ yếu dựa vào dịch truy vấn ở tầng query để biến truy vấn Postgres thành truy vấn SQLite, do cấu trúc nguyên khối của SQLite, và sự khác biệt trong hành vi bên ngoài của hai cơ sở dữ liệu gây ra độ lệch rất lớn
  • Về mặt nội bộ, phần lớn cơ sở dữ liệu SQL đều thực hiện các phép toán nền tảng tương tự nhau xoay quanh B-tree và tập chỉ mục
  • Cấu trúc lưu trữ của Postgres và SQLite có những khác biệt rõ ràng
    • Postgres lưu hàng trong heap file và dùng B-tree index riêng, tuple version, TID, vacuum
    • SQLite gom cụm dữ liệu trong B-tree
  • Những khác biệt này chủ yếu phát sinh từ cách bố trí byte trên đĩa, và các phép toán cần cho Postgres có thể được biểu diễn bằng VDBE hiện có hoặc được hỗ trợ bằng cách mở rộng lệnh VDBE
  • Trong cấu trúc mới, frontend cơ sở dữ liệu có thể được hoán đổi
    1. Phân tích ngôn ngữ Postgres thành AST chung
    2. Biên dịch AST thành bytecode của Turso
    3. Lõi Turso dùng chung thực thi bytecode
  • Thử nghiệm ban đầu để kiểm chứng tính khả thi được thực hiện qua pgmicro, và kết quả đã được hợp nhất vào cây mã chính của Turso để trở thành dự án chính thức

Hình thức chạy và kịch bản sử dụng

  • Mục tiêu là cung cấp cùng một SQL Postgres và hành vi cơ sở dữ liệu dưới nhiều hình thức mà không cần server
    • Chạy cơ sở dữ liệu tương thích Postgres thực sự trong một tab trình duyệt
    • Agent có thể tạo cơ sở dữ liệu mới cho từng người dùng và quản lý mỗi cơ sở dữ liệu như một tệp duy nhất
    • Ứng dụng local-first có thể tải dữ liệu Postgres về thành một tệp đơn rồi đồng bộ lại
    • Chạy nhúng như SQLite trên điện thoại di động và nhiều loại thiết bị
  • Dự án cũng có kế hoạch hỗ trợ trong Turso/Postgres khả năng đồng bộ cơ sở dữ liệu Turso hiện có xuống tệp cục bộ
  • Không chỉ có chạy nhúng và dạng tệp đơn, dự án còn bao gồm cả giao thức wire và triển khai server để ứng dụng hiện có, ORM và psql có thể kết nối
  • Trong tương lai gần, frontend chính thức do nhóm Turso trực tiếp phát triển sẽ là SQLite và Postgres, còn cấu trúc sẽ được mở để người đóng góp bên ngoài có thể tạo các frontend khác

Cách chạy hiện tại và cách tham gia

  • Hiện chưa có gói phát hành, nhưng có thể tự build và chạy từ mã nguồn 
    cd postgres/cli && cargo run
  • Frontend Postgres không được phát triển ở kho riêng mà ngay từ ngày đầu đã được phát triển như frontend chính thức bên trong cây mã Turso
  • Việc phát triển và đóng góp diễn ra tại kho GitHub của Turso

Mục tiêu và ranh giới của tính tương thích

  • Do Postgres phức tạp hơn SQLite rất nhiều, dự án không đặt tương thích 100% làm mục tiêu bắt buộc
  • Dự án tập trung hỗ trợ đầy đủ các tính năng cốt lõi và tính năng được dùng rộng rãi để đa số người dùng có thể chạy ứng dụng mà không cần sửa đổi
  • Khi tính năng hiện đại xung đột với khả năng tương thích 1:1 hoàn hảo, dự án sẽ đánh giá theo từng tính năng
    • Materialized view của Turso dùng cách tự động cập nhật theo thời gian thực
    • Chưa xác định có triển khai riêng cách cũ không tự động cập nhật chỉ để đạt tương thích hoàn toàn hay không
  • Khi phạm vi tính năng tăng lên, Turso/Postgres có thể trở nên gần với một cơ sở dữ liệu độc lập hơn là bản sao của Postgres

Sử dụng AI và tốc độ phát triển

  • Dự án tích cực dùng công cụ AI nhưng không bỏ qua việc rà soát mã và hiểu kiến trúc
  • Với các thành phần quan trọng như cơ sở dữ liệu, nhóm cho rằng công cụ AI vẫn chưa đạt tới mức có thể thay thế trách nhiệm kiểm chứng
  • So với cách chạy Fable 24 giờ mỗi ngày, tốc độ theo từng commit có thể chậm hơn, nhưng dự án khởi đầu từ một lõi cơ sở dữ liệu đã hoạt động và được kiểm thử rộng rãi
  • Thay vì thay đổi quá nhanh rồi làm hỏng hệ thống, nhóm chọn cách triển khai chậm hơn nhưng đúng đắn
  • Việc hoàn thiện mọi tính năng sẽ cần thời gian, và một số tính năng có thể phải trải qua quá trình phát triển dài cho đến khi kiến trúc phù hợp được hình thành

PL/pgSQL và extension

  • PL/pgSQL không phải thứ bất khả thi vì về bản chất đây là một ngôn ngữ thủ tục, nhưng thay vì tái triển khai nguyên trạng, nhiều khả năng dự án sẽ cung cấp một ngôn ngữ thủ tục riêng cùng lớp tương thích
  • Dự án đã có proof of concept cho việc nạp một số extension của Postgres trong container WASM
    • Có thể nạp tùy ý các extension chỉ dùng những symbol do container WASM cung cấp
    • Có tổn thất hiệu năng khi chạy WASM
    • Đây chưa phải phương án đã được chốt là thiết kế cuối cùng
  • Nhóm cho rằng một hệ thống extension cho phép chạy mã tùy ý mà không giới hạn là không mong muốn
  • Một số extension có thể không được hỗ trợ, nhưng nhiều extension được kỳ vọng có thể nạp nếu biên dịch sang WASM

Lịch trình dự kiến và chiến lược mã nguồn mở

  • Thay vì tạo cơ sở dữ liệu mới hoàn toàn từ đầu, dự án bắt đầu từ một lõi đã hoạt động, đã được kiểm thử và chia sẻ phần lớn cấu trúc nội bộ với Postgres
  • Việc triển khai toàn bộ tính năng của Postgres có thể mất rất nhiều thời gian, nhưng nhóm kỳ vọng trong vài tháng có thể cung cấp một tập con tính năng đủ lớn để hữu ích trong công việc thực tế
  • Hai nhà phát triển cốt lõi hiện khoảng 44 tuổi và còn có thể tiếp tục phát triển ít nhất 20 năm nữa, nên không vội hoàn thành toàn bộ tính năng
  • Tốc độ và phạm vi phát triển thực tế phụ thuộc rất nhiều vào đóng góp từ cộng đồng
    • Khi hỗ trợ đa tiến trình cho phương ngữ SQLite, do đội ngũ không có máy Windows nên phần triển khai Windows đã bị bỏ lại
    • Một nhà phát triển bên ngoài dùng Turso rất nhiều đã quan tâm và hoàn thành hỗ trợ Windows chỉ trong một tuần
  • Các frontend thử nghiệm có thể được phát triển ngoài cây mã, nhưng frontend Postgres chính thức sẽ áp dụng cùng giấy phép MIT như Turso hiện có

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Có cảm giác gần như mọi cơ sở dữ liệu SQL đều biên dịch truy vấn cho máy ảo (VM)
    Nên việc chỉ riêng SQLite được nêu ra ở điểm này có vẻ hơi lạ

    • Hầu hết cơ sở dữ liệu tạo ra cây toán tử quan hệ và đặt giao diện push hoặc pull cho từng toán tử
      Trong khi đó, SQLite biên dịch truy vấn thành bytecode mệnh lệnh với biến và vòng lặp

  • Với tư cách là người phát triển pgwire, thật vui khi thấy Turso lại dùng pgwire cho cơ sở dữ liệu tương thích PostgreSQL

  • Tò mò vì sao công ty lại cho rằng cần phải chuyển hướng

  • Tò mò không biết họ đã hoàn thành việc tái triển khai SQLite hay là đã từ bỏ nó
    https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

  • Đây là một bài viết rất thú vị, việc nó bị báo cáo sai thật đáng xấu hổ

    • Đây là công nghệ có sức ảnh hưởng lớn, đến mức một ngày nào đó có thể thay đổi cục diện dự án công việc của tôi
      Nó hoàn toàn không phải “off-topic” hay “spam”, nên tôi không thể hiểu nổi vì sao lại bị báo cáo như vậy
      Cũng không rõ có phải chỉ vì trong bài có một dấu gạch nối mà ai đó kết luận đó là rác AI hay không, cảm giác như mọi người đang thật sự mất trí
      Văn hóa báo cáo trên trang này đã trở nên khủng khiếp, mong ban quản trị có biện pháp. Chặn vài người báo cáo ác ý thì có khi những người còn lại cũng sẽ tự kiềm chế
    • Đến mức chính việc báo cáo sai giờ đã trở thành một phần văn hóa ở đây

  • Từ trước tôi đã thấy khó chịu với cách Turso tự nhận là người kế thừa của SQLite, và vì thế đã tự nhủ từ vài năm trước là sẽ không bao giờ dùng phần mềm của họ
    Nhưng nếu họ cung cấp materialized view tự động làm mới nhanh và rẻ bên ngoài SQL Server, thì có lẽ cuối cùng tôi vẫn sẽ dùng