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

कॉन्टेंट कनेक्टर एक सॉफ़्टवेयर प्रोग्राम है. इसका इस्तेमाल, किसी एंटरप्राइज़ की रिपॉज़िटरी (डेटा स्टोर करने की जगह) में डेटा को दिखाने और किसी डेटा सोर्स में अपने-आप जानकारी भरने के लिए किया जाता है. कॉन्टेंट कनेक्टर डेवलप करने के लिए, Google ये विकल्प उपलब्ध कराता है:

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

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

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

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

कॉन्टेंट कनेक्टर 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 टूल आपके कनेक्टर के main() तरीके से कॉल करने के बाद initConfig() तरीके को कॉल करता है 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 का डुप्लीकेट बनाना होगा, ताकि यह पक्का किया जा सके कि सिर्फ़ वही उपयोगकर्ता खोज नतीजे में उस आइटम को देख सकें जिनके पास किसी आइटम का ऐक्सेस है. किसी आइटम को इंडेक्स करते समय उस आइटम का एसीएल (एसीएल) भी शामिल करना ज़रूरी है, ताकि Google Cloud Search को वह जानकारी मिल सके जो आइटम के ऐक्सेस का सही लेवल देने के लिए ज़रूरी है.

कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का रिच सेट उपलब्ध कराता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर आपकी रिपॉज़िटरी का एसीएल (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 बनाने के लिए, आपके पास आइटम का कम से कम यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट, 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() तरीके से, खास तौर पर RepositoryDoc ऑब्जेक्ट CheckpointCloseableIterable का Iterator दिखता है. कोई इटरेटर बनाने और उसे लौटाने के लिए, CheckpointClosableIterableImpl.Builder क्लास का इस्तेमाल किया जा सकता है. नीचे दिया गया कोड स्निपेट, इटरेटर को बनाने और उसे लौटाने का तरीका बताता है.

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

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

अगले चरण

यहां कुछ ऐसे कदम दिए गए हैं जिन्हें आप आज़मा सकते हैं:

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

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 टूल आपके कनेक्टर के main() तरीके से कॉल करने के बाद initConfig() तरीके को कॉल करता है 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 एक ApiOperation अनुरोध होता है, जो किसी आइटम को Cloud Search की इंडेक्स करने की सूची में भेजने के लिए इस्तेमाल किया जाता है.

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);
}

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

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 दिखाने की सुविधा नहीं दी जाती. NullPointerException. में null नतीजे मिल रहे हैं

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

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

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

कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का रिच सेट उपलब्ध कराता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर आपकी रिपॉज़िटरी का एसीएल (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 बनाने के लिए, आपके पास आइटम का कम से कम यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट, 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() तरीका लागू करें.
  • (वैकल्पिक) कॉन्टेंट कनेक्टर 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 को इंस्टैंशिएट करने का तरीका बताता है:

ग्राफ़ट्रेवर्सल सैंपल.जावा
/**
 * 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 टूल आपके कनेक्टर के main() तरीके से कॉल करने के बाद initConfig() तरीके को कॉल करता है 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 अनुरोध किया जाता है.

ग्राफ़ट्रेवर्सल सैंपल.जावा
PushItems.Builder allIds = new PushItems.Builder();
PushItem item = new PushItem();
allIds.addPushItem("root", item);

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

ग्राफ़ट्रेवर्सल सैंपल.जावा
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 वापस करें.

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

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

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

कॉन्टेंट कनेक्टर SDK टूल, ज़्यादातर रिपॉज़िटरी के ACL को मॉडल करने के लिए ACL क्लास और तरीकों का रिच सेट उपलब्ध कराता है. आपको अपने डेटा स्टोर करने की जगह में मौजूद हर आइटम के लिए ACL का विश्लेषण करना होगा और किसी आइटम को इंडेक्स करते समय Google Cloud Search के लिए उससे जुड़ा ACL बनाना होगा. अगर आपकी रिपॉज़िटरी का एसीएल (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 बनाने के लिए, आपके पास आइटम का कम से कम यूनीक स्ट्रिंग आईडी, आइटम टाइप, एसीएल, यूआरएल, और वर्शन होना चाहिए. नीचे दिया गया कोड स्निपेट, IndexingItemBuilder हेल्पर क्लास का इस्तेमाल करके Item बनाने का तरीका बताता है.

ग्राफ़ट्रेवर्सल सैंपल.जावा
// 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 का इस्तेमाल करके, इंडेक्स किया जा सकने वाला असल आइटम बनाया जा सकता है. नीचे दिए गए उदाहरण में, इंडेक्स करने लायक एक आइटम बनाने का तरीका बताया गया है.

ग्राफ़ट्रेवर्सल सैंपल.जावा
// 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 की इंडेक्स करने की सूची में डालें

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

ग्राफ़ट्रेवर्सल सैंपल.जावा
// 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. (ज़रूरी नहीं) इंडेक्स करने के लिए 100KiB से बड़ी फ़ाइलें अपलोड करने के लिए items.upload का इस्तेमाल करना. छोटी फ़ाइलों के लिए, 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 देखें.