कॉन्टेंट कनेक्टर बनाना

कॉन्टेंट कनेक्टर एक सॉफ़्टवेयर प्रोग्राम है, जिसका इस्तेमाल किसी एंटरप्राइज़ के डेटा स्टोर करने की जगह में डेटा को ट्रैक करने और डेटा सोर्स को पॉप्युलेट करने के लिए किया जाता है. कॉन्टेंट कनेक्टर डेवलप करने के लिए, Google ये विकल्प देता है:

  • कॉन्टेंट कनेक्टर का SDK टूल. अगर आपको Java में प्रोग्रामिंग करना है, तो यह एक अच्छा विकल्प है. Content Connector SDK टूल, REST API के चारों ओर एक रैपर होता है. इसकी मदद से, तेज़ी से कनेक्टर बनाए जा सकते हैं. SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, Content Connector SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाएं लेख पढ़ें.

  • कम लेवल का REST API या एपीआई लाइब्रेरी. अगर Java में प्रोग्राम नहीं किया जा रहा है या आपके कोड बेस में किसी REST API या लाइब्रेरी को बेहतर तरीके से शामिल किया जाता है, तो इन विकल्पों का इस्तेमाल करें. REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने के लिए, REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाना देखें.

किसी सामान्य कॉन्टेंट कनेक्टर में ये काम किए जाते हैं:

  1. कॉन्फ़िगरेशन पैरामीटर को पढ़ता और उन्हें प्रोसेस करता है.
  2. यह तीसरे पक्ष के कॉन्टेंट स्टोर करने की जगह से, इंडेक्स किए जा सकने वाले डेटा के अलग-अलग हिस्सों को इकट्ठा करता है. इस डेटा को "items" कहा जाता है.
  3. यह ACL, मेटाडेटा, और कॉन्टेंट डेटा को इंडेक्स किए जा सकने वाले आइटम में जोड़ता है.
  4. आइटम को Cloud Search डेटा सोर्स में इंडेक्स करता है.
  5. (ज़रूरी नहीं) तीसरे पक्ष की कॉन्टेंट स्टोर करने की जगह से मिलने वाली सूचनाओं को बदलने के लिए सुनता है. बदलाव की सूचनाओं को इंडेक्स करने के अनुरोधों में बदल दिया जाता है, ताकि Cloud Search के डेटा सोर्स को तीसरे पक्ष के डेटा स्टोर करने की जगह के साथ सिंक रखा जा सके. कनेक्टर यह काम सिर्फ़ तब करता है, जब डेटा स्टोर करने की जगह में बदलाव का पता लगाने की सुविधा काम करती हो.

Content Connector SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाएं

यहां दिए गए सेक्शन में, कॉन्टेंट कनेक्टर SDK टूल का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने का तरीका बताया गया है.

डिपेंडेंसी सेट अप करें

SDK टूल का इस्तेमाल करने के लिए, आपको अपनी बिल्ड फ़ाइल में कुछ डिपेंडेंसी शामिल करनी होंगी. अपने बिल्ड एनवायरमेंट के लिए डिपेंडेंसी देखने के लिए, नीचे दिए गए टैब पर क्लिक करें:

Maven

<dependency>
<groupId>com.google.enterprise.cloudsearch</groupId>
<artifactId>google-cloudsearch-indexing-connector-sdk</artifactId>
<version>v1-0.0.3</version>
</dependency>

ग्रेडल

compile group: 'com.google.enterprise.cloudsearch',
        name: 'google-cloudsearch-indexing-connector-sdk',
        version: 'v1-0.0.3'

अपना कनेक्टर कॉन्फ़िगरेशन बनाएं

हर कनेक्टर की एक कॉन्फ़िगरेशन फ़ाइल होती है, जिसमें कनेक्टर इस्तेमाल किए जाने वाले पैरामीटर होते हैं. जैसे, डेटा स्टोर करने की जगह का आईडी. पैरामीटर को की-वैल्यू पेयर के तौर पर बताया जाता है, जैसे कि api.sourceId=1234567890abcdef.

Google Cloud Search SDK टूल में, Google की ओर से दिए गए कई कॉन्फ़िगरेशन पैरामीटर शामिल होते हैं. इनका इस्तेमाल सभी कनेक्टर करते हैं. आपको अपनी कॉन्फ़िगरेशन फ़ाइल में, Google से दिए गए इन पैरामीटर का एलान करना होगा:

  • कॉन्टेंट कनेक्टर के लिए, आपको api.sourceId और api.serviceAccountPrivateKeyFile के बारे में एलान करना होगा, क्योंकि ये पैरामीटर आपके डेटा स्टोर करने की जगह और डेटा स्टोर करने की जगह को ऐक्सेस करने के लिए ज़रूरी निजी कुंजी की जगह की पहचान करते हैं.
  • आइडेंटिटी कनेक्टर के लिए, आपको api.identitySourceId का एलान करना होगा, क्योंकि यह पैरामीटर आपके बाहरी आइडेंटिटी सोर्स की लोकेशन की पहचान करता है. उपयोगकर्ताओं को सिंक करने पर, आपको अपने एंटरप्राइज़ के Google Workspace खाते के लिए, api.customerId को यूनीक आईडी के तौर पर बताना होगा.

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

कॉन्फ़िगरेशन फ़ाइल में इस्तेमाल करने के लिए, डेटा स्टोर करने की जगह के हिसाब से बनाए गए पैरामीटर भी तय किए जा सकते हैं.

कॉन्फ़िगरेशन फ़ाइल को कनेक्टर में पास करें

कॉन्फ़िगरेशन फ़ाइल को अपने कनेक्टर में पास करने के लिए, सिस्टम प्रॉपर्टी config को सेट करें. कनेक्टर शुरू करते समय, -D आर्ग्युमेंट का इस्तेमाल करके प्रॉपर्टी को सेट किया जा सकता है. उदाहरण के लिए, यहां दिया गया निर्देश, कनेक्टर को MyConfig.properties कॉन्फ़िगरेशन फ़ाइल से शुरू करता है:

java -classpath myconnector.jar;... -Dconfig=MyConfig.properties MyConnector

अगर यह आर्ग्युमेंट मौजूद नहीं है, तो SDK टूल, connector-config.properties नाम की डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल को ऐक्सेस करने की कोशिश करता है.

अपनी ट्रैवर्सल रणनीति तय करें

कॉन्टेंट कनेक्टर का मुख्य काम, किसी रिपॉज़िटरी को खोजना और उसके डेटा को इंडेक्स करना होता है. आपको अपने रिपॉज़िटरी में डेटा के साइज़ और लेआउट के आधार पर एक ट्रैवर्सल रणनीति लागू करनी होगी. आपके पास अपनी ज़रूरत के हिसाब से रणनीति बनाने या SDK टूल में लागू की गई इन रणनीतियों में से किसी को चुनने का विकल्प होता है:

