Ai đó có thể giải thích nghĩa đầy đủ trong thuật ngữ cơ sở dữ liệu? Ví dụ, ý nghĩa của việc nói một chỉ mục là cồng kềnh. Tôi đã cố gắng tìm kiếm nó nhưng không có lời giải thích nào về việc đầy hơi là gì, chỉ có những gì nó gây ra hoặc những gì nó gây ra.
Câu trả lời:
Do cách PostgreSQL xử lý các giao dịch và đồng thời, MVCC - Kiểm soát đồng thời nhiều phiên bản, bạn có thể nhận được sự phình to. Trong PostgreSQL, khi bạn thực hiện một UPDATEhoặc DELETE, hàng không thực sự bị xóa. Đối với a DELETE, nó chỉ đơn giản đánh dấu hàng là không có sẵn cho các giao dịch trong tương lai và đối với phần UPDATEdưới đó, nó được kết hợp INSERTsau đó DELETE, trong đó phiên bản trước của hàng được đánh dấu là không có sẵn.
Mặc dù dữ liệu được đánh dấu là không có sẵn, nó vẫn ở đó và không gian có thể được sử dụng. Sau đó, để đánh dấu không gian là có sẵn để sử dụng bởi cơ sở dữ liệu, một quy trình chân không cần đi kèm đằng sau các hoạt động và đánh dấu không gian có sẵn cho cơ sở dữ liệu để sử dụng. Nó không được trả lại cho hệ điều hành, tuy nhiên. Điều đó chỉ xảy ra khi không có hàng hoạt động trong toàn bộ trang, điều này có thể không phổ biến trong một số khối lượng công việc. Đây có thể là một điều tốt cho một số khối lượng công việc, bởi vì bạn chỉ cần cập nhật không gian trên các trang riêng lẻ bên trong các tệp dữ liệu mà không cần thêm các tệp dữ liệu bổ sung.
Các vấn đề xảy ra với sự phình to khi có số lượng lớn các tuple chết so với các tuple sống. Đi bộ và kiểm tra tất cả các cờ hiển thị cần có thời gian và có thêm tệp dữ liệu cho mối quan hệ dẫn đến tải IO không cần thiết bổ sung. Bloat đặc biệt đáng chú ý trên các chỉ mục, cũng có thể có nhiều bộ dữ liệu chết, đôi khi nhiều hơn so với bảng. Bloat có thể làm chậm quá trình tra cứu và quét chỉ mục, điều này sẽ hiển thị trong thời gian truy vấn tăng chậm và thay đổi kế hoạch truy vấn.
Bạn có thể khôi phục không gian bằng cách sử dụng pg_reorg , pg_repack , CLUSTERhoặc VACUUM FULL. Điều này sẽ đi qua và sắp xếp lại các tập tin, di chuyển các bộ dữ liệu và sắp xếp lại để đảm bảo rằng không có bộ dữ liệu chết nào, sẽ loại bỏ sự phình to.
Bloat cũng có thể được quản lý một cách hiệu quả bằng cách điều chỉnh VACUUMcài đặt trên mỗi bảng, đánh dấu không gian tuple chết có sẵn để sử dụng lại bởi các truy vấn tiếp theo.
Bạn có thể sử dụng các truy vấn trên PostgreQuery Wiki liên quan đến Hiển thị cơ sở dữ liệu và Chỉ mục Bloat để xác định mức độ phình to của bạn và từ đó, thực hiện một chút phân tích hiệu suất để xem bạn có gặp vấn đề với số lượng phình to trên bảng của mình không .
Điều này có lẽ đề cập đến các vấn đề phổ biến với các chỉ mục trong đó hai hoặc nhiều cột được thêm vào chỉ mục hoặc có các chỉ mục chồng chéo trên một bảng. Đó là, nhiều chỉ mục với cùng một tập hợp các cột trong đó (làm cho một trong số chúng không cần thiết). Tôi sẽ xem xét tất cả các chỉ mục trên các bảng tìm kiếm các cột chồng chéo, tìm kiếm các chỉ mục chỉ là tập hợp con của các chỉ mục khác và xóa chúng NẾU bạn có thể xác định rằng chúng không được sử dụng.
Trên hết, khi dữ liệu trong các bảng được cập nhật, các chỉ mục có thể bị phân mảnh khiến chúng lớn hơn mức cần thiết. Tôi không quen thuộc với postgres, nhưng tôi nghi ngờ có các phương pháp để chống phân mảnh các chỉ mục (bằng cách xây dựng lại các chỉ mục) sẽ làm giảm kích thước của chúng trên đĩa.