Kolejki indeksowania Google Cloud Search

Pakiet SDK Connector i interfejs Google Cloud Search API umożliwiają tworzenie kolejek indeksowania Cloud Search, które służą do wykonywania tych zadań:

• Utrzymuj stan poszczególnych dokumentów (stan, wartości skrótu itp.), który może być używany do synchronizowania indeksu z repozytorium.

• Prowadź listę elementów do zindeksowania, które zostały wykryte podczas procesu przeszukiwania.

• Ustalaj priorytety elementów w kolejkach na podstawie ich stanu.

• Utrzymywanie dodatkowych informacji o stanie na potrzeby wydajnej integracji, takich jak punkty kontrolne, token zmiany itp.

Kolejka to etykieta przypisana do indeksowanego elementu, np. „default” w przypadku kolejki domyślnej lub „B” w przypadku kolejki B.

Stan i priorytet

Priorytet dokumentu w kolejce zależy od jego ItemStatus. Poniżej podano możliwe kody ItemStatus w kolejności priorytetu (od pierwszego do ostatniego):

• ERROR – podczas indeksowania elementu wystąpił błąd asynchroniczny i należy go ponownie zindeksować.

• MODIFIED – element, który był wcześniej indeksowany, a od ostatniego indeksowania został zmodyfikowany w repozytorium.

• NEW_ITEM – element, który nie jest indeksowany.

• ACCEPTED – dokument, który został wcześniej zindeksowany i od ostatniego indeksowania nie uległ zmianie w repozytorium.

Gdy 2 elementy w kolejce mają ten sam stan, wyższy priorytet mają elementy, które znajdują się w kolejce najdłużej.

Omówienie używania kolejek indeksowania do indeksowania nowego lub zmienionego elementu

Ilustracja 1 przedstawia etapy indeksowania nowego lub zmienionego elementu za pomocą kolejki indeksowania. Te kroki pokazują wywołania interfejsu API REST. Odpowiedniki wywołań pakietu SDK znajdziesz w artykule Operacje na kolejkach (pakiet SDK łącznika).

1. Łącznik treści używa items.push do przesyłania elementów (metadanych i wartości skrótu) do kolejki indeksowania, aby określić stan elementu (MODIFIED, NEW_ITEM, DELETED). W szczególności:

   • Podczas wysyłania oprogramowanie sprzęgające wyraźnie zawiera wysyłanie type lub contentHash.
   • Jeśli oprogramowanie sprzęgające nie zawiera znacznika type, Cloud Search automatycznie używa znacznika contentHash do określania stanu elementu.
   • Jeśli produkt jest nieznany, jego stan jest ustawiony na NEW_ITEM.
   • Jeśli produkt istnieje, a wartości skrótu są zgodne, stan pozostaje ACCEPTED.
   • Jeśli element istnieje, a wartości hashów się różnią, stan zmieni się na MODIFIED.

   Więcej informacji o tym, jak określa się stan elementu, znajdziesz w przykładowym kodzie Traversing the GitHub repositories w samouczku dla początkujących dotyczącym Cloud Search.

   Zwykle jest to związane z procesami przechodzenia przez treści lub wykrywania zmian w łączniku.

2. Łącznik treści używa items.poll do sprawdzania kolejki i określania elementów do zindeksowania. Cloud Search informuje łącznik, które elementy wymagają indeksowania w pierwszej kolejności. Są one sortowane najpierw według kodu stanu, a potem według czasu oczekiwania w kolejce.

3. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy żądania interfejsu Index API.

4. Oprogramowanie sprzęgające używa items.index do indeksowania elementów. Element przechodzi w stan ACCEPTED dopiero po pomyślnym zakończeniu przetwarzania przez Cloud Search.

Oprogramowanie sprzęgające może też usunąć element, jeśli nie istnieje już w repozytorium, lub ponownie przesłać element, jeśli nie został zmodyfikowany lub wystąpił błąd repozytorium źródłowego. Więcej informacji o usuwaniu produktów znajdziesz w następnej sekcji.

Omówienie korzystania z kolejek indeksowania do usuwania elementu

Strategia pełnego przechodzenia wykorzystuje proces z 2 kolejkami do indeksowania elementów i wykrywania usunięć. Ilustracja 2 przedstawia kroki usuwania elementu za pomocą 2 kolejek indeksowania. Rysunek 2 przedstawia drugie przejście wykonane przy użyciu strategii pełnego przejścia. W tych krokach używamy wywołań interfejsu API REST. Odpowiedniki wywołań pakietu SDK znajdziesz w artykule Operacje na kolejkach (pakiet SDK łącznika).

1. Podczas pierwszego przejścia łącznik treści używa items.push do umieszczania elementów (metadanych i wartości hash) w kolejce indeksowania „kolejka A” jako NEW_ITEM, ponieważ nie ma ich w kolejce. Każdy element ma etykietę „A” oznaczającą „kolejkę A”. Treści są indeksowane w Cloud Search.

2. Łącznik treści używa items.poll do odpytywania kolejki A w celu określenia elementów do zindeksowania. Cloud Search informuje łącznik, które elementy wymagają indeksowania w pierwszej kolejności. Są one sortowane najpierw według kodu stanu, a potem według czasu oczekiwania w kolejce.

3. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy żądania interfejsu Index API.