पूरी ट्रैवर्सल रणनीति

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

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

लिस्ट ट्रैवर्सल रणनीति

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

ट्रैवर्सल की यह रणनीति तब काम आती है, जब बदलाव का पता लगाना मुश्किल हो या जो डेटा स्टोर करने की जगह के साथ काम न करती हो, आपके पास बिना हैरारकी वाला डेटा हो, और जब बहुत बड़े डेटा सेट का इस्तेमाल किया जा रहा हो.

ग्राफ़ ट्रैवर्सल

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

अगर आपके पास कोई ऐसा हैरारकी है जिसे क्रॉल करने की ज़रूरत है, तो यह रणनीति आपके लिए सही है. जैसे, डायरेक्ट्री या वेब पेजों की सीरीज़.

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

टेंप्लेट क्लास का इस्तेमाल करके पूरा ट्रेवर्सल कनेक्टर बनाएं

दस्तावेज़ों का यह सेक्शन, FullTraversalSample उदाहरण से कोड स्निपेट के बारे में बताता है.

कनेक्टर का एंट्री पॉइंट लागू करें

कनेक्टर का एंट्री पॉइंट main() तरीका है. इस तरीके का मुख्य टास्क, Application क्लास का एक इंस्टेंस बनाना और कनेक्टर को चलाने के लिए, इसके start() तरीके को शुरू करना है.

application.start() को कॉल करने से पहले, FullTraversalConnector टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder क्लास का इस्तेमाल करें. FullTraversalConnector में Repository ऑब्जेक्ट को स्वीकार किया जाता है, जिसका तरीका लागू होता है. नीचे दिया गया कोड स्निपेट, main() तरीके को लागू करने का तरीका दिखाता है:

FullTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a full
 * traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new FullTraversalConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

ऐसा होने पर, SDK टूल initConfig() तरीके को तब कॉल करता है, जब आपके कनेक्टर main() तरीके को कॉल करते हैं Application.build. initConfig() तरीके से ये काम किए जाते हैं:

  1. यह पक्का करने के लिए कि Configuration शुरू नहीं हुआ है, Configuation.isInitialized() तरीके का इस्तेमाल करता है.
  2. Google से दिए गए की-वैल्यू पेयर के साथ, Configuration ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर, Configuration ऑब्जेक्ट में एक ConfigValue ऑब्जेक्ट में सेव होता है.

Repository इंटरफ़ेस को लागू करना

Repository ऑब्जेक्ट का मकसद, रिपॉज़िटरी आइटम का ट्रैवर्सल और इंडेक्स करना है. टेंप्लेट का इस्तेमाल करते समय, आपको कॉन्टेंट कनेक्टर बनाने के लिए, Repository इंटरफ़ेस में मौजूद कुछ तरीकों को ही बदलना होगा. आप जिन तरीकों को ओवरराइड करते हैं वे आपकी ओर से इस्तेमाल की जाने वाली टेंप्लेट और ट्रैवर्सल रणनीति पर निर्भर करते हैं. FullTraversalConnector के लिए, इन तरीकों को बदलें:

  • init() तरीका. डेटा रिपॉज़िटरी को सेट-अप करने और शुरू करने के लिए, init() तरीके को बदलें.

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

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

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

Repository ऑब्जेक्ट के हर तरीके से, किसी तरह का ApiOperation ऑब्जेक्ट दिखाया जाता है. कोई ApiOperation ऑब्जेक्ट, आपके रिपॉज़िटरी (डेटा स्टोर करने की जगह) को इंडेक्स करने के लिए, सिंगल या कई IndexingService.indexItem() कॉल के तौर पर कार्रवाई करता है.

कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं

अपने कनेक्टर के कॉन्फ़िगरेशन को मैनेज करने के दौरान, आपको Configuration ऑब्जेक्ट से कोई भी कस्टम पैरामीटर पाने की ज़रूरत होगी. आम तौर पर, यह टास्क Repository क्लास के init() तरीके से किया जाता है.

Configuration क्लास में कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके हैं. हर तरीका, ConfigValue ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू पाने के लिए, ConfigValue ऑब्जेक्ट के get() वाले तरीके का इस्तेमाल करना होगा. FullTraversalSample के नीचे दिए गए स्निपेट में, Configuration ऑब्जेक्ट से सिंगल कस्टम पूर्णांक वैल्यू पाने का तरीका बताया गया है:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration क्लास के टाइप पार्सर में से किसी एक का इस्तेमाल करें. ट्यूटोरियल कनेक्टर के इस स्निपेट में, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए, getMultiValue तरीके का इस्तेमाल किया गया है:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

पूरा ट्रैवर्सल परफ़ॉर्म करें

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

  1. अनुमतियां सेट करें.
  2. उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
  3. मेटाडेटा और आइटम को एक साथ इंडेक्स किया जा सकने वाला RepositoryDoc बनाएं.
  4. इंडेक्स किए जा सकने वाले हर आइटम को इटरेटर में पैकेज करें. इसके बाद, getAllDocs() तरीके का इस्तेमाल करें. ध्यान दें कि getAllDocs() असल में CheckpointCloseableIterable दिखाता है, जो ApiOperation ऑब्जेक्ट का इटरेशन है. इसमें हर ऑब्जेक्ट, RepositoryDoc पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि उसे इंडेक्स करना.

अगर कई आइटम का सेट एक कॉल में प्रोसेस करने के लिए बहुत बड़ा है, तो एक चेकपॉइंट शामिल करें और hasMore(true) सेट करें. इससे यह पता चलेगा कि इंडेक्स करने के लिए ज़्यादा आइटम उपलब्ध हैं.

किसी आइटम के लिए अनुमतियां सेट करना

आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करता है, ताकि उन उपयोगकर्ताओं या ग्रुप की पहचान की जा सके जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.

आपको डेटा स्टोर करने की जगह में इस्तेमाल किए जाने वाले ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि खोज के नतीजे में सिर्फ़ वे उपयोगकर्ता ही आइटम को देख सकें जिनके पास आइटम का ऐक्सेस है. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल (ACL) को शामिल करना ज़रूरी है. इससे Google Cloud Search को आइटम का सही लेवल ऐक्सेस देने के लिए ज़रूरी जानकारी मिल पाएगी.

Content Connector SDK टूल, डेटा स्टोर करने की ज़्यादातर जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट उपलब्ध कराता है. आपको डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर डेटा स्टोर करने की जगह का ACL, ACL इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल करता है, तो इसकी मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.

ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, सिंगल-डोमेन ACL काम करता है. इसमें क्रॉस-डोमेन ACL काम नहीं करते. ACL का इस्तेमाल करके हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder क्लास का इस्तेमाल करें. यह कोड स्निपेट, पूरे ट्रैवर्सल सैंपल से लिया गया है. इसकी मदद से, सभी उपयोगकर्ता या “प्रिंसिपल” (getCustomerPrincipal()), खोज करते समय सभी उपयोगकर्ताओं (.setReaders()) के तौर पर सभी आइटम को “पाठक” के तौर पर देख सकते हैं.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

