गूगल मैप्स पर डेटा प्रदर्शित करने का एक हाइब्रिड तरीका है

यह आलेख इंटरेक्टिव मैप्स (maps.google.com, maps.yandex.ru) पर डेटा प्रदर्शित करने की विधि का वर्णन करता है।

सम्मानित काशी के पदों में, मानचित्रों पर वस्तुओं को प्रदर्शित करने की विधि पर यहां और वहां चर्चा की गई थी।

इस पद्धति का अध्ययन करने के बाद, मैंने इसे सबसे बड़े मोटर वाहन संसाधन के लिए लागू करना शुरू कर दिया।
नवंबर में, जब अधिकांश कोड लिखा गया था, तो अप्रत्याशित हुआ - Google ने एक मानचित्र सेवा शुरू की, जिस पर मक्खी पर खोज परिणामों के साथ नक्शे के चित्र (टाइलें) बनाए गए थे।

मैंने इस तकनीक को "मुँहासे तकनीक" कहा - खोज परिणाम छोटे लाल डॉट्स के साथ सीधे png छवि पर लागू होते हैं, जो मानचित्र परत के शीर्ष पर एक अलग परत है। आप इसे यहाँ देख सकते हैं।
एक अलग परत के रूप में डेटा प्रदर्शित करना लंबे समय से इस्तेमाल किया गया है, उदाहरण के लिए, wikimapia.org पर। Google की मुख्य सफलता यह थी कि "मुँहासे" के साथ चित्र "मक्खी पर" बनते हैं और सर्वर पर कैश नहीं होते हैं। इसके लिए बड़े सर्वर की आवश्यकता होती है।
मैंने अपने परीक्षण किए और पता चला कि एक आधुनिक सर्वर प्रति सेकंड 160 टाइल तक खींचता है। लोडों की तुलना करने से, यह स्पष्ट हो गया कि एक सर्वर एक साथ जुड़े सैकड़ों उपयोगकर्ताओं से अधिक नहीं सेवा कर सकता है, जो कि बहुत छोटा है। इसके अलावा, प्रौद्योगिकी के कई महत्वपूर्ण नुकसान भी हैं:

• बड़ी संख्या में सर्वर अनुरोध (प्रति टाइल)
• एक टाइल के लिए प्रत्येक अनुरोध के लिए वस्तुओं का चयन करने की आवश्यकता है

इसी समय, एक महत्वपूर्ण प्लस है - "क्लस्टरिंग" के बिना बड़ी संख्या में वस्तुओं को प्रदर्शित करने की क्षमता और क्लाइंट और ब्राउज़र डोम पर लोड।
वैसे, अभी लॉन्च किए गए realty.yandex.ru में, कार्ड सिर्फ DOM पर बने होते हैं (यानी, प्रत्येक मार्कर एक DIV है)। इसलिए, यह इस तरह से बदल जाता है
नक्शे के चारों ओर जाओ ...

बाद के शोध के परिणामस्वरूप, तथाकथित "हाइब्रिड" प्रणाली।

"हाइब्रिड" का सार यह है कि ब्राउज़र की क्षमताओं के आधार पर (निश्चित रूप से, हम यानी के बारे में बात कर रहे हैं), डेटा प्रदर्शित करने के अपने तरीके का उपयोग किया जाता है।
इसलिए, उदाहरण के लिए, सभी आधुनिक ब्राउज़र (9 संस्करण को छोड़कर) कैनवास टैग का समर्थन करते हैं।
इन ब्राउज़रों के लिए, मैंने क्लाइंट पर सीधे ऑब्जेक्ट्स के साथ एक परत खींचने की तकनीक लागू की।
इस प्रकार, मैप को मूविंग / जूम करते समय, सर्वर से केवल 1 अनुरोध होता है। डेटा प्राप्त करने के बाद, ब्राउज़र खुद एक परत खींचता है।
प्रदर्शित करने का दूसरा तरीका - ie8 और कुछ अन्य ब्राउज़रों के लिए - dataUrl का उपयोग करता है। फिर से, प्रत्येक आंदोलन के लिए - 1 अनुरोध। चित्र सर्वर पर खींचे जाते हैं और डेटा के साथ एक xml फ़ाइल में भेजे जाते हैं।
आज तक, ऐसे अनुरोध - लगभग 18%। यह स्पष्ट है कि धीरे-धीरे प्रतिशत घट जाएगा।
तीसरा तरीका क्लासिक है। सबसे पहले, डेटा प्रेषित किया जाता है, और फिर चित्रों का अनुरोध किया जाता है - प्रत्येक अनुरोध की अपनी तस्वीर होती है। यह 7 और नीचे के लिए है। ऐसे लगभग 6% हैं। इस पद्धति का उपयोग Google मानचित्र में किया जाता है।

कुल मिलाकर, इस तरह के हाइब्रिड का उपयोग करते हुए, हमें "क्लासिक्स" की तुलना में अनुरोधों की संख्या में 4 गुना की कमी प्राप्त हुई, और सर्वर लोड भी लगभग 4 गुना था।

मेरे नक्शे अब प्रति टाइल अधिकतम 100 ऑब्जेक्ट प्रदर्शित करते हैं। औसत खिड़की के आकार के साथ, यह 2400 मुँहासे तक है।

