কন্টেন্ট কানেক্টর হল একটি সফটওয়্যার প্রোগ্রাম যা একটি এন্টারপ্রাইজের রিপোজিটরিতে ডেটা স্থানান্তর করতে এবং একটি ডেটা উৎস পূরণ করতে ব্যবহৃত হয়। কন্টেন্ট কানেক্টর তৈরির জন্য গুগল নিম্নলিখিত বিকল্পগুলি প্রদান করে:
কন্টেন্ট কানেক্টর SDK। যদি আপনি জাভাতে প্রোগ্রামিং করেন তবে এটি একটি ভালো বিকল্প। কন্টেন্ট কানেক্টর SDK হল REST API এর চারপাশে একটি মোড়ক যা আপনাকে দ্রুত সংযোগকারী তৈরি করতে দেয়। SDK ব্যবহার করে একটি কন্টেন্ট কানেক্টর তৈরি করতে, কন্টেন্ট কানেক্টর SDK ব্যবহার করে একটি কন্টেন্ট কানেক্টর তৈরি করুন দেখুন।
একটি নিম্ন-স্তরের REST API বা API লাইব্রেরি। যদি আপনি জাভাতে প্রোগ্রামিং না করেন, অথবা আপনার কোডবেস যদি REST API বা লাইব্রেরি আরও ভালভাবে সামঞ্জস্যপূর্ণ হয় তবে এই বিকল্পগুলি ব্যবহার করুন। REST API ব্যবহার করে একটি কন্টেন্ট সংযোগকারী তৈরি করতে, REST API ব্যবহার করে একটি কন্টেন্ট সংযোগকারী তৈরি করুন দেখুন।
একটি সাধারণ কন্টেন্ট সংযোগকারী নিম্নলিখিত কাজগুলি সম্পাদন করে:
- কনফিগারেশন প্যারামিটারগুলি পড়ে এবং প্রক্রিয়া করে।
- তৃতীয় পক্ষের কন্টেন্ট রিপোজিটরি থেকে " items " নামক সূচীযোগ্য ডেটার বিচ্ছিন্ন অংশ টেনে আনে।
- ACL, মেটাডেটা এবং কন্টেন্ট ডেটাকে সূচীযোগ্য আইটেমগুলিতে একত্রিত করে।
- ক্লাউড সার্চ ডেটা সোর্সে আইটেমগুলিকে সূচীবদ্ধ করে।
- (ঐচ্ছিক) তৃতীয় পক্ষের কন্টেন্ট রিপোজিটরি থেকে পরিবর্তনের বিজ্ঞপ্তিগুলি শোনে। ক্লাউড সার্চ ডেটা সোর্সকে তৃতীয় পক্ষের রিপোজিটরির সাথে সিঙ্ক করার জন্য পরিবর্তনের বিজ্ঞপ্তিগুলি ইন্ডেক্সিং অনুরোধে রূপান্তরিত হয়। সংযোগকারীটি কেবল তখনই এই কাজটি সম্পাদন করে যদি রিপোজিটরি পরিবর্তন সনাক্তকরণ সমর্থন করে।
কন্টেন্ট কানেক্টর SDK ব্যবহার করে একটি কন্টেন্ট কানেক্টর তৈরি করুন
নিম্নলিখিত বিভাগগুলিতে কন্টেন্ট কানেক্টর SDK ব্যবহার করে কীভাবে একটি কন্টেন্ট কানেক্টর তৈরি করতে হয় তা ব্যাখ্যা করা হয়েছে।
নির্ভরতা সেট আপ করুন
SDK ব্যবহার করার জন্য আপনার বিল্ড ফাইলে নির্দিষ্ট কিছু নির্ভরতা অন্তর্ভুক্ত করতে হবে। আপনার বিল্ড পরিবেশের নির্ভরতা দেখতে নীচের একটি ট্যাবে ক্লিক করুন:
মাভেন
<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() পদ্ধতিটি কীভাবে প্রয়োগ করবেন তা দেখায়:
পর্দার আড়ালে, SDK আপনার সংযোগকারীর main() পদ্ধতিটি Application.build কল করার পরে initConfig() পদ্ধতিটি কল করে। initConfig() পদ্ধতিটি নিম্নলিখিত কাজগুলি সম্পাদন করে:
-
Configurationআরম্ভ করা হয়নি তা নিশ্চিত করার জন্যConfiguation.isInitialized()পদ্ধতিটি কল করে। - গুগল-সরবরাহকৃত কী-মান জোড়া দিয়ে একটি
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 অবজেক্ট থেকে একটি একক কাস্টম পূর্ণসংখ্যা মান পুনরুদ্ধার করা যায়:
একাধিক মান সম্বলিত একটি প্যারামিটার পেতে এবং পার্স করতে, Configuration ক্লাসের টাইপ পার্সারগুলির একটি ব্যবহার করে ডেটাকে বিচ্ছিন্ন অংশে পার্স করুন। টিউটোরিয়াল সংযোগকারী থেকে নিম্নলিখিত স্নিপেটটি GitHub রিপোজিটরির নামের একটি তালিকা পেতে getMultiValue পদ্ধতি ব্যবহার করে:
একটি সম্পূর্ণ ট্রাভার্সাল সম্পাদন করুন
আপনার রিপোজিটরির সম্পূর্ণ ট্র্যাভার্সাল সম্পাদন করতে এবং সূচী করতে getAllDocs() ওভাররাইড করুন। getAllDocs() পদ্ধতিটি একটি চেকপয়েন্ট গ্রহণ করে। প্রক্রিয়াটি বাধাগ্রস্ত হলে একটি নির্দিষ্ট আইটেমে সূচী পুনরায় শুরু করতে চেকপয়েন্টটি ব্যবহার করা হয়। আপনার রিপোজিটরির প্রতিটি আইটেমের জন্য, getAllDocs() পদ্ধতিতে এই পদক্ষেপগুলি সম্পাদন করুন:
- অনুমতি সেট করুন।
- আপনি যে আইটেমটি ইন্ডেক্স করছেন তার মেটাডেটা সেট করুন।
- মেটাডেটা এবং আইটেমকে একটি সূচীযোগ্য
RepositoryDocএ একত্রিত করুন। - প্রতিটি ইনডেক্সেবল আইটেমকে
getAllDocs()পদ্ধতি দ্বারা ফেরত পাঠানো একটি ইটারেটরে প্যাকেজ করুন। মনে রাখবেন যেgetAllDocs()আসলে একটিCheckpointCloseableIterableফেরত দেয় যাApiOperationঅবজেক্টের একটি পুনরাবৃত্তি, প্রতিটি অবজেক্ট একটিRepositoryDocএ সম্পাদিত একটি API অনুরোধ প্রতিনিধিত্ব করে, যেমন এটিকে ইনডেক্স করা।
যদি আইটেমের সেটটি খুব বড় হয় এবং একটি একক কলে প্রক্রিয়া করা সম্ভব হয় না, তাহলে একটি চেকপয়েন্ট অন্তর্ভুক্ত করুন এবং hasMore(true) সেট করুন যাতে বোঝা যায় যে আরও আইটেম ইনডেক্সিংয়ের জন্য উপলব্ধ।
একটি আইটেমের জন্য অনুমতি সেট করুন
আপনার সংগ্রহস্থল একটি অ্যাক্সেস কন্ট্রোল লিস্ট (ACL) ব্যবহার করে কোন ব্যবহারকারী বা গোষ্ঠীর কোনও আইটেমে অ্যাক্সেস আছে তা সনাক্ত করতে। ACL হল এমন গোষ্ঠী বা ব্যবহারকারীদের আইডির একটি তালিকা যারা আইটেমটি অ্যাক্সেস করতে পারে।
আপনার রিপোজিটরিতে ব্যবহৃত ACL-এর ডুপ্লিকেট অবশ্যই করতে হবে যাতে শুধুমাত্র সেই ব্যবহারকারীরা যারা কোনও আইটেমের অ্যাক্সেস আছে তারাই অনুসন্ধান ফলাফলের মধ্যে সেই আইটেমটি দেখতে পান। কোনও আইটেমের সূচীকরণের সময় কোনও আইটেমের ACL অবশ্যই অন্তর্ভুক্ত করতে হবে যাতে Google Cloud Search-এর কাছে আইটেমটিতে সঠিক স্তরের অ্যাক্সেস প্রদানের জন্য প্রয়োজনীয় তথ্য থাকে।
কন্টেন্ট কানেক্টর SDK বেশিরভাগ রিপোজিটরির ACL মডেল করার জন্য ACL ক্লাস এবং পদ্ধতির একটি সমৃদ্ধ সেট প্রদান করে। আপনার রিপোজিটরির প্রতিটি আইটেমের জন্য ACL বিশ্লেষণ করতে হবে এবং কোনও আইটেম ইনডেক্স করার সময় Google Cloud Search এর জন্য একটি সংশ্লিষ্ট ACL তৈরি করতে হবে। যদি আপনার রিপোজিটরির ACL ACL উত্তরাধিকারের মতো ধারণা ব্যবহার করে, তাহলে সেই ACL মডেল করা জটিল হতে পারে। Google Cloud Search ACL সম্পর্কে আরও তথ্যের জন্য, Google Cloud Search ACL দেখুন।
দ্রষ্টব্য: ক্লাউড সার্চ ইনডেক্সিং API একক-ডোমেন ACL সমর্থন করে। এটি ক্রস-ডোমেন ACL সমর্থন করে না। ACL ব্যবহার করে প্রতিটি আইটেমের অ্যাক্সেস সেট করতে Acl.Builder ক্লাস ব্যবহার করুন। সম্পূর্ণ ট্র্যাভার্সাল নমুনা থেকে নেওয়া নিম্নলিখিত কোড স্নিপেটটি অনুসন্ধান করার সময় সমস্ত ব্যবহারকারী বা "প্রিন্সিপাল" ( getCustomerPrincipal() ) কে সমস্ত আইটেমের ( .setReaders() ) "পাঠক" হতে দেয়।
রিপোজিটরির জন্য ACL গুলিকে সঠিকভাবে মডেল করার জন্য আপনাকে ACL গুলি বুঝতে হবে। উদাহরণস্বরূপ, আপনি হয়তো এমন একটি ফাইল সিস্টেমের মধ্যে ফাইলগুলি ইনডেক্স করছেন যা কোনও ধরণের ইনহেরিটেন্স মডেল ব্যবহার করে যেখানে চাইল্ড ফোল্ডারগুলি প্যারেন্ট ফোল্ডারগুলি থেকে অনুমতি গ্রহণ করে। ACL ইনহেরিটেন্স মডেল করার জন্য Google ক্লাউড অনুসন্ধান ACL গুলিতে অন্তর্ভুক্ত অতিরিক্ত তথ্যের প্রয়োজন।
একটি আইটেমের জন্য মেটাডেটা সেট করুন
মেটাডেটা একটি Item অবজেক্টে সংরক্ষণ করা হয়। একটি Item তৈরি করতে, আপনার ন্যূনতম একটি অনন্য স্ট্রিং ID, আইটেমের ধরণ, ACL, URL এবং আইটেমটির সংস্করণ প্রয়োজন। নিম্নলিখিত কোড স্নিপেটে IndexingItemBuilder সহায়ক ক্লাস ব্যবহার করে কীভাবে একটি Item তৈরি করবেন তা দেখানো হয়েছে।
ইনডেক্সেবল আইটেম তৈরি করুন
একবার আপনি আইটেমটির জন্য মেটাডেটা সেট করার পরে, আপনি RepositoryDoc.Builder ক্লাস ব্যবহার করে প্রকৃত সূচীযোগ্য আইটেম তৈরি করতে পারেন। নিম্নলিখিত উদাহরণটি দেখায় কিভাবে একটি একক সূচীযোগ্য আইটেম তৈরি করতে হয়।
একটি RepositoryDoc হল এক ধরণের ApiOperation যা প্রকৃত IndexingService.indexItem() অনুরোধটি সম্পাদন করে।
আপনি RepositoryDoc.Builder ক্লাসের setRequestMode() পদ্ধতিটি ব্যবহার করে INDEXING অনুরোধটিকে ASYNCHRONOUS বা SYNCHRONOUS হিসাবে সনাক্ত করতে পারেন:
-
ASYNCHRONOUS - অ্যাসিঙ্ক্রোনাস মোডের ফলে ইনডেক্সিং-টু-সার্ভিং ল্যাটেন্সি দীর্ঘ হয় এবং ইনডেক্সিং অনুরোধের জন্য বৃহৎ থ্রুপুট কোটা সমন্বিত হয়। সমগ্র রিপোজিটরির প্রাথমিক ইনডেক্সিং (ব্যাকফিল) এর জন্য অ্যাসিঙ্ক্রোনাস মোড সুপারিশ করা হয়।
-
SYNCHRONOUS - সিঙ্ক্রোনাস মোডের ফলে ইন্ডেক্সিং-টু-সার্ভিং ল্যাটেন্সি কম হয় এবং সীমিত থ্রুপুট কোটা সমন্বিত হয়। রিপোজিটরিতে আপডেট এবং পরিবর্তনের ইন্ডেক্সিংয়ের জন্য সিঙ্ক্রোনাস মোড সুপারিশ করা হয়। যদি নির্দিষ্ট না করা থাকে, তাহলে অনুরোধ মোড ডিফল্টভাবে
SYNCHRONOUSএ সেট করা হয়।
প্রতিটি ইনডেক্সেবল আইটেম একটি ইটারেটরে প্যাকেজ করুন
getAllDocs() পদ্ধতিটি RepositoryDoc অবজেক্টের একটি Iterator , বিশেষ করে একটি CheckpointCloseableIterable , ফেরত পাঠায়। আপনি CheckpointClosableIterableImpl.Builder ক্লাস ব্যবহার করে একটি iterator তৈরি এবং ফেরত পাঠাতে পারেন। নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে একটি iterator তৈরি এবং ফেরত পাঠাতে হয়।
SDK ইটারেটরের মধ্যে আবদ্ধ প্রতিটি ইনডেক্সিং কল কার্যকর করে।
পরবর্তী পদক্ষেপ
আপনার পরবর্তী কিছু পদক্ষেপ এখানে দেওয়া হল:
- (ঐচ্ছিক) যদি আপনার ইনডেক্সিং থ্রুপুট ধীর বলে মনে হয়, তাহলে
FullTraversalConnectorজন্য ইনডেক্সিং রেট বৃদ্ধি দেখুন। - (ঐচ্ছিক) শাটডাউনের আগে যেকোনো রিসোর্স প্রকাশ করার জন্য
close()পদ্ধতিটি প্রয়োগ করুন। - (ঐচ্ছিক) কন্টেন্ট কানেক্টর SDK ব্যবহার করে একটি পরিচয় সংযোগকারী তৈরি করুন ।
একটি টেমপ্লেট ক্লাস ব্যবহার করে একটি তালিকা ট্র্যাভার্সাল সংযোগকারী তৈরি করুন
ক্লাউড সার্চ ইনডেক্সিং কিউ ব্যবহার করা হয় রিপোজিটরিতে প্রতিটি আইটেমের জন্য আইডি এবং ঐচ্ছিক হ্যাশ মান ধরে রাখার জন্য। একটি তালিকা ট্র্যাভার্সাল সংযোগকারী আইটেম আইডিগুলিকে গুগল ক্লাউড সার্চ ইনডেক্সিং কিউতে ঠেলে দেয় এবং ইন্ডেক্সিংয়ের জন্য একে একে পুনরুদ্ধার করে। গুগল ক্লাউড সার্চ কিউ বজায় রাখে এবং আইটেমের স্থিতি নির্ধারণের জন্য কিউ কন্টেন্ট তুলনা করে, যেমন রিপোজিটরি থেকে কোনও আইটেম মুছে ফেলা হয়েছে কিনা। ক্লাউড সার্চ ইনডেক্সিং কিউ সম্পর্কে আরও তথ্যের জন্য, ক্লাউড সার্চ ইনডেক্সিং কিউ দেখুন।
ডক্সের এই অংশটি ListTraversalSample উদাহরণ থেকে কোড স্নিপেটগুলিকে নির্দেশ করে।
সংযোগকারীর প্রবেশ বিন্দু বাস্তবায়ন করুন
একটি সংযোগকারীর প্রবেশ বিন্দু হল main() পদ্ধতি। এই পদ্ধতির প্রাথমিক কাজ হল Application ক্লাসের একটি উদাহরণ তৈরি করা এবং সংযোগকারীটি চালানোর জন্য এর start() পদ্ধতিটি ব্যবহার করা।
application.start() কল করার আগে, ListingConnector টেমপ্লেটটি ইন্সট্যান্ট করার জন্য IndexingApplication.Builder ক্লাস ব্যবহার করুন। ListingConnector একটি Repository অবজেক্ট গ্রহণ করে যার পদ্ধতিগুলি আপনি প্রয়োগ করেন। নিম্নলিখিত স্নিপেটে ListingConnector এবং এর সাথে সম্পর্কিত Repository কীভাবে ইন্সট্যান্ট করবেন তা দেখানো হয়েছে:
পর্দার আড়ালে, SDK আপনার সংযোগকারীর main() পদ্ধতিটি Application.build কল করার পরে initConfig() পদ্ধতিটি কল করে। initConfig() পদ্ধতি:
-
Configurationআরম্ভ করা হয়নি তা নিশ্চিত করার জন্যConfiguation.isInitialized()পদ্ধতিটি কল করে। - গুগল-সরবরাহকৃত কী-মান জোড়া দিয়ে একটি
Configurationঅবজেক্ট শুরু করে। প্রতিটি কী-মান জোড়াConfigurationঅবজেক্টের মধ্যে একটিConfigValueঅবজেক্টে সংরক্ষণ করা হয়।
Repository ইন্টারফেস বাস্তবায়ন করুন
Repository অবজেক্টের একমাত্র উদ্দেশ্য হল রিপোজিটরি আইটেমগুলির ট্র্যাভার্সাল এবং ইন্ডেক্সিং সম্পাদন করা। টেমপ্লেট ব্যবহার করার সময়, একটি কন্টেন্ট সংযোগকারী তৈরি করার জন্য আপনাকে Repository ইন্টারফেসের মধ্যে কেবলমাত্র কিছু পদ্ধতি ওভাররাইড করতে হবে। আপনি যে পদ্ধতিগুলি ওভাররাইড করবেন তা আপনার ব্যবহৃত টেমপ্লেট এবং ট্র্যাভার্সাল কৌশলের উপর নির্ভর করে। ListingConnector এর জন্য, নিম্নলিখিত পদ্ধতিগুলি ওভাররাইড করুন:
init()পদ্ধতি। যেকোনো ডেটা রিপোজিটরি সেট-আপ এবং ইনিশিয়ালাইজেশন করতে,init()পদ্ধতিটি ওভাররাইড করুন।getIds()পদ্ধতি। রিপোজিটরিতে থাকা সকল রেকর্ডের জন্য ID এবং হ্যাশ মান পুনরুদ্ধার করতে,getIds()পদ্ধতিটি ওভাররাইড করুন।getDoc()পদ্ধতি। সূচক থেকে নতুন আইটেম যোগ করতে, আপডেট করতে, পরিবর্তন করতে বা মুছে ফেলতে,getDoc()পদ্ধতিটি ওভাররাইড করুন।(ঐচ্ছিক)
getChanges()পদ্ধতি। যদি আপনার সংগ্রহস্থল পরিবর্তন সনাক্তকরণ সমর্থন করে, তাহলেgetChanges()পদ্ধতিটি ওভাররাইড করুন। পরিবর্তিত আইটেমগুলি পুনরুদ্ধার করতে এবং সেগুলিকে সূচী করতে প্রতিটি নির্ধারিত ক্রমবর্ধমান ট্র্যাভার্সালের জন্য (আপনার কনফিগারেশন দ্বারা সংজ্ঞায়িত) এই পদ্ধতিটি একবার বলা হয়।(ঐচ্ছিক)
close()পদ্ধতি। যদি আপনার রিপোজিটরি পরিষ্কার করার প্রয়োজন হয়, তাহলেclose()পদ্ধতিটি ওভাররাইড করুন। সংযোগকারী বন্ধ করার সময় এই পদ্ধতিটি একবার বলা হয়।
Repository অবজেক্টের প্রতিটি পদ্ধতিই কিছু ধরণের ApiOperation অবজেক্ট প্রদান করে। একটি ApiOperation অবজেক্ট আপনার রিপোজিটরির প্রকৃত ইনডেক্সিং সম্পাদনের জন্য একটি একক, অথবা সম্ভবত একাধিক, IndexingService.indexItem() কলের আকারে একটি ক্রিয়া সম্পাদন করে।
কাস্টম কনফিগারেশন প্যারামিটার পান
আপনার সংযোগকারীর কনফিগারেশন পরিচালনা করার অংশ হিসেবে, আপনাকে Configuration অবজেক্ট থেকে যেকোনো কাস্টম প্যারামিটার পেতে হবে। এই কাজটি সাধারণত একটি Repository ক্লাসের init() পদ্ধতিতে সম্পাদিত হয়।
Configuration ক্লাসে একটি কনফিগারেশন থেকে বিভিন্ন ধরণের ডেটা টাইপ পাওয়ার জন্য বিভিন্ন পদ্ধতি রয়েছে। প্রতিটি পদ্ধতি একটি ConfigValue অবজেক্ট ফেরত দেয়। এরপর আপনি প্রকৃত মান পুনরুদ্ধার করতে ConfigValue অবজেক্টের get() পদ্ধতি ব্যবহার করবেন। FullTraversalSample থেকে নিম্নলিখিত স্নিপেটটি দেখায় যে কীভাবে একটি Configuration অবজেক্ট থেকে একটি একক কাস্টম পূর্ণসংখ্যা মান পুনরুদ্ধার করা যায়:
একাধিক মান সম্বলিত একটি প্যারামিটার পেতে এবং পার্স করতে, Configuration ক্লাসের টাইপ পার্সারগুলির একটি ব্যবহার করে ডেটাকে বিচ্ছিন্ন অংশে পার্স করুন। টিউটোরিয়াল সংযোগকারী থেকে নিম্নলিখিত স্নিপেটটি GitHub রিপোজিটরির নামের একটি তালিকা পেতে getMultiValue পদ্ধতি ব্যবহার করে:
তালিকার ট্রাভার্সাল সম্পাদন করুন
রিপোজিটরিতে থাকা সকল রেকর্ডের আইডি এবং হ্যাশ মান পুনরুদ্ধার করতে getIds() পদ্ধতিটি ওভাররাইড করুন। getIds() পদ্ধতিটি একটি চেকপয়েন্ট গ্রহণ করে। প্রক্রিয়াটি বাধাগ্রস্ত হলে একটি নির্দিষ্ট আইটেমে ইনডেক্সিং পুনরায় শুরু করতে চেকপয়েন্টটি ব্যবহার করা হয়।
এরপর, ক্লাউড সার্চ ইনডেক্সিং সারিতে প্রতিটি আইটেম পরিচালনা করার জন্য getDoc() পদ্ধতিটি ওভাররাইড করুন।
পুশ আইটেম আইডি এবং হ্যাশ মান
রিপোজিটরি থেকে আইটেম আইডি এবং তাদের সাথে সম্পর্কিত কন্টেন্ট হ্যাশ মান আনতে getIds() ওভাররাইড করুন। তারপর আইডি এবং হ্যাশ মান জোড়াগুলিকে ক্লাউড সার্চ ইনডেক্সিং কিউতে পুশ অপারেশন অনুরোধে প্যাকেজ করা হয়। রুট বা প্যারেন্ট আইডিগুলি সাধারণত প্রথমে পুশ করা হয় এবং তারপরে চাইল্ড আইডিগুলি যতক্ষণ না আইটেমগুলির সম্পূর্ণ শ্রেণিবিন্যাস প্রক্রিয়া করা হয়।
getIds() পদ্ধতিটি একটি চেকপয়েন্ট গ্রহণ করে যা শেষ আইটেমটি সূচীবদ্ধ করার প্রতিনিধিত্ব করে। প্রক্রিয়াটি বাধাগ্রস্ত হলে একটি নির্দিষ্ট আইটেমে সূচী পুনরায় শুরু করতে চেকপয়েন্টটি ব্যবহার করা যেতে পারে। আপনার রিপোজিটরির প্রতিটি আইটেমের জন্য, getIds() পদ্ধতিতে এই পদক্ষেপগুলি সম্পাদন করুন:
- সংগ্রহস্থল থেকে প্রতিটি আইটেম আইডি এবং সংশ্লিষ্ট হ্যাশ মান পান।
- প্রতিটি আইডি এবং হ্যাশ মান জোড়া একটি
PushItemsতে প্যাকেজ করুন। - প্রতিটি
PushItemsgetIds()পদ্ধতি দ্বারা ফেরত পাঠানো একটি ইটারেটরে একত্রিত করুন। মনে রাখবেন যেgetIds()আসলে একটিCheckpointCloseableIterableপ্রদান করে যাApiOperationঅবজেক্টের একটি পুনরাবৃত্তি, প্রতিটি অবজেক্ট একটিRepositoryDocএ সম্পাদিত API অনুরোধের প্রতিনিধিত্ব করে, যেমন আইটেমগুলিকে কিউতে পুশ করা।
নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে প্রতিটি আইটেম আইডি এবং হ্যাশ মান পেতে হয় এবং সেগুলিকে একটি PushItems এ সন্নিবেশ করাতে হয়। একটি PushItems হল একটি ApiOperation অনুরোধ যা একটি আইটেমকে ক্লাউড অনুসন্ধান সূচক সারিতে পুশ করার জন্য।
নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে PushItems.Builder ক্লাস ব্যবহার করে ID এবং হ্যাশ মানগুলিকে একটি একক পুশে ApiOperation প্যাকেজ করতে হয়।
আরও প্রক্রিয়াকরণের জন্য আইটেমগুলিকে ক্লাউড অনুসন্ধান সূচক সারিতে পুশ করা হয়।
প্রতিটি আইটেম উদ্ধার করুন এবং পরিচালনা করুন
ক্লাউড সার্চ ইন্ডেক্সিং কিউতে প্রতিটি আইটেম পরিচালনা করতে getDoc() ওভাররাইড করুন। একটি আইটেম নতুন, পরিবর্তিত, অপরিবর্তিত হতে পারে, অথবা সোর্স রিপোজিটরিতে আর বিদ্যমান থাকতে পারে না। নতুন বা পরিবর্তিত প্রতিটি আইটেম পুনরুদ্ধার করুন এবং সূচী করুন। সোর্স রিপোজিটরিতে আর বিদ্যমান নেই এমন আইটেমগুলি সূচী থেকে সরান।
getDoc() পদ্ধতিটি Google Cloud Search Indexing Queue থেকে একটি আইটেম গ্রহণ করে। সারিতে থাকা প্রতিটি আইটেমের জন্য, getDoc() পদ্ধতিতে এই পদক্ষেপগুলি সম্পাদন করুন:
ক্লাউড সার্চ ইনডেক্সিং কিউ-এর মধ্যে থাকা আইটেমটির আইডি রিপোজিটরিতে বিদ্যমান কিনা তা পরীক্ষা করুন। যদি না থাকে, তাহলে ইনডেক্স থেকে আইটেমটি মুছে ফেলুন।
আইটেমের স্থিতির জন্য সূচীটি পোল করুন এবং যদি কোনও আইটেম অপরিবর্তিত থাকে (
ACCEPTED), তবে কিছুই করবেন না।সূচী পরিবর্তিত অথবা নতুন আইটেম:
- অনুমতিগুলি সেট করুন।
- আপনি যে আইটেমটি ইন্ডেক্স করছেন তার মেটাডেটা সেট করুন।
- মেটাডেটা এবং আইটেমকে একটি সূচীযোগ্য
RepositoryDocএ একত্রিত করুন। -
RepositoryDocফেরত দিন।
দ্রষ্টব্য: ListingConnector টেমপ্লেটটি getDoc() পদ্ধতিতে null রিটার্নিং সমর্থন করে না। null রিটার্নিং করলে NullPointerException.
মুছে ফেলা আইটেমগুলি পরিচালনা করুন
নিম্নলিখিত কোড স্নিপেটটি দেখায় যে কীভাবে কোনও আইটেম রিপোজিটরিতে বিদ্যমান কিনা তা নির্ধারণ করতে হয় এবং যদি না থাকে তবে এটি মুছে ফেলতে হয়।
মনে রাখবেন যে documents হল একটি ডেটা স্ট্রাকচার যা রিপোজিটরির প্রতিনিধিত্ব করে। যদি documents এ documentID না পাওয়া যায়, তাহলে সূচী থেকে আইটেমটি মুছে ফেলার জন্য APIOperations.deleteItem(resourceName) ফেরত দিন।
অপরিবর্তিত আইটেমগুলি পরিচালনা করুন
নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে ক্লাউড অনুসন্ধান সূচী সারিতে আইটেমের স্থিতি পোল করতে হয় এবং একটি অপরিবর্তিত আইটেম পরিচালনা করতে হয়।
আইটেমটি অপরিবর্তিত আছে কিনা তা নির্ধারণ করতে, আইটেমটির স্থিতি পরীক্ষা করুন এবং অন্যান্য মেটাডেটাও পরীক্ষা করুন যা পরিবর্তন নির্দেশ করতে পারে। উদাহরণে, আইটেমটি পরিবর্তন করা হয়েছে কিনা তা নির্ধারণ করতে মেটাডেটা হ্যাশ ব্যবহার করা হয়।
একটি আইটেমের জন্য অনুমতি সেট করুন
আপনার সংগ্রহস্থল একটি অ্যাক্সেস কন্ট্রোল লিস্ট (ACL) ব্যবহার করে কোন ব্যবহারকারী বা গোষ্ঠীর কোনও আইটেমে অ্যাক্সেস আছে তা সনাক্ত করতে। ACL হল এমন গোষ্ঠী বা ব্যবহারকারীদের আইডির একটি তালিকা যারা আইটেমটি অ্যাক্সেস করতে পারে।
আপনার রিপোজিটরিতে ব্যবহৃত ACL-এর ডুপ্লিকেট অবশ্যই করতে হবে যাতে শুধুমাত্র সেই ব্যবহারকারীরা যারা কোনও আইটেমের অ্যাক্সেস আছে তারাই অনুসন্ধান ফলাফলের মধ্যে সেই আইটেমটি দেখতে পান। কোনও আইটেমের সূচীকরণের সময় কোনও আইটেমের ACL অবশ্যই অন্তর্ভুক্ত করতে হবে যাতে Google Cloud Search-এর কাছে আইটেমটিতে সঠিক স্তরের অ্যাক্সেস প্রদানের জন্য প্রয়োজনীয় তথ্য থাকে।
কন্টেন্ট কানেক্টর SDK বেশিরভাগ রিপোজিটরির ACL মডেল করার জন্য ACL ক্লাস এবং পদ্ধতির একটি সমৃদ্ধ সেট প্রদান করে। আপনার রিপোজিটরির প্রতিটি আইটেমের জন্য ACL বিশ্লেষণ করতে হবে এবং কোনও আইটেম ইনডেক্স করার সময় Google Cloud Search এর জন্য একটি সংশ্লিষ্ট ACL তৈরি করতে হবে। যদি আপনার রিপোজিটরির ACL ACL উত্তরাধিকারের মতো ধারণা ব্যবহার করে, তাহলে সেই ACL মডেল করা জটিল হতে পারে। Google Cloud Search ACL সম্পর্কে আরও তথ্যের জন্য, Google Cloud Search ACL দেখুন।
দ্রষ্টব্য: ক্লাউড সার্চ ইনডেক্সিং API একক-ডোমেন ACL সমর্থন করে। এটি ক্রস-ডোমেন ACL সমর্থন করে না। ACL ব্যবহার করে প্রতিটি আইটেমের অ্যাক্সেস সেট করতে Acl.Builder ক্লাস ব্যবহার করুন। সম্পূর্ণ ট্র্যাভার্সাল নমুনা থেকে নেওয়া নিম্নলিখিত কোড স্নিপেটটি অনুসন্ধান করার সময় সমস্ত ব্যবহারকারী বা "প্রিন্সিপাল" ( getCustomerPrincipal() ) কে সমস্ত আইটেমের ( .setReaders() ) "পাঠক" হতে দেয়।
রিপোজিটরির জন্য ACL গুলিকে সঠিকভাবে মডেল করার জন্য আপনাকে ACL গুলি বুঝতে হবে। উদাহরণস্বরূপ, আপনি হয়তো এমন একটি ফাইল সিস্টেমের মধ্যে ফাইলগুলি ইনডেক্স করছেন যা কোনও ধরণের ইনহেরিটেন্স মডেল ব্যবহার করে যেখানে চাইল্ড ফোল্ডারগুলি প্যারেন্ট ফোল্ডারগুলি থেকে অনুমতি গ্রহণ করে। ACL ইনহেরিটেন্স মডেল করার জন্য Google ক্লাউড অনুসন্ধান ACL গুলিতে অন্তর্ভুক্ত অতিরিক্ত তথ্যের প্রয়োজন।
একটি আইটেমের জন্য মেটাডেটা সেট করুন
মেটাডেটা একটি Item অবজেক্টে সংরক্ষণ করা হয়। একটি Item তৈরি করতে, আপনার ন্যূনতম একটি অনন্য স্ট্রিং ID, আইটেমের ধরণ, ACL, URL এবং আইটেমটির সংস্করণ প্রয়োজন। নিম্নলিখিত কোড স্নিপেটে IndexingItemBuilder সহায়ক ক্লাস ব্যবহার করে কীভাবে একটি Item তৈরি করবেন তা দেখানো হয়েছে।
একটি ইনডেক্সেবল আইটেম তৈরি করুন
একবার আপনি আইটেমটির জন্য মেটাডেটা সেট করে ফেললে, আপনি RepositoryDoc.Builder ব্যবহার করে প্রকৃত সূচীযোগ্য আইটেম তৈরি করতে পারেন। নিম্নলিখিত উদাহরণটি দেখায় কিভাবে একটি একক সূচীযোগ্য আইটেম তৈরি করতে হয়।
একটি RepositoryDoc হল এক ধরণের ApiOperation যা প্রকৃত IndexingService.indexItem() অনুরোধটি সম্পাদন করে।
আপনি RepositoryDoc.Builder ক্লাসের setRequestMode() পদ্ধতিটি ব্যবহার করে INDEXING অনুরোধটিকে ASYNCHRONOUS বা SYNCHRONOUS হিসাবে সনাক্ত করতে পারেন:
-
ASYNCHRONOUS - অ্যাসিঙ্ক্রোনাস মোডের ফলে ইনডেক্সিং-টু-সার্ভিং ল্যাটেন্সি দীর্ঘ হয় এবং ইনডেক্সিং অনুরোধের জন্য বৃহৎ থ্রুপুট কোটা সমন্বিত হয়। সমগ্র রিপোজিটরির প্রাথমিক ইনডেক্সিং (ব্যাকফিল) এর জন্য অ্যাসিঙ্ক্রোনাস মোড সুপারিশ করা হয়।
-
SYNCHRONOUS - সিঙ্ক্রোনাস মোডের ফলে ইন্ডেক্সিং-টু-সার্ভিং ল্যাটেন্সি কম হয় এবং সীমিত থ্রুপুট কোটা সমন্বিত হয়। রিপোজিটরিতে আপডেট এবং পরিবর্তনের ইন্ডেক্সিংয়ের জন্য সিঙ্ক্রোনাস মোড সুপারিশ করা হয়। যদি নির্দিষ্ট না করা থাকে, তাহলে অনুরোধ মোড ডিফল্টভাবে
SYNCHRONOUSএ সেট করা হয়।
পরবর্তী পদক্ষেপ
আপনার পরবর্তী কিছু পদক্ষেপ এখানে দেওয়া হল:
- (ঐচ্ছিক) শাটডাউনের আগে যেকোনো রিসোর্স প্রকাশ করার জন্য
close()পদ্ধতিটি প্রয়োগ করুন। - (ঐচ্ছিক) কন্টেন্ট কানেক্টর SDK ব্যবহার করে একটি পরিচয় সংযোগকারী তৈরি করুন ।
একটি টেমপ্লেট ক্লাস ব্যবহার করে একটি গ্রাফ ট্র্যাভার্সাল সংযোগকারী তৈরি করুন
ক্লাউড সার্চ ইন্ডেক্সিং কিউ ব্যবহার করা হয় রিপোজিটরিতে প্রতিটি আইটেমের জন্য আইডি এবং ঐচ্ছিক হ্যাশ মান ধরে রাখার জন্য। একটি গ্রাফ ট্র্যাভার্সাল সংযোগকারী আইটেম আইডিগুলিকে গুগল ক্লাউড সার্চ ইন্ডেক্সিং কিউতে ঠেলে দেয় এবং ইন্ডেক্সিংয়ের জন্য একে একে পুনরুদ্ধার করে। গুগল ক্লাউড সার্চ কিউ বজায় রাখে এবং আইটেমের স্থিতি নির্ধারণের জন্য কিউ কন্টেন্ট তুলনা করে, যেমন রিপোজিটরি থেকে কোনও আইটেম মুছে ফেলা হয়েছে কিনা। ক্লাউড সার্চ ইন্ডেক্সিং কিউ সম্পর্কে আরও তথ্যের জন্য, গুগল ক্লাউড সার্চ ইন্ডেক্সিং কিউ দেখুন।
সূচকের সময়, ডেটা রিপোজিটরি থেকে আইটেমের বিষয়বস্তু সংগ্রহ করা হয় এবং যেকোনো শিশু আইটেম আইডি কিউতে পুশ করা হয়। সমস্ত আইটেম পরিচালনা না করা পর্যন্ত সংযোগকারীটি পুনরাবৃত্তভাবে পিতামাতা এবং শিশুদের আইডি প্রক্রিয়াকরণ করে।
ডক্সের এই অংশটি GraphTraversalSample উদাহরণ থেকে কোড স্নিপেটগুলি উল্লেখ করে।
সংযোগকারীর প্রবেশ বিন্দু বাস্তবায়ন করুন
একটি সংযোগকারীর প্রবেশ বিন্দু হল main() পদ্ধতি। এই পদ্ধতির প্রাথমিক কাজ হল Application ক্লাসের একটি উদাহরণ তৈরি করা এবং সংযোগকারীটি চালানোর জন্য এর start() পদ্ধতিটি ব্যবহার করা।
application.start() কল করার আগে, ListingConnector টেমপ্লেটটি ইন্সট্যান্ট করার জন্য IndexingApplication.Builder ক্লাস ব্যবহার করুন। ListingConnector একটি Repository অবজেক্ট গ্রহণ করে যার পদ্ধতিগুলি আপনি প্রয়োগ করেন।
নিম্নলিখিত স্নিপেটটি দেখায় কিভাবে ListingConnector এবং এর সাথে সম্পর্কিত Repository ইন্সট্যান্ট করতে হয়:
পর্দার আড়ালে, SDK আপনার সংযোগকারীর main() পদ্ধতিটি Application.build কল করার পরে initConfig() পদ্ধতিটি কল করে। initConfig() পদ্ধতি:
-
Configurationআরম্ভ করা হয়নি তা নিশ্চিত করার জন্যConfiguation.isInitialized()পদ্ধতিটি কল করে। - গুগল-সরবরাহকৃত কী-মান জোড়া দিয়ে একটি
Configurationঅবজেক্ট শুরু করে। প্রতিটি কী-মান জোড়াConfigurationঅবজেক্টের মধ্যে একটিConfigValueঅবজেক্টে সংরক্ষণ করা হয়।
Repository ইন্টারফেস বাস্তবায়ন করুন
Repository অবজেক্টের একমাত্র উদ্দেশ্য হল রিপোজিটরি আইটেমগুলির ট্র্যাভার্সাল এবং ইন্ডেক্সিং সম্পাদন করা। টেমপ্লেট ব্যবহার করার সময়, একটি কন্টেন্ট সংযোগকারী তৈরি করার জন্য আপনাকে Repository ইন্টারফেসের মধ্যে কেবলমাত্র কিছু পদ্ধতি ওভাররাইড করতে হবে। আপনি যে পদ্ধতিগুলি ওভাররাইড করবেন তা আপনার ব্যবহৃত টেমপ্লেট এবং ট্র্যাভার্সাল কৌশলের উপর নির্ভর করে। ListingConnector এর জন্য, আপনি নিম্নলিখিত পদ্ধতিগুলি ওভাররাইড করেন:
init()পদ্ধতি। যেকোনো ডেটা রিপোজিটরি সেট-আপ এবং ইনিশিয়ালাইজেশন করতে,init()পদ্ধতিটি ওভাররাইড করুন।getIds()পদ্ধতি। রিপোজিটরিতে থাকা সকল রেকর্ডের জন্য ID এবং হ্যাশ মান পুনরুদ্ধার করতে,getIds()পদ্ধতিটি ওভাররাইড করুন।getDoc()পদ্ধতি। সূচক থেকে নতুন আইটেম যোগ করতে, আপডেট করতে, পরিবর্তন করতে বা মুছে ফেলতে,getDoc()পদ্ধতিটি ওভাররাইড করুন।(ঐচ্ছিক)
getChanges()পদ্ধতি। যদি আপনার সংগ্রহস্থল পরিবর্তন সনাক্তকরণ সমর্থন করে, তাহলেgetChanges()পদ্ধতিটি ওভাররাইড করুন। পরিবর্তিত আইটেমগুলি পুনরুদ্ধার করতে এবং সেগুলিকে সূচী করতে প্রতিটি নির্ধারিত ক্রমবর্ধমান ট্র্যাভার্সালের জন্য (আপনার কনফিগারেশন দ্বারা সংজ্ঞায়িত) এই পদ্ধতিটি একবার বলা হয়।(ঐচ্ছিক)
close()পদ্ধতি। যদি আপনার রিপোজিটরি পরিষ্কার করার প্রয়োজন হয়, তাহলেclose()পদ্ধতিটি ওভাররাইড করুন। সংযোগকারী বন্ধ করার সময় এই পদ্ধতিটি একবার বলা হয়।
Repository অবজেক্টের প্রতিটি পদ্ধতিই কিছু ধরণের ApiOperation অবজেক্ট প্রদান করে। একটি ApiOperation অবজেক্ট আপনার রিপোজিটরির প্রকৃত ইনডেক্সিং সম্পাদনের জন্য একটি একক, অথবা সম্ভবত একাধিক, IndexingService.indexItem() কলের আকারে একটি ক্রিয়া সম্পাদন করে।
কাস্টম কনফিগারেশন প্যারামিটার পান
আপনার সংযোগকারীর কনফিগারেশন পরিচালনা করার অংশ হিসেবে, আপনাকে Configuration অবজেক্ট থেকে যেকোনো কাস্টম প্যারামিটার পেতে হবে। এই কাজটি সাধারণত একটি Repository ক্লাসের init() পদ্ধতিতে সম্পাদিত হয়।
Configuration ক্লাসে একটি কনফিগারেশন থেকে বিভিন্ন ধরণের ডেটা টাইপ পাওয়ার জন্য বিভিন্ন পদ্ধতি রয়েছে। প্রতিটি পদ্ধতি একটি ConfigValue অবজেক্ট ফেরত দেয়। এরপর আপনি প্রকৃত মান পুনরুদ্ধার করতে ConfigValue অবজেক্টের get() পদ্ধতি ব্যবহার করবেন। FullTraversalSample থেকে নিম্নলিখিত স্নিপেটটি দেখায় যে কীভাবে একটি Configuration অবজেক্ট থেকে একটি একক কাস্টম পূর্ণসংখ্যা মান পুনরুদ্ধার করা যায়:
একাধিক মান সম্বলিত একটি প্যারামিটার পেতে এবং পার্স করতে, Configuration ক্লাসের টাইপ পার্সারগুলির একটি ব্যবহার করে ডেটাকে বিচ্ছিন্ন অংশে পার্স করুন। টিউটোরিয়াল সংযোগকারী থেকে নিম্নলিখিত স্নিপেটটি GitHub রিপোজিটরির নামের একটি তালিকা পেতে getMultiValue পদ্ধতি ব্যবহার করে:
গ্রাফের ট্রাভার্সাল সম্পাদন করুন
রিপোজিটরিতে থাকা সকল রেকর্ডের আইডি এবং হ্যাশ মান পুনরুদ্ধার করতে getIds() পদ্ধতিটি ওভাররাইড করুন। getIds() পদ্ধতিটি একটি চেকপয়েন্ট গ্রহণ করে। প্রক্রিয়াটি বাধাগ্রস্ত হলে একটি নির্দিষ্ট আইটেমে ইনডেক্সিং পুনরায় শুরু করতে চেকপয়েন্টটি ব্যবহার করা হয়।
এরপর, ক্লাউড সার্চ ইনডেক্সিং সারিতে প্রতিটি আইটেম পরিচালনা করার জন্য getDoc() পদ্ধতিটি ওভাররাইড করুন।
পুশ আইটেম আইডি এবং হ্যাশ মান
রিপোজিটরি থেকে আইটেম আইডি এবং তাদের সাথে সম্পর্কিত কন্টেন্ট হ্যাশ মান আনতে getIds() ওভাররাইড করুন। তারপর আইডি এবং হ্যাশ মান জোড়াগুলিকে ক্লাউড সার্চ ইনডেক্সিং কিউতে পুশ অপারেশন অনুরোধে প্যাকেজ করা হয়। রুট বা প্যারেন্ট আইডিগুলি সাধারণত প্রথমে পুশ করা হয় এবং তারপরে চাইল্ড আইডিগুলি যতক্ষণ না আইটেমগুলির সম্পূর্ণ শ্রেণিবিন্যাস প্রক্রিয়া করা হয়।
The getIds() method accepts a checkpoint representing the last item to be indexed. The checkpoint can be used to resume indexing at a specific item should the process be interrupted. For each item in your repository, perform these steps in the getIds() method:
- Get each item ID and associated hash value from the repository.
- Package each ID and hash value pair into a
PushItems. - Combine each
PushItemsinto an iterator returned by thegetIds()method. Note thatgetIds()actually returns aCheckpointCloseableIterablewhich is an iteration ofApiOperationobjects, each object representing an API request performed on aRepositoryDoc, such as push the items to the queue.
The following code snippet shows how to get each item ID and hash value and insert them into a PushItems . A PushItems is an ApiOperation request to push an item to the Cloud Search Indexing Queue.
The following code snippet shows how to use the PushItems.Builder class to package the IDs and hash values into a single push ApiOperation .
Items are pushed to the Cloud Search Indexing Queue for further processing.
Retrieve and handle each item
Override getDoc() to handle each item in the Cloud Search Indexing Queue. An item can be new, modified, unchanged, or can no longer exist in the source repository. Retrieve and index each item that is new or modified. Remove items from the index that no longer exist in the source repository.
The getDoc() method accepts an Item from the Cloud Search Indexing Queue. For each item in the queue, perform these steps in the getDoc() method:
Check if the item's ID, within the Cloud Search Indexing Queue, exists in the repository. If not, delete the item from the index. If the item does exist, continue with the next step.
Index changed or new items:
- Set the permissions.
- Set the metadata for the item that you are indexing.
- Combine the metadata and item into one indexable
RepositoryDoc. - Place the child IDs in the Cloud Search Indexing Queue for further processing.
- Return the
RepositoryDoc.
Handle deleted items
The following code snippet shows how to determine if an item exists in the index and, it not, delete it.
Set the permissions for an item
Your repository uses an Access Control List (ACL) to identify the users or groups that have access to an item. An ACL is a list of IDs for groups or users who can access the item.
You must duplicate the ACL used by your repository to ensure only those users with access to an item can see that item within a search result. The ACL for an item must be included when indexing an item so that Google Cloud Search has the information it needs to provide the correct level of access to the item.
The Content Connector SDK provides a rich set of ACL classes and methods to model the ACLs of most repositories. You must analyze the ACL for each item in your repository and create a corresponding ACL for Google Cloud Search when you index an item. If your repository's ACL employs concepts such as ACL inheritance, modeling that ACL can be tricky. For further information on Google Cloud Search ACLs, refer to Google Cloud Search ACLs .
Note: The Cloud Search Indexing API supports single-domain ACLs. It does not support cross-domain ACLs. Use the Acl.Builder class to set access to each item using an ACL. The following code snippet, taken from the full traversal sample, allows all users or “principals” ( getCustomerPrincipal() ) to be “readers” of all items ( .setReaders() ) when performing a search.
You need to understand ACLs to properly model ACLs for the repository. For example, you might be indexing files within a file system that uses some sort of inheritance model whereby child folders inherit permissions from parent folders. Modeling ACL inheritance requires additional information covered in Google Cloud Search ACLs
Set the metadata for an item
Metadata is stored in an Item object. To create an Item , you need a minimum of a unique string ID, item type, ACL, URL, and version for the item. The following code snippet shows how to build an Item using the IndexingItemBuilder helper class.
Create the indexable item
Once you have set the metadata for the item, you can create the actual indexable item using the RepositoryDoc.Builder . The following example shows how to create a single indexable item.
A RepositoryDoc is a type of ApiOperation that performs the actual IndexingService.indexItem() request.
You can also use the setRequestMode() method of the RepositoryDoc.Builder class to identify the indexing request as ASYNCHRONOUS or SYNCHRONOUS :
-
ASYNCHRONOUS - Asynchronous mode results in longer indexing-to-serving latency and accommodates large throughput quota for indexing requests. Asynchronous mode is recommended for initial indexing (backfill) of the entire repository.
-
SYNCHRONOUS - Synchronous mode results in shorter indexing-to-serving latency and accommodates limited throughput quota. Synchronous mode is recommended for indexing of updates and changes to the repository. If unspecified, the request mode defaults to
SYNCHRONOUS.
Place the child IDs in the Cloud Search Indexing Queue
The following code snippet shows how to include the child IDs, for the currently processing parent item, into the queue for processing. These IDs are processed after the parent item is indexed.
Next Steps
Here are a few next steps you might take:
- (optional) Implement the
close()method to release any resources before shutdown. - (optional) Create an identity connector using the Identity Connector SDK.
Create a content connector using the REST API
The following sections explain how to create a content connector using the REST API.
Determine your traversal strategy
The primary function of a content connector is to traverse a repository and index its data. You must implement a traversal strategy based on the size and layout of data in your repository. Following are three common traversal strategies:
- Full traversal strategy
A full traversal strategy scans the entire repository and blindly indexes every item. This strategy is commonly used when you have a small repository and can afford the overhead of doing a full traversal every time you index.
This traversal strategy is suitable for small repositories with mostly static, non-hierarchical, data. You might also use this traversal strategy when change detection is difficult or not supported by the repository.
- List traversal strategy
A list traversal strategy scans the entire repository, including all child nodes, determining the status of each item. Then, the connector takes a second pass and only indexes items that are new or have been updated since the last indexing. This strategy is commonly used to perform incremental updates to an existing index (instead of having to do a full traversal every time you update the index).
This traversal strategy is suitable when change detection is difficult or not supported by the repository, you have non-hierarchical data, and you are working with very large data sets.
- Graph traversal
A graph traversal strategy scans the entire parent node determining the status of each item. Then, the connector takes a second pass and only indexes items in the root node are new or have been updated since the last indexing. Finally, the connector passes any child IDs then indexes items in the child nodes that are new or have been updated. The connector continues recursively through all child nodes until all items have been addressed. Such traversal is typically used for hierarchical repositories where listing of all IDs isn't practical.
This strategy is suitable if you have hierarchical data that needs to be crawled, such as a series directories or web pages.
Implement your traversal strategy and index items
Every indexable element for Cloud Search is referred to as an item in the Cloud Search API. An item might be a file, folder, a line in a CSV file, or a database record.
Once your schema is registered, you can populate the index by:
(optional) Using
items.uploadto upload files larger than 100KiB for indexing. For smaller files, embed the content as inlineContent usingitems.index.(optional) Using
media.uploadto upload media files for indexing.Using
items.indexto index the item. For example, if your schema uses the object definition in the movie schema , an indexing request for a single item would look like this:{ "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" }(Optional) Using items.get calls to verify an item has been indexed.
To perform a full traversal, you would periodically reindex the entire repository. To perform a list or graph traversal, you need to implement code to handle repository changes .
Handle repository changes
You can periodically gather and index each item from a repository to perform a full indexing. While effective at ensuring your index is up-to-date, a full indexing can be costly when dealing with larger or hierarchical repositories.
Instead of using index calls to index an entire repository every so often, you can also use the Google Cloud Indexing Queue as a mechanism for tracking changes and only indexing those items that have changed. You can use the items.push requests to push items into the queue for later polling and updating. For more information on the Google Cloud Indexing Queue, refer to Google Cloud Indexing Queue .
For further information on the Google Cloud Search API, refer to Cloud Search API .