डेटा स्टोर करने की जगह के लिए ACL को ठीक से मॉडल करने के लिए आपको ACL को समझना होगा. उदाहरण के लिए, मुमकिन है कि आपने ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स किया हो जिसमें किसी तरह के इनहेरिटेंस मॉडल का इस्तेमाल किया गया हो, जिसमें चाइल्ड फ़ोल्डर को पैरंट फ़ोल्डर की अनुमतियां मिलती हों. एसीएल इनहेरिटेंस को मॉडल करने के लिए Google Cloud Search ACL में शामिल अतिरिक्त जानकारी की ज़रूरत होती है

किसी आइटम के लिए मेटाडेटा सेट करना

मेटाडेटा को Item ऑब्जेक्ट में सेव किया जाता है. Item बनाने के लिए, आपके पास कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, ACL, यूआरएल, और आइटम का वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट यह दिखाता है कि IndexingItemBuilder हेल्पर क्लास का इस्तेमाल करके, Item कैसे बनाया जाता है.

FullTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Using the SDK item builder class to create the document with appropriate attributes
// (this can be expanded to include metadata fields etc.)
Item item = IndexingItemBuilder.fromConfiguration(Integer.toString(id))
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .build();

इंडेक्स किया जा सकने वाला आइटम बनाना

आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder क्लास का इस्तेमाल करके इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. नीचे दिए गए उदाहरण में, इंडेक्स किया जा सकने वाला एक आइटम बनाने का तरीका बताया गया है.

FullTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %d", id);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

// Create the fully formed document
RepositoryDoc doc = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT)
    .build();

RepositoryDoc एक तरह का ApiOperation है, जो असली IndexingService.indexItem() अनुरोध करता है.

इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS या SYNCHRONOUS के तौर पर करने के लिए, RepositoryDoc.Builder क्लास के setRequestMode() तरीके का इस्तेमाल भी किया जा सकता है:

ASYNCHRONOUS
एसिंक्रोनस मोड का इस्तेमाल करने पर, पेज को इंडेक्स करने में ज़्यादा समय लगता है. साथ ही, इसमें इंडेक्स करने के अनुरोधों के लिए, डेटा भेजने की प्रोसेस का ज़्यादा कोटा शामिल होता है. पूरे डेटा स्टोर करने की जगह के शुरुआती इंडेक्स (बैकफ़िल) के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
सिंक्रोनस मोड से, पेज को इंडेक्स करने में लगने वाला समय कम हो जाता है. साथ ही, इसमें सीमित थ्रूपुट कोटा कम होता है. अपडेट को इंडेक्स करने और डेटा स्टोर करने की जगह में बदलावों के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर इसके बारे में नहीं बताया जाता है, तो अनुरोध मोड डिफ़ॉल्ट रूप से SYNCHRONOUS पर सेट होता है.

इंडेक्स हो सकने वाले हर आइटम को इटरेटर में पैकेज करें

getAllDocs() इस तरीके से Iterator, खास तौर पर RepositoryDoc ऑब्जेक्ट के लिए CheckpointCloseableIterable ऑब्जेक्ट दिखाता है. इटरेटर बनाने और दिखाने के लिए, CheckpointClosableIterableImpl.Builder क्लास का इस्तेमाल किया जा सकता है. नीचे दिया गया कोड स्निपेट, इटरेटर बनाने और उन्हें वापस करने का तरीका बताता है.

FullTraversalSample.java
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(allDocs).build();

एसडीके, इटरेटर के अंदर मौजूद हर इंडेक्स कॉल को एक्ज़ीक्यूट करता है.

अगले चरण

यहां दिए गए कुछ तरीके आज़माएं:

टेंप्लेट क्लास का इस्तेमाल करके सूची ट्रैवर्सल कनेक्टर बनाएं

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

दस्तावेज़ों के इस सेक्शन में, ListTraversalSample के उदाहरण से मिले कोड स्निपेट के बारे में बताया गया है.

कनेक्टर का एंट्री पॉइंट लागू करें

कनेक्टर का एंट्री पॉइंट main() तरीका है. इस तरीके का मुख्य टास्क, Application क्लास का एक इंस्टेंस बनाना और कनेक्टर को चलाने के लिए, इसके start() तरीके को शुरू करना है.

application.start() को कॉल करने से पहले, ListingConnector टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder क्लास का इस्तेमाल करें. ListingConnector ऐसे Repository ऑब्जेक्ट को स्वीकार करता है जिसके तरीके लागू किए जाते हैं. नीचे दिया गया स्निपेट ListingConnector और उससे जुड़े Repository को तुरंत ट्रिगर करने का तरीका बताता है:

ListTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a
 * list traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new ListingConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

ऐसा होने पर, SDK टूल initConfig() तरीके को तब कॉल करता है, जब आपके कनेक्टर main() तरीके को कॉल करते हैं Application.build. initConfig() तरीका:

  1. यह पक्का करने के लिए कि Configuration शुरू नहीं हुआ है, Configuation.isInitialized() तरीके का इस्तेमाल करता है.
  2. Google से दिए गए की-वैल्यू पेयर के साथ, Configuration ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर, Configuration ऑब्जेक्ट में एक ConfigValue ऑब्जेक्ट में सेव होता है.

Repository इंटरफ़ेस को लागू करना

Repository ऑब्जेक्ट का मकसद, रिपॉज़िटरी आइटम का ट्रैवर्सल और इंडेक्स करना है. किसी टेंप्लेट का इस्तेमाल करते समय, आपको कॉन्टेंट कनेक्टर बनाने के लिएRepository इंटरफ़ेस में मौजूद कुछ खास तरीकों को ही बदलना होगा. आप जिन तरीकों को ओवरराइड करते हैं वे आपकी इस्तेमाल की जाने वाली टेंप्लेट और ट्रैवर्सल रणनीति पर निर्भर करते हैं. ListingConnector के लिए, ये तरीके बदलें:

  • init() तरीका. डेटा रिपॉज़िटरी को सेट-अप करने और शुरू करने के लिए, init() तरीके को बदलें.

  • getIds() तरीका. डेटा स्टोर करने की जगह में सभी रिकॉर्ड के लिए आईडी और हैश वैल्यू पाने के लिए, getIds() तरीके को बदलें.

  • getDoc() तरीका. इंडेक्स में नया आइटम जोड़ने, अपडेट करने, उसमें बदलाव करने या उसे मिटाने के लिए, getDoc() तरीका बदलें.

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

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