लाचिंग और कैशिंग

अलग-अलग, डेटा खोजने के साथ समस्या का समाधान किया गया था।
यदि सब कुछ सरल था और पहले से ज्ञात कई श्रेणियों के लिए केवल डेटा प्रदर्शित करना आवश्यक था, तो बगीचे को अवरुद्ध करने का कोई मतलब नहीं होगा। लेकिन खोज बार में कीवर्ड द्वारा आउटपुट प्राप्त करना कार्य था। बेशक, स्फिंक्स इसके लिए जुड़ा हुआ था।

लेकिन समस्या अलग थी:
हर बार जब कार्ड चलता है, तो फिर से अनुरोध करने के लिए आवश्यक है, इसे पार्सर और स्फिंक्स के माध्यम से चलाएं, फिर mysql के माध्यम से अंक प्राप्त करें ... हमें किसी तरह इसे सरल बनाने की आवश्यकता है ...
नतीजतन, मेम्चे का उपयोग करके एक php कैशिंग इंजन बनाया गया था।
सब कुछ निम्नानुसार होता है:
सर्वर एक खोज स्ट्रिंग प्राप्त करता है (उदाहरण के लिए, "ऑडी डीलर"), इसे पार्स करता है और इसे स्फिंक्स को भेजता है। स्फिंक्स खोज परिणाम देता है, फिर अंक प्राप्त करने और निष्पादित करने के लिए mysql-request उत्पन्न होती है। सभी प्राप्त बिंदुओं को पैक किया जाता है और मेम्चे में भेजा जाता है।
तो, 10,000 अंकों के लिए, कैश आकार लगभग 1mb है। जैसा कि योजना बनाई गई है, यह अधिकतम आकार है।
इसके अलावा, जब कार्ड बिंदुओं के लिए कॉल करता है, तो डेटा को मेम्चे से लोड किया जाता है और बहुत जल्दी खोजा जाता है।
बहुत तेज़ - यह प्रति 10,000 अंक पर 0.02 सेकंड तक है। कैशिंग क्लास में, नमूनों के लिए केवल मूल php फ़ंक्शन का उपयोग किया जाता है, मूल्यों की गणना के साथ कोई लूप नहीं।
कैश 3 मिनट से अधिक नहीं रहता है। यदि कैश में आवश्यक डेटा नहीं है, तो अनुरोध फिर से उत्पन्न, निष्पादित और कैश किया गया है। ऐसा करने के लिए, नक्शे के लिए टाइल और डेटा के अनुरोध में खोज स्ट्रिंग को डुप्लिकेट किया गया है।

सामान्य तौर पर, कैश क्लास विभिन्न तरीकों से कैश करने की क्षमता प्रदान करता है, जिसमें डिस्क कैशिंग भी शामिल है। मामले के लिए जब आपको खोज पट्टी का उपयोग करने की आवश्यकता नहीं है, लेकिन श्रेणियों, विभिन्न सूचियों और jackdaws के साथ एक मेनू। यदि अनुरोध के प्रकारों की संख्या सीमित है, तो यह विधि उपयुक्त है।

मार्कर

प्रारंभ के दौरान कार्ड का प्रबंधन करने वाला सर्वर वर्ग मार्करों और उनके विवरण के साथ स्प्राइट स्वीकार करता है।
विवरण - यह आकार, स्प्राइट में स्थिति, लंगर, छाया, आदि है।
तदनुसार, बहुत बड़ी संख्या में मार्करों को स्प्राइट में भरा जा सकता है और उन सभी का उपयोग मानचित्र पर किया जा सकता है। मेरे सिस्टम के लिए मार्कर का आकार 200x200 तक है, जो कि पर्याप्त से अधिक है।
इंजन में डेटा स्थानांतरित करते समय, प्रत्येक बिंदु के लिए आप अपने खुद के मार्कर (स्प्राइट से) छाया और होवर के साथ सेट कर सकते हैं। और इसे प्रदर्शित किया जाएगा (3 में से एक तरीके से)।

कार्ड का स्तर

मानचित्र के 3 स्तरों का उपयोग करने का निर्णय लिया गया - देश, क्षेत्र, शहर। "देश" के स्तर पर हम क्षेत्रों की राजधानियों के मार्कर दिखाते हैं, "क्षेत्र" के स्तर पर - शहर, "शहर" - अंक ("मुँहासे")।
स्तरों की संख्या सेटिंग्स द्वारा समायोजित की जाती है।

लेकिन यांडेक्स के बारे में क्या?
छोटे रूपांतरण वाले लिखित इंजन में, आप यैंडेक्स-कार्ड के लिए समर्थन एम्बेड कर सकते हैं।
लेकिन इस तरह के कार्य को प्रस्तुत नहीं किया गया था, और इसलिए इसका एहसास नहीं हुआ था।

आज तक, परियोजना 80% में लिखी गई है, लेकिन मूल विचारों को पहले ही लागू किया जा चुका है।
आप इसे यहाँ russia.auto.ru पर देख सकते हैं
और यहाँ क्लब-lexus.ru/partners/index.php?city=1&mode=citymap