Google Cloud Search इंडेक्स करने की सूची

Connector SDK और Google Cloud Search API की मदद से, Cloud Search इंडेक्सिंग कतारें बनाई जा सकती हैं. इनका इस्तेमाल ये काम करने के लिए किया जाता है:

• हर दस्तावेज़ की स्थिति (स्टेटस, हैश वैल्यू वगैरह) को बनाए रखें. इसका इस्तेमाल, अपने इंडेक्स को अपनी रिपॉज़िटरी के साथ सिंक करने के लिए किया जा सकता है.

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

• सामान की स्थिति के आधार पर, कतारों में मौजूद सामान को प्राथमिकता दें.

• बेहतर इंटिग्रेशन के लिए, स्थिति के बारे में अतिरिक्त जानकारी बनाए रखें. जैसे, चेकपॉइंट, बदलाव का टोकन वगैरह.

कतार, इंडेक्स किए गए आइटम को असाइन किया गया लेबल होता है. जैसे, डिफ़ॉल्ट कतार के लिए "डिफ़ॉल्ट" या कतार B के लिए "B".

स्थिति और प्राथमिकता

किसी दस्तावेज़ को प्राथमिकता के आधार पर, कतार में रखने का फ़ैसला उसके ItemStatus कोड के आधार पर किया जाता है. यहां प्राथमिकता के क्रम में ItemStatus कोड दिए गए हैं. इन्हें सबसे पहले से लेकर सबसे आखिर तक हैंडल किया जाता है:

• ERROR - इंडेक्सिंग की प्रोसेस के दौरान, आइटम में एसिंक्रोनस गड़बड़ी हुई है. इसलिए, इसे फिर से इंडेक्स करने की ज़रूरत है.

• MODIFIED - ऐसा आइटम जिसे पहले इंडेक्स किया गया था. हालांकि, पिछली बार इंडेक्स करने के बाद से, रिपॉज़िटरी में इसमें बदलाव किया गया है.

• NEW_ITEM - ऐसा आइटम जिसे इंडेक्स नहीं किया गया है.

• ACCEPTED - ऐसा दस्तावेज़ जिसे पहले इंडेक्स किया गया था और पिछली बार इंडेक्स किए जाने के बाद से, रिपॉज़िटरी में उसमें कोई बदलाव नहीं हुआ है.

जब किसी कतार में मौजूद दो आइटम का स्टेटस एक जैसा होता है, तो उन आइटम को ज़्यादा प्राथमिकता दी जाती है जो कतार में सबसे ज़्यादा समय से मौजूद हैं.

किसी नए या बदले गए आइटम को इंडेक्स करने के लिए, इंडेक्सिंग कतारों का इस्तेमाल करने के बारे में खास जानकारी

पहली इमेज में, इंडेक्सिंग की कतार का इस्तेमाल करके, नए या बदले गए आइटम को इंडेक्स करने का तरीका दिखाया गया है. इन चरणों में, REST API कॉल दिखाए गए हैं. एसडीके के बराबर कॉल के लिए, Queue operations (Connector SDK) पर जाएं.

1. कॉन्टेंट कनेक्टर, आइटम (मेटाडेटा और हैश) को इंडेक्सिंग की कतार में पुश करने के लिए items.push का इस्तेमाल करता है, ताकि आइटम की स्थिति (MODIFIED, NEW_ITEM, DELETED) का पता लगाया जा सके. खास तौर पर:

   • पुश करने के दौरान, कनेक्टर में पुश type या contentHash शामिल होता है.
   • अगर कनेक्टर में type शामिल नहीं है, तो Cloud Search आइटम की स्थिति का पता लगाने के लिए, contentHash का इस्तेमाल अपने-आप करता है.
   • अगर आइटम की जानकारी नहीं है, तो आइटम का स्टेटस NEW_ITEM पर सेट हो जाता है.
   • अगर आइटम मौजूद है और हैश वैल्यू मेल खाती हैं, तो स्टेटस को ACCEPTED के तौर पर सेट किया जाता है.
   • अगर आइटम मौजूद है और हैश अलग-अलग हैं, तो स्टेटस MODIFIED हो जाता है.

   किसी आइटम की स्थिति का पता कैसे लगाया जाता है, इस बारे में ज़्यादा जानने के लिए, Cloud Search का इस्तेमाल शुरू करने से जुड़े ट्यूटोरियल में GitHub रिपॉज़िटरी को ट्रैवर्स करने के सैंपल कोड पर जाएं.

   आम तौर पर, पुश करने की सुविधा, कनेक्टर में कॉन्टेंट ट्रैवर्सल और/या बदलाव का पता लगाने की प्रोसेस से जुड़ी होती है.

2. कॉन्टेंट कनेक्टर, इंडेक्स किए जाने वाले आइटम का पता लगाने के लिए, कतार को पोल करने के लिए items.poll का इस्तेमाल करता है. Cloud Search, कनेक्टर को बताता है कि किन आइटम को इंडेक्स करने की सबसे ज़्यादा ज़रूरत है. इन्हें सबसे पहले स्टेटस कोड के हिसाब से और फिर क्वेरी में लगने वाले समय के हिसाब से क्रम में लगाया जाता है.