Repository ऑब्जेक्ट के हर तरीके से कुछ खास तरह का ApiOperation ऑब्जेक्ट दिखाया जाता है. कोई ApiOperation ऑब्जेक्ट, आपके रिपॉज़िटरी (डेटा स्टोर करने की जगह) को इंडेक्स करने के लिए, सिंगल या कई IndexingService.indexItem() कॉल के तौर पर कार्रवाई करता है.

कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं

अपने कनेक्टर के कॉन्फ़िगरेशन को मैनेज करने के दौरान, आपको Configuration ऑब्जेक्ट से कोई भी कस्टम पैरामीटर पाने की ज़रूरत होगी. आम तौर पर, यह टास्क Repository क्लास के init() तरीके से किया जाता है.

Configuration क्लास में कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके हैं. हर तरीका, ConfigValue ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू पाने के लिए, ConfigValue ऑब्जेक्ट के get() वाले तरीके का इस्तेमाल करना होगा. FullTraversalSample के नीचे दिए गए स्निपेट में, Configuration ऑब्जेक्ट से सिंगल कस्टम पूर्णांक वैल्यू पाने का तरीका बताया गया है:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration क्लास के टाइप पार्सर में से किसी एक का इस्तेमाल करें. ट्यूटोरियल कनेक्टर के इस स्निपेट में, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए, getMultiValue तरीके का इस्तेमाल किया गया है:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

लिस्ट ट्रैवर्सल परफ़ॉर्म करना

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

इसके बाद, Cloud Search इंडेक्स करने की सूची में मौजूद हर आइटम को मैनेज करने के लिए, getDoc() वाले तरीके को बदलें.

आइटम आईडी और हैश वैल्यू पुश करें

डेटा स्टोर करने की जगह से आइटम आईडी और उनसे जुड़े कॉन्टेंट की हैश वैल्यू फ़ेच करने के लिए, getIds() को बदलें. इसके बाद, आईडी और हैश वैल्यू के पेयर को, Cloud Search इंडेक्स करने के लिए मौजूद सूची में पुश ऑपरेशन के अनुरोध में पैकेज के तौर पर शामिल किया जाता है. आम तौर पर, रूट या पैरंट आईडी को सबसे पहले चाइल्ड आईडी के बाद भेजा जाता है. ऐसा तब तक होता है, जब तक आइटम की पूरी हैरारकी प्रोसेस नहीं हो जाती.

getIds() तरीके में, इंडेक्स किए जाने वाले आखिरी आइटम के लिए चेकपॉइंट स्वीकार किया जाता है. प्रोसेस में रुकावट आने पर, चेकपॉइंट का इस्तेमाल करके किसी खास आइटम को इंडेक्स करने की प्रोसेस फिर से शुरू की जा सकती है. डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए, getIds() तरीके में यह तरीका अपनाएं:

  • रिपॉज़िटरी से हर आइटम आईडी और उससे जुड़ी हैश वैल्यू पाएं.
  • हर आईडी और हैश वैल्यू के जोड़े को PushItems में पैकेज करें.
  • हर PushItems को इटरेटर के तौर पर जोड़ें. इसके लिए, getIds() वाले तरीके का इस्तेमाल करें. ध्यान दें कि getIds() असल में CheckpointCloseableIterable दिखाता है, जो ApiOperation ऑब्जेक्ट का इटरेशन कहलाता है. हर ऑब्जेक्ट, RepositoryDoc पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि आइटम को सूची में पुश करना.

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

ListTraversalSample.java
PushItems.Builder allIds = new PushItems.Builder();
for (Map.Entry<Integer, Long> entry : this.documents.entrySet()) {
  String documentId = Integer.toString(entry.getKey());
  String hash = this.calculateMetadataHash(entry.getKey());
  PushItem item = new PushItem().setMetadataHash(hash);
  log.info("Pushing " + documentId);
  allIds.addPushItem(documentId, item);
}

नीचे दिए गए कोड स्निपेट में, आईडी और हैश वैल्यू को एक ही पुश ApiOperation में पैकेज करने के लिए, PushItems.Builder क्लास का इस्तेमाल करने का तरीका बताया गया है.

ListTraversalSample.java
ApiOperation pushOperation = allIds.build();
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(
      Collections.singletonList(pushOperation))
  .build();
return iterator;

आगे की प्रोसेस के लिए, आइटम को Cloud Search की इंडेक्स करने वाली सूची में भेजा जाता है.

हर आइटम को वापस पाएं और मैनेज करें

Cloud Search इंडेक्स करने वाली सूची में मौजूद हर आइटम को मैनेज करने के लिए, getDoc() को बदलें. कोई आइटम नया हो सकता है, उसमें बदलाव किया जा सकता है, कोई बदलाव नहीं किया जा सकता या सोर्स डेटा स्टोर करने की जगह में अब मौजूद नहीं हो सकता. हर उस आइटम को वापस पाएं और इंडेक्स करें जिसमें बदलाव किया गया है या जो नया है. इंडेक्स से वे आइटम हटाएं जो अब सोर्स रिपॉज़िटरी में मौजूद नहीं हैं.

getDoc() वाला तरीका, Google Cloud Search की इंडेक्स करने वाली सूची से आइटम को स्वीकार करता है. सूची में मौजूद हर आइटम के लिए, getDoc() तरीका इस्तेमाल करके यह तरीका अपनाएं:

  1. देखें कि Cloud Search इंडेक्स करने वाली सूची में, आइटम का आईडी, डेटा स्टोर करने की जगह में मौजूद है या नहीं. अगर नहीं, तो आइटम को इंडेक्स से मिटा दें.

  2. आइटम की स्थिति के लिए इंडेक्स पोल करें. अगर आइटम में कोई बदलाव नहीं हुआ है (ACCEPTED), तो कुछ न करें.

  3. इंडेक्स में बदलाव किए गए या नए आइटम:

    1. अनुमतियां सेट करें.
    2. उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
    3. मेटाडेटा और आइटम को एक साथ इंडेक्स किया जा सकने वाला RepositoryDoc बनाएं.
    4. RepositoryDoc वापस करें.

ध्यान दें: ListingConnector टेंप्लेट, getDoc() तरीके पर null दिखाने की सुविधा नहीं देता. null फ़ंक्शन को NullPointerException. में नतीजे मिलते हैं

मिटाए गए आइटम मैनेज करना

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

ListTraversalSample.java
String resourceName = item.getName();
int documentId = Integer.parseInt(resourceName);

if (!documents.containsKey(documentId)) {
  // Document no longer exists -- delete it
  log.info(() -> String.format("Deleting document %s", item.getName()));
  return ApiOperations.deleteItem(resourceName);
}

