Tối ưu hóa một điểm rất lớn trong truy vấn đa giác

Tôi có bộ dữ liệu quốc gia về điểm địa chỉ (37 triệu) và bộ dữ liệu đa giác về đường viền lũ (2 triệu) loại MultiPolygonZ, một số đa giác rất phức tạp, tối đa ST_NPoints là khoảng 200.000. Tôi đang cố gắng xác định bằng PostGIS (2.18) trong đó các điểm địa chỉ nằm trong đa giác lũ và ghi chúng vào một bảng mới với id địa chỉ và chi tiết rủi ro lũ lụt. Tôi đã thử từ góc độ địa chỉ (ST_Within) nhưng sau đó đổi chỗ này bắt đầu từ phối cảnh vùng lũ (ST_Contains), lý do là có những khu vực rộng lớn không có rủi ro lũ lụt. Cả hai bộ dữ liệu đã được phân bổ lại thành 4326 và cả hai bảng đều có chỉ số không gian. Truy vấn của tôi dưới đây đã chạy được 3 ngày và không có dấu hiệu hoàn thành sớm!

select a.id, f.risk_factor_1, f.risk_factor_2, f.risk_factor_3
into gb.addresses_with_flood_risk
from gb.flood_risk_areas f, gb.addresses a
where ST_Contains(f.the_geom, a.the_geom);

Có cách nào tối ưu hơn để chạy cái này không? Ngoài ra, đối với các truy vấn chạy dài loại này, cách tốt nhất để theo dõi tiến trình ngoài việc xem xét việc sử dụng tài nguyên và pg_stat_activity là gì?

Truy vấn ban đầu của tôi đã hoàn thành OK mặc dù trong 3 ngày và tôi đã bị lãng quên với công việc khác vì vậy tôi không bao giờ phải dành thời gian để thử giải pháp. Tuy nhiên tôi mới truy cập lại cái này và làm việc thông qua các khuyến nghị, cho đến nay vẫn tốt. Tôi đã sử dụng như sau:

1. Tạo lưới 50km trên khắp Vương quốc Anh bằng giải pháp ST_FishNet được đề xuất tại đây
2. Đặt SRID của lưới được tạo thành Lưới quốc gia Anh và xây dựng một chỉ mục không gian trên đó
3. Cắt dữ liệu lũ của tôi (MultiPolygon) bằng ST_Intersection và ST_Intersects (chỉ có Gotcha ở đây là tôi phải sử dụng ST_Force_2D trên geom khi shape2pgsql thêm chỉ mục Z
4. Cắt dữ liệu điểm của tôi bằng cách sử dụng cùng một lưới
5. Tạo các chỉ mục trên hàng và chỉ mục col và không gian trên mỗi bảng

Tôi đã sẵn sàng để chạy tập lệnh của mình bây giờ, sẽ lặp lại các hàng và cột kết quả vào một bảng mới cho đến khi tôi phủ sóng toàn quốc. Nhưng chỉ cần kiểm tra dữ liệu lũ lụt của tôi và một số đa giác lớn nhất dường như đã bị mất trong bản dịch! Đây là truy vấn của tôi:

SELECT g.row, g.col, f.gid, f.objectid, f.prob_4band, ST_Intersection(ST_Force_2D(f.geom), g.geom) AS geom 
INTO rofrse.tmp_flood_risk_grid 
FROM rofrse.raw_flood_risk f, rofrse.gb_grid g
WHERE (ST_Intersects(ST_Force_2D(f.geom), g.geom));

Dữ liệu gốc của tôi trông như thế này:

Tuy nhiên bài đăng cắt nó trông như thế này:

Đây là một ví dụ về đa giác "mất tích":

Để trả lời câu hỏi cuối cùng của bạn trước, hãy xem bài đăng nàyvề sự mong muốn có thể theo dõi tiến trình của các truy vấn. Vấn đề rất khó và sẽ được giải quyết trong một truy vấn không gian, vì biết rằng 99% địa chỉ đã được quét để ngăn chặn trong một đa giác lũ, mà bạn có thể nhận được từ bộ đếm vòng lặp trong triển khai quét bảng bên dưới, không nhất thiết phải giúp đỡ nếu 1% địa chỉ cuối cùng xảy ra giao cắt một đa giác lũ với hầu hết các điểm, trong khi 99% trước đó giao với một số khu vực nhỏ. Đây là một trong những lý do tại sao EXPLAIN đôi khi có thể không hữu ích với không gian, vì nó đưa ra dấu hiệu của các hàng sẽ được quét, nhưng, vì lý do rõ ràng, không tính đến độ phức tạp của đa giác (và do đó chiếm tỷ lệ lớn của thời gian chạy) của bất kỳ truy vấn loại giao cắt / giao cắt.

Một vấn đề thứ hai là nếu bạn nhìn vào một cái gì đó như

EXPLAIN 
SELECT COUNT(a.id) 
FROM sometable a, someothertable b
WHERE ST_Intersects (a.geom, b.geom)

bạn sẽ thấy một cái gì đó như, sau khi bỏ lỡ rất nhiều chi tiết:

_st_intersects(a.geom, b.geom)
   ->  Bitmap Index Scan on ix_spatial_index_name  (cost...rows...width...))
   Index Cond: (a.geom && geom)

