एक ऑर्डर देना कितना आसान है, ग्राहक का पता (बहुत नहीं)

सभी को नमस्कार! मेरा नाम डेनिस गिरको है, मैं लमोडा में ई-कॉमर्स प्लेटफॉर्म का सिस्टम आर्किटेक्ट हूं। पिछले साल मैंने DevConf सम्मेलन में एक रिपोर्ट के साथ बात की थी जिसे मैं आपके साथ साझा करना चाहता हूं।

यह कठिनाइयों पर एक समीक्षा रिपोर्ट है जो ऑर्डर डिलीवरी की प्रक्रिया में एक बड़े ऑनलाइन स्टोर का सामना करती है और तकनीकी समाधान उन्हें दूर करने में मदद कर सकते हैं (उदाहरण के रूप में लमोडा में हमारे द्वारा परीक्षण किए गए समाधानों का उपयोग करके)।

इसके बारे में क्या होगा? मैं आपको बताता हूँ:

• वितरण प्रक्रिया और समस्याओं की पहचान के बारे में;
• डेटाबेस में वितरण क्षेत्र को प्रभावी ढंग से कैसे संग्रहीत करें;
• हम ग्राहक से प्राप्त होने वाले डेटा की गुणवत्ता में सुधार कैसे करें;
• अधिक सटीक परिणाम जानने के लिए पता डेटाबेस में पताका की खोज कैसे करें।

सामान्य लमोडा ऑर्डर डिलीवरी योजना

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

लमोडा आदेश को स्वीकार करता है, पंजीकरण के समय ग्राहक से पते के लिए पूछता है और कूरियर सेवा में इसे पास करता है।

क्या होगा यदि हमारे पास एक कूरियर सेवा नहीं है, लेकिन कई हैं? फिर अगला कदम जोड़ा जाता है - यह निर्धारित करने के लिए कि हम किस डिलीवरी सेवा को ऑर्डर लेंगे।

कुछ व्यावसायिक चयन मानदंड हो सकते हैं। लेकिन इस बारे में सोचने वाली पहली बात यह है कि इस कूरियर सेवा का ग्राहक द्वारा चयनित शहर में वितरण है या नहीं। इसलिए, किसी भी कूरियर कंपनी को हमारे सिस्टम में एकीकृत करने का पहला चरण इसका कवरेज क्षेत्र पता लगाना है।

इसके बाद, आपको यह जानने की ज़रूरत है कि ग्राहक का पता इस क्षेत्र में पड़ता है या नहीं।

सामान्य योजना में सुधार किया जाएगा और इस तरह दिखेगा:

• एक पते के लिए पूछें;
• पता लगाएं कि कौन सी कूरियर सेवाएं इसे वितरित कर सकती हैं;
• जिसे आप चाहते हैं उसे चुनें

अब इन चरणों के बारे में थोड़ा और।

हम क्लाइंट से पता पूछते हैं

मैं उससे कैसे पूछ सकता हूं?

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

हम किस डिलीवरी सेवा में परिवहन कर रहे हैं?

चूंकि हमारे पास एक पहचानकर्ता (इंडेक्स) है, तो हमारे डेटाबेस में संग्रहीत क्षेत्र को इंडेक्स की सूची द्वारा दर्शाया जाए। इस स्थिति में, शहर के क्षेत्र में प्रवेश की जाँच करने के लिए एल्गोरिथ्म बहुत सरल है। तो चलिए इसे करते हैं: हम कूरियर सेवाओं से प्राप्त डिलीवरी प्रदेशों को सूचकांक के रूप में डेटाबेस में रखेंगे।

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

अनुक्रमणिका क्यों गायब हैं?

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

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

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

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

बहुभुज क्षेत्र निर्माण इंटरफ़ेस

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

रूटिंग इंटरफ़ेस

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

तथ्य यह है कि ग्राहक अक्सर उन परिदृश्यों का पालन नहीं करते हैं जो हम उनके लिए प्रदान करते हैं, इसलिए हमने उन 4 देशों में से प्रत्येक के लिए पता डेटाबेस प्राप्त किए हैं जहां वे ऑर्डर वितरित करते हैं। और उन्होंने न केवल शहर के लिए, बल्कि सड़क के लिए, और यहां तक ​​कि घर की संख्या के लिए भी एक सजग बनाया। घरों की एक सूची बनाने के लिए, हमने 'openstreetmap.org' के खुले डेटा को पार्स किया।

चेकआउट फॉर्म एड्रेस डेटा को औपचारिक रूप देने के लिए सुझाव देता है

आधार का पता

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

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

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

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

यदि आपको दो स्रोतों की आवश्यकता है - कृपया डाउनलोड करें। मुख्य बात यह है कि विचारों में रूपांतरण के बाद इस डेटा आउटपुट का प्रारूप समान है।

लोड किए गए पते डेटाबेस के लिए एक और आवश्यकता यह थी कि इसके लिए बिंदु सुधार करना आवश्यक था। एक सरल उदाहरण: FIAS में, चुवाश गणराज्य को "चुवाश प्रतिनिधि कहा जाता है। - Chuvashia "। खैर, हम सिर्फ चुवाश गणराज्य चाहते हैं। हमें इस डैश की आवश्यकता क्यों है? और एक ही समय में, हम अभी भी स्रोतों से आवधिक अपडेट से बच नहीं सकते हैं।