ध्यान दें कि documents, रिपॉज़िटरी को दिखाने वाला डेटा स्ट्रक्चर है. अगर documents में documentID नहीं मिलता है, तो इंडेक्स से आइटम को मिटाने के लिए APIOperations.deleteItem(resourceName) वापस करें.

जिन आइटम में कोई बदलाव नहीं किया गया है उन्हें हैंडल करना

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

ListTraversalSample.java
String currentHash = this.calculateMetadataHash(documentId);
if (this.canSkipIndexing(item, currentHash)) {
  // Document neither modified nor deleted, ack the push
  log.info(() -> String.format("Document %s not modified", item.getName()));
  PushItem pushItem = new PushItem().setType("NOT_MODIFIED");
  return new PushItems.Builder().addPushItem(resourceName, pushItem).build();
}

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

ListTraversalSample.java
/**
 * Checks to see if an item is already up to date
 *
 * @param previousItem Polled item
 * @param currentHash  Metadata hash of the current github object
 * @return PushItem operation
 */
private boolean canSkipIndexing(Item previousItem, String currentHash) {
  if (previousItem.getStatus() == null || previousItem.getMetadata() == null) {
    return false;
  }
  String status = previousItem.getStatus().getCode();
  String previousHash = previousItem.getMetadata().getHash();
  return "ACCEPTED".equals(status)
      && previousHash != null
      && previousHash.equals(currentHash);
}

किसी आइटम के लिए अनुमतियां सेट करना

आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करता है, ताकि उन उपयोगकर्ताओं या ग्रुप की पहचान की जा सके जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.

आपको डेटा स्टोर करने की जगह में इस्तेमाल किए जाने वाले ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि खोज के नतीजे में सिर्फ़ वे उपयोगकर्ता ही आइटम को देख सकें जिनके पास आइटम का ऐक्सेस है. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल (ACL) को शामिल करना ज़रूरी है. इससे Google Cloud Search को आइटम का सही लेवल ऐक्सेस देने के लिए ज़रूरी जानकारी मिल पाएगी.

Content Connector SDK टूल, डेटा स्टोर करने की ज़्यादातर जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट उपलब्ध कराता है. आपको डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर डेटा स्टोर करने की जगह का ACL, ACL इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल करता है, तो इसकी मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.

ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, सिंगल-डोमेन ACL काम करता है. इसमें क्रॉस-डोमेन ACL काम नहीं करते. ACL का इस्तेमाल करके हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder क्लास का इस्तेमाल करें. यह कोड स्निपेट, पूरे ट्रैवर्सल सैंपल से लिया गया है. इसकी मदद से, सभी उपयोगकर्ता या “प्रिंसिपल” (getCustomerPrincipal()), खोज करते समय सभी उपयोगकर्ताओं (.setReaders()) के तौर पर सभी आइटम को “पाठक” के तौर पर देख सकते हैं.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

डेटा स्टोर करने की जगह के लिए ACL को ठीक से मॉडल करने के लिए आपको ACL को समझना होगा. उदाहरण के लिए, मुमकिन है कि आपने ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स किया हो जिसमें किसी तरह के इनहेरिटेंस मॉडल का इस्तेमाल किया गया हो, जिसमें चाइल्ड फ़ोल्डर को पैरंट फ़ोल्डर की अनुमतियां मिलती हों. एसीएल इनहेरिटेंस को मॉडल करने के लिए Google Cloud Search ACL में शामिल अतिरिक्त जानकारी की ज़रूरत होती है

किसी आइटम के लिए मेटाडेटा सेट करना

मेटाडेटा को Item ऑब्जेक्ट में सेव किया जाता है. Item बनाने के लिए, आपके पास कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, ACL, यूआरएल, और आइटम का वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट यह दिखाता है कि IndexingItemBuilder हेल्पर क्लास का इस्तेमाल करके, Item कैसे बनाया जाता है.

ListTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Set metadata hash so queue can detect changes
String metadataHash = this.calculateMetadataHash(documentId);

// Using the SDK item builder class to create the document with
// appropriate attributes. This can be expanded to include metadata
// fields etc.
Item item = IndexingItemBuilder.fromConfiguration(Integer.toString(documentId))
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .setHash(metadataHash)
    .build();

इंडेक्स किया जा सकने वाला आइटम बनाना

आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder का इस्तेमाल करके इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. नीचे दिए गए उदाहरण में, इंडेक्स किया जा सकने वाला एक आइटम बनाने का तरीका बताया गया है.

ListTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %d", documentId);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

// Create the fully formed document
RepositoryDoc doc = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT)
    .build();

RepositoryDoc एक तरह का ApiOperation है, जो असली IndexingService.indexItem() अनुरोध करता है.

इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS या SYNCHRONOUS के तौर पर करने के लिए, RepositoryDoc.Builder क्लास के setRequestMode() तरीके का इस्तेमाल भी किया जा सकता है:

ASYNCHRONOUS
एसिंक्रोनस मोड का इस्तेमाल करने पर, पेज को इंडेक्स करने में ज़्यादा समय लगता है. साथ ही, इसमें इंडेक्स करने के अनुरोधों के लिए, डेटा भेजने की प्रोसेस का ज़्यादा कोटा शामिल होता है. पूरे डेटा स्टोर करने की जगह के शुरुआती इंडेक्स (बैकफ़िल) के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
सिंक्रोनस मोड से, पेज को इंडेक्स करने में लगने वाला समय कम हो जाता है. साथ ही, इसमें सीमित थ्रूपुट कोटा कम होता है. अपडेट को इंडेक्स करने और डेटा स्टोर करने की जगह में बदलावों के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर इसके बारे में नहीं बताया जाता है, तो अनुरोध मोड डिफ़ॉल्ट रूप से SYNCHRONOUS पर सेट होता है.

अगले चरण

यहां दिए गए कुछ तरीके आज़माएं:

  • (ज़रूरी नहीं) close() तरीका लागू करें, ताकि सेवा बंद होने से पहले किसी भी संसाधन को रिलीज़ किया जा सके.
  • (ज़रूरी नहीं) Content Connector SDK टूल का इस्तेमाल करके पहचान कनेक्टर बनाएं.

टेंप्लेट क्लास का इस्तेमाल करके ग्राफ़ ट्रैवर्सल कनेक्टर बनाना

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

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

दस्तावेज़ों के इस सेक्शन में, GraphTraversalSample के उदाहरण से मिले कोड स्निपेट के बारे में बताया गया है.

कनेक्टर का एंट्री पॉइंट लागू करें

कनेक्टर का एंट्री पॉइंट main() तरीका है. इस तरीके का मुख्य टास्क, Application क्लास का एक इंस्टेंस बनाना और कनेक्टर को चलाने के लिए, इसके start() तरीके को शुरू करना है.

