👍🏼 🍄 🌞 हमने नक्शे में प्रवेश को कैसे जोड़ा और आधारों के आकार को 10% तक कम कर दिया 🚶🏾 🛐 💏

पिछले महीने के अंत में, 2GIS ने पोर्च प्रदर्शित करना शुरू किया। हम 2013 से संगठनों को प्रवेश दे रहे हैं, और प्रवेश द्वार एक ही प्रवेश द्वार लगते हैं। तो अभी क्यों? सभी आंतरिक उत्पाद और प्रक्रियाएं तैयार हैं, आपको बस इतना करना है कि UI में थोड़ा और जोड़ दें और डिस्प्ले को सही करें।

मानक उत्तर के अलावा "अन्य प्राथमिकताएँ थीं," एक बहुत मानक एक भी नहीं है: "यह इतना सरल नहीं है।" यह लेख इस बारे में है कि क्या कठिनाइयाँ थीं और हमने उन्हें कैसे हल किया।

सबसे पहले, प्रवेश द्वार प्रवेश नहीं है। इसलिए, एक प्रवेश द्वार में कई प्रवेश द्वार बन सकते हैं, आमतौर पर भवन के विभिन्न किनारों से। एक आम प्रवेश द्वार के साथ "(बहु-स्तरीय) अपार्टमेंट की ब्लॉक की परिभाषा भी गलत है। ऐसा होता है कि एक प्रवेश द्वार की पहली मंजिल की ओर जाता है, और दूसरा - दूसरे और बाद की मंजिलों के लिए।

दूसरे, मैं प्रवेश द्वारों की तलाश करना चाहता हूं।

यह एक बहुत मांग वाला अवसर है, क्योंकि प्रवेश द्वार हमेशा एक स्पष्ट तरीके से स्थित होते हैं।

सबसे स्पष्ट प्रवेश संख्या के साथ घर नहीं

प्रवेश संख्या के अलावा, नाम (आमतौर पर एक अक्षर से) भी होते हैं।

या कलिनिनग्राद के रूप में भी - एक अलग पता सीढ़ी को बिल्कुल सौंपा गया है।

कैलिनग्रैड में प्रवेश द्वारों की स्वतंत्र संख्या

