เพิ่มประสิทธิภาพจุดที่มีขนาดใหญ่มากในการค้นหารูปหลายเหลี่ยม

ฉันมีชุดข้อมูลที่อยู่แห่งชาติ (37 ล้านชุด) และชุดข้อมูลรูปหลายเหลี่ยมของชุดข้อมูลน้ำท่วม (2 ล้าน) ประเภท MultiPolygonZ ประเภทของรูปหลายเหลี่ยมมีความซับซ้อนมาก ST_NPoints สูงสุดอยู่ที่ประมาณ 200,000 ฉันกำลังพยายามระบุโดยใช้ PostGIS (2.18) ซึ่งจุดที่อยู่ในรูปหลายเหลี่ยมน้ำท่วมและเขียนสิ่งเหล่านี้ไปยังตารางใหม่ที่มีที่อยู่ ID และรายละเอียดความเสี่ยงน้ำท่วม ฉันได้ลองจากมุมมองที่อยู่ (ST_ ภายใน) แต่จากนั้นสลับมุมมองนี้เริ่มต้นจากมุมมองของพื้นที่น้ำท่วม (ST_Contains) เหตุผลว่ามีพื้นที่ขนาดใหญ่ที่ไม่มีความเสี่ยงจากน้ำท่วมเลย ชุดข้อมูลทั้งคู่ได้รับการทำซ้ำเป็น 4326 และทั้งสองตารางมีดัชนีเชิงพื้นที่ ข้อความค้นหาด้านล่างของฉันทำงานเป็นเวลา 3 วันในขณะนี้และไม่แสดงสัญญาณว่าจะเสร็จเร็ว ๆ นี้!

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);

มีวิธีที่เหมาะสมที่สุดในการเรียกใช้หรือไม่ นอกจากนี้สำหรับเคียวรีที่รันนานชนิดนี้วิธีที่ดีที่สุดในการติดตามความคืบหน้านอกเหนือจากการดูการใช้ทรัพยากรและ pg_stat_activity คืออะไร

ข้อความค้นหาเดิมของฉันเสร็จสิ้นแล้วถึงแม้ว่าจะเป็นเวลา 3 วันและฉันก็หันไปทำงานอื่น ๆ ดังนั้นฉันจึงไม่ต้องเสียเวลาในการลองแก้ปัญหา อย่างไรก็ตามฉันเพิ่งเข้ามาเยี่ยมชมอีกครั้งและทำงานผ่านข้อเสนอแนะจนถึงตอนนี้ก็ดีมาก ฉันใช้สิ่งต่อไปนี้:

1. สร้างกริด 50 กม. ทั่วสหราชอาณาจักรโดยใช้โซลูชัน ST_FishNet ที่แนะนำที่นี่
2. ตั้งค่า SRID ของกริดที่สร้างขึ้นเป็น British National Grid และสร้างดัชนีเชิงพื้นที่ขึ้น
3. ตัดข้อมูลน้ำท่วมของฉัน (MultiPolygon) โดยใช้ ST_Intersection และ ST_Intersects (เฉพาะ gotcha ที่นี่ฉันต้องใช้ ST_Force_2D บน geom เป็นรูปร่าง 2pgsql เพิ่มดัชนี Z
4. ตัดข้อมูลจุดของฉันโดยใช้กริดเดียวกัน
5. สร้างดัชนีในแถวและคอลัมน์และดัชนีเชิงพื้นที่ในแต่ละตาราง

ฉันพร้อมที่จะเรียกใช้สคริปต์ตอนนี้จะวนซ้ำแถวและคอลัมน์ที่เติมผลลัพธ์ลงในตารางใหม่จนกว่าฉันจะครอบคลุมทั้งประเทศ แต่เพิ่งตรวจสอบข้อมูลน้ำท่วมของฉันและรูปหลายเหลี่ยมที่ใหญ่ที่สุดบางส่วนหายไปในการแปล! นี่คือคำถามของฉัน:

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));

ข้อมูลต้นฉบับของฉันมีลักษณะดังนี้:

อย่างไรก็ตามโพสต์การตัดมันดูเหมือนว่า:

นี่คือตัวอย่างของรูปหลายเหลี่ยม "ขาดหายไป":