application.start() को कॉल करने से पहले, ListingConnector टेंप्लेट को इंस्टैंशिएट करने के लिए, IndexingApplication.Builder क्लास का इस्तेमाल करें. ListingConnector में Repository ऑब्जेक्ट को स्वीकार किया जाता है, जिसका तरीका लागू होता है.

नीचे दिया गया स्निपेट ListingConnector और उससे जुड़े Repository को तुरंत ट्रिगर करने का तरीका बताता है:

GraphTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a graph
 * traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new ListingConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

ऐसा होने पर, SDK टूल initConfig() तरीके को तब कॉल करता है, जब आपके कनेक्टर main() तरीके को कॉल करते हैं Application.build. initConfig() तरीका:

  1. यह पक्का करने के लिए कि Configuration शुरू नहीं हुआ है, Configuation.isInitialized() तरीके का इस्तेमाल करता है.
  2. Google से दिए गए की-वैल्यू पेयर के साथ, Configuration ऑब्जेक्ट को शुरू करता है. हर की-वैल्यू पेयर, Configuration ऑब्जेक्ट में एक ConfigValue ऑब्जेक्ट में सेव होता है.

Repository इंटरफ़ेस को लागू करना

Repository ऑब्जेक्ट का सिर्फ़ एक ही मकसद है, रिपॉज़िटरी आइटम का ट्रैवर्सल और इंडेक्स करना. किसी टेंप्लेट का इस्तेमाल करते समय, आपको कॉन्टेंट कनेक्टर बनाने के लिए Repository इंटरफ़ेस में मौजूद कुछ खास तरीकों को ही बदलना होगा. ओवरराइड करने के तरीके, इस्तेमाल किए जाने वाले टेंप्लेट और ट्रैवर्सल रणनीति पर निर्भर करते हैं. ListingConnector के लिए, इन तरीकों को बदला जा सकता है:

  • init() तरीका. डेटा रिपॉज़िटरी को सेट-अप करने और शुरू करने के लिए, init() तरीके को बदलें.

  • getIds() तरीका. डेटा स्टोर करने की जगह में सभी रिकॉर्ड के लिए आईडी और हैश वैल्यू पाने के लिए, getIds() तरीके को बदलें.

  • getDoc() तरीका. इंडेक्स में नया आइटम जोड़ने, अपडेट करने, उसमें बदलाव करने या उसे मिटाने के लिए, getDoc() तरीका बदलें.

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

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

Repository ऑब्जेक्ट के हर तरीके से, कुछ तरह का ApiOperation ऑब्जेक्ट दिखाया जाता है. कोई ApiOperation ऑब्जेक्ट, आपके रिपॉज़िटरी (डेटा स्टोर करने की जगह) को इंडेक्स करने के लिए, सिंगल या कई IndexingService.indexItem() कॉल के रूप में कार्रवाई करता है.

कस्टम कॉन्फ़िगरेशन पैरामीटर पाएं

अपने कनेक्टर के कॉन्फ़िगरेशन को मैनेज करने के दौरान, आपको Configuration ऑब्जेक्ट से कोई भी कस्टम पैरामीटर पाने की ज़रूरत होगी. आम तौर पर, यह टास्क Repository क्लास के init() तरीके से किया जाता है.

Configuration क्लास में कॉन्फ़िगरेशन से अलग-अलग तरह का डेटा पाने के कई तरीके हैं. हर तरीका, ConfigValue ऑब्जेक्ट दिखाता है. इसके बाद, असल वैल्यू पाने के लिए, ConfigValue ऑब्जेक्ट के get() वाले तरीके का इस्तेमाल करना होगा. FullTraversalSample के नीचे दिए गए स्निपेट में, Configuration ऑब्जेक्ट से सिंगल कस्टम पूर्णांक वैल्यू पाने का तरीका बताया गया है:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

कई वैल्यू वाला पैरामीटर पाने और पार्स करने के लिए, डेटा को अलग-अलग हिस्सों में पार्स करने के लिए, Configuration क्लास के टाइप पार्सर में से किसी एक का इस्तेमाल करें. ट्यूटोरियल कनेक्टर के इस स्निपेट में, GitHub रिपॉज़िटरी के नामों की सूची पाने के लिए, getMultiValue तरीके का इस्तेमाल किया गया है:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

ग्राफ़ ट्रैवर्सल चलाएं

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

इसके बाद, Cloud Search इंडेक्स करने की सूची में मौजूद हर आइटम को मैनेज करने के लिए, getDoc() वाले तरीके को बदलें.

आइटम आईडी और हैश वैल्यू पुश करें

डेटा स्टोर करने की जगह से आइटम आईडी और उनसे जुड़े कॉन्टेंट की हैश वैल्यू फ़ेच करने के लिए, getIds() को बदलें. इसके बाद, आईडी और हैश वैल्यू के पेयर को, Cloud Search इंडेक्स करने के लिए मौजूद सूची में पुश ऑपरेशन के अनुरोध में पैकेज के तौर पर शामिल किया जाता है. आम तौर पर, रूट या पैरंट आईडी को सबसे पहले चाइल्ड आईडी के बाद भेजा जाता है. ऐसा तब तक होता है, जब तक आइटम की पूरी हैरारकी प्रोसेस नहीं हो जाती.

getIds() तरीके में, इंडेक्स किए जाने वाले आखिरी आइटम के लिए चेकपॉइंट स्वीकार किया जाता है. प्रोसेस में रुकावट आने पर, चेकपॉइंट का इस्तेमाल करके किसी खास आइटम को इंडेक्स करने की प्रोसेस फिर से शुरू की जा सकती है. डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए, getIds() तरीके में यह तरीका अपनाएं:

  • रिपॉज़िटरी से हर आइटम आईडी और उससे जुड़ी हैश वैल्यू पाएं.
  • हर आईडी और हैश वैल्यू के जोड़े को PushItems में पैकेज करें.
  • हर PushItems को इटरेटर में जोड़ें. इसके बाद, getIds() तरीके का इस्तेमाल किया जाएगा. ध्यान दें कि getIds() असल में CheckpointCloseableIterable दिखाता है, जो ApiOperation ऑब्जेक्ट का इटरेशन कहलाता है. हर ऑब्जेक्ट, RepositoryDoc पर किए गए एपीआई अनुरोध को दिखाता है, जैसे कि आइटम को सूची में पुश करना.

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

GraphTraversalSample.java
PushItems.Builder allIds = new PushItems.Builder();
PushItem item = new PushItem();
allIds.addPushItem("root", item);

यह कोड स्निपेट एक ही पुश ApiOperation में, आईडी और हैश वैल्यू को पैकेज करने के लिए, PushItems.Builder क्लास का इस्तेमाल करने का तरीका बताता है.

GraphTraversalSample.java
ApiOperation pushOperation = allIds.build();
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(
      Collections.singletonList(pushOperation))
  .build();