तीसरा, हमने तय किया कि अगर हम प्रवेश द्वारों की खोज करना चाहते हैं, तो अपार्टमेंट नंबर द्वारा खोज का तुरंत समर्थन क्यों न करें। उन्होंने फैसला किया - और अपार्टमेंट की सीमाएं एकत्र कीं, हालांकि, अभी तक एक मंजिल बंधन के बिना। प्रवेश द्वार के साथ के रूप में, अपार्टमेंट में न केवल संख्यात्मक नाम हो सकते हैं (ज्यादातर अक्सर "ए" अक्षर के साथ वेरिएंट होते हैं, और सीमाएं हमेशा निरंतर होती हैं। सेंट पीटर्सबर्ग के पुराने घरों में, नंबरिंग अजीब है: अपार्टमेंट 1 और 3 एक ही प्रवेश द्वार में हो सकते हैं, और अपार्टमेंट 2 भवन के विपरीत भाग में हो सकते हैं।

डेटा सत्यापन के बारे में गीतात्मक विषयांतर

बहुत अधिक एकत्र किए गए डेटा की वैधता बनाने की कोशिश न करें - उत्तरी राजधानी में ऐसे मामले हैं जब आप कई प्रवेश द्वारों से एक अपार्टमेंट में जा सकते हैं, और कुछ यूरोपीय बस्तियों में घर के अलावा प्रवेश द्वार और इस प्रवेश द्वार में अपार्टमेंट नंबर का नाम शामिल है। पीटर भी आठवें प्रवेश द्वार के साथ एक इमारत के साथ प्रसन्न है।

चौथा, मैं हमेशा नक्शे पर प्रवेश द्वार दिखाना चाहता हूं, और न केवल तब जब हम किसी विशेष घर या प्रवेश द्वार की जानकारी का अध्ययन करते हैं।

और, अंत में, कई प्रवेश द्वार हैं - वर्तमान अनुमान के अनुसार, अकेले मास्को में उनमें से लगभग एक सौ हजार हैं। "उंगलियों पर" पहले आकलन ने कुछ खगोलीय आंकड़े दिए - हमने हर बार एक बार बड़ी तरफ एक गलती की।

निष्कर्ष:

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

समाधान के लिए हो रही है

पहले दो बिंदुओं को आंतरिक और बाहरी दोनों उत्पादों में बदलाव की आवश्यकता होती है, लेकिन यह एक दिनचर्या है। उत्तरार्द्ध एक पूरी तरह से अलग मामला है। चूंकि हम उपयोगकर्ताओं को परेशान करना पसंद नहीं करते हैं, इसलिए हम प्रतिबंध लगाते हैं: डेटा ऑफ़लाइन उपलब्ध होना चाहिए, और इसे जोड़ने से डेटाबेस का आकार नहीं बढ़ना चाहिए।

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

डेटा की मात्रा कम करें

इसे कम करने के दो तरीके हैं:

संग्रहीत डेटा को ध्यान से देखें और कुछ ऐसा खोजने की कोशिश करें जो हम बिना कर सकते हैं।
इस बारे में सोचें कि क्या यह संभव है कि डेटा को अधिक कुशलता से संग्रहीत किया जाए, जितना हम अभी कर रहे हैं।

पोर्च के युग से पहले डेटा भंडारण प्रारूप का विकास

बहुत पहला और सबसे आसान विकल्प

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

इमारतों के साथ एक टेबल के भंडारण के अनुकूलन का एक बहुत ही सरल उदाहरण:

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

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

कार्य को सरल बनाएं

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

दोनों जोंस को कार्ड दिखाने के लिए, और संचार को एक समय में कई दसियों की शक्ति से सीमित संख्या में वस्तुओं के लिए प्राप्त करने की आवश्यकता होती है। लेकिन ऐसे परिदृश्य हैं जहां बड़े नमूनों के लिए व्यक्तिगत विशेषताओं को एक बार में प्राप्त करने की आवश्यकता होती है, सैकड़ों हजारों तक। इस तरह की विशेषताओं को एक अलग इकाई में एक अलग भंडारण प्रारूप - गुणों के साथ अलग करना अधिक तर्कसंगत है। गुण प्रकार के हो सकते हैं और द्विआधारी प्रारूप में अधिक कुशलता से संग्रहीत किए जा सकते हैं।

जोंस को संचय करने के लिए एक भोली दृष्टिकोण एक कुंजी-मूल्य डेटाबेस का उपयोग करना है। मास्को को एक उदाहरण के रूप में लें, हमारी परियोजनाओं में सबसे बड़ा। यहां तक कि सबसे सरल रूप में भी संभव है - प्रत्येक ऑब्जेक्ट के लिए json खुद को संग्रहीत किया जाता है, पहचानकर्ता के 8 बाइट्स और एक सीमांकक चरित्र - निर्देशिका 1.9 GiB ले जाएगा। परिणामी आकार पिछले वर्णित विकल्प की तुलना में लगभग छह गुना बड़ा है, और यह अभी भी संबंधों और गुणों के बिना है।

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

डेटा संपीड़ित करें

अतिरेक को समाप्त करने के लिए सामान्यीकरण एकमात्र तरीका नहीं है। दूसरा लोकप्रिय तरीका संपीड़न है। हमारी अविश्वसनीय रूप से मोटी फ़ाइल का lzma संग्रह केवल 55 MiB लेता है।

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

हम एक ओर, और दूसरी ओर, डेटा को संपीड़ित करके, आवश्यक स्थान के आकार को कम करके त्वरित यादृच्छिक पहुँच कैसे प्राप्त कर सकते हैं? जवाब है कि पेजिंग का उपयोग करना।

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

इस प्रारूप में, सभी डेटा संग्रहीत हैं - json'y, रिश्ते और गुण। यह वस्तुओं के पहचानकर्ताओं के साथ इस डेटा को जोड़ने के लिए बना हुआ है। प्रत्येक पहचानकर्ता के लिए, हमें एक या एक से अधिक जोड़े <संग्रहण संख्या, संग्रहण में डेटा संख्या> संग्रहीत करने की आवश्यकता है।

स्टोरेज में ऑब्जेक्ट आइडेंटिफ़ायर और डेटा के बीच संबंधों का सरलीकृत प्रारूप

स्टोरेज में ऑब्जेक्ट आइडेंटिफ़ायर और डेटा के बीच संबंधों का सरलीकृत प्रारूप

सभी सीरियल नंबर, ऑफ़सेट और साइज़ UTF-8 के समान एक संपीड़ित प्रारूप में संगृहीत होते हैं, जहाँ छोटे मान केवल एक बाइट लेते हैं। यह हमें घटनाओं की आवृत्ति को कम करने के लिए बाइनरी रिपॉजिटरी की सामग्री को क्रमबद्ध करके लिंक के आकार को कम करने की अनुमति देता है।

कुछ गुणों में कई आवृत्ति मूल्य होते हैं, और इसलिए छंटाई आकार में एक बड़ा लाभ देती है। दूसरी ओर, इसकी वजह से, डेटा का सीरियल नंबर सभी स्टोरेज के लिए मेल नहीं खा सकता है।

इसके अलावा, सभी वस्तुओं से दूर सभी भंडारण में डेटा है, और इसलिए भंडारण की संख्या खाली वस्तुओं को संदर्भित करने की तुलना में अधिक कुशल है।

डेटा पुनर्प्राप्ति को गति दें

वर्णित प्रारूप में एक समस्या है। निर्दिष्ट पहचानकर्ता के लिए सूचक को संग्रहीत करने वाली ऑब्जेक्ट की संख्या को खोजने के लिए, हमें पहले ऑब्जेक्ट के डेटा के अंदर एक द्विआधारी खोज चलाने की आवश्यकता है। ऐसा करने के लिए, आपको या तो 10.9 MiB को मेमोरी में लोड करना होगा, या 21 अतिरिक्त रीडिंग करना होगा। दोनों समाधान हमारे लिए उपयुक्त नहीं हैं, और इसलिए हम एक पेड़ में डेटा संग्रहीत करके रीडिंग की संख्या को कम करते हैं।

पहचानकर्ता द्वारा त्वरित डेटा खोज के लिए पेड़ का प्रारूप

हम 32 ऑब्जेक्ट्स पर डेटा ग्रुप करते हैं, और मध्यवर्ती स्तरों में हम नेस्टेड नोड्स के पहले पहचानकर्ताओं में से 128 स्टोर करते हैं। हमने पेड़ के तीन स्तरों को जोड़ा और अतिरिक्त रीडिंग की संख्या को घटाकर चार कर दिया (लेकिन वास्तव में, पहले से पढ़े गए पेड़ के नोड्स की कैशिंग को ध्यान में रखते हुए, यहां तक कि 1-3 तक)। मूल्य - 400 KiB से थोड़ा कम।

इस स्तर पर, हम रिश्तों और गुणों को संचय करने में बहुत कुशल हैं, लेकिन json का स्थान बहुत अधिक है। यह समझ में आता है। पृष्ठ का आकार जितना बड़ा होता है, उतनी ही वस्तुएँ मिलती हैं और बेहतर संपीड़न एल्गोरिदम यह निर्धारित करने में सक्षम होता है कि कौन सी जानकारी निरर्थक है। लेकिन, दूसरी ओर, किसी एक वस्तु को पढ़ने के लिए हमें जितना अधिक काम करना होगा। जोंस काफी बड़ी वस्तुएं हैं, और इसलिए एक पृष्ठ में उनमें से बहुत कम हैं। इसलिए, आपको एल्गोरिथ्म को अपना काम बेहतर तरीके से करने में मदद करने की आवश्यकता है।

Json को भागों में तोड़ें

सबसे पहले, कई वस्तुओं में डेटा योजनाएँ होती हैं, केवल विशेषता मान भिन्न होते हैं। दूसरी बात, विभिन्न योजनाओं के साथ वस्तुओं के लिए भी कई गुण मान समान होते हैं। हम स्कीम और एट्रिब्यूट वैल्यू को अलग-अलग स्टोरेज में अलग-अलग करेंगे, और हम फॉर्म में जोंस को स्टोर करेंगे: स्कीम की एक लिंक + फीचर्स वैल्यूज के लिए लिंक।

हमारे डेटा स्कीमा में, विशेषता नामों की संख्या सीमित है। इसलिए हम उन्हें एक अलग फ़ाइल में रख सकते हैं और इसके बजाय नंबर को स्टोर कर सकते हैं। हम यह भी ध्यान में रखते हुए कुछ और बदलाव करेंगे, कि json हमेशा ऑब्जेक्ट हैं।

जोंस वस्तुओं स्कीमा के भंडारण के लिए वास्तविक प्रारूप

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

हमने पृष्ठ का आकार 1 KiB पर सेट किया है और यह पता चला है कि जब हमने प्रारूप को अनुकूलित किया था, ताकि एक तरफ, रीडिंग बहुत धीमी न हो, और दूसरी ओर, डेटा को यथासंभव पैक किया गया था, हमने ... पहले से ही आकार में "अनुकूलित तालिकाओं" को बायपास कर दिया था। उपयोग में आसानी के लिए। लेकिन कुछ नहीं के लिए यह सब था! अधिकतम लाभ विशेषताओं, गुणों और योजनाओं के मूल्यों के संपीड़न से होना चाहिए। हम zlib को उकसाते हैं और सत्यापित करते हैं कि, बाकी काम की पृष्ठभूमि के खिलाफ, डेटाबेस से डेटा पढ़ने में बहुत कम समय लगता है। परिणाम से संतुष्ट, हम अन्य कार्यों पर स्विच करते हैं।

अनावश्यक से छुटकारा पाएं

हम उन डेटा की खोज करके कम करना शुरू करते हैं जिनसे आप छुटकारा पा सकते हैं। यह पता चला है कि प्रारूप के अस्तित्व के दौरान, हमने सबसे बड़े कनेक्शन के बिना करना सीख लिया है। यह आकार का 10% है!

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

संस्करण द्वारा उपयोगकर्ता वितरण

सबसे ऊपर एंड्रॉइड एप्लिकेशन के नवीनतम संस्करणों द्वारा उपयोगकर्ताओं का वितरण है। नीचे iOS है।

यह नोटिस करना आसान है कि iOS उपकरणों के उपयोगकर्ताओं को बहुत अधिक आसानी से अपडेट किया जाता है, लेकिन उनमें से भी पुराने संस्करणों के उपयोगकर्ताओं की संख्या बहुत अधिक है।

हम अभी भी विंडोज फोन के लिए जमे हुए संस्करण के लिए नया डेटा जारी कर रहे हैं। और यद्यपि WP8 उपयोगकर्ता हमारे दर्शकों का केवल एक छोटा सा हिस्सा बनाते हैं, पूर्ण संख्या में यह लगभग 200,000 प्रति माह है।

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

किए गए काम से एक अच्छा बोनस मासिक अद्यतन के आकार को कम कर रहा है, क्योंकि दूरस्थ कनेक्शन महीने से महीने में बहुत बदल गया है, अंतर के आकार को बढ़ाता है।

यदि आप शेष डेटा को देखते हैं, तो कुल मिलाकर आप एक ही 10% निचोड़ सकते हैं, हालांकि, कीमत अतुलनीय रूप से अधिक होगी। अब तक हमने फैसला किया था कि मैं नहीं छूऊंगा।

वर्तमान संग्रहण प्रारूप का अनुकूलन करें

जैसा कि ऊपर लिखा गया था, हमने 1 KiB पेज बनाए और सभी बाइनरी रिपोजिटरी को पैक नहीं किया।

पहली चीज़ जो हम करते हैं, वह भी लिंक वाले पृष्ठों को पैक करने की कोशिश करता है, और जाँचता है कि डेटा प्राप्त करने की गति में अंतर त्रुटि के क्षेत्र में है।

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

बड़े चयनों पर पृष्ठ आकार का प्रभाव

यदि पृष्ठ वृद्धि से छोटे चयनों को धीमा करने की उम्मीद की जाती है, तो बड़े - सैकड़ों तत्वों से - और भी त्वरित हो जाते हैं। इसका मतलब यह है कि एक अच्छे तरीके से आपको स्टोर किए गए डेटा के उपयोग के मामलों के आधार पर स्टोरेज के लिए अलग-अलग आकार चुनने की आवश्यकता है।

कुल मिलाकर, केवल ये दो बिंदु आधार को 18% तक कम कर सकते हैं!

संपीड़न प्रारूप को बदलें

zlib, ज़ाहिर है, एक क्लासिक है, लेकिन zstd अधिक संपीड़न अनुपात के साथ उच्च विघटन गति प्रदान करता है। इसके अलावा, zstd आपको पहले उपलब्ध सभी डेटा के लिए एक ही शब्दकोश बनाने की अनुमति देता है, और फिर इसे एक बार सहेज कर सभी पृष्ठों के साथ संपीड़ित करता है। इस प्रकार, हम डेटाबेस के साथ फ़ाइल बनाने की प्रक्रिया को धीमा कर देते हैं, लेकिन हम अतिरिक्त 8% निचोड़ लेते हैं।

पोर्च जोड़ें

आसान तरीका है

सबसे आसान तरीका है कि प्रत्येक प्रवेश द्वार को एक अलग ऑब्जेक्ट बनाया जाए, उन्हें अलग-अलग इंडेक्स किया जाए (इंडेक्स साइज़ के + 10% के अनुसार), और मैप को ड्राइंग करने के लिए डेटा में उनकी ज्यामिति को अलग से स्टोर करें।

यह विधि कुल 3% तक आधार को बढ़ाएगी। पिछले चरणों में, हमने सामान्य योजना के अनुसार प्रवेश द्वारों को शांत करने और काम करने के लिए पर्याप्त से अधिक जीता, लेकिन ... काम की शुरुआत के समय, हम इस बारे में निश्चित नहीं थे, और एक वैकल्पिक प्रारूप पर काम समानांतर में था।

विस्तृत मूल्यांकन, रुचि रखने वालों के लिए

आइए प्रत्येक वस्तु के लिए डेटाबेस के साथ पैकेज के आकार में वृद्धि का मूल्यांकन करने का प्रयास करें:

8 बाइट्स - पहचानकर्ता,
6 बाइट्स - उपयोग किए गए स्टोरेज की संख्या (डेटा + पांच गुण; संपत्तियों को मुख्य डेटा से निकाला जाता है और बाइनरी फॉर्म में संग्रहीत किया जाता है, क्योंकि उन्हें अक्सर बड़ी संख्या में वस्तुओं की आवश्यकता होती है),
3 बाइट्स - डेटा वेयरहाउस में सूचकांक,
2 बाइट्स - ऑब्जेक्ट का ऑफसेट डेटा,
5 बाइट्स - डेटा मान - प्रति सर्किट 2 बाइट्स, अपार्टमेंट जानकारी के लिए औसतन 3 बाइट्स (हम मानते हैं कि कई डुप्लिकेट होंगे और डेटा खुद एक बार संग्रहीत होता है)
6 बाइट्स - ऑफसेट डेटा निर्देशांक (अन्य गुणों में कई डुप्लिकेट मान हैं और ढह जाएंगे),
8 बाइट्स - मूल्यों का समन्वय।

प्रति वस्तु कुल 38 बाइट्स। मास्को के मामले में, यह 124 हजार से अधिक एकत्रित इनपुट के लिए 4.5 MiB है।

अगला, हमें घर और प्रवेश द्वार के बीच के कनेक्शन को भी स्टोर करने की आवश्यकता है, यह प्रत्येक अपार्टमेंट बिल्डिंग के लिए 2.5 बाइट्स और प्रत्येक प्रवेश द्वार के लिए 8 बाइट्स है। 1 और मि.बी.

अब हम विचार करते हैं कि यह सब मानचित्र पर कितना लगेगा।

सबसे पहले, हमें ज्यामिति को संग्रहित करना चाहिए। पॉलीलाइन के लिए, पहला बिंदु हमेशा 8 बाइट्स लेता है, और बाद के सभी आवश्यक सटीकता के अंतर के रूप में संग्रहीत होते हैं। यहां हम डेसीमीटर की सटीकता से संतुष्ट हैं। अधिकांश इनपुट में दो बिंदु होते हैं जो एक दूसरे से बहुत दूर नहीं होते हैं, और इसलिए यह माना जा सकता है कि ज्यामिति स्वयं 10 बाइट पर कब्जा कर लेगी। कुल 1.2 मि.बी.

हमें इनपुट पहचानकर्ता और ऑब्जेक्ट को इसकी ज्यामिति के साथ जोड़ने की भी आवश्यकता है। एक अनुक्रमणिका वही बाइनरी स्टोरेज है जो बाकी सब कुछ है, केवल संचार गंतव्य (1 बाइट), लेयर नंबर (1 बाइट) और ऑब्जेक्ट नंबर (3 बाइट्स) संग्रहीत हैं। पहचानकर्ता प्रति 8 बाइट्स, साथ ही एक त्वरित खोज ट्री। कुल एक और 1.5 मि.बी.

जैसा कि लेख के बहुत शुरुआत में कहा गया था, हम नक्शे पर प्रवेश द्वार को लगातार प्रदर्शित करना चाहते हैं, और ऐसा करने का सबसे आसान तरीका डॉट्स के साथ एक और परत को उतारना है, लेकिन ... आप ज्यामितीय के साथ परत का पुन: उपयोग भी कर सकते हैं, एक नया प्रतीक बना सकते हैं जो हमें उस चित्र को प्रदर्शित करेगा जिसकी हमें आवश्यकता है पॉलीलाइन के अंतिम बिंदु पर।

खोज सूचकांक का 10% 5.9 MiB है। सब कुछ संक्षेप में, हमें 14.2 MiB मिलता है, जो कि 3% से थोड़ा अधिक है।

वर्तमान विकल्प

प्रवेश द्वारों को अनुक्रमित करने और खोज इंडेक्स को फुलाए जाने के बजाय, हम घरों की खोज करते हैं, लेकिन इसके अतिरिक्त क्वेरी शब्दों को भी चिन्हित करते हैं और उसमें से पतों का चयन करते हैं (कलिनिनग्राद में प्रवेशों की खोज के लिए प्रासंगिक), प्रवेश द्वार और / या अपार्टमेंट। इस प्रकार, बाहर निकलने पर हमारे पास घर पहचानकर्ता और टाइप किए गए पाठ फ़ील्ड होते हैं, जिनके द्वारा हमें वह सीढ़ी मिलनी चाहिए जिसकी हमें आवश्यकता है।

टिप्पणी

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

इसके अलावा, व्यक्तिगत वस्तुओं को उतारने के बजाय, हम सीधे निर्माण डेटा में प्रवेश द्वारों के बारे में सभी जानकारी शामिल करते हैं।
और अंत में, हम ज्यामिति का हिस्सा निर्देशिका में स्थानांतरित करते हैं।

उत्तरार्द्ध अधिक विस्तार से खुलासा करने योग्य है।

सबसे पहले, हम देखते हैं कि अधिकांश इनपुट दो बिंदु हैं और समान लंबाई है। इस तरह के इनपुट को बिंदु + दिशा के रूप में संग्रहीत किया जा सकता है, अर्थात। प्रति इनपुट 1 बाइट बचाएं।

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

हमारे पास पहले से ही इमारतों के केंद्रीय बिंदु हैं।क्या होगा यदि हम भवन के लिए एक नई संपत्ति जोड़ते हैं - इसकी पूर्णांक "दिशा", और प्रत्येक इनपुट के लिए दो और - पूर्णांक में पूर्णांक ऑफसेट और दिशा रेखा के लंबवत? यह देखते हुए कि कैसे हम जानकारी के साथ जोंस को स्टोर करते हैं, औसतन इनपुट ज्यामिति केवल दो बाइट्स पर कब्जा कर लेगी।

एक अतिरिक्त बोनस यह है कि चूंकि ज्योमेट्री डायरेक्टरी में है, इसलिए हमें मैप लेयर में इनपुट आइडेंटिफ़ायर और ऑब्जेक्ट नंबर के बीच पत्राचार को स्टोर करने की आवश्यकता नहीं है।

माइनस - कोड अधिक जटिल हो गया है। पहले हमने मानचित्र को केवल "ऐसी और ऐसी वस्तुओं को दिखाएं" कहा था, और अब इनपुट प्रदर्शित करते समय हम इस डेटा को जसन से निकालते हैं और गतिशील वस्तुओं को मानचित्र में जोड़ते हैं। यहां सब कुछ बहुत डरावना नहीं है। जस इनपुट्स के एरो कीज़ को प्रदर्शित करने के समय तक, हमारे पास पहले से ही संबंधित वस्तुएं हैं, अर्थात इसके अलावा डेटाबेस में जाने की कोई आवश्यकता नहीं है। प्रदर्शित प्रवेश बिंदुओं के साथ, सब कुछ थोड़ा खराब है - अब हमें पृष्ठभूमि में यह निर्धारित करना होगा कि कौन से घर दिखाई दे रहे हैं, डेटाबेस से इन घरों के डेटा को बाहर निकालें, पार्स जोंस और, अगर इनपुट हैं, तो उनके लिए गतिशील ऑब्जेक्ट बनाएं।

टिप्पणी

एक अस्पष्ट निर्णय। यहां तक कि सभी प्रकार के अनुकूलन और काफी तेज काम को ध्यान में रखते हुए, हम अभी भी अतिरिक्त कार्य करते हैं जो कि आधार आकार को 0.2% (मॉस्को के लिए 972 KiB) से बढ़ाकर किया जा सकता है।

चूँकि हमने प्रवेश द्वारों पर प्रदर्शन करने के लिए पहले ही अतिरिक्त कोड लिख दिया है, इसलिए कुछ भी हमें निर्देशिका में संगठन में दो-बिंदु आदानों को संग्रहित करने से रोकता है। इस मामले में लाभ छोटा, लेकिन मुक्त होगा।

इसने हमें कितना दिया? 3% 0.5% में बदल गया। हम और भी कम कर सकते थे, लेकिन हमने गलत इनपुट्स के बारे में उपयोगकर्ता संदेशों के प्रसंस्करण को सरल बनाने के लिए डेटा में पहचानकर्ताओं को छोड़ दिया (जो खराब तरीके से संपीड़ित हैं)।

परिणाम

हमने बड़ी संख्या में प्रवेश द्वार जोड़े, जबकि फ़ाइल डेटा के नक्शे को 0.5% से कम करके और निर्देशिका डेटा के साथ फ़ाइल के आकार को 26.6% तक कम किया। उत्तरार्द्ध अभी भी हमारी फ़ाइलों में सबसे बड़ा है, लेकिन यह केवल चार "भारी" फाइलों में से एक है, इसलिए समग्र परिवर्तन अधिक मामूली निकला - 10.1%।

प्रवेश द्वार अभी तक एकत्र नहीं किए गए हैं। आधारों का आकार समय के साथ थोड़ा बढ़ेगा (वर्तमान अनुमानों के अनुसार, समान मॉस्को में 0.4% की वृद्धि होगी), लेकिन किसी भी मामले में, लक्ष्य आकार को बढ़ाए बिना प्रवेश को जारी करना है, हासिल से अधिक।

आगे क्या है?

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

तकनीकी योजनाओं में, कई विचारों की जांच होती है जो संदर्भ डेटा के साथ फ़ाइल के आकार में और कमी ला सकते हैं, और आपको अन्य फ़ाइलों को ध्यान से देखने की आवश्यकता है।

और, निश्चित रूप से, हम उन त्रुटियों को ठीक करेंगे जो हमारे पास अब तक हैं।

एक और विचार: JSON का बुद्धिमानी से उपयोग करें

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

यह दूसरी भाषा में लिखे C ++ से UI तक JSON डेटा के हस्तांतरण को भी प्रतिबंधित करने के लायक है।

सबसे पहले, आपको इसे एक स्ट्रिंग में बदलना होगा।

दूसरे, यूआई भाग से उपलब्ध पार्सर इस लाइन को फिर से इकट्ठा करेंगे, और यह बहुत धीमी गति से करेंगे।

JSON से सभी डेटा को अपने आप प्राप्त करना बेहतर है, और UI के लिए विशिष्ट तत्वों को प्रदर्शित करने के लिए अनुकूलित सरल इंटरफेस को फेंक दें।

हमने नक्शे में प्रवेश को कैसे जोड़ा और आधारों के आकार को 10% तक कम कर दिया