Google मानचित्र पर 100-200K मार्कर लोड हो रहा है

Question

फिलहाल मैं मानचित्र पर मार्करों को आकर्षित करने के लिए Google मानचित्र v.3 API का उपयोग कर रहा हूं। मेरे पास कुल 500 मार्कर हैं।

उद्देश्यों को प्रदर्शित करने के लिए मैं ब्राउज़र में क्लाइंट पक्ष पर इस टूल का उपयोग करके मार्करक्लस्टर और समूह मार्कर का उपयोग करता हूं।

हालांकि, मैं स्थान संख्या का विस्तार करने की योजना बना रहा हूं और मानता हूं कि यह 100K या 200K तक तेजी से बढ़ सकता है।

मैंने कुछ तनाव परीक्षण किए, और महसूस किया कि वर्तमान समाधान मूल रूप से ब्राउज़र और लगभग 10-20K मार्करों को मारता है।

तो मेरा सवाल है कि कई मार्करों को आकर्षित करने के लिए सबसे अच्छा तरीका क्या है (आवश्यक Google मानचित्र नहीं)?

मैं इसी तरह के सवाल के साथ पोस्ट, उदा .:

Showing many markers in Google Maps

Best solution for too many pins on google maps

पढ़ा है मूल रूप से लोगों को प्रदर्शन के उद्देश्य से है, जो मैं पहले से ही उपयोग के लिए कुछ clusterer उपयोग करने के लिए सुझाव देते हैं।

या डेटा पुनर्प्राप्त करने के लिए फ़्यूज़न टेबल का उपयोग करने के लिए, जो एक विकल्प नहीं है, क्योंकि डेटा को मेरे सर्वर पर रहना है। साथ ही मुझे लगता है कि प्रदर्शन कार्यक्षमता संलयन तालिकाओं के साथ सीमित है।

मैं इस परिदृश्य पर लागू करने के बारे में सोच रहा हूँ: प्रत्येक पृष्ठ ज़ूम/लोड पर

• - प्रदर्शन दृश्य की सीमाएँ साथ ajax अनुरोध भेजने, सभी पक्षों पर के बारे में 30% जोड़ सकते हैं और, मार्कर को पुनः प्राप्त जो केवल इस भौगोलिक क्षेत्र में आते हैं। उपयोगकर्ता ज़ूम आउट होने पर 30% जोड़ा जाता है, ताकि मैं अन्य मार्करों को जल्दी से चारों ओर प्रदर्शित कर सकूं और फिर पृष्ठभूमि में आगे बढ़ सकें (व्यापक क्षेत्र)

• जब मार्करों की संख्या 50 से अधिक है - तो मैं उद्देश्यों को प्रदर्शित करने के लिए क्लस्टरिंग लागू करने की योजना। लेकिन जैसा कि जावास्क्रिप्ट में मार्करक्लस्टर काफी धीमा है, अर्थात् मार्करक्लस्टर नहीं बल्कि Google स्वयं ही है, क्योंकि यह अभी भी सभी मार्करों के स्थानों को लागू करता है, मैं लगभग 15 * 15 ग्रिड में प्रदर्शित मानचित्र की सीमाओं को विभाजित करके सर्वर की तरफ क्लस्टरिंग करने की योजना बना रहा हूं। और मार्करों को विशेष कोशिकाओं में छोड़ दें और फिर मूल रूप से क्लाइंट क्लस्टर को अंदर मार्करों की संख्या के साथ भेजें (उदाहरण के लिए हीटमैप के लिए)। और फिर क्लस्टर को मार्कर के रूप में प्रदर्शित करने के लिए।

क्या आप कृपया कुछ अंतर्दृष्टि दे सकते हैं जो भी समान था। क्या यह सामान्य रूप से समझ में आता है। या यह एक बेवकूफ दृष्टिकोण है क्योंकि AJAX अनुरोध सर्वर पर प्रत्येक मानचित्र ज़ूम और शिफ्ट और मूल रूप से अनावश्यक अनुरोधों के साथ अधिभार सर्वर पर भेजा जाएगा?

जो मैं प्राप्त करना चाहता हूं वह मार्करों के बड़े डेटासेट (2 सेकंड से कम में लोड करने के लिए) पर एक अच्छा उपयोगकर्ता अनुभव है।

Answer 1

आपका दृष्टिकोण ठोस है। यदि संभव हो, तो आप क्लस्टर को प्रीकंप्यूट करना और उन्हें सर्वर-साइड कैश करना चाहते हैं, उनके अपडेट रणनीति के साथ अंतर्निहित डेटासेट कितनी बार बदलता है।

Google मानचित्रों में ~ 20 ज़ूम स्तर हैं, इस पर निर्भर करता है कि आप ग्रह पर कहां हैं।आपके डेटा को क्लस्टर करने के आधार पर, यदि आपके पास 200,000 मार्कर कुल हैं और किसी दिए गए समय पर मानचित्र पर 500 के बारे में दिखाने के इच्छुक हैं, तो सभी क्लस्टर स्थानों और मूल मार्करों की गणना करने के लिए आप केवल 2n = 400,000 स्थानों सर्वर को संग्रहीत कर लेंगे आपके सभी ज़ूम स्तर संयुक्त के साथ।

संभव क्लस्टर अद्यतन करने की रणनीतियों:

• हर नए मार्कर पर अद्यतन गयी। कुछ लिखने के साथ एक पठन-भारी आवेदन के लिए संभव है, यदि आपको उच्च समय की डेटा समयबद्धता की आवश्यकता है।
• एक कार्यक्रम एक अद्यतन अगर ((कोई नया मार्कर हैं बंद
• किक पर अद्यतन के बाद से पिछले क्लस्टरिंग पास & & कैश एक्स से अधिक उम्र के) है || वहाँ पिछले क्लस्टरिंग पास के बाद से वाई नया मार्कर की तुलना में अधिक कर रहे हैं)

भौगोलिक डेटा का समर्थन करने वाले डेटाबेस में इन मार्करों को संग्रहीत करना फायदेमंद हो सकता है। यह एसक्यूएल-जैसे बयान स्थानों से पूछताछ की अनुमति देता है।

क्लाइंट-साइड, मैं किसी भी तरफ 50% मार्जिन लाने पर विचार करता हूं, 30% नहीं। Google 2 की शक्तियों में ज़ूम करता है। यह आपको एक पूर्ण ज़ूम स्तर प्रदर्शित करने की अनुमति देगा।

अगला, यदि इस एप्लिकेशन को भारी उपयोग मिलेगा और अनुकूलन सार्थक होगा, तो क्लाइंट ज़ूम इन होने पर मैं सर्वर-साइड लॉग करूंगा। अपना उपयोग प्रोफ़ाइल करने का प्रयास करें, ताकि आप यह निर्धारित कर सकें कि उपयोगकर्ता अक्सर ज़ूम इन और आउट करते हैं या नहीं। ठोस संख्याओं के साथ (जैसे "प्रारंभिक परिणामों को पुनर्प्राप्त करने के बाद उपयोगकर्ताओं का 70% ज़ूम इन करें, और 20% ज़ूम आउट करें"), आप यह निर्धारित कर सकते हैं कि यूआई हासिल करने के लिए अपने उपयोगकर्ताओं के लिए ज़ूम किए गए डेटा की अगली परत को प्रीलोड करना उचित होगा या नहीं जवाबदेही।