आगे की प्रोसेस के लिए, आइटम को Cloud Search की इंडेक्स करने वाली सूची में भेजा जाता है.

हर आइटम को वापस पाएं और मैनेज करें

Cloud Search इंडेक्स करने वाली सूची में मौजूद हर आइटम को मैनेज करने के लिए, getDoc() को बदलें. कोई आइटम नया हो सकता है, उसमें बदलाव किया जा सकता है, कोई बदलाव नहीं किया जा सकता या सोर्स डेटा स्टोर करने की जगह में अब मौजूद नहीं हो सकता. हर उस आइटम को वापस पाएं और इंडेक्स करें जिसमें बदलाव किया गया है या जो नया है. इंडेक्स से वे आइटम हटाएं जो अब सोर्स रिपॉज़िटरी में मौजूद नहीं हैं.

getDoc() वाला तरीका, Cloud Search इंडेक्स करने वाली सूची से आइटम को स्वीकार करता है. सूची में मौजूद हर आइटम के लिए, getDoc() तरीका इस्तेमाल करके यह तरीका अपनाएं:

  1. देखें कि Cloud Search इंडेक्स करने वाली सूची में, आइटम का आईडी, डेटा स्टोर करने की जगह में मौजूद है या नहीं. अगर नहीं, तो आइटम को इंडेक्स से मिटा दें. अगर आइटम मौजूद है, तो अगले चरण पर जाएं.

  2. इंडेक्स में बदलाव किए गए या नए आइटम:

    1. अनुमतियां सेट करें.
    2. उस आइटम के लिए मेटाडेटा सेट करें जिसे इंडेक्स किया जा रहा है.
    3. मेटाडेटा और आइटम को एक साथ इंडेक्स किया जा सकने वाला RepositoryDoc बनाएं.
    4. आगे की प्रक्रिया के लिए, चाइल्ड आईडी को Cloud Search की इंडेक्स करने वाली सूची में रखें.
    5. RepositoryDoc वापस करें.

मिटाए गए आइटम मैनेज करना

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

GraphTraversalSample.java
String resourceName = item.getName();
if (documentExists(resourceName)) {
  return buildDocumentAndChildren(resourceName);
}
// Document doesn't exist, delete it
log.info(() -> String.format("Deleting document %s", resourceName));
return ApiOperations.deleteItem(resourceName);

किसी आइटम के लिए अनुमतियां सेट करना

आपका रिपॉज़िटरी, ऐक्सेस कंट्रोल लिस्ट (एसीएल) का इस्तेमाल करता है, ताकि उन उपयोगकर्ताओं या ग्रुप की पहचान की जा सके जिनके पास किसी आइटम का ऐक्सेस है. एसीएल, उन ग्रुप या उपयोगकर्ताओं के आईडी की सूची होती है जो आइटम को ऐक्सेस कर सकते हैं.

आपको डेटा स्टोर करने की जगह में इस्तेमाल किए जाने वाले ACL का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि खोज के नतीजे में सिर्फ़ वे उपयोगकर्ता ही आइटम को देख सकें जिनके पास आइटम का ऐक्सेस है. किसी आइटम को इंडेक्स करते समय, उसके लिए एसीएल (ACL) को शामिल करना ज़रूरी है. इससे Google Cloud Search को आइटम का सही लेवल ऐक्सेस देने के लिए ज़रूरी जानकारी मिल पाएगी.

Content Connector SDK टूल, डेटा स्टोर करने की ज़्यादातर जगहों के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का एक रिच सेट उपलब्ध कराता है. आपको डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए एसीएल का विश्लेषण करना होगा. साथ ही, किसी आइटम को इंडेक्स करते समय, Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर डेटा स्टोर करने की जगह का ACL, ACL इनहेरिटेंस जैसे कॉन्सेप्ट का इस्तेमाल करता है, तो इसकी मॉडलिंग करना मुश्किल हो सकता है. Google Cloud Search ACL के बारे में ज़्यादा जानकारी के लिए, Google Cloud Search ACL देखें.

ध्यान दें: Cloud Search इंडेक्स करने वाला एपीआई, सिंगल-डोमेन ACL काम करता है. इसमें क्रॉस-डोमेन ACL काम नहीं करते. ACL का इस्तेमाल करके हर आइटम का ऐक्सेस सेट करने के लिए, Acl.Builder क्लास का इस्तेमाल करें. यह कोड स्निपेट, पूरे ट्रैवर्सल सैंपल से लिया गया है. इसकी मदद से, सभी उपयोगकर्ता या “प्रिंसिपल” (getCustomerPrincipal()), खोज करते समय सभी उपयोगकर्ताओं (.setReaders()) के तौर पर सभी आइटम को “पाठक” के तौर पर देख सकते हैं.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

डेटा स्टोर करने की जगह के लिए ACL को ठीक से मॉडल करने के लिए आपको ACL को समझना होगा. उदाहरण के लिए, मुमकिन है कि आपने ऐसे फ़ाइल सिस्टम में फ़ाइलों को इंडेक्स किया हो जिसमें किसी तरह के इनहेरिटेंस मॉडल का इस्तेमाल किया गया हो, जिसमें चाइल्ड फ़ोल्डर को पैरंट फ़ोल्डर की अनुमतियां मिलती हों. एसीएल इनहेरिटेंस को मॉडल करने के लिए Google Cloud Search ACL में शामिल अतिरिक्त जानकारी की ज़रूरत होती है

किसी आइटम के लिए मेटाडेटा सेट करना

मेटाडेटा को Item ऑब्जेक्ट में सेव किया जाता है. Item बनाने के लिए, आपके पास कम से कम एक यूनीक स्ट्रिंग आईडी, आइटम टाइप, ACL, यूआरएल, और आइटम का वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट यह दिखाता है कि IndexingItemBuilder हेल्पर क्लास का इस्तेमाल करके, Item कैसे बनाया जाता है.

GraphTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Using the SDK item builder class to create the document with
// appropriate attributes. This can be expanded to include metadata
// fields etc.
Item item = IndexingItemBuilder.fromConfiguration(documentId)
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .build();

इंडेक्स किया जा सकने वाला आइटम बनाना

आइटम के लिए मेटाडेटा सेट करने के बाद, RepositoryDoc.Builder का इस्तेमाल करके इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. नीचे दिए गए उदाहरण में, इंडेक्स किया जा सकने वाला एक आइटम बनाने का तरीका बताया गया है.

GraphTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %s", documentId);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

RepositoryDoc.Builder docBuilder = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT);

RepositoryDoc एक तरह का ApiOperation है, जो असली IndexingService.indexItem() अनुरोध करता है.

इंडेक्स करने के अनुरोध की पहचान ASYNCHRONOUS या SYNCHRONOUS के तौर पर करने के लिए, RepositoryDoc.Builder क्लास के setRequestMode() तरीके का इस्तेमाल भी किया जा सकता है:

