राज्य ड्यूमा ने ओपन बिल सर्च एपीआई लॉन्च किया

यह आलेख राज्य ड्यूमा की वेबसाइट (नवाचार 1 ) पर नवाचारों पर लेखों की एक श्रृंखला का दूसरा है।

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

एपीआई सुविधाएँ

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

आइए एपीआई द्वारा संसाधित खोज प्रश्नों के कुछ उदाहरण देखें:

• राज्य ड्यूमा Zhirinovsky के उपाध्यक्ष द्वारा प्रस्तावित बिलों को वी.वी.
• पुलिस पर बिल और उसमें संशोधन;
• रूसी संघ के अध्यक्ष द्वारा पेश किए गए बिल, वर्तमान में राज्य ड्यूमा की समितियों द्वारा विचार किए जाने की प्रतीक्षा कर रहे हैं।

इन प्रश्नों के लिए खोज परिणाम यहां पाया जा सकता है , और प्रलेखन में PHP के लिए स्रोत कोड।

एपीआई के साथ इंटरैक्शन रीस्ट आर्किटेक्चर शैली के अनुसार किया जाता है, अर्थात, HTTP प्रोटोकॉल का उपयोग किया जाता है, प्रतिक्रिया XML, JSON (JSONP सहित) और RSS प्रारूपों में जारी की जाती है। समर्थित स्वरूपों की एक विस्तृत श्रृंखला आपको विभिन्न स्थितियों में एपीआई लागू करने की अनुमति देती है। इसे सीधे जावास्क्रिप्ट ब्राउजर से एक्सेस किया जा सकता है। आप आवेदन के सर्वर पक्ष से या यहां तक ​​कि एक मोटे ग्राहक से अनुरोध भेज सकते हैं। और आप RSS के माध्यम से एक विशिष्ट खोज क्वेरी की सदस्यता ले सकते हैं, और नवीनतम जानकारी का सीधे पालन कर सकते हैं।

आंकड़े

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

सबसे पहले, खोज मापदंडों का उपयोग करने की आवृत्ति का विश्लेषण किया गया था (100 से अधिक प्रतिशत का योग, क्योंकि एक अनुरोध में कई मापदंडों का उपयोग किया जा सकता है)।



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

अब देखते हैं कि उपयोगकर्ता पेजेशन का उपयोग कैसे करते हैं।



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

अगला, हमने सॉर्ट प्रकार द्वारा प्रश्नों के वितरण की जांच की।



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

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



आप देख सकते हैं कि अनुरोधों को अक्सर पर्याप्त रूप से दोहराया जाता है, इसलिए कैशिंग उचित है।

और आंकड़ों के अंत में, TOP-10 खोज क्वेरी।



आंकड़ों को एकत्र करने के समय सबसे गर्म विषयों में से एक शिक्षा पर कानून था।

अनुकूलन

एपीआई के विकास के साथ, ड्राफ्ट लॉ डेटाबेस को Oracle से PostgreSQL में स्थानांतरित करने का कार्य भी था (ora2pg का उपयोग करके डेटा आयात किया गया था)। निम्नलिखित अनुकूलन विधियों को लागू किया गया था।

GIN इंडेक्स का उपयोग करके पोस्टग्रेएसक्यूएल की अंतर्निहित पूर्ण-पाठ खोज का उपयोग किया जाता है।

उन क्षेत्रों के लिए अनुक्रमित का निर्माण किया गया था जिनके लिए छंटाई उपलब्ध है, और उन लोगों के लिए जिनके लिए फ़िल्टरिंग सबसे अधिक बार किया जाता है।

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

 का चयन करें 
   x। * 
 से 
   (main_query) x
 कहां
   पंक्तिम् <= २०

