Thiết kế tốt nhất cho nguyên mẫu Python / PostGIS mã nguồn mở

Tôi đang viết một ứng dụng web chuyên sâu về dữ liệu được phân phối thông qua apache. Câu hỏi của tôi là về cách sắp xếp tốt nhất xử lý cho rằng có nhiều tùy chọn.

Tôi có quyền xử lý OpenLayers / JQuery / Javascript, PostGIS / Postgresql (với pssql), python / psycopg2, php.

Cơ sở dữ liệu chứa khoảng 3 triệu hàng và nguyên mẫu hiện đang chạy như sau:

• Người dùng nhấp vào một điểm trên cửa sổ OpenLayers

• Tọa độ được gửi dưới dạng yêu cầu AJAX thông qua chức năng python trên máy chủ

• Hiện tại ứng dụng của tôi không quốc tịch

• Psycopg2 của Python được sử dụng để gọi một thủ tục được lưu trữ pssql và một tập hợp lớn các giá trị WKT (và trường dữ liệu) được trả về mô-đun python

• Trường dữ liệu được sử dụng để phân loại các bản ghi WKT trong python như sau: tất cả các giá trị WKT được phân loại thành một trong 5 nhóm. Khoảng 1% giá trị WKT thực sự được sửa đổi.

• Năm bộ / nhóm WKT được đệm để tạo ra năm đa giác riêng biệt. Tôi hiện đang gọi một thủ tục được lưu trữ trong cơ sở dữ liệu để làm điều này. Đến lượt nó chỉ sử dụng ST_BUFFER. (Tôi đã cân nhắc sử dụng Shapely nhưng không chắc chắn sẽ có lợi thế về hiệu suất do thư viện GEOS được sử dụng trong cả hai trường hợp ...)

• Cuối cùng, 5 giá trị văn bản WKT được gói trong một chuỗi JSON và được gửi lại cho OpenLayers để hiển thị dưới dạng năm lớp.

Tôi thấy rằng các nút cổ chai là tìm kiếm không gian ban đầu và giai đoạn đệm cuối cùng.

Tôi đoán Câu hỏi là:

Có cách nào tốt hơn để sắp xếp mọi thứ? Ví dụ, TẤT CẢ việc xử lý dữ liệu có nên được thực hiện trong PostgreSQL (ví dụ: với con trỏ) và đây có phải là một điều tốt về mặt bảo trì và hiệu suất không? Sẽ tốt hơn nếu sử dụng máy chủ ô vuông để tránh truyền chuỗi WKT dài cho máy khách web? Làm thế nào bạn sẽ giải quyết nó?

Đệm cổ chai

Khi sử dụng ST_Buffer, bạn có thể giảm độ phức tạp của hình dạng kết quả bằng cách thêm tùy chọn num_seg_ cục_circle thấp hơn. Điều này sẽ làm giảm số lượng xử lý khi đệm, và trong các hoạt động tiếp theo.

Từ tài liệu của PostGIS:

Nói chung trong PostGIS, bạn sẽ có hiệu suất tốt hơn nếu bạn chạy truy vấn đối với các bảng được lập chỉ mục đúng. Điều này cho phép bạn dễ dàng truy cập vào một số tối ưu hóa (chẳng hạn như phân cụm). Xem xét xử lý 1% thay đổi riêng biệt và hợp nhất hai ở cuối.

Không nghĩ gì về kiến ​​trúc, đối với tất cả các ứng dụng bản đồ Web, bạn muốn thực hiện càng nhiều việc xử lý trước thời hạn. Điều này có nghĩa là nếu bạn có thể, bộ đệm nên được tính toán trước, tất cả dữ liệu của bạn phải ở trong SRS đầu ra, v.v ... Rõ ràng, một số dữ liệu và tính toán cần phải là động.

Tôi đề nghị rằng ngoài Python, bạn nhìn vào MapServer và Geoserver để thực hiện các tính toán và tạo đầu ra. Cả hai đều có thể tạo ra các ô hình ảnh hoặc đầu ra GeoJSON. Cả hai ứng dụng đều có thể sử dụng PostGIS làm mặt sau.