250 माइक्रोसेकंड में लड़की कैसे पाएं

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

4 से 30 मापदंडों के साथ 11 मिलियन प्रोफाइल के डेटाबेस में औसत खोज प्रत्येक औसत 3.5 मिलीसेकंड पर होती है। और एक ही समय में, खोज के अलावा, माम्बा डेमन-सेचर निम्नलिखित प्रदर्शन करता है, जिसमें काफी पारंपरिक कार्य शामिल नहीं हैं:

• प्रत्येक विशिष्ट प्रश्नावली के लिए खोज में अपना स्थान देता है (प्रत्येक उपयोगकर्ता, अपनी प्रोफ़ाइल में प्रवेश करते हुए, "आप खोज में Nth स्थान पर हैं" संदेश देखते हैं)
• प्राथमिक कुंजी द्वारा सूची से एक विशिष्ट प्रोफ़ाइल देता है
• निर्दिष्ट मापदंडों के अनुसार प्रोफ़ाइल के लिए एक सीधी खोज करता है

इस तथ्य के बावजूद कि शुरुआत से ही हमारी खोज अपने आप ही विकसित हुई थी, समय-समय पर पहले से ज्ञात, रन-इन और प्रभावी होने की गारंटी के लिए कुछ का उपयोग करने के विचार थे। खैर, अगर हम खोज के बारे में सोचते हैं, तो स्फिंक्स सबसे पहले दिमाग में आता है। कुछ बिंदु पर, हमने यह जांचने का फैसला किया कि क्या यह हमें गंभीर लाभ दे सकता है, और परिणामों पर कुछ आश्चर्यचकित थे। 2 मिलियन प्रश्नावली के परीक्षण आधार पर, स्फिंक्स ने अनुरोध के आधार पर 100-120 एमएस का औसत परिणाम दिखाया, जबकि हम (चूंकि यह अभी भी एक परीक्षण है) सूचकांक में खेतों के एक हिस्से को शामिल किया गया था। एक ही आधार पर और एक ही उपकरण पर हमारी खोज प्रति अनुरोध 0.2 से 1.1 एमएस तक खर्च होती है।

Sphinx: source - mysql, int sql_attr_uint. .

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

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

लेकिन मुख्य सूचकांक सामान्य सूचकांक के प्रत्येक भाग की संरचना में छिपे हुए हैं, जिनका निर्माण निम्नानुसार किया गया है:

• प्रोफाइल को प्रति ब्लॉक 256 प्रोफाइल के ब्लॉक में विभाजित किया गया है
• प्रत्येक ब्लॉक को सूचकांक में रखा गया है: पहला, प्रत्येक प्रश्नावली के पहले क्षेत्र का पहला बिट, फिर प्रत्येक प्रश्नावली से दूसरा बिट आदि। इस प्रकार, सभी प्रोफाइल के क्षेत्र से एक बिट का डेटा एक पंक्ति में जाता है।

खोज के लिए इसका क्या अर्थ है? उदाहरण के लिए, हमारे पास "लिंग" और "आयु" फ़ील्ड पर एक इंडेक्स है, जहां लिंग "एम" और "एफ" मान ले सकता है, और उम्र 18 से 21 तक हो सकती है। कल्पना करें कि उपयोगकर्ता 20 साल की लड़की को ढूंढना चाहता है (यानी) स्थितियाँ प्रत्येक क्षेत्र के केवल एक मूल्य को संतुष्ट करती हैं)।

मान लीजिए कि हमारे पास ऐसी प्रोफ़ाइल हैं (1 ब्लॉक दिखाया गया है, चूंकि न्यूनतम आयु 18 वर्ष है, फिर 18 वर्ष की आयु को 0000, 19 को 0010, 20 को 0100 के रूप में और इतने पर एन्कोडेड किया जाता है)



प्रसंस्करण के बाद, निम्नलिखित फॉर्म का एक इंडेक्स प्राप्त किया जाता है (पहला बिट बोल्ड में, पहले और बाद में प्रदर्शित होता है):



कुछ क्षेत्रों के लिए, मूल्य गैर-कॉम्पैक्ट रूप से संग्रहीत किया जाता है। उदाहरण के लिए, एक वास्तविक आयु क्षेत्र में 64 मान होते हैं। आप प्रति संभव मूल्य 1 बिट स्टोर कर सकते हैं, अर्थात फ़ील्ड 64 बिट्स लेगी, लेकिन खोज केवल 1 ऑपरेशन लेगी, और रेंज खोज 2 ऑपरेशन लेगी। एक अधिक पारंपरिक विकल्प इसे एक संख्या के रूप में संग्रहीत करना है, फिर यह log2 (64) = 6 बिट्स लेगा, लेकिन एक विशिष्ट आयु की खोज में 6 ऑपरेशन होंगे, और 12 से अधिक की सीमा की खोज (सटीक मान DNF के रूप में दर्ज की गई तुलना की लंबाई पर निर्भर करता है)।

खोज प्रक्रिया स्वयं इस प्रकार है:

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

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

अनुरोध निम्नानुसार संसाधित किया गया है:



उसके बाद, यह परिणाम के साथ बिटमैप के माध्यम से जाने के लिए ही रहता है और देखें कि किन प्रोफाइल में 1 है।

हमारे उदाहरण में, परिणाम 00010 होगा, अर्थात, केवल प्रोफ़ाइल नंबर 4 अनुरोध को पूरा करेगा।

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

वास्तविक खोज आँकड़े इस प्रकार हैं:


अंजीर। 1 आईडी प्रोफ़ाइल द्वारा खोज अनुरोध (एक सर्वर से ग्राफ)


अंजीर। 2 मापदंडों द्वारा खोज करने का अनुरोध (एक सर्वर से ग्राफ)

कुल मिलाकर, खोज दो मशीनों पर चलती है, एक का शिखर प्रदर्शन 20k प्रश्नावली खोज ऑपरेशन है, जो प्रति सेकंड पाई गई प्रोफाइल की संख्या की पूरी गणना के साथ पैरामीटर है (यह सबसे लंबा ऑपरेशन है, बाकी बहुत तेजी से काम करता है)। वर्कलोड - व्यक्तिगत डेटा प्राप्त करने के लिए लगभग 800 आरपीएस खोज + 1000 आरपीएस एक स्थान + 1500 आरपीएस प्राप्त करने के लिए।


अंजीर। 3 खोज परिणामों में प्रश्नावली के स्थान को प्रदर्शित करना (एक सर्वर से ग्राफ)


सभी (दो) खोज इंजनों से कुल प्रतिक्रिया समय का वितरण (यानी, खाता नेटवर्क इंटरैक्शन में लेना)। औसत 2.5 एमएस है, मध्यमा 1.5 एमएस है, 5% अनुरोध 10 से अधिक एमएस लेते हैं, और 1% अनुरोध 15 एमएस से अधिक लगते हैं।