Kích thước cơ sở dữ liệu giảm sau khi sao lưu trên PostgreQuery 8.3 và khôi phục trong PostgreQuery 9.4

Tôi đã thực hiện pg_dumptrên cơ sở dữ liệu JIRA mà tôi đang lưu trữ trong máy chủ PostgreQuery 8.3. Kích thước của cơ sở dữ liệu sau vacuum fulllà 217132652(khoảng 207 MB).

Sau đó, tôi đã khôi phục cơ sở dữ liệu JIRA trên máy chủ PostgreQuery 9.4 bằng lệnh sau:

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

Tôi giả sử rằng khôi phục sẽ thoát khỏi bất kỳ lỗi nào kể từ khi tôi sử dụng ON_ERROR_STOP=1, nhưng tập lệnh SQL đã hoàn thành chính xác (mặc dù một số cảnh báo không liên quan đến khôi phục dữ liệu).

Tôi đã kết thúc với một cơ sở dữ liệu với kích thước 158019348(khoảng 151 MB).

Vậy, câu chuyện ở đây là gì? Tôi có thể giả sử cơ sở dữ liệu đã được khôi phục thành công và PostgreQuery đã tối ưu hóa công cụ lưu trữ của nó (ở đâu đó giữa phiên bản 8.3 và 9.4) và đang sử dụng không gian hiệu quả hơn?

Khi bạn khôi phục cơ sở dữ liệu, bạn có tất cả thông tin trên đó , không có khoảng trống giữa các hàng (hoặc trong các chỉ mục), trừ khi có một số cài đặt cụ thể (về cơ bản: FILLFACTORcho các bảng và FILLFACTORcho các chỉ mục ).

Mặt khác, khi cơ sở dữ liệu của bạn đã được sử dụng một thời gian và bạn đã chia sẻ các phần chèn, cập nhật và xóa, không gian không sử dụng miễn phí sẽ xuất hiện . Điều này là do cách PostgreSQL và Multiversion Concurrency Control, hay còn gọi là MVCC hoạt động. MVCC cho phép khóa ít hơn, về cơ bản có nghĩa là bạn tiết kiệm thời gian . Nhưng bạn phải trả giá về mặt không gian :

1. Mọi thứ đều UPDATEtương đương với INSERTcùng với a DELETE, với chi phí chung (ít nhất là về mặt không gian được sử dụng) liên kết với cả hai.
2. Khi bạn có một vài giao dịch đang chạy và mỗi giao dịch đang diễn INSERTra, UPDATEing hoặc DELETEing, bạn có đồng thời một vài bản sao của mỗi hàng liên quan.
3. Không gian được phân bổ cho các phiên bản hàng này sẽ không được giải phóng ngay sau khi cam kết và trong một thời gian, sẽ là không gian không được sử dụng trong các tệp nơi dữ liệu bảng (và chỉ mục) của bạn đang được lưu trữ.

Autovacuum chăm sóc không gian này được sử dụng lại theo mặc định hoặc bạn có thể có một số quy trình cụ thể để hút bụi thường xuyên .

Thực tế này đã có thể giải thích sự thay đổi kích thước.

Tối ưu hóa giữa các phiên bản có lẽ cũng đã diễn ra; và có thể giải thích những cải tiến hơn nữa. Tối ưu hóa cũng có thể đã được thực hiện cho tốc độ chứ không phải kích thước, và kích thước thực tế có thể thực sự phát triển từ phiên bản này sang phiên bản tiếp theo. Tôi thực sự không biết chi tiết cụ thể để có thể nói; mặc dù nhận xét từ @Erwin nói rằng cả hai thay đổi làm cho bảng của bạn co lại và thay đổi làm cho bảng của bạn phình to (tăng trưởng) đã diễn ra kể từ phiên bản 8.3.

Để phân biệt giữa hai hiệu ứng, nếu bạn tò mò, bạn có thể, như @Jack Douglas gợi ý, khôi phục cơ sở dữ liệu của bạn vào ngày 8.3. Nó có thể sẽ thu nhỏ kích thước. Nếu nó co lại dưới 151 MB (kích thước nhỏ hơn những gì bạn nhận được với phiên bản 9,4), thì việc loại bỏ không gian không sử dụng đã khiến DB của bạn co lại và thay đổi phiên bản thực sự khiến DB của bạn phát triển.

Để hiểu rõ hơn về MVCC, hãy xem bài thuyết trình của Bruce Momjian .