Điều kiện cuối cùng, &&, có nghĩa là thực hiện kiểm tra hộp giới hạn, trước khi thực hiện bất kỳ giao điểm chính xác hơn của hình học thực tế. Điều này rõ ràng là hợp lý và là cốt lõi của cách R-Plants hoạt động. Tuy nhiên, và tôi cũng đã từng làm việc về dữ liệu lũ lụt ở Anh trong quá khứ, vì vậy tôi đã quen với cấu trúc của dữ liệu, nếu Đa giác (Đa) rất rộng - vấn đề này đặc biệt nghiêm trọng nếu một dòng sông chảy vào, giả sử, 45 độ - bạn nhận được các hộp giới hạn lớn, có thể buộc một số lượng lớn các giao lộ tiềm năng được kiểm tra trên các đa giác rất phức tạp.

Giải pháp duy nhất tôi có thể đưa ra cho "truy vấn của tôi đã chạy được 3 ngày và tôi không biết liệu chúng tôi đang ở mức 1% hay 99%" là sử dụng một loại chia và chinh phục cho người giả Cách tiếp cận, theo ý tôi, chia khu vực của bạn thành các phần nhỏ hơn và chạy riêng rẽ, trong một vòng lặp trong plpgsql hoặc rõ ràng trong bảng điều khiển. Điều này có lợi thế là cắt các đa giác phức tạp thành các phần, có nghĩa là điểm tiếp theo trong kiểm tra đa giác đang làm việc trên các đa giác nhỏ hơn và các hộp giới hạn của đa giác nhỏ hơn nhiều.

Tôi đã quản lý để chạy các truy vấn trong một ngày bằng cách chia Vương quốc Anh thành các khối 50km bằng 50km, sau khi giết một truy vấn đã chạy trong hơn một tuần trên toàn Vương quốc Anh. Bên cạnh đó, tôi hy vọng truy vấn của bạn ở trên là TẠO BẢNG hoặc CẬP NHẬT và không chỉ là CHỌN. Khi bạn đang cập nhật một bảng, địa chỉ, dựa trên việc nằm trong đa giác lũ, bạn sẽ phải quét toàn bộ bảng đang được cập nhật, dù sao địa chỉ, vì vậy thực sự có một chỉ số không gian trên đó không giúp ích gì cả.

EDIT: Trên cơ sở một hình ảnh đáng giá cả ngàn từ, đây là hình ảnh của một số dữ liệu lũ lụt ở Anh. Có một đa giác rất lớn, hộp giới hạn bao phủ toàn bộ khu vực đó, vì vậy, thật dễ dàng để thấy, ví dụ, bằng cách đầu tiên giao giữa đa giác lũ với lưới màu đỏ, hình vuông ở góc phía tây nam sẽ đột nhiên chỉ được kiểm tra chống lại một tập hợp nhỏ của đa giác.