Phần chúng ta ghét nhất ở PostgreSQL (2023)

Phần đáng ghét nhất trong PostgreSQL

• PostgreSQL đã trở thành DBMS được yêu thích nhất trên Internet trong 5 năm gần đây. Điều này là nhờ độ tin cậy, tính năng, khả năng mở rộng và việc nó phù hợp với phần lớn khối lượng công việc vận hành.
• Tuy nhiên, cách PostgreSQL triển khai kiểm soát đồng thời đa phiên bản (MVCC) bị đánh giá là tệ nhất so với các DBMS quan hệ khác.

Kiểm soát đồng thời đa phiên bản là gì?

• Mục tiêu của MVCC là cho phép nhiều truy vấn одновременно đọc và ghi cơ sở dữ liệu mà không can thiệp lẫn nhau.
• DBMS không ghi đè lên hàng hiện có mà duy trì nhiều phiên bản, để truy vấn có thể chọn phiên bản phù hợp nhằm đáp ứng yêu cầu.
• Cách này loại bỏ nhu cầu khóa bản ghi tường minh, cho phép truy vấn quan sát một ảnh chụp nhanh của cơ sở dữ liệu.

Kiểm soát đồng thời đa phiên bản của PostgreSQL

• Khi cập nhật hàng hiện có, PostgreSQL sử dụng cách lưu trữ phiên bản chỉ ghi thêm để áp dụng thay đổi bằng cách tạo ra một phiên bản mới.
• Cách này gây ra nhiều vấn đề phức tạp.

Lưu trữ đa phiên bản

• PostgreSQL lưu tất cả các phiên bản hàng trong cùng một không gian lưu trữ.
• Khi cập nhật, nó cấp phát một ô phiên bản mới, sao chép phiên bản cũ rồi áp dụng thay đổi.
• PostgreSQL dùng chuỗi phiên bản để ghi lại quan hệ giữa các phiên bản.

Dọn dẹp phiên bản

• PostgreSQL sử dụng quy trình vacuum để loại bỏ các phiên bản cũ.
• Tự động vacuum (autovacuum) chạy định kỳ để xóa các phiên bản đã hết hạn và tái sử dụng không gian.

Vì sao MVCC của PostgreSQL là tệ nhất

• Cách triển khai MVCC của PostgreSQL là một thiết kế từ thập niên 1980, không phù hợp với mô hình hệ thống cấu trúc log hiện đại.
• Bài viết giải thích bốn vấn đề chính phát sinh từ MVCC của PostgreSQL.

Vấn đề 1: sao chép phiên bản

• PostgreSQL sao chép mọi cột sang phiên bản mới, làm tăng trùng lặp dữ liệu và nhu cầu lưu trữ.
• MySQL và Oracle lưu delta để tránh vấn đề này.

Vấn đề 2: phình bảng

• Các phiên bản đã hết hạn trong PostgreSQL vẫn chiếm không gian, và nếu autovacuum không xóa được chúng thì cơ sở dữ liệu sẽ tiếp tục phình to.
• Điều này làm giảm hiệu năng truy vấn.

Vấn đề 3: bảo trì chỉ mục phụ

• PostgreSQL phải cập nhật mọi chỉ mục sau mỗi lần cập nhật.
• Điều này làm giảm hiệu năng truy vấn.

Vấn đề 4: quản lý vacuum

• Hiệu năng của PostgreSQL phụ thuộc rất nhiều vào mức độ hiệu quả của autovacuum.
• Nếu autovacuum không hoạt động đúng cách thì sẽ phát sinh vấn đề hiệu năng.

Tổng kết của GN⁺

• PostgreSQL vẫn là một DBMS rất được yêu thích, nhưng cách triển khai MVCC của nó không còn hiện đại.
• Cần rất nhiều thời gian và công sức để giải quyết các vấn đề MVCC của PostgreSQL.
• Có thể cải thiện hiệu năng bằng cách tối ưu cấu hình autovacuum của PostgreSQL.
• Có thể cân nhắc MySQL và Oracle như các lựa chọn thay thế để xử lý vấn đề MVCC của PostgreSQL.

[GN⁺]

Ý kiến Hacker News

• OrioleDB đã cố gắng giải quyết vấn đề bằng một storage engine mới

  • Nếu chủ yếu thực hiện thao tác INSERT thì không cần thêm không gian bổ sung
  • Có giới hạn về số lượng câu lệnh trong một transaction, nhưng có thể tránh điều này bằng cách dùng COPY FROM
  • Từ góc độ DBA, không cần quản lý riêng không gian rollback/undo

• Thiết kế của PostgreSQL không phải tệ ở mọi mặt

  • MySQL và Oracle lưu delta nén giữa phiên bản mới và phiên bản hiện tại
  • git không lưu diff mà lưu toàn bộ object, tương tự PostgreSQL

• Cách triển khai MVCC của Oracle và MySQL không lưu địa chỉ vật lý của phiên bản mới

  • Thay vào đó, chúng lưu một định danh logic để DBMS tìm địa chỉ vật lý của phiên bản hiện tại
  • Điều này có thể làm việc đọc secondary index chậm hơn, nhưng bù lại giảm overhead nhờ những ưu điểm khác

• Khi cập nhật một hàng đơn lẻ trong MySQL, SELECT id WHERE something; UPDATE what WHERE id=id nhanh hơn nhiều

  • Trong các tác vụ thông thường, cách này không được dùng, và điều đó làm DML dùng một lần chậm hơn

• Trong thập niên 2010, MongoDB được xem là "webscale" vì các ghi không bền vững

  • Đây là kết quả của marketing

• Không đồng ý với phần giải thích về pg_repack

  • VACUUM FULL thì nặng, nhưng repack là một lựa chọn thay thế nhanh hơn và nhẹ hơn

• PostgreSQL trở nên phổ biến vì các lý do sau

  • Tính an toàn dữ liệu, ACID, sự tương đồng với Oracle, MVCC, tuân thủ chuẩn SQL, đội ngũ Postgres, cộng đồng, kiểu dữ liệu, hiệu năng cao, tính linh hoạt của BSD
  • PostgreSQL đang liên tục phát triển, và cộng đồng đóng vai trò rất lớn

• Có câu hỏi liệu việc PostgreSQL lưu toàn bộ phiên bản row-tuple mới có phải là thuộc tính của storage engine mặc định hay không

• Bài viết được viết tốt, dễ đọc và dễ hiểu

  • Nó giúp hiểu các vấn đề liên quan đến vacuum, và các sơ đồ minh họa cũng rất tốt