หากต้องการตอบคำถามสุดท้ายก่อนดูโพสต์นี้เกี่ยวกับความต้องการของความสามารถในการตรวจสอบความคืบหน้าของแบบสอบถาม ปัญหาเป็นเรื่องยากและจะรวมอยู่ในการสืบค้นเชิงพื้นที่เนื่องจากทราบว่า 99% ของที่อยู่ได้รับการสแกนแล้วสำหรับการบรรจุในรูปหลายเหลี่ยมน้ำท่วมซึ่งคุณสามารถได้รับจากเคาน์เตอร์วนในการดำเนินการสแกนตารางพื้นฐานไม่จำเป็นต้อง ช่วยถ้าที่อยู่ 1% สุดท้ายเกิดขึ้นเพื่อตัดรูปหลายเหลี่ยมน้ำท่วมที่มีคะแนนมากที่สุดในขณะที่ 99% ก่อนหน้าตัดพื้นที่เล็ก ๆ บางส่วน นี่คือหนึ่งในเหตุผลที่อธิบายบางครั้งไม่สามารถช่วยเหลือเกี่ยวกับอวกาศเนื่องจากมันเป็นตัวบ่งชี้ของแถวที่จะสแกน แต่ด้วยเหตุผลที่ชัดเจนไม่ได้คำนึงถึงความซับซ้อนของรูปหลายเหลี่ยม (และด้วยเหตุนี้สัดส่วนที่มีขนาดใหญ่ ของเวลาทำงาน) ของข้อความค้นหาประเภททางแยก / ทางแยกใด ๆ

ปัญหาที่สองคือถ้าคุณมองสิ่งที่ชอบ

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

คุณจะเห็นบางสิ่งบางอย่างหลังจากหายไปจากรายละเอียดมากมาย:

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

เงื่อนไขสุดท้าย && หมายถึงทำเครื่องหมายในช่องทำเครื่องหมายก่อนที่จะทำการตัดรูปทรงเรขาคณิตที่แม่นยำยิ่งขึ้น นี่เป็นเหตุผลที่ชัดเจนและเป็นหัวใจของการทำงานของ R-Trees อย่างไรก็ตามและฉันยังเคยทำงานเกี่ยวกับข้อมูลน้ำท่วมของสหราชอาณาจักรในอดีตดังนั้นฉันจึงคุ้นเคยกับโครงสร้างของข้อมูลหากรูปหลายเหลี่ยม (หลาย) กว้างมาก - ปัญหานี้รุนแรงมากโดยเฉพาะถ้าแม่น้ำไหลไปพูด 45 องศา - คุณได้รับกล่องขนาดใหญ่ซึ่งอาจบังคับให้ตรวจสอบจุดตัดที่อาจเกิดขึ้นจำนวนมากบนรูปหลายเหลี่ยมที่ซับซ้อนมาก

ทางออกเดียวที่ฉันสามารถทำได้สำหรับ"การค้นหาของฉันทำงานเป็นเวลา 3 วันและฉันไม่รู้ว่าเราอยู่ที่ 1% หรือ 99%"ปัญหาคือการใช้การหารและพิชิตสำหรับหุ่น วิธีที่ฉันหมายถึงแบ่งพื้นที่ของคุณออกเป็นชิ้นเล็ก ๆ และเรียกใช้แยกจากกันไม่ว่าจะเป็นวงใน plpgsql หรือในคอนโซลอย่างชัดเจน สิ่งนี้มีข้อดีของการตัดรูปหลายเหลี่ยมที่ซับซ้อนออกเป็นส่วน ๆ ซึ่งหมายความว่าจุดต่อมาในการตรวจสอบรูปหลายเหลี่ยมกำลังทำงานกับรูปหลายเหลี่ยมที่มีขนาดเล็กลงและกล่องของรูปหลายเหลี่ยมมีขนาดเล็กกว่ามาก

ฉันจัดการเรียกใช้ข้อความค้นหาในหนึ่งวันโดยแบ่งสหราชอาณาจักรเป็น 50 กม. โดยบล็อก 50 กม. หลังจากฆ่าข้อความค้นหาที่ทำงานมานานกว่าหนึ่งสัปดาห์ในสหราชอาณาจักรทั้งหมด นอกเหนือจากนี้ฉันหวังว่าข้อความค้นหาของคุณด้านบนคือสร้างตารางหรืออัปเดตไม่ใช่แค่เลือก เมื่อคุณกำลังอัปเดตหนึ่งตารางที่อยู่โดยอยู่ในรูปหลายเหลี่ยมที่มีน้ำท่วมคุณจะต้องสแกนทั้งตารางที่กำลังอัปเดตที่อยู่ดังนั้นที่จริงแล้วการมีดัชนีปริภูมิอยู่นั้นไม่มีความช่วยเหลือเลย

แก้ไข: บนพื้นฐานของภาพที่มีค่าหนึ่งพันคำนี่คือภาพของข้อมูลน้ำท่วมในสหราชอาณาจักร มีรูปหลายเหลี่ยมขนาดใหญ่มากหนึ่งกล่องที่ครอบคลุมพื้นที่ทั้งหมดนั้นดังนั้นจึงเป็นเรื่องง่ายที่จะดูว่าเช่นโดยการตัดรูปหลายเหลี่ยมน้ำท่วมครั้งแรกกับตารางสีแดงตารางในมุมตะวันตกเฉียงใต้ก็จะถูกทดสอบเท่านั้น เทียบกับส่วนย่อยเล็ก ๆ ของรูปหลายเหลี่ยม