ASYNCHRONOUS
एसिंक्रोनस मोड का इस्तेमाल करने पर, पेज को इंडेक्स करने में ज़्यादा समय लगता है. साथ ही, इसमें इंडेक्स करने के अनुरोधों के लिए, डेटा भेजने की प्रोसेस का ज़्यादा कोटा शामिल होता है. पूरे डेटा स्टोर करने की जगह के शुरुआती इंडेक्स (बैकफ़िल) के लिए, एसिंक्रोनस मोड का सुझाव दिया जाता है.
SYNCHRONOUS
सिंक्रोनस मोड से, पेज को इंडेक्स करने में लगने वाला समय कम हो जाता है. साथ ही, इसमें सीमित थ्रूपुट कोटा कम होता है. अपडेट को इंडेक्स करने और डेटा स्टोर करने की जगह में बदलावों के लिए, सिंक्रोनस मोड का सुझाव दिया जाता है. अगर इसके बारे में नहीं बताया जाता है, तो अनुरोध मोड डिफ़ॉल्ट रूप से SYNCHRONOUS पर सेट होता है.

चाइल्ड आईडी को Cloud Search इंडेक्स करने वाली सूची में डालना

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

GraphTraversalSample.java
// Queue the child nodes to visit after indexing this document
Set<String> childIds = getChildItemNames(documentId);
for (String id : childIds) {
  log.info(() -> String.format("Pushing child node %s", id));
  PushItem pushItem = new PushItem();
  docBuilder.addChildId(id, pushItem);
}

RepositoryDoc doc = docBuilder.build();

अगले चरण

यहां दिए गए कुछ तरीके आज़माएं:

  • (ज़रूरी नहीं) close() तरीका लागू करें, ताकि सेवा बंद होने से पहले किसी भी संसाधन को रिलीज़ किया जा सके.
  • (ज़रूरी नहीं) Identity Connector SDK टूल का इस्तेमाल करके पहचान कनेक्टर बनाएं.

REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाएं

इन सेक्शन में, REST API का इस्तेमाल करके कॉन्टेंट कनेक्टर बनाने का तरीका बताया गया है.

अपनी ट्रैवर्सल रणनीति तय करें

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

पूरी ट्रैवर्सल रणनीति

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

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

लिस्ट ट्रैवर्सल रणनीति

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

ट्रैवर्सल की यह रणनीति तब काम आती है, जब बदलाव का पता लगाना मुश्किल हो या जो डेटा स्टोर करने की जगह के साथ काम न करती हो, आपके पास बिना हैरारकी वाला डेटा हो, और जब बहुत बड़े डेटा सेट का इस्तेमाल किया जा रहा हो.

ग्राफ़ ट्रैवर्सल

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

अगर आपके पास ऐसी हैरारकी वाला डेटा है जिसे क्रॉल करने की ज़रूरत है, तो यह रणनीति आपके लिए सही है. जैसे, सीरीज़ डायरेक्ट्री या वेब पेज.

अपनी ट्रैवर्सल रणनीति और इंडेक्स आइटम लागू करें

Cloud Search के लिए इंडेक्स किए जा सकने वाले हर एलिमेंट को Cloud Search API में एक आइटम कहा जाता है. आइटम कोई फ़ाइल, फ़ोल्डर, CSV फ़ाइल की कोई लाइन या डेटाबेस रिकॉर्ड हो सकता है.

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

  1. (ज़रूरी नहीं) items.upload का इस्तेमाल करके, इंडेक्स करने के लिए 100KiB से बड़ी फ़ाइलों को अपलोड करें. छोटी फ़ाइलों के लिए, items.index का इस्तेमाल करके कॉन्टेंट को inlineContent के तौर पर एम्बेड करें.

  2. (ज़रूरी नहीं) इंडेक्स करने के लिए मीडिया फ़ाइलें अपलोड करने के लिए, media.upload का इस्तेमाल करें.

  3. आइटम को इंडेक्स करने के लिए, items.index का इस्तेमाल किया जा रहा है. उदाहरण के लिए, अगर आपका स्कीमा मूवी स्कीमा में दिए गए ऑब्जेक्ट की परिभाषा का इस्तेमाल करता है, तो किसी एक आइटम को इंडेक्स करने का अनुरोध ऐसा दिखेगा:

    {
  "name": "datasource/<data_source_id>/items/titanic",
  "acl": {
    "readers": [
      {
        "gsuitePrincipal": {
          "gsuiteDomain": true
        }
      }
    ]
  },
  "metadata": {
    "title": "Titanic",
    "viewUrl": "http://www.imdb.com/title/tt2234155/?ref_=nv_sr_1",
    "objectType": "movie"
  },
  "structuredData": {
    "object": {
      "properties": [
        {
          "name": "movieTitle",
          "textValues": {
            "values": [
              "Titanic"
            ]
          }
        },
        {
          "name": "releaseDate",
          "dateValues": {
            "values": [
              {
                "year": 1997,
                "month": 12,
                "day": 19
              }
            ]
          }
        },
        {
          "name": "actorName",
          "textValues": {
            "values": [
              "Leonardo DiCaprio",
              "Kate Winslet",
              "Billy Zane"
            ]
          }
        },
        {
          "name": "genre",
          "enumValues": {
            "values": [
              "Drama",
              "Action"
            ]
          }
        },
        {
          "name": "userRating",
          "integerValues": {
            "values": [
              8
            ]
          }
        },
        {
          "name": "mpaaRating",
          "textValues": {
            "values": [
              "PG-13"
            ]
          }
        },
        {
          "name": "duration",
          "textValues": {
            "values": [
              "3 h 14 min"
            ]
          }
        }
      ]
    }
  },
  "content": {
    "inlineContent": "A seventeen-year-old aristocrat falls in love with a kind but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.",
    "contentFormat": "TEXT"
  },
  "version": "01",
  "itemType": "CONTENT_ITEM"
}

  4. (ज़रूरी नहीं) items.get कॉल का इस्तेमाल करके पुष्टि करें कि किसी आइटम को इंडेक्स किया गया है.

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

डेटा स्टोर करने की जगह में किए गए बदलावों को मैनेज करना

पूरी तरह इंडेक्स करने के लिए, समय-समय पर डेटा स्टोर करने की जगह से हर आइटम को इकट्ठा और इंडेक्स किया जा सकता है. यह पक्का करने में असरदार तरीके से काम करता है कि आपका इंडेक्स अप-टू-डेट है, लेकिन बड़ी या हैरारकी के हिसाब से डेटा स्टोर करने की जगह का इस्तेमाल करते समय, इंडेक्स करना काफ़ी महंगा पड़ सकता है.

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

Google Cloud Search API के बारे में ज़्यादा जानकारी के लिए, Cloud Search API पर जाएं.