3. कनेक्टर, इन आइटम को रिपॉज़िटरी से वापस पाता है और इंडेक्स एपीआई अनुरोध बनाता है.

4. कनेक्टर, आइटम को इंडेक्स करने के लिए items.index का इस्तेमाल करता है. Cloud Search, आइटम को प्रोसेस करने की प्रक्रिया पूरी करने के बाद ही, आइटम ACCEPTED स्थिति में पहुंचता है.

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

किसी आइटम को मिटाने के लिए इंडेक्सिंग कतारों का इस्तेमाल करने की खास जानकारी

पूरी तरह से ट्रैवर्स करने की रणनीति, आइटम को इंडेक्स करने और आइटम के हटाए जाने का पता लगाने के लिए, दो-कतार वाली प्रोसेस का इस्तेमाल करती है. दूसरी इमेज में, इंडेक्सिंग की दो कतारों का इस्तेमाल करके किसी आइटम को मिटाने का तरीका दिखाया गया है. खास तौर पर, दूसरी इमेज में फ़ुल-ट्रैवर्सल की रणनीति का इस्तेमाल करके, दूसरी ट्रैवर्सल प्रोसेस को दिखाया गया है. इन चरणों में, REST API कॉल का इस्तेमाल किया जाता है. एसडीके के मिलते-जुलते कॉल के लिए, Queue operations (Connector SDK) देखें.

1. शुरुआती ट्रैवर्सल पर, कॉन्टेंट कनेक्टर items.push का इस्तेमाल करके, आइटम (मेटाडेटा और हैश) को इंडेक्सिंग की कतार में डालता है. "कतार A" में NEW_ITEM के तौर पर, क्योंकि यह कतार में मौजूद नहीं है. हर आइटम को "A" लेबल असाइन किया गया है, जो "कतार A" के लिए है. कॉन्टेंट को Cloud Search में इंडेक्स किया जाता है.

2. कॉन्टेंट कनेक्टर, इंडेक्स किए जाने वाले आइटम का पता लगाने के लिए, items.poll का इस्तेमाल करके, क्यू ए को पोल करता है. Cloud Search, कनेक्टर को बताता है कि किन आइटम को इंडेक्स करने की सबसे ज़्यादा ज़रूरत है. इन्हें सबसे पहले स्टेटस कोड के हिसाब से और फिर क्वेरी में लगने वाले समय के हिसाब से क्रम में लगाया जाता है.

3. कनेक्टर, इन आइटम को रिपॉज़िटरी से वापस पाता है और इंडेक्स एपीआई अनुरोध बनाता है.

4. कनेक्टर, आइटम को इंडेक्स करने के लिए items.index का इस्तेमाल करता है. Cloud Search, आइटम को प्रोसेस करने की प्रक्रिया पूरी करने के बाद ही, आइटम ACCEPTED स्थिति में पहुंचता है.

5. deleteQueueItems तरीके को "queue B" पर कॉल किया जाता है. हालांकि, किसी भी आइटम को B वाली कतार में नहीं भेजा गया है. इसलिए, कुछ भी नहीं मिटाया जा सकता.

6. दूसरे फ़ुल ट्रैवर्सल में, कॉन्टेंट कनेक्टर, आइटम (मेटाडेटा और हैश) को B कतार में पुश करने के लिए, items.push का इस्तेमाल करता है:

   • पुश करने के दौरान, कनेक्टर में पुश type या contentHash शामिल होता है.
   • अगर कनेक्टर में type शामिल नहीं है, तो Cloud Search आइटम की स्थिति का पता लगाने के लिए, contentHash का इस्तेमाल अपने-आप करता है.
   • अगर आइटम की जानकारी नहीं है, तो आइटम का स्टेटस NEW_ITEM पर सेट हो जाता है. साथ ही, कतार का लेबल बदलकर "B" हो जाता है.
   • अगर आइटम मौजूद है और हैश वैल्यू मेल खाती हैं, तो स्टेटस को ACCEPTED के तौर पर सेट किया जाता है. साथ ही, कतार के लेबल को "B" में बदल दिया जाता है.
   • अगर आइटम मौजूद है और हैश अलग-अलग हैं, तो स्टेटस MODIFIED हो जाता है. साथ ही, कतार का लेबल बदलकर "B" हो जाता है.

7. कॉन्टेंट कनेक्टर, इंडेक्स किए जाने वाले आइटम का पता लगाने के लिए, कतार को पोल करने के लिए items.poll का इस्तेमाल करता है. Cloud Search, कनेक्टर को बताता है कि किन आइटम को इंडेक्स करने की सबसे ज़्यादा ज़रूरत है. इन्हें सबसे पहले स्टेटस कोड के हिसाब से और फिर क्वेरी में लगने वाले समय के हिसाब से क्रम में लगाया जाता है.

8. कनेक्टर, इन आइटम को रिपॉज़िटरी से वापस पाता है और इंडेक्स एपीआई अनुरोध बनाता है.

