2.0.2 जारी, उपयोगकर्ताओं को जल्द ही रैली और 2.0.3

हमने यहां परीक्षण किया, बाइनरी पैकेज संकलित किए और स्फिंक्स 2.0.2-बीटा के संस्करण को अपलोड किया (यह वेबसाइटों के एक समूह पर इस्तेमाल किया जाने वाला एक ऐसा ओपन-सोर्स सर्च सर्वर है), जिसे दिसंबर-दिसंबर (क्रांतिकारी बदलाव) के लिए Sphinx 1.4.3-रिलीज़ , और रिलीज़ करने की योजना बनाई गई थी। हम सेंट पीटर्सबर्ग में 04 दिसंबर को स्फिंक्स उपयोगकर्ताओं की (मुफ्त) रैली पर भी कड़ी मेहनत कर रहे हैं। आपको लिंक के माध्यम से बैठक के लिए पंजीकरण करने की आवश्यकता है, हमारे संपर्क फ़ॉर्म के माध्यम से एक शांत रिपोर्ट सबमिट करें, और अगले रिलीज़ के लिए उन ~ 30 नई सुविधाओं और योजनाओं / शर्तों के बारे में कई विवरण और उनके चक्र में कटौती के तहत पढ़ा जा सकता है।

सुविधाओं के बारे में

यह स्पष्ट है कि उन 30 विशेषताओं में से अधिकांश बल्कि सुखद चीजें हैं। खैर, एक नया झंडा है, जिसमें ऐसी स्थिति में लॉग रिप्ले करने की क्षमता शामिल है, जहां किसी कारण से समय तेजी से उछलता है, सभी समूहों में फैले स्निपेट का समर्थन (और प्रत्येक मशीन पर कॉपी नहीं किया गया), 256 पाठ फ़ील्ड (32 नहीं) के लिए समर्थन करता है। एन। लेकिन फिर से कुछ टुकड़े हैं जिन्हें हम सामान्य रूप से अपेक्षाकृत बड़े और महत्वपूर्ण मानते हैं।

MVA64 विशेषताओं के लिए संलग्न समर्थन। "क्लासिक" एमवीए 32-बिट अहस्ताक्षरित मानों के एक बहुत हैं, नए एमवीए 64 क्रमशः, 64-बिट हस्ताक्षर वाले बहुत सारे हैं। मैं दो स्पष्ट अनुप्रयोगों को याद कर सकता हूं: क) टकराव की संभावना को खत्म करना, यदि सीआरवी 32 को एमवीए में लाइनों से बचाया गया था, तो बी) वहां कोई अतिरिक्त डेटा बचा है, लेकिन मुझे यकीन है कि आपको कई और कम स्पष्ट और अधिक दिलचस्प एप्लिकेशन मिलेंगे। MVA64 डिस्क और आरटी इंडेक्स दोनों में समर्थित हैं।

वैसे, एमवीए विशेषताओं को अब आरटी इंडेक्स और साथ ही index_exact_words में भी समर्थित किया गया है । सामान्य तौर पर, हम पहले से ही आरटी में अनुपस्थित सभी अवसरों को बहुत कम कर रहे हैं।

RT इंडेक्स में तानाशाही = कीवर्ड के लिए समर्थन । इसका मतलब यह है कि अब आरटी इंडेक्स में कीवर्ड्स (शब्द *) की शुरुआत से खोज होती है। Min_prefix_len, min_infix_len निर्देश जो कि डिस्क इंडेक्स में मौजूद थे, जो अग्रिम में सभी संभावित सबस्ट्रिंग को अनुक्रमित करते थे, हमने विशेष रूप से निर्णय नहीं लिया: यह हर जगह इंडेक्सिंग पर एक मजबूत हिट है, लेकिन डिस्क इंडेक्स के मामले में, यह (अपेक्षाकृत बड़ी) डिस्क पर हिट भी है, और आरटी के मामले में भी। अनमोल स्मृति, जिसकी हमेशा कमी रहती है। यदि मैं बार-बार सब्सट्रेटिंग खोजने के लिए डिस्क आवश्यकताओं को बढ़ाता हूं, तो मैं किसी भी तरह सहमत हूं, फिर कोई मेमोरी आवश्यकता नहीं है। खैर, तानाशाह = खोजशब्दों के आगमन के साथ, सबस्ट्रिंग की खोज संभव है, और स्मृति बरकरार है।

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

