13 điểm bởi GN⁺ 2023-12-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Viết lại các hàm JSON hiện có của SQLite. Tùy theo mẫu sử dụng, có thể chạy nhanh hơn nhiều lần
  • Ban đầu, các hàm JSON hoạt động theo 3 bước
    1. Phân tích JSON sang định dạng nhị phân nội bộ để mã C có thể xử lý dễ dàng
    2. Thực hiện thao tác được yêu cầu, như tìm một trường cụ thể hoặc chỉnh sửa JSON
    3. Nếu thao tác đã thay đổi JSON, chuyển định dạng nhị phân nội bộ thành chuỗi JSON RFC-8279 để xuất ra hoặc lưu trữ
  • Ngoài bước 2, bước 1 và 3 đều là overhead
  • SQLite đã sử dụng dạng JSON nhị phân nội bộ chứa nhiều con trỏ. Dạng này phù hợp với chương trình C nhưng khó serialize
  • Thông qua việc viết lại JSONB, biểu diễn nhị phân nội bộ của JSON này được chuyển thành một mảng byte liên tục có thể đọc hoặc ghi như SQL BLOB
  • Nhờ vậy, có thể lưu biểu diễn JSON dùng nội bộ trong cơ sở dữ liệu thay vì JSON dạng văn bản, nên có thể loại bỏ overhead của bước 1 và 3

Những thay đổi

  • Tất cả chức năng hiện có vẫn được giữ nguyên. Chỉ bổ sung chức năng mới
  • Giờ đây, mọi hàm JSON nhận JSON văn bản làm đầu vào cũng sẽ nhận nội dung nhị phân JSONB với cùng tham số
    • Không cần cho hàm biết phải lấy văn bản hay dữ liệu nhị phân. Hàm sẽ tự nhận biết
  • Giờ đây, các hàm JSON xuất JSON được cung cấp dưới hai phiên bản
    • Hàm json_ hiện có hoạt động giống hệt như trước
    • Có thêm hàm jsonb_ trả về JSONB thay vì JSON văn bản, nên trong xử lý thông thường có thể bỏ qua bước 3
  • Nếu không thay đổi ứng dụng, tốc độ sẽ chỉ nhanh hơn một chút (1%) nhưng mọi thứ vẫn tiếp tục hoạt động như cũ
  • Tuy nhiên, nếu chỉnh sửa ứng dụng để bắt đầu lưu JSONB thay vì JSON văn bản, có thể thấy hiệu năng tăng ít nhất 3 lần, đặc biệt với các tác vụ sử dụng JSON nhiều
  • Ngoài ra, JSONB trong đa số trường hợp cũng nhỏ hơn JSON văn bản một chút (khoảng 5% đến 10%), nên nếu dùng JSON nhiều, kích thước cơ sở dữ liệu cũng có thể giảm đôi chút

1 bình luận

 
GN⁺ 2023-12-07
Ý kiến trên Hacker News
  • Có khá nhiều nhầm lẫn về JSONB

    • JSONB được dùng trong ứng dụng gần như tương tự kiểu dữ liệu JSON.
    • Ứng dụng vẫn đọc và ghi chuỗi JSON, nhưng không nhìn thấy nội dung JSONB thực tế.
    • Có thể dùng cùng các hàm SQL đó với tiền tố jsonb_.
    • Kiểu dữ liệu JSON được lưu trên đĩa dưới dạng JSON, còn JSONB được lưu dưới dạng nhị phân đặc biệt.
    • Kiểu dữ liệu JSON phải phân tích toàn bộ JSON để thực hiện thao tác, trong khi JSONB có thể bỏ qua bước phân tích cú pháp và thao tác trực tiếp trên định dạng lưu trên đĩa.
    • Nếu chỉ đơn giản đọc và ghi toàn bộ blob JSON trong SQLite thì kiểu dữ liệu JSON là phù hợp, nhưng nếu truy vấn hoặc thao tác dữ liệu bằng SQL thì JSONB phù hợp hơn.
  • JSONB là định dạng do Postgres cung cấp và được khuyến nghị vì hiệu năng đọc tốt hơn JSON thông thường.

  • Phải mất vài năm mới hiểu được mục đích của document store, và nó rất xuất sắc để xây dựng POC (Proof of Concept).

    • Việc tăng cường hỗ trợ JSON sẽ giúp SQLite trở thành một document store phù hợp.
    • Có thể tuần tự hóa và giải tuần tự hóa message Protobuf để có hỗ trợ kiểu đầy đủ, và nếu biến cột này thành JSONB thì có thể lọc theo cột đó mà không cần trải dữ liệu có thể tìm kiếm ra các cột khác.
  • Thắc mắc về quy trình phát hành của SQLite.

    • Bản phát hành mới nhất là 3.44, còn JSONB nằm trong snapshot tiền phát hành.
    • Muốn dùng tính năng này trên D1 của Cloudflare và Fly.io, nhưng phiên bản SQLite có thể chưa được công bố hoặc đã được tùy biến.
    • Các thay đổi API có thể phá vỡ cam kết của Cloudflare rằng có thể nhập các tệp dump/query tương thích với SQLite.
  • Có thể thử JSONB trong snapshot tiền phát hành hoặc playground.

  • Ý tưởng cốt lõi của đặc tả JSONB là mỗi phần tử bắt đầu bằng một header chứa kích thước và kiểu dữ liệu.

    • Có ý kiến cho rằng việc bổ sung chỉ báo kích thước vào đặc tả JSON có thể giảm lượng bộ nhớ cần thiết để xử lý JSON.
  • Quen thuộc với BSON của MongoDB nhưng không quen với JSONB.

    • Tham khảo bài blog giải thích sự khác biệt giữa JSONB và BSON.
  • JSONB có ảnh hưởng đến hiệu năng.

  • Mong rằng có cách nén dữ liệu JSON trên nhiều hàng.

    • Có các blob rất giống nhau trong từng hàng, nên cần một cách giảm dung lượng lưu trữ cho nhiều blob tương tự trên nhiều hàng.
  • Bất chấp định dạng nội bộ, nó vẫn có thể dùng ngay trong ứng dụng.

    • Ví dụ, trong chèn hàng loạt bằng Python, lời gọi chèn cho mỗi hàng có overhead đáng kể.
    • JSONB có thể cải thiện hiệu năng bằng cách dùng CTE (Common Table Expressions).
    • json_each có thể nhận tham số được bind từ ứng dụng dưới dạng JSONB BLOB.