यहाँ निम्नलिखित परतें हैं जो हमारे पास PostgreSQL में हैं।

बाईं ओर टेबल स्रोत से डाउनलोड किए गए कच्चे डेटा हैं।

उनके पीछे वे विचार हैं जो डेटा को एक मानक प्रारूप में परिवर्तित करते हैं।

स्थानीय ओवरराइडिंग - हमारे पास तालिकाओं का एक सेट है जो लोड किए गए पते डेटा की कुछ विशेषताओं को फिर से परिभाषित करता है। हमने यहां उदाहरण के लिए शामिल किया है, कि ऐसे पहचानकर्ता के साथ एक रिकॉर्ड "चुवाश प्रतिनिधि के बजाय प्राप्त करना चाहिए। - चुवाशिया ”हमारा चुना हुआ नाम है।

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

पता वस्तुओं - सभी सुधारों और परिवर्धन के साथ पता आधार बनाया।

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

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

मेरे पास यहां एक विशेष स्लाइड है, ऐसी डरावनी कहानी - हमें क्या करना होगा अगर हमने इसे PHP में बदलने के लिए मैन्युअल रूप से सब कुछ लिया: यानी, चेचन्या, चेचन गणराज्य, और इसलिए हर डेटा स्रोत के लिए - नरक नरक है।

जोड़: स्क्रीन पर - सेवा से वास्तविक कोड का एक टुकड़ा, जो वर्णित समाधानों के कारण अनावश्यक हो गया।

हमने इन समस्याओं को वर्गीकृत किया है।

1) समान वस्तुओं के समतुल्य नाम। उदाहरण के लिए, चुवाशिया और चुवाश गणराज्य जैसे सामान्य समानार्थक शब्द।

2) नाम दिया गया शहर। यूक्रेन अब कम्युनिस्ट अतीत से छुटकारा पाने के सक्रिय चरण में है, यही वजह है कि वे सचमुच हर दिन अपनी बस्तियों के नाम में बदलाव करते हैं। इस कारण से, यह पता चल सकता है कि एक डेटाबेस में हमारे पास पुराने नाम हैं, और दूसरे में - नए हैं।

3) बहुत सारी गलतियाँ। अक्सर बस्तियों की स्थिति में गलत। एक गाँव है, यहाँ एक गाँव है या यहाँ एक गाँव है, एक खेत है।

4) रूसी में अनुवादित विदेशी शब्द, अक्सर एक ही नाम विभिन्न तरीकों से अनुवादित होता है।

5) पदानुक्रम में कई त्रुटियां हैं: ज़ेलेनोग्राड, आदत से, मॉस्को क्षेत्र से संबंधित है, हालांकि औपचारिक रूप से यह मॉस्को में एक एफआईएएस के रूप में भी सूचीबद्ध है। सही ढंग से "मॉस्को शहर, ज़ेलनोग्राद" लिखें।

हम इसके साथ कैसे आए?

पहली चीज जो हम करते हैं, वह नाम से पते के सभी तुच्छ घटकों को अलग करती है। हम उन्हें दूर नहीं फेंकते हैं, वे खोज में भाग लेते हैं, लेकिन महत्वपूर्ण भागों से अलग।

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

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

हम टाइपो को सही करते हैं और लेआउट को ठीक करते हैं।

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

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

और हमें ऐसा खोज एप्लिकेशन कहां मिला?

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

हम नहीं रुकते। यह एक प्रक्रिया है जिसे हम अभी भी सुधार सकते हैं।

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

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

स्लाइड पर इंटरफ़ेस का एक टुकड़ा है जो आपको मैन्युअल रूप से क्षेत्र को कॉन्फ़िगर करने की अनुमति देता है, लेकिन वास्तव में सब कुछ स्ट्रिंग ऑब्जेक्ट के रूप में पता ऑब्जेक्ट की बैच-लोड की गई सूची से कॉन्फ़िगर किया गया है।

हमने घरों के लिए openstreetmap.org से जियो निर्देशांक डाउनलोड किए। अब, बड़े प्रतिशत मामलों में, स्थान का पता लगाने के लिए हमें किसी बाहरी सेवा में जाने की आवश्यकता नहीं है। इससे हमें यैंडेक्स की 10 गुना यात्राएं कम हो गईं, जिससे स्वाभाविक रूप से पैसे बच गए।

हमें पता डेटा के लिए खोज श्रृंखला में PHP से छुटकारा मिलता है। हमने उस कोड को फिर से लिखा है जो लुआ पर सोल्र तक पहुँचा था। ओपनरेस्टी के साथ बदला हुआ नगेंक्स , अब सब कुछ बहुत तेज है और भारी भार का सामना कर सकता है। हमारी खोज सेवा की प्रतिक्रियाओं का 95% 10 मिलीसेकंड में फिट होता है, जो हमारे लिए पर्याप्त से अधिक है।

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

निष्कर्ष

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