PostgreSQL điều chỉnh các phương pháp hay nhất để lưu trữ dữ liệu

Question

Tôi đã tìm thấy nhiều hướng dẫn trực tuyến và in về cách điều chỉnh và tối ưu hóa hiệu suất cho Postgres cho các ứng dụng OLTP, nhưng tôi không tìm thấy bất kỳ thứ gì cụ thể cho các ứng dụng Kho dữ liệu. Vì có quá nhiều sự khác biệt trong các loại khối lượng công việc, tôi chắc chắn có một số khác biệt trong cách cơ sở dữ liệu được quản lý và điều chỉnh.

Một số của riêng tôi:

• Tôi đã tìm thấy từ phía DDL mà tôi sử dụng chỉ số tự do nhiều hơn, kể từ khi tôi thường chỉ lo lắng về việc chèn một lần một ngày và có thể làm chèn hàng loạt với chỉ số phép tái xây dựng .

• Tôi thường sẽ sử dụng các phím thay thế nguyên liệu mà thường có nhiều hơn một chìa khóa tự nhiên cho gia nhập nhanh

• Tôi thường sẽ xác định và duy trì một bảng ngày rất toàn diện mà có thao tác cập nhật được xây dựng sẵn (ngày tài chính như trái ngược với ngày dương lịch, năm tài chính, ngày bắt đầu trong tuần, vv) và sử dụng nó một cách tự do thay vì sử dụng các hàm trong các câu lệnh chọn và các câu lệnh. Điều này thường giúp trong các truy vấn tổng hợp liên kết CPU.

Tôi hy vọng rằng tôi sẽ tìm thấy một số thông tin về quản lý bộ nhớ và các cài đặt cơ sở dữ liệu khác, nhưng tôi rất sẵn lòng nghe bất kỳ thực tiễn tốt nhất nào hữu ích dành riêng cho kho dữ liệu dựa trên Postgres.

Answer 1

Từ góc độ quản lý bộ nhớ, một trong những khác biệt lớn nhất của bạn là bạn thường có thể hy vọng giữ OLTP hoạt động trong bộ nhớ trong khi đây không phải là trường hợp với môi trường OLAP. Ngoài ra rất thường xuyên các bộ tham gia của bạn lớn hơn. Điều này có nghĩa là các thiết lập work_mem cao hơn có thể rất hữu ích và các bảng mức độ không được chuẩn hóa nghĩa là người ta có thể đẩy work_mem cao hơn một chút so với mức có thể khác. Tôi không chắc lời khuyên của tôi về shared_buffers sẽ thay đổi (tôi thích bắt đầu thấp và tăng, kiểm tra hiệu suất ở từng bước) nhưng work_mem chắc chắn sẽ cần tăng nếu bạn đang báo cáo về các bộ có kích thước bất kỳ.

Answer 2

Kinh nghiệm của tôi (thừa nhận trên một quy mô khá nhỏ khi nói đến kho dữ liệu):

• Giống như bạn đề cập,-tập hợp trước dữ liệu có thể dễ dàng điều quan trọng nhất, vì nó làm giảm số lượng dữ liệu mà cần phải được đọc bởi nhiều đơn đặt hàng của cường độ.
• Tránh các giao dịch bằng văn bản ngắn, các giao dịch phụ và các điểm lưu trữ. Điều này bao gồm xử lý ngoại lệ trong PL/pgSQL. Các lỗi này ghi nhanh chóng qua không gian "ID giao dịch" có sẵn và gây ra expensive "wraparound" vacuums that need to rewrite whole tables.
• Tôi thấy rằng các bảng phân vùng sao cho mỗi phân vùng riêng lẻ có thể vừa với bộ nhớ cache của hạt nhân là tốt cho việc bảo trì và di chuyển, nếu bạn cần làm bất kỳ điều gì. Điều này có nghĩa là bạn có thể tạo lại tất cả các chỉ mục trên một phân vùng chỉ với 1 lần quét từ đĩa, thay vì một lần quét cho mỗi chỉ mục.
• Giống như Chris đã đề cập, hãy hào phóng với work_mem và maintenance_work_mem; nếu khối lượng công việc của bạn không phù hợp với RAM thì việc lưu giữ nhiều dữ liệu tạm thời trong bộ nhớ sẽ tiết kiệm thời gian I/O và CPU do kế hoạch truy vấn thông minh hơn (quan trọng nhất là HashAggregate).
• Nếu bạn cần làm các loại lớn, nó có thể giúp mua một SSD chuyên dụng để lưu trữ các tệp tạm thời.