यह सामान्य रूप से, सबसे सही तरीका नहीं था, लेकिन उपयोग किए गए संस्करण (Oracle 9i) में यह ठीक काम करता था। और जब दिखाना आवश्यक था, उदाहरण के लिए, 100 से शुरू होने वाली 20 लाइनें, निम्नलिखित निर्माण लागू किया गया था। इसमें, आंतरिक क्वेरी पहले 120 पंक्तियों का चयन करती है, और बाहरी केवल उनमें से अंतिम 20 को छोड़ता है।

 का चयन करें 
   * 
 से (
   का चयन करें 
     रोन्नम ए.एस. 
     x। * 
   से 
     (main_query) x
   कहां
     उपद्रवी <= 120)
 कहां
   xrownum> 100;

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

 का चयन करें
   *
 से
     ख
   शामिल हों
     एक
   पर
     b.a_id = a.id
 आदेश द्वारा
   b.value,
   b.id
 सीमा २०
 OFFSET 100;

                                            जल्दी योजना                                           
 -------------------------------------------------- ----------------------------------------------
  सीमा (लागत = 52.30..62.76 पंक्तियाँ = 20 चौड़ाई = 39)
    -> नेस्टेड लूप (लागत = 0.00..522980.13 पंक्तियाँ = 1,000,000 चौड़ाई = 39)
          -> बी (मूल्य = 0.00..242736.13 पंक्तियों = 1,000,000 चौड़ाई = 27) पर b_value_id_idx का उपयोग करके सूचकांक स्कैन करें)
          -> a (लागत = 0.00..0.27 पंक्तियों = 1 चौड़ाई = 12) पर a_pkey का उपयोग करके सूचकांक स्कैन करें।
                सूचकांक कंडोम: (a.id = b.a_id)

यानी यह सूचकांक b_value_id_idx से होकर गुजरता है, और तालिका b के प्रत्येक पाए गए रिकॉर्ड के लिए, तालिका के रिकॉर्ड्स a_pkey द्वारा जोड़े जाते हैं । इस तरह से पाए गए पहले 100 रिकॉर्ड को छोड़ दिया जाता है और अगले 20 को ले लिया जाता है। अब देखते हैं कि अगर हम टेबल पर b को लिमिट और OFFSET को लागू करते हैं तो क्या होता है। आप यहां पेज नेविगेशन के संगठन के बारे में अधिक पढ़ सकते हैं।

 का चयन करें
   *
 से
   (
     का चयन करें
       *
     से
       ख
     आदेश द्वारा
       b.value,
       b.id
     सीमा २०
     OFFSET 100
   ) बी
   शामिल हों
     एक
   पर
     b.a_id = a.id;

                                               जल्दी योजना                                              
 -------------------------------------------------- -------------------------------------------------- -
  हैश ज्वाइन (लागत = 29.44..49.39 पंक्तियाँ = 20 चौड़ाई = 60)
    हैश कांड: (a.id = public.b.a_id)
    -> एक स्कैन (लागत = 0.00..16.00 पंक्तियों पर = 1000 चौड़ाई = 12)
    -> हैश (लागत = 29.19..29.19 पंक्तियाँ = 20 चौड़ाई = 48)
          -> सीमा (लागत = 24.16..28.99 पंक्तियाँ = 20 चौड़ाई = 27)
                -> सूचकांक स्कैन b_value_id_idx का उपयोग कर b (लागत = 0.00..241620.14 पंक्तियों = 1,000,000 चौड़ाई = 27)

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

मेकिंग के उपयोग से कैशिंग क्वेरी परिणाम आयोजित किए जाते हैं। बिलों के लिए प्रत्येक खोज की विशेषता है:

• फ़िल्टर लागू किया गया
• छँटाई विधि
• पृष्ठ संख्या प्रदर्शित की गई।

दो प्रकार के कैश प्रदान किए गए थे:

• कुंजी सुपरइम्पोज़्ड फ़िल्टर का एक सेट है, और मूल्य संतोषजनक परिणामों की संख्या है।
• कुंजी लगाए गए फिल्टर का सेट है, सॉर्टिंग विधि और पृष्ठ संख्या (यानी सभी खोज पैरामीटर), और मूल्य बिलों की आईडी है।

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

डेटाबेस अनुकूलन ने 65 हजार खोज प्रश्नों के परीक्षण नमूने के प्रसंस्करण समय को 10 घंटे से 15 मिनट तक कम करने की अनुमति दी।

परिणाम

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

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