9. कनेक्टर, आइटम को इंडेक्स करने के लिए items.index का इस्तेमाल करता है. Cloud Search, आइटम को प्रोसेस करने की प्रक्रिया पूरी करने के बाद ही, आइटम ACCEPTED स्थिति में पहुंचता है.

10. आखिर में, deleteQueueItems को क्यू A पर कॉल किया जाता है, ताकि पहले से इंडेक्स किए गए उन सभी CCloud Search आइटम को मिटाया जा सके जिन पर अब भी क्यू "A" का लेबल लगा है.

11. इसके बाद, इंडेक्स करने के लिए इस्तेमाल की जाने वाली कतार और मिटाने के लिए इस्तेमाल की जाने वाली कतार को बदल दिया जाता है.

Queue operations (Connector SDK)

Content Connector SDK, आइटम को किसी कतार में पुश करने और कतार से आइटम खींचने के लिए ऑपरेशन उपलब्ध कराता है.

किसी आइटम को पैकेज करने और उसे किसी कतार में भेजने के लिए, pushItems बिल्डर क्लास का इस्तेमाल करें.

प्रोसेसिंग के लिए, किसी आइटम को क्यू से हटाने के लिए आपको कुछ भी करने की ज़रूरत नहीं है. इसके बजाय, SDK टूल, Repository क्लास के getDoc तरीके का इस्तेमाल करके, प्राथमिकता के क्रम में, क्यू से आइटम अपने-आप खींच लेता है.

कतार से जुड़ी कार्रवाइयां (REST API)

REST API, किसी क्यू में आइटम भेजने और उससे आइटम पाने के लिए, ये दो तरीके उपलब्ध कराता है:

• किसी आइटम को क्यू में भेजने के लिए, Items.push का इस्तेमाल करें.
• कतार में मौजूद आइटम को पोल करने के लिए, Items.poll का इस्तेमाल करें.

इंडेक्सिंग के दौरान आइटम को कतार में भेजने के लिए, Items.index का भी इस्तेमाल किया जा सकता है. इंडेक्सिंग के दौरान, जिन आइटम को कतार में रखा जाता है उनके लिए type की ज़रूरत नहीं होती. उन्हें ACCEPTED स्टेटस अपने-आप असाइन हो जाता है.

Items.push

Items.push मेथड, आईडी को सूची में जोड़ता है. इस तरीके को किसी खास type वैल्यू के साथ कॉल किया जा सकता है. इससे पुश ऑपरेशन का नतीजा तय होता है. type वैल्यू की सूची के लिए, Items.push तरीके में item.type फ़ील्ड देखें.

नया आईडी पुश करने पर, NEW_ITEM ItemStatus कोड के साथ एक नई एंट्री जुड़ जाती है.

वैकल्पिक पेलोड हमेशा सेव किया जाता है. इसे अपारदर्शी वैल्यू के तौर पर माना जाता है और Items.poll से वापस भेजा जाता है.

जब किसी आइटम के लिए पोल किया जाता है, तो उसे आरक्षित कर दिया जाता है. इसका मतलब है कि Items.poll को कॉल करके, उसे वापस नहीं लाया जा सकता. type को NOT_MODIFIED, REPOSITORY_ERROR या REQUEUE के तौर पर इस्तेमाल करके, Items.push के साथ इस्तेमाल करने पर, पोल की गई एंट्री को अनरिज़र्व किया जाता है. आरक्षित और बिना आरक्षित की गई एंट्री के बारे में ज़्यादा जानकारी के लिए, Items.poll सेक्शन देखें..

हैश के साथ Items.push

Google Cloud Search API, Items.index अनुरोधों पर मेटाडेटा और कॉन्टेंट हैश वैल्यू तय करने की सुविधा देता है. type तय करने के बजाय, मेटाडेटा और/या कॉन्टेंट हैश वैल्यू को पुश अनुरोध के साथ तय किया जा सकता है. Cloud Search इंडेक्सिंग की प्रोसेस में शामिल क्यू, दी गई हैश वैल्यू की तुलना, डेटा सोर्स में मौजूद आइटम की सेव की गई वैल्यू से करता है. अगर वैल्यू मेल नहीं खाती है, तो उस एंट्री को MODIFIED के तौर पर मार्क किया जाता है. अगर इंडेक्स में कोई मिलता-जुलता आइटम मौजूद नहीं है, तो स्थिति NEW_ITEM के तौर पर दिखेगी.

Items.poll

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

डिफ़ॉल्ट रूप से, प्राथमिकता के आधार पर, किसी भी सेक्शन की एंट्री वापस की जा सकती हैं. हर वापस लाई गई एंट्री रिज़र्व होती है. साथ ही, जब तक इनमें से कोई एक शर्त पूरी नहीं हो जाती, तब तक Items.poll को किए गए अन्य कॉल से इसे वापस नहीं लाया जाता:

• बुकिंग का समय खत्म हो जाता है.
• Items.index ने एंट्री को फिर से लाइन में लगा दिया है.
• Items.push को NOT_MODIFIED, REPOSITORY_ERROR या REQUEUE की type वैल्यू के साथ कॉल किया जाता है.