PostgreSQL cho các giao dịch khối lượng lớn và cho kho dữ liệu

Là một điều khá mới mẻ với PostgreSQL, tôi chưa bao giờ thực hiện một triển khai lớn bằng cách sử dụng nó trước đây. Nhưng, tôi có kinh nghiệm tốt về các giải pháp doanh nghiệp và tôi muốn thử và áp dụng một số điều tôi đã học được bằng PostgreQuery.

Tôi có trang web có kích thước để xử lý số lượng lớn dữ liệu và lưu lượng truy cập. Cơ sở hạ tầng sẽ được xây dựng bằng cách sử dụng trên amazon (AWS) bằng các phiên bản EC2 và khối lượng EBS.

Thiết kế nên có hai cơ sở dữ liệu, cơ sở dữ liệu giao dịch chính và kho dữ liệu để xử lý phân tích và báo cáo.

Cơ sở dữ liệu giao dịch chính

sẽ được sử dụng cho trang web trực tiếp, trang web được xây dựng trên nhiều nút để mở rộng quy mô người dùng đồng thời. Chủ yếu chúng tôi yêu cầu cơ sở dữ liệu cho trường hợp này phải cực kỳ nhanh trong các hoạt động đọc, chúng tôi hy vọng> 100GB dữ liệu với mức tăng trưởng 30% hàng năm. Tại thời điểm này, chúng tôi đang có kế hoạch sử dụng hai máy chủ EC2 ( và bổ sung thêm sau này khi chúng tôi cần ).

Câu hỏi của tôi, các thiết lập được đề nghị cho các yêu cầu trên là gì? Thêm vào đó, có cách nào để quản lý phân vùng bảng và âm lượng không? Có khuyến nghị nào cho việc sử dụng thiết lập AWS không?

Cơ sở dữ liệu kho dữ liệu

Sẽ được sử dụng chủ yếu để thu thập tất cả dữ liệu từ cơ sở dữ liệu giao dịch chính theo chiều thời gian. vì vậy, ngay cả các bản ghi bị xóa khỏi cơ sở dữ liệu chính sẽ được ghi lại trong DWH. Do đó, dữ liệu sẽ rất lớn và tăng trưởng sẽ còn lớn hơn nữa. Chúng tôi cũng sẽ sử dụng vài phiên bản EC2 trở lên nếu được yêu cầu.

Các thiết lập được đề nghị trong trường hợp này là gì? điều này sẽ yêu cầu thao tác viết nhanh vì viết liên tục (ETL). Chúng ta có thể xây dựng các khối OLAP trong PostgreSQL không? nếu có, có ai ở ngoài đó đã thử không?

Kết nối với cơ sở dữ liệu

Các máy chủ web sẽ được kết nối với cơ sở dữ liệu chính để truy vấn và viết. Chúng tôi hiện đang phát triển một ứng dụng sử dụng django sử dụng thư viện riêng để kết nối. Có nên sử dụng cùng một phương pháp cơ bản? hoặc chúng ta nên cấu hình pgpool?

Kho dữ liệu (ETL)

Cách nào được đề xuất để xây dựng các quy trình ETL để đọc từ chính và tải vào kho dữ liệu? Bất kỳ công cụ? Phương pháp nào để tuân theo? PostgreQuery có cung cấp bất kỳ chức năng / công cụ hữu ích nào trong việc xây dựng các quy trình ETL không?

Cơ sở hạ tầng / Dịch vụ cơ sở dữ liệu

Có lẽ bạn nên đọc phần này để biết tổng quan về một trang web có dung lượng lớn chạy trên AWS với EBS. Họ đã chuyển sang lưu trữ Ephemeral nhưng phải tạo ra một số dự phòng để có thể (lưu lại) dữ liệu.

http://blog.reddit.com/2012/01/jan nóng-2012-state-of-subvers.html

Kho dữ liệu / ETL

Tôi đã sử dụng Pentaho trong quá khứ. Không trực tiếp với postgres, nhưng tôi thấy đó là một giải pháp tốt cho cả OLAP (Mondrian) và ETL (Ấm đun nước)

http://www.pentaho.com/

chỉnh sửa: "Phiên bản cộng đồng" có thể được tìm thấy ở đây

http://mondrian.pentaho.com/

http://keling.pentaho.com/

Kết nối

Những người này dường như thực sự thích pgbouncer. /programming/1125504/django-persistent-database-connection

Tôi không có kinh nghiệm với nó, mặc dù. Rõ ràng, Disqus sử dụng nó.

Thiết lập của bạn giống với cái mà tôi đã phát triển cho một trường đại học. Cơ sở dữ liệu không lớn, nhưng khá lớn, kích thước khoảng 300 GB và bảng lớn nhất chứa khoảng 500 triệu bản ghi. Và vẫn đang phát triển.

Với mục đích, hai máy chủ thực sự mạnh mẽ (sắt thật, không ảo hóa), một máy chủ chuyên dùng để xử lý dữ liệu từ một trang web và máy chủ còn lại được sử dụng để tính toán và phân tích thống kê, đã được sử dụng. Dữ liệu được sao chép theo cả hai hướng bằng Slony. Dữ liệu OLTP được sao chép liên tục đến máy chủ OLAP và một số lược đồ và bảng đơn được sao chép từ máy chủ OLAP sang OLTP. Theo cách này, các tính toán nặng có thể được thực hiện trên máy chủ phân tích mà không ảnh hưởng đến máy chủ OLTP. Ngày nay, có một số lựa chọn thay thế cho Slony để sao chép dữ liệu: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony là tốt và nhanh chóng cho mối quan tâm của chúng tôi nhưng nó có thể là giáo viên khắc nghiệt.

Vì máy chủ OLAP sẽ phát triển ổn định, bạn nên cân nhắc sử dụng một số loại chia tay nếu có.

Nếu có khả năng, sử dụng kết nối tổng hợp. Tôi chỉ sử dụng PGPool và nó hoạt động hoàn hảo. PGBouncer là một lựa chọn khác. Bên cạnh việc giảm độ trễ init, nó cũng giảm việc khởi động phiên và quản lý phiên. http://momjian.us/main/bloss/pgblog/2012.html#April_25_2012

Một lợi ích khác của việc sử dụng nhóm kết nối là bạn có một điểm duy nhất để bạn có thể dễ dàng chuyển hướng lưu lượng truy cập của mình (điều này tất nhiên cũng có thể là một rủi ro).

Tôi chưa sử dụng bất kỳ ETL readymade nào để tải dữ liệu vào máy chủ OLAP. Tôi đã viết tập lệnh của riêng mình bằng Python khi một số dữ liệu được gửi trong các tệp văn bản lớn với định dạng đặc biệt.

Cấu trúc của cơ sở dữ liệu cần được xem xét cẩn thận. Sử dụng lược đồ là tốt để thu thập và dễ dàng xử lý các đối tượng. Nó có vẻ rườm rà khi bắt đầu sử dụng các lược đồ nhưng khi số lượng đối tượng tăng lên, bạn sẽ cảm ơn chính mình. Biết rằng bạn phải rõ ràng tiền tố các đối tượng với lược đồ của chúng, bạn biết chính xác các đối tượng bạn hoạt động trên. http://momjian.us/main/bloss/pgblog/2012.html#April_27_2012

Đối với những người táo bạo, PostgreSQL XC là một sự thay thế thú vị hoặc chỉ là một trang phục quá khổ http://postgres-xc.sourceforge.net/