4. Oprogramowanie sprzęgające używa items.index do indeksowania elementów. Element przechodzi w stan ACCEPTED dopiero po pomyślnym zakończeniu przetwarzania przez Cloud Search.

5. Metoda deleteQueueItems jest wywoływana w przypadku „kolejki B”. Jednak do kolejki B nie zostały przesłane żadne elementy, więc nie można niczego usunąć.

6. Podczas drugiego pełnego przejścia oprogramowanie sprzęgające treści używa items.push do umieszczania elementów (metadanych i wartości skrótu) w kolejce B:

   • Podczas wysyłania oprogramowanie sprzęgające wyraźnie zawiera wysyłanie type lub contentHash.
   • Jeśli oprogramowanie sprzęgające nie zawiera znacznika type, Cloud Search automatycznie używa znacznika contentHash do określania stanu elementu.
   • Jeśli element jest nieznany, jego stan zostanie ustawiony na NEW_ITEM, a etykieta kolejki zmieni się na „B”.
   • Jeśli produkt istnieje, a wartości skrótu są zgodne, stan pozostaje ACCEPTED, a etykieta kolejki zmienia się na „B”.
   • Jeśli element istnieje, a wartości hashów się różnią, stan zmieni się na MODIFIED, a etykieta kolejki zostanie zmieniona na „B”.

7. Łącznik treści używa items.poll do sprawdzania kolejki i określania elementów do zindeksowania. Cloud Search informuje łącznik, które elementy wymagają indeksowania w pierwszej kolejności. Są one sortowane najpierw według kodu stanu, a potem według czasu oczekiwania w kolejce.

8. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy żądania interfejsu Index API.

9. Oprogramowanie sprzęgające używa items.index do indeksowania elementów. Element przechodzi w stan ACCEPTED dopiero po pomyślnym zakończeniu przetwarzania przez Cloud Search.

10. Na koniec w kolejce A wywoływana jest funkcja deleteQueueItems w celu usunięcia wszystkich wcześniej zindeksowanych elementów CCloud Search, które nadal mają etykietę kolejki „A”.

11. Podczas kolejnych pełnych przejść kolejki używane do indeksowania i usuwania są zamieniane.

Operacje na kolejce (pakiet SDK łącznika)

Pakiet SDK łącznika treści udostępnia operacje przesyłania elementów do kolejki i pobierania z niej elementów.

Aby spakować element i przesłać go do kolejki, użyj klasy narzędzia do tworzenia pushItems.

Nie musisz nic robić, aby pobrać elementy z kolejki do przetworzenia. Zamiast tego pakiet SDK automatycznie pobiera elementy z kolejki w kolejności priorytetów za pomocą metody getDoc klasy Repository.

Operacje na kolejkach (API REST)

Interfejs REST API udostępnia te 2 metody przesyłania elementów do kolejki i pobierania ich z niej:

• Aby przenieść element do kolejki, użyj Items.push.
• Aby sprawdzić elementy w kolejce, użyj Items.poll.

Możesz też użyć Items.index, aby podczas indeksowania umieszczać elementy w kolejce. Elementy dodane do kolejki podczas indeksowania nie wymagają type i automatycznie otrzymują stan ACCEPTED.

Items.push

Metoda Items.push dodaje identyfikatory do kolejki. Tę metodę można wywołać z określoną wartością type, która określa wynik operacji push. Listę wartości type znajdziesz w polu item.type metody Items.push.

Wysłanie nowego identyfikatora powoduje dodanie nowego wpisu z kodem NEW_ITEM ItemStatus.

Opcjonalny ładunek jest zawsze przechowywany, traktowany jako nieprzejrzysta wartość i zwracany przez Items.poll.

Gdy element jest sprawdzany, jest rezerwowany, co oznacza, że nie można go zwrócić za pomocą innego wywołania funkcji Items.poll. Użycie Items.push z type jako NOT_MODIFIED, REPOSITORY_ERROR lub REQUEUE cofnie rezerwację sprawdzonych wpisów. Więcej informacji o zarezerwowanych i niezarezerwowanych wpisach znajdziesz w sekcji Items.poll.

Items.push z haszami

Interfejs Google Cloud Search API obsługuje określanie metadanych i wartości skrótu treści w Items.indexżądaniach. Zamiast określać type, wartości metadanych lub skrótów treści można określić za pomocą żądania push. Kolejka indeksowania Cloud Search porównuje podane wartości skrótu z wartościami przechowywanymi dostępnymi w przypadku elementu w źródle danych. Jeśli dane są niezgodne, wpis jest oznaczony jako MODIFIED. Jeśli w indeksie nie ma odpowiedniego elementu, stan to NEW_ITEM.

Items.poll

Metoda Items.poll pobiera z kolejki wpisy o najwyższym priorytecie. Żądane i zwrócone wartości stanu wskazują stan żądanych kolejek priorytetowych lub stan zwróconych identyfikatorów.

Domyślnie mogą być zwracane wpisy z dowolnej sekcji kolejki na podstawie priorytetu. Każdy zwrócony wpis jest zarezerwowany i nie jest zwracany przez inne wywołania funkcji Items.poll, dopóki nie zostanie spełniony jeden z tych warunków:

• Rezerwacja wygasa.
• Wpis jest ponownie umieszczany w kolejce przez Items.index.
• Items.push jest wywoływana z wartością type NOT_MODIFIED, REPOSITORY_ERROR lub REQUEUE.