Ở phần trước, chúng ta đã biết được cách thức tổ chức lưu trữ trong PostgreSQL (data page (8KB) -> data file (1GB) -> tablespace). Trong phần này chúng ta sẽ tìm hiểu 2 đối tượng lưu trữ đặc biệt hơn.

 

TOAST

TOAST là từ viết tắt của The Oversized-Attribute Storage Technique. Bình thường 1 block dữ liệu có dung lượng 8KB. Nếu 1 row có kích thước lớn hơn 8KB, chẳng hạn row có chứa dữ liệu hình ảnh, video… row đó sẽ không thể chứa đủ trong block 8KB.

 

Để giải quyết vấn đề này, PostgreSQL sẽ “bẻ” dữ liệu cột có dung lượng lớn ra thành các mảnh nhỏ 2KB, lưu trong TOAST table, là 1 table phụ trợ cho table chính, được quản lý tự động, trong suốt với người dùng. Dữ liệu của cột đó trong table chính bây giờ chỉ là pointer trỏ đến dữ liệu thật trong toast table.

 

Việc lưu trữ này phụ thuộc vào thuộc tính Storage của data type. Chỉ có 1 số kiểu dữ liệu hỗ trợ lưu trong toast table, như char, varchar, bytea, numeric

 

 

Ở trên ta thấy 3 cột kiểu char, varcharbytea mặc định có storage extended. Cột kiểu numeric ta có thể set như sau:

 

 

Có tất cả 4 giá trị thuộc tính Storage:

  • PLAIN: không hỗ trợ compress cũng như lưu ra toast table
  • EXTENDED: dữ liệu sẽ được nén trước, nếu đủ thì lưu vào table chính, nếu vẫn lớn thì lưu ra toast table. Đây là thuộc tính mặc định cho đa số các data type hỗ trợ
  • EXTERNAL: không hỗ trợ compress, nếu lớn thì lưu ra toast table
  • MAIN: hỗ trợ compress, nhưng không hỗ trợ lưu ra toast table. Thực ra thì vẫn có thể lưu, trong trường hợp không thể làm cho row đủ nhỏ lưu trong 1 page/block. Như ở trên ta thấy có thể set cho column kiểu numeric

Ưu điểm của toast là việc lưu trữ trong suốt, truy cập thao tác bình thường như với các kiểu dữ liệu thông thường, không cần phải theo dõi OID.  Tuy vậy, hạn chế là kích thước của 1 giá trị lưu theo dạng toast hiện tại chỉ có thể lớn tối đa 1GB, và 1 table có cột có toast storage thì chỉ có thể có tối đa 4 tỷ dòng. Ngoài ra, ta phải được encode binary data trước khi ghi vào database, cũng như cần decode binary data khi query.

 

Binary Large Object – BLOB

 

Với dữ liệu có kích thước lớn hơn 1GB, ta phải sử dụng 1 cấu trúc lưu trữ khác, là Binary Large Object, hay còn gọi là BLOB. Binary Large Object có ưu điểm là hỗ trợ lưu giá trị có kích thước lên tới 4TB, và tối đa 4 tỷ giá trị BLOB trong database, dữ liệu cũng sẽ được encode/decode tự động.

 

Tuy vậy, sử dụng Binary Large Object đòi hỏi phải theo dõi OID, đồng thời các thao tác truy cập, sử dụng dữ liệu sẽ phức tạp hơn thông thường.

 

2 cách thức lưu trữ này cũng khá rắc rối, nên chúng ta sẽ cùng tìm hiểu sâu hơn trong những bài viết sau.