बहुभुज क्वेरी में एक बहुत बड़े बिंदु का अनुकूलन

Question

मेरे पास एड्रेस पॉइंट्स (37 मिलियन) का एक राष्ट्रीय डेटासेट है और मल्टीपॉलीगंज के प्रकारों की बाढ़ रूपरेखा (2 मिलियन) का बहुभुज डेटासेट है, कुछ पॉलीगॉन बहुत जटिल हैं, अधिकतम ST_NPoints 200,000 के आसपास हैं। मैं PostGIS (2.18) का उपयोग करके पहचान करने की कोशिश कर रहा हूं कि कौन से पते बिंदु एक बाढ़ बहुभुज में हैं और इन्हें पता आईडी और बाढ़ जोखिम विवरण के साथ एक नई तालिका में लिखें। मैंने एक पते के नजरिए (ST_Within) से कोशिश की है, लेकिन फिर बाढ़ क्षेत्र के दृष्टिकोण (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- सक्रियता को देखने के अलावा प्रगति की निगरानी का सबसे अच्छा तरीका क्या है?

---

मेरी मूल क्वेरी 3 दिनों के लिए ठीक हो गई और मैं दूसरे काम से अलग हो गया, इसलिए मुझे कभी समाधान निकालने की कोशिश करने के लिए समय नहीं मिला। हालाँकि, मैंने अभी इस पर दोबारा विचार किया है और सिफारिशों के माध्यम से काम कर रहा है, अब तक यह अच्छा है। मैंने निम्नलिखित का उपयोग किया है:

1. यहां सुझाए गए ST_FishNet समाधान का उपयोग करके यूके में 50 किमी का ग्रिड बनाया गया
2. उत्पन्न ग्रिड के SRID को ब्रिटिश नेशनल ग्रिड पर सेट करें और इस पर एक स्थानिक सूचकांक बनाया
3. ST_Intersection और ST_Intersects का उपयोग करके मेरे बाढ़ के डेटा (MultiPolygon) को बंद कर दिया गया था (केवल यहाँ गोछा था मुझे जियोम पर ST_Force_2D का उपयोग करना था क्योंकि shape2pgsql ने एक 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));

मेरा मूल डेटा इस तरह दिखता है:

हालाँकि पोस्ट क्लिपिंग यह इस तरह दिखता है:

यह "लापता" बहुभुज का एक उदाहरण है:

Comments

मुझे बस एहसास हुआ कि हम सियोल में FOSS4G में मिले थे और ESRI लोकेटर हब के चमत्कार के बारे में बात की थी :-)

— जॉन पॉवेल

क्या आपने कभी विभाजन को खत्म किया और दृष्टिकोण को जीत लिया? क्या आप इस दृष्टिकोण के साथ बेंचमार्क समय को अपडेट कर सकते हैं?

— andrew

Answer 1

पहले अपने अंतिम प्रश्न का उत्तर देने के लिए, इस पोस्ट को देखेंप्रश्नों की प्रगति की निगरानी करने में सक्षम होने की वांछनीयता के बारे में। यह समस्या कठिन है और इसे एक स्थानिक क्वेरी में समाहित किया जाएगा, क्योंकि यह जानते हुए कि 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)

अंतिम स्थिति, &&, का अर्थ है वास्तविक ज्यामिति के किसी भी अधिक सटीक चौराहे को करने से पहले एक बाउंडिंग बॉक्स की जांच करना। यह स्पष्ट रूप से समझदार है और आर-ट्रीज़ के मूल में है। हालाँकि, और मैंने अतीत में यूके के बाढ़ के आंकड़ों पर भी काम किया है, इसलिए मैं डेटा की संरचना से परिचित हूं, अगर (मल्टी) पॉलीगॉन बहुत व्यापक हैं - तो यह समस्या विशेष रूप से तीव्र है यदि कोई नदी नदी पर चलती है, तो कहें, 45 डिग्रियां - आपको विशाल बाउंडिंग बॉक्स मिलते हैं, जो कि बड़ी संख्या में संभावित चौराहों को बहुत जटिल पॉलीगॉन पर जांचने के लिए मजबूर कर सकते हैं।

