Tối ưu hóa PostgreSQL cho dữ liệu nhất thời

Tôi có một vài bảng với 100-300 cột số nguyên mỗi loại, chứa dữ liệu rất dễ bay hơi. Các bộ dữ liệu được khóa bởi một hoặc hai khóa chính và khi làm mới xảy ra, toàn bộ dữ liệu sẽ bị xóa và dữ liệu mới được chèn vào một giao dịch. Kích thước bộ dữ liệu thường là vài trăm hàng, nhưng có thể lên đến vài nghìn hàng trong trường hợp cực đoan. Làm mới xảy ra một lần mỗi giây và các cập nhật dữ liệu cho các khóa khác nhau thường bị rời rạc, do đó việc bỏ và tạo lại bảng là không khả thi.

Làm cách nào để điều chỉnh Postgres để xử lý tải như vậy? Tôi có thể sử dụng phiên bản mới nhất và lớn nhất nếu điều đó tạo ra sự khác biệt.

postgresql optimization database-tuning

— Alex Tokarev
nguồn

Tùy thuộc vào có bao nhiêu bộ dữ liệu khác nhau, một tùy chọn sẽ là phân vùng các bảng cho mỗi tập dữ liệu.

Khi một tập dữ liệu được cập nhật, BEGINmột giao dịch mới, TRUNCATEbảng, COPYdữ liệu mới vào đó và COMMIT. PostgreSQL có một tối ưu hóa nơi COPYing vào một bảng đó là được TRUNCATEd trong cùng một giao dịch không nhiều ít I / O nếu bạn đang sử dụng wal_level = minimal(mặc định).

Nếu bạn không thể phân vùng và cắt bớt (giả sử, nếu bạn đang xử lý hàng chục hoặc hàng trăm nghìn bộ dữ liệu, nơi có quá nhiều bảng), thay vào đó, bạn sẽ muốn quay vòng tự động để chạy càng nhiều càng tốt , đảm bảo bạn có các chỉ mục tốt trên bất cứ thứ gì bạn xóa dựa trên và được chuẩn bị cho hiệu suất hơi bình thường.

Nếu bạn không cần sự cố an toàn - bạn không ngại các bảng của mình trống sau sự cố hệ thống - bạn cũng có thể tạo các bảng của mình UNLOGGED, điều này sẽ giúp bạn tiết kiệm một khoản chi phí I / O rất lớn.

Nếu bạn không phải khôi phục toàn bộ thiết lập từ bản sao lưu sau sự cố hệ thống, bạn có thể tiến thêm một bước và cũng thiết lập fsync=off, điều này về cơ bản nói với PostgreQuery "đừng bận tâm với sự cố an toàn, tôi có bản sao lưu tốt và tôi không 'quan tâm nếu dữ liệu của tôi là vĩnh viễn và hoàn toàn không thể phục hồi sau sự cố và tôi rất vui initdbkhi được sử dụng lại cơ sở dữ liệu của mình ".

Tôi đã viết thêm về điều này trong một chủ đề tương tự trên Stack Overflow về việc tối ưu hóa PostgreSQL để thử nghiệm nhanh ; đề cập đến việc điều chỉnh hệ điều hành máy chủ, tách WAL trên một đĩa khác nếu bạn không sử dụng unloggedbảng, điều chỉnh con trỏ, v.v.

Ngoài ra còn có một số thông tin trong tài liệu PG để tải dữ liệu nhanh và cài đặt không bền .

— Craig Ringer
nguồn

Cảm ơn các mẹo phân vùng, tôi không bao giờ nghĩ về việc sử dụng chúng trong trường hợp này. Đối với các bảng chưa được đăng ký - bạn có nghĩa là chúng sẽ bị trống theo mặc định sau khi hệ thống bị sập? Nó không làm cho bất kỳ sự khác biệt, tôi chỉ tò mò.

— Alex Tokarev

@AlexTokarev Đúng vậy; sau khi PostgreSQL tắt một cách không sạch sẽ (postmaster hoặc một phân đoạn phụ trợ, chu kỳ năng lượng hệ thống đột ngột, phụ trợ là SIGKILLed, v.v.) bất kỳ UNLOGGEDbảng nào cũng có thể bị TRUNCATEd, vì vậy chúng trống khi khởi động. Chúng không bị cắt cụt sau khi tắt máy và khởi động lại, nhưng bạn không nên dựa vào chúng để được bền.

— Craig Ringer

Cảm ơn đã giải thích. Tôi không cần an toàn dữ liệu cho các bảng được đề cập, dữ liệu trong đó là nhất thời và được làm mới từ nguồn mỗi giây. Tuy nhiên, tắt fsync không phải là một tùy chọn, vì có các bảng truyền thống khác trong cùng một lược đồ cần phải an toàn và có thể phục hồi được. Có UNLOGGEDtùy chọn cho mỗi bảng là tuyệt vời.

— Alex Tokarev

Tôi đang xem tài liệu phân vùng và có vẻ như nó có thể là một giải pháp (gần như) hoàn hảo cho vấn đề. Một câu hỏi mặc dù: nếu tôi sẽ có một bảng cha cho lược đồ và các bảng con để giữ dữ liệu, tôi sẽ truy vấn dữ liệu từ bảng cha, phải không? Nếu một bảng con cho phạm vi đó tồn tại, truy vấn sẽ trả về nó, nếu không, nó sẽ trả về một tập dữ liệu trống. Trong trường hợp đó, tôi thậm chí có thể thả và tạo lại các bảng con cho mỗi lô dữ liệu mới. Với hoàn cảnh, điều gì sẽ hiệu quả hơn, TRUNCATEhoặc DROP/CREATE TABLEtrình tự?

— Alex Tokarev

@AlexTokarev Tôi muốn giới thiệu bạn TRUNCATE, cá nhân. DDL churn có chi phí riêng của mình. Vì bạn thường xuyên thực hiện các thay đổi với mức cao như vậy, nên sẽ rất quan trọng để đảm bảo rằng bạn bật tính năng gây hấn của autovacuum pg_catalog.pg_classvà các bảng hệ thống khác có thể tăng lên theo khối lượng công việc đó.

— Craig Ringer