अद्यतन कथन अब WHERE में अधिक पूर्ण स्थितियों का समर्थन करता है । अब आप UPDATE myindex SET हटाए गए = 0 WHERE MATCH ('परीक्षण'), कुएं, या वहाँ जैसे प्रश्न कर सकते हैं ... जहाँ विक्रेता = 123। उन। शर्त के हिसाब से एक हज़ार का रिकॉर्ड बनाना आसान हो गया है। आईडी द्वारा कॉलम मानों के पिछले अद्यतन के साथ, यह नया अद्यतन नियमित और डिस्क दोनों अनुक्रमित में भी काम करता है।

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

अब आप कर सकते हैं। रैंकिंग सूत्र को कम से कम प्रत्येक व्यक्तिगत अनुरोध के लिए सेट किया जा सकता है। साथ ही, उपलब्ध रैंकिंग कारक काफी अधिक हो गए हैं। नए "स्क्रिप्ट योग्य" रैंक वाले सभी रैंकों का सफलतापूर्वक अनुकरण किया जाता है। प्रलेखन में उदाहरण हैं, यहाँ एक है:

$client->SetRankingMode(SPH_RANK_EXPR, "sum(lcs*user_weight)*1000+bm25");

हैरानी की बात यह है कि यह मेरी उम्मीद से ज्यादा तेज काम करता है। मुझे कई बार मंदी की उम्मीद थी, वास्तव में, 1,000,000 ब्लॉग पोस्ट के एक छोटे से परीक्षण संग्रह पर, मैं 1.1x से 1.3x बार तक मंदी का निरीक्षण करता हूं - यह संकलित सी ++ कोड की तुलना में है, जो इसके अलावा बहुत कम कारकों पर विचार करता है। मुझे लगता है कि यह बहुत अच्छा है।

विकास योजनाओं के बारे में

2.0.x शाखा अब जमी हुई है, वहाँ और अधिक सुविधाएँ नहीं होंगी, केवल बग फिक्स और नियमित रूप से इन बग फिक्स के साथ रिलीज। निकटतम एक को 1 महीने के बाद नियुक्त किया जाता है, फिर उसके बाद या तो 1-2 महीने के अंतराल के साथ घंटे के द्वारा (यदि पर्याप्त सुधार जमा होते हैं), या जैसे वे जमा होते हैं।

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

रिलीज के बारे में

सुविधाओं की विशेषताएं, उनके अलावा, हमने फिर से परीक्षण, कोडांतरण और रोलिंग आउट की आंतरिक प्रक्रियाओं को हिला दिया। ऐसा लगता है कि स्पर्श किया जा सकता है, इसलिए अगले संस्करण, 2.0.3-रिलीज़ को हमेशा की तरह, "जब यह तैयार हो जाए" - तो कॉल नहीं किया जाएगा, लेकिन 1 महीने के बाद, दिसंबर 2011 के मध्य में। यदि आपका बॉस निर्णायक रूप से इस तरह के टैग के बिना आदेश नहीं देता है, तो यहां वह एक महीने में हो जाएगा।

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

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

सम्मेलन के बारे में

सब कुछ नया, और पुराने के सही उपयोग के बारे में अधिक, और मुझे आशा है कि निकट भविष्य में अन्य चीजों का एक गुच्छा न केवल दुर्लभ ब्लॉग पोस्टों में पढ़ा जा सकता है, बल्कि एक उपयोगकर्ता सम्मेलन में लाइव भी सुन सकता है। हम दूसरी बार व्यवस्था कर रहे हैं, फिर भी स्वतंत्र हैं (मैंने पहली बार कुछ भी नहीं सिखाया !!!), लेकिन अब एक बदलाव के लिए, मास्को नहीं, बल्कि सेंट पीटर्सबर्ग, रविवार, 04 दिसंबर । पाठकों से जल्द से जल्द पंजीकरण करने का अनुरोध करें, लेखकों के लिए शर्मीली नहीं होने के लिए अनुरोध करें और हमें रिपोर्ट और / या बिजली की वार्ता के बारे में सुझाव भेजें।

सभी को नमस्कार, नई रिलीज़ और, उम्मीद है, सम्मेलन में लाइव बैठकें।