एकमात्र समाधान जो मैं "मेरी क्वेरी 3 दिनों से चल रही है, और मैं नहीं जानता कि क्या हम 1% या 99% पर चल रहे हैं" समस्या का एक प्रकार का विभाजन और डमी के लिए जीतना है दृष्टिकोण, जिससे मेरा मतलब है, अपने क्षेत्र को छोटे टुकड़ों में तोड़ दें, और उन दोनों को अलग-अलग चलाएं, या तो plpgsql में लूप में या स्पष्ट रूप से कंसोल में। इससे जटिल बहुभुजों को भागों में काटने का लाभ होता है, जिसका अर्थ है कि बहुभुज की जांच में बाद के बिंदु छोटे बहुभुजों पर काम कर रहे हैं और बहुभुज के बाउंडिंग बॉक्स बहुत छोटे हैं।

पूरे ब्रिटेन पर एक सप्ताह से चल रही एक क्वेरी को मारने के बाद, मैंने यूके को 50 किमी ब्लॉक में 50 किमी तक तोड़कर एक दिन में प्रश्नों को चलाने में कामयाबी हासिल की है। एक तरफ के रूप में, मुझे आशा है कि ऊपर आपकी क्वेरी क्रिएट टेबल या अद्यतन है और न केवल एक चयन। जब आप बाढ़ की बहुभुज में होने के आधार पर एक तालिका, पते को अपडेट कर रहे हैं, तो आपको पूरी तालिका को अपडेट किया जा रहा है, वैसे भी पते स्कैन करने होंगे, इसलिए वास्तव में इस पर एक स्थानिक सूचकांक होने से कोई मदद नहीं मिलती है।

EDIT: इस आधार पर कि एक छवि एक हजार शब्दों के लायक है, यहां यूके के कुछ बाढ़ के आंकड़ों की छवि है। एक बहुत बड़ा मल्टीप्लगॉन है, जिसकी बाउंडिंग बॉक्स उस पूरे क्षेत्र को कवर करती है, इसलिए यह देखना आसान है कि कैसे, उदाहरण के लिए, पहले लाल ग्रिड के साथ बाढ़ बहुभुज को काटकर, दक्षिण-पश्चिम कोने में वर्ग का केवल अचानक परीक्षण किया जाएगा बहुभुज के एक छोटे सबसेट के खिलाफ।

Comments

हाय जॉन और व्यापक जवाब के लिए बहुत बहुत धन्यवाद, मैं ग्रिड दृष्टिकोण पर आपकी सिफारिश का पालन करूंगा, एक बहुत ही समझदार सुझाव जैसा लगता है, मैं वास्तव में सरलता और सटीकता को खोना नहीं चाहता हूं। मैं एक ब्लॉक के साथ बेंचमार्क करूंगा और फिर समानांतर में चला जाऊंगा, बादल के साथ इन दिनों बहुत आसान है! धन्यवाद फिर से

— मार्क वर्ले

हाय मार्क, कोई चिंता नहीं है, कृपया उत्तर को स्वीकार करने पर विचार करें यदि आपको लगता है कि इससे मदद मिली है। यह साइट को साफ रखने में मदद करता है, बिना स्वीकृत उत्तरों के प्रश्न ऐसे मेट्रिक्स में से एक हैं जो स्टैक एक्सचेंज साइट्स को देखते हैं।

— जॉन पॉवेल

ठीक है, यह मेरी पहली पोस्ट है, मैं सामान्य रूप से विस्तृत थ्रेड्स और सहायक प्रतिक्रियाओं से उत्तर पाता हूं। क्वेरी लगभग 3 दिनों के बाद आज सुबह समाप्त हो गई, जो बहुत बुरा नहीं है, लेकिन आज आपकी सलाह का पालन करने जा रहा है और बेहतर प्रदर्शन के लिए इसे विखंडू में तोड़ देगा। आपकी मदद जॉन के लिए फिर से धन्यवाद और शायद अगस्त में बॉन में आपको देखें!

— मार्क वर्ले

मैंने एक तस्वीर जोड़ी, हालांकि मुझे एहसास है कि आपको तस्वीर मिल गई है: डी, ​​यह दूसरों को यह कल्पना करने में मदद कर सकता है कि मैं किस बारे में हूं। हां, मैं लगभग निश्चित रूप से Foss4G यूके जा रहा हूं, और बॉन के बारे में सोचूंगा।

— जॉन पॉवेल