Tôi đã cập nhật / truy cập bảng rất nhiều nơi tôi lưu trữ các đối tượng java được tuần tự hóa. Họ ở trong bảng trong 2-3 giờ (cũng đang được cập nhật trong khoảng thời gian đó) và sau đó loại bỏ. Kích thước của bảng là khoảng 300MB. Tôi đã phát hiện ra nó rất, rất thường xuyên VACUUMed và tự hỏi nếu thay đổi fillfactorsẽ giúp gì?
Câu trả lời:
Các từ khóa ở đây là:
Điểm 1. là dấu hiệu cho hệ số lấp đầy thấp hơn, trong khi 2. thì ngược lại. Nó giúp hiệu suất nếu nhiều phiên bản hàng được lưu trữ trên cùng một trang dữ liệu. Cập nhật HOT sẽ đạt được điều đó. Đọc ở đây hoặc ở đây . Họ cần một số phòng ngọ nguậy trên trang dữ liệu - như bộ dữ liệu chết hoặc không gian dành cho fillfactor<100. Nhưng họ chỉ có thể làm việc của mình, nếu không có chỉ số nào liên quan đến bất kỳ cột nào được cập nhật , điều này đúng với trường hợp của bạn.
Một yếu tố quan trọng khác ở đây sẽ là kích thước tuple (so với kích thước trang của bạn (thường là 8 kb). Chi tiết khác trong câu trả lời liên quan này:
Nếu kích thước tuple là 4 kb trở lên, việc giảm hệ số lấp đầy sẽ là vô ích, vì không bao giờ có thể có nhiều hơn một tuple trên trang dữ liệu. Bạn cũng có thể để nó tại 100(dù sao đó cũng là mặc định). Tuy nhiên, một số loại dữ liệu là "nướng" và được lưu trữ ngoài luồng nếu vượt quá giới hạn kích thước, do đó, các bộ dữ liệu yêu cầu nhiều trong ngã ba quan hệ chính là rất hiếm.
Bất cứ điều gì bạn làm, VACUUM sẽ được chạy thường xuyên. Và đó thường là một điều tốt, tôi sẽ không lo lắng về điều đó. Bạn tạo ra rất nhiều bộ dữ liệu chết. VACUUMxác định các hàng chết không thể nhìn thấy đối với bất kỳ giao dịch mở nào nữa. Hướng dẫn sử dụng:
Hình thức tiêu chuẩn
VACUUMloại bỏ các phiên bản hàng chết trong bảng và chỉ mục và đánh dấu không gian có sẵn để tái sử dụng trong tương lai .
Nhấn mạnh đậm của tôi.
Bạn có thể chơi với các cài đặt trên mỗi bảng cho autovacuum để kích hoạt nó ít hơn (hoặc nhiều hơn) chỉ cho bảng này:
Các ngưỡng mặc định và các yếu tố tỷ lệ được lấy từ
postgresql.conf, nhưng có thể ghi đè chúng trên cơ sở từng bảng ;
Nhấn mạnh đậm của tôi. Đặc biệt với autovacuum_vacuum_thresholdvàautovacuum_vacuum_scale_factor . Chạy VACUUMnhiều thực sự có thể là một ý tưởng tốt, thay vì rất thấp fillfacter. Điều đó phụ thuộc vào các mẫu truy cập. Nếu tất cả các bộ dữ liệu trực tiếp, giả sử, 3 giờ và mỗi lần được cập nhật nhiều lần, tôi vẫn sẽ hạ thấp xuống mức fillfactor50. Bạn sẽ phải kiểm tra và tìm ra điểm ngọt ngào.
Tất cả điều này sang một bên, vì dữ liệu của bạn dường như không ổn định để bắt đầu: sử dụng UNLOGGEDbảng :
Dữ liệu được ghi vào các bảng chưa được ghi không được ghi vào nhật ký ghi trước (xem Chương 29 ), làm cho chúng nhanh hơn đáng kể so với các bảng thông thường. Tuy nhiên, chúng không an toàn với sự cố : một bảng không được gắn sẽ tự động bị cắt sau khi gặp sự cố hoặc tắt máy ô uế. Nội dung của một bảng chưa được đăng ký cũng không được sao chép sang các máy chủ dự phòng.
Nhấn mạnh đậm của tôi. Không sử dụng điều này nếu máy chủ của bạn có thể gặp sự cố và bạn vẫn cần dữ liệu sau đó. Nhưng nếu chúng ta đang nói về dữ liệu phiên cho các ứng dụng web, đây có thể là một mức giá chấp nhận được để trả.
Hoặc, thậm chí triệt để hơn: Sử dụng kho lưu trữ khóa-giá trị như Redis nếu bạn có thể làm mà không cần các tính năng và bảo mật được cung cấp bởi RDBMS hoàn toàn.
Tôi muốn đề xuất một DBMS giá trị khóa, nhưng tôi ném nó ra ngoài vì lợi ích.
Thay vì thực hiện các câu lệnh INSERT & DELETE, chỉ thực hiện CẬP NHẬT.
Cấu trúc bảng sẽ giống như
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriateCột giữ đối tượng sẽ có chiều dài cố định để tránh chia tách và di chuyển hàng. Kích thước cột này để chứa các đối tượng của bạn và để lấp đầy một trang trên đĩa một cách hiệu quả.
Điền trước bảng của bạn với nhiều hàng như bạn sẽ cần và một vài hàng nữa.
Khi một đối tượng được viết, hãy tìm một hàng với Được sử dụng = Sai và CẬP NHẬT hàng đó. Khi một đối tượng bị hủy, đặt nó được sử dụng thành "Sai". Không có rác được tạo và do đó không có bộ sưu tập rác.
Tất nhiên, có rất nhiều, nhiều điều kiện ngoại lệ để xử lý (tràn hàng, tràn bảng, điều kiện cuộc đua khi sử dụng ID, v.v.) nhưng không có điều kiện nào là không thể vượt qua.