คิวการจัดทำดัชนีของ Google Cloud Search

Connector SDK และ Cloud Search API รองรับการสร้าง คิวการจัดทำดัชนีของ Cloud Search โดยคุณสามารถใช้คิวเหล่านี้เพื่อทำสิ่งต่อไปนี้

• รักษาสถานะต่อเอกสาร (สถานะ, แฮช ฯลฯ) เพื่อให้ดัชนีเป็นข้อมูลล่าสุด
• เก็บรักษารายการไอเทมที่จะจัดทำดัชนีตามที่พบระหว่างการสำรวจ
• จัดลำดับความสำคัญของไอเทมตามสถานะ
• เก็บรักษาข้อมูลสถานะ เช่น จุดตรวจสอบและโทเค็นการเปลี่ยนแปลง

คิวคือป้ายกำกับที่กำหนดให้กับไอเทมที่จัดทำดัชนีแล้ว (เช่น "ค่าเริ่มต้น")

สถานะและลำดับความสำคัญ

ลำดับความสำคัญของเอกสารขึ้นอยู่กับรหัส ItemStatus รหัสที่เป็นไปได้ตามลำดับความสำคัญ (สูงสุดไปต่ำสุด) มีดังนี้

• ERROR: ไอเทมพบข้อผิดพลาดแบบไม่พร้อมกันและต้องจัดทำดัชนีใหม่
• MODIFIED: ไอเทมเคยจัดทำดัชนีแล้วแต่มีการเปลี่ยนแปลงในที่เก็บ
• NEW_ITEM: ไอเทมยังไม่ได้จัดทำดัชนี
• ACCEPTED: ไอเทมเคยจัดทำดัชนีแล้วและไม่มีการเปลี่ยนแปลง

สำหรับไอเทมที่มีสถานะเดียวกัน ไอเทมที่อยู่ในคิวนานที่สุดจะมีลำดับความสำคัญสูงกว่า

จัดทำดัชนีไอเทมใหม่หรือไอเทมที่มีการเปลี่ยนแปลง

รูปที่ 1 แสดงขั้นตอนการจัดทำดัชนีไอเทมใหม่หรือไอเทมที่มีการเปลี่ยนแปลงโดยใช้คิวการจัดทำดัชนี ขั้นตอนเหล่านี้แสดงถึงการเรียก REST API ส่วนการเรียก SDK ที่เทียบเท่ากันนั้น ให้ดูที่ การดำเนินการกับคิว (Connector SDK)

1. ตัวเชื่อมต่อเนื้อหาใช้ items.push เพื่อส่งข้อมูลเมตาและแฮชไปยังคิว
   • หากตัวเชื่อมต่อมี type หรือ contentHash สำหรับการส่ง Cloud Search จะกำหนดสถานะ
   • ไอเทมที่ไม่รู้จักจะมีสถานะ NEW_ITEM
   • ไอเทมที่มีอยู่ซึ่งมีแฮชที่ตรงกันจะยังคงมีสถานะ ACCEPTED
   • ไอเทมที่มีอยู่ซึ่งมีแฮชที่แตกต่างกันจะมีสถานะ MODIFIED
2. ตัวเชื่อมต่อใช้ items.poll เพื่อกำหนดไอเทมที่จะจัดทำดัชนี Cloud Search จะแสดงไอเทมตามลำดับความสำคัญ
3. ตัวเชื่อมต่อจะดึงไอเทมจากที่เก็บและสร้างคำขอ Index API
4. ตัวเชื่อมต่อใช้ items.index เพื่อจัดทำดัชนีไอเทม ไอเทมจะเข้าสู่สถานะ ACCEPTED หลังจากประมวลผลสำเร็จ

ลบไอเทม

กลยุทธ์การสำรวจแบบเต็ม จะใช้ 2 คิวเพื่อจัดทำดัชนีไอเทมและตรวจหาการลบ รูปที่ 2 แสดงการสำรวจครั้งที่ 2 ในกลยุทธ์นี้

1. ในการสำรวจครั้งแรก ตัวเชื่อมต่อจะส่งไอเทมไปยัง "คิว A" เป็น NEW_ITEM โดยแต่ละไอเทมจะได้รับป้ายกำกับ "A"
2. ตัวเชื่อมต่อจะสำรวจคิว A และจัดทำดัชนีไอเทม
3. ในการสำรวจแบบเต็มครั้งที่ 2 ตัวเชื่อมต่อจะส่งไอเทมไปยัง "คิว B"
   • ไอเทมที่ไม่รู้จักจะได้รับป้ายกำกับ "B" และสถานะ NEW_ITEM
   • ไอเทมที่มีอยู่ซึ่งมีแฮชที่ตรงกันจะเปลี่ยนป้ายกำกับเป็น "B" และยังคงมีสถานะ ACCEPTED
   • ไอเทมที่มีอยู่ซึ่งมีแฮชที่แตกต่างกันจะเปลี่ยนป้ายกำกับเป็น "B" และมีสถานะ MODIFIED
4. ตัวเชื่อมต่อจะสำรวจคิว B และจัดทำดัชนีไอเทม
5. สุดท้าย ตัวเชื่อมต่อจะเรียก deleteQueueItems ในคิว A ซึ่งจะลบไอเทมที่จัดทำดัชนีไว้ก่อนหน้านี้ทั้งหมดที่ยังคงมีป้ายกำกับ "A"
6. การสำรวจครั้งต่อๆ ไปจะสลับบทบาทของคิวทั้ง 2

การดำเนินการกับคิว (Connector SDK)

ใช้บิลเดอร์ pushItems เพื่อส่งไอเทม SDK จะดึงไอเทมจากคิว ตามลำดับความสำคัญโดยอัตโนมัติโดยใช้ getDoc เมธอดของคลาส Repository

การดำเนินการกับคิว (REST API)

• หากต้องการส่ง ให้ใช้ Items.push
• หากต้องการสำรวจ ให้ใช้ Items.poll

นอกจากนี้ คุณยังใช้ Items.index เพื่อส่งไอเทมระหว่างการจัดทำดัชนีได้ด้วย ไอเทมเหล่านี้จะได้รับสถานะ ACCEPTED โดยอัตโนมัติ

Items.push

เมธอดนี้จะเพิ่มรหัสลงในคิว type จะกำหนดผลลัพธ์ การส่งรหัสใหม่จะเพิ่มรายการที่มีสถานะ NEW_ITEM เพย์โหลดที่ไม่บังคับจะแสดงขึ้นระหว่างการสำรวจ

ระบบจะ สงวน ไอเทมที่สำรวจและคำขอสำรวจอื่นๆ จะไม่แสดงไอเทมดังกล่าว การใช้ Items.push โดยตั้งค่า type เป็น NOT_MODIFIED, REPOSITORY_ERROR หรือ REQUEUE จะเป็นการ ยกเลิกการสงวน รายการ

Items.push พร้อมแฮช

ระบุข้อมูลเมตาหรือแฮชเนื้อหาในคำขอส่ง Cloud Search จะเปรียบเทียบแฮชเหล่านี้กับค่าที่เก็บไว้ หากไม่ตรงกัน รายการจะมีสถานะ MODIFIED รหัสที่ไม่ตรงกันซึ่งไม่มีอยู่จะมีสถานะ NEW_ITEM

Items.poll

เมธอดนี้จะดึงรายการที่มีลำดับความสำคัญสูง ระบบจะสงวนแต่ละรายการที่แสดงผลจนกว่าจะหมดเวลา จัดทำดัชนีใหม่ หรือยกเลิกการสงวนโดยใช้ Items.push