Kolejki indeksowania Google Cloud Search

Pakiet SDK Connector i Google Cloud Search API umożliwiają tworzenie Cloud Search Kolejki indeksowania używane do wykonywania następujących zadań:

  • Zachowuj stan poszczególnych dokumentów (stan, wartości skrótu itd.), który może być służy do synchronizacji indeksu z repozytorium.

  • Utwórz listę elementów do zindeksowania w takiej postaci, w jakiej zostały wykryte podczas przemierzania proces tworzenia konta.

  • Nadaj priorytet elementom w kolejce na podstawie ich stanu.

  • Przechowywanie dodatkowych informacji o stanie w celu skutecznej integracji, takich jak: punktów kontrolnych, zmień token itd.

Kolejka to etykieta przypisana do zindeksowanego elementu, np. „domyślna”. dla domyślna kolejka, czyli „B” w kolejce B.

Stan priorytet

Priorytet dokumentu w kolejce zależy od ItemStatus w kodzie. Oto możliwe ItemStatus kodów w kolejności według priorytetu (obsługiwane od pierwszego do ostatniego):

  • ERROR – podczas indeksowania element napotkał błąd asynchroniczny i wymaga ponownego zindeksowania.

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

  • NEW_ITEM – element, który nie został zindeksowany.

  • ACCEPTED – dokument, który był wcześniej zindeksowany i nie został zmieniony w sekcji od ostatniego indeksowania.

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

Omówienie korzystania z kolejek indeksowania do indeksowania nowego lub zmienionego elementu

Rysunek 1 przedstawia etapy indeksowania nowego lub zmienionego elementu za pomocą indeksowania kolejkę. Te kroki pokazują wywołania interfejsu API REST. Równoważne wywołania pakietu SDK znajdziesz tutaj: Operacje w kolejce (SDK oprogramowania sprzęgającego)

Omówienie indeksowania w Google Cloud Search
Rysunek 1. Czynności, które należy wykonać, aby dodać lub zaktualizować element
  1. Łącznik treści używa funkcji items.push przenieść elementy (metadane i hasze) do kolejki indeksowania w celu ustalenia stan (MODIFIED, NEW_ITEM, DELETED). Więcej szczegółów:

    • Wypychanie powoduje, że łącznik jawnie zawiera metodę push type lub contentHash.
    • Jeśli oprogramowanie sprzęgające nie zawiera interfejsu type, wtedy Cloud Search automatycznie określa stan elementu na podstawie contentHash.
    • Jeśli produkt jest nieznany, jego stan jest ustawiany na NEW_ITEM.
    • Jeśli produkt istnieje, a wartości skrótu do niego pasują, zostanie zachowany stan ACCEPTED.
    • Jeśli produkt istnieje, a szyfry różnią się, stan zmienia się na MODIFIED.

    Więcej informacji o tym, jak określamy stan produktu, znajdziesz w Przemierzanie repozytoriów GitHub przykładowego kodu w sekcji Samouczek dla początkujących dotyczący Cloud Search.

    Zwykle push jest powiązane z przechodzeniem między treściami lub wykrywaniem zmian. w oprogramowaniu sprzęgającym.

  2. Łącznik treści używa funkcji items.poll sondowanie kolejki w celu określenia elementów do zindeksowania. Cloud Search przekazuje do oprogramowania sprzęgającego elementy wymagające indeksowania, posortowane najpierw według kodu stanu, a następnie przez czas w kolejce.

  3. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy indeks kompilacji Żądania do interfejsu API.

  4. Łącznik używa items.index aby je zindeksować. Element przechodzi w stan ACCEPTED dopiero po Cloud Search zakończy przetwarzanie elementu.

Oprogramowanie sprzęgające może też usunąć element, jeśli nie ma go już w repozytorium, lub wypchnąć go ponownie, jeśli nie został zmodyfikowany lub jeśli błąd repozytorium źródłowego. Informacje o usuwaniu elementów znajdziesz w następnym .

Omówienie korzystania z kolejek indeksowania do usuwania elementu

strategia pełnego przemierzania korzysta z procesu 2 kolejek do indeksowania elementów. i wykryć ich usunięcia. Rysunek 2 przedstawia kroki usuwania elementu przy użyciu dwóch kolejek indeksowania. Dokładniej, na rys. 2 widać drugi etap przemierzania przy użyciu strategii pełnego przemierzania. W tych krokach używane są wywołania interfejsu API REST. Dla: równoważnych wywołań SDK znajdziesz w sekcji Queue Operations (Connector SDK).

Omówienie indeksowania w Google Cloud Search
Rysunek 2. Usuwam elementy
  1. Podczas początkowego przemierzania łącznik treści wykorzystuje items.push do przesyłania elementów (metadanych i haszowania) do kolejki indeksowania, jako NEW_ITEM, ponieważ nie ma go w kolejce. Każdemu elementowi przypisano etykietę „A” dla „kolejki A”. Treści są indeksowane w Cloud Search.

  2. Łącznik treści używa funkcji items.poll sondowania kolejki A w celu określenia elementów do zindeksowania. Cloud Search przekazuje do oprogramowania sprzęgającego elementy wymagające indeksowania, posortowane najpierw według kodu stanu, a następnie przez czas w kolejce.

  3. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy indeks kompilacji Żądania do interfejsu API.

  4. Łącznik używa items.index aby je zindeksować. Element przechodzi w stan ACCEPTED dopiero po Cloud Search zakończy przetwarzanie elementu.

  5. deleteQueueItems dla metody „kolejka B”. Żadne elementy nie zostały jednak przesunięte do kolejki B, więc nie można niczego usunąć.

  6. Podczas drugiego pełnego przemierzania łącznik treści używa parametru items.push aby przekazać elementy (metadane i hasz) do kolejki B:

    • Wypychanie powoduje, że łącznik jawnie zawiera metodę push type lub contentHash.
    • Jeśli oprogramowanie sprzęgające nie zawiera interfejsu type, wtedy Cloud Search automatycznie określa stan elementu na podstawie contentHash.
    • Jeśli element jest nieznany, jego stan zostanie ustawiony na NEW_ITEM, a kolejka etykieta została zmieniona na „B”.
    • Jeśli produkt istnieje, a wartości skrótu do niego pasują, zostanie zachowany stan ACCEPTED a etykieta kolejki zmienia się na „B”.
    • Jeśli element istnieje, a skróty różnią się, stan zmienia się na MODIFIED, a kolejka etykieta została zmieniona na „B”.
  7. Łącznik treści używa funkcji items.poll sondowanie kolejki w celu określenia elementów do zindeksowania. Cloud Search przekazuje do oprogramowania sprzęgającego elementy wymagające indeksowania, posortowane najpierw według kodu stanu, a następnie przez czas w kolejce.

  8. Oprogramowanie sprzęgające pobiera te elementy z repozytorium i tworzy indeks kompilacji Żądania do interfejsu API.

  9. Łącznik używa items.index aby je zindeksować. Element przechodzi w stan ACCEPTED dopiero po Cloud Search zakończy przetwarzanie elementu.

  10. I na koniec, deleteQueueItems jest wywoływana dla kolejki A w celu usunięcia wszystkich wcześniej zindeksowanych elementów CCloud Search, które nadal mam kolejkę „A” .

  11. Po kolejnych pełnych przemierzaniach stronach kolejka wykorzystywana do indeksowania i kolejka używana do usunięcia zostanie zastąpiona.

Operacje kolejki (pakiet SDK oprogramowania sprzęgającego)

Pakiet Content Connector SDK umożliwia operacje przekazywania elementów do i pobierania elementów z kolejki.

Aby spakować element i przekazać go do kolejki, użyj narzędzia pushItems w klasie konstruktora.

Nie musisz wykonywać żadnych specjalnych czynności, aby pobierać elementy z kolejki o przetwarzaniu danych. Zamiast tego pakiet SDK automatycznie pobiera elementy z kolejki według priorytetu. zamówienie, używając Klasy Repository getDoc. .

Operacje kolejki (interfejs API REST)

Interfejs API REST udostępnia 2 metody przekazywania elementów do pobieranie elementów z kolejki:

  • Aby przekazać element do kolejki, użyj Items.push.
  • Do ankietowania elementów w kolejce służy Items.poll.

Możesz też użyć Items.index , aby przenieść elementy do kolejki podczas indeksowania. Elementy przeniesione do kolejki w trakcie indeksowanie nie wymaga type i automatycznie otrzymują stan ACCEPTED

Items.push

Items.push dodaje identyfikatory do kolejki. Tę metodę można wywołać z określonym type określająca wynik operacji push. Listę wartości type znajdziesz w dokumentacji, do item.type w polu Items.push .

Przekazywanie nowego identyfikatora powoduje dodanie nowego wpisu z atrybutem NEW_ITEM ItemStatus w kodzie.

Ładunek opcjonalny jest zawsze przechowywany, traktowany jako wartość nieprzezroczysta i zwracany od Items.poll

Gdy element jest ankietowany, jest zarezerwowany, co oznacza, że nie może zostać zwrócony przez funkcję kolejne połączenie do Items.poll. Zastosowanie Items.push z type jako NOT_MODIFIED, REPOSITORY_ERROR lub REQUEUE, nie rezerwuje wpisów ankietowanych. Aby uzyskać więcej informacji o zarezerwowanych i niezarezerwowanych wpisach, zapoznaj się z sekcją Items.poll.

Items.push z haszami

Interfejs Google Cloud Search API obsługuje określanie wartości metadanych i skrótu treści włączono Items.index żądań. Zamiast określać type wartości skrótu metadanych lub treści można określić za pomocą żądania push. Kolejka indeksowania w Cloud Search zawiera porównanie podane wartości skrótu z zapisanymi wartościami dostępnymi dla elementu w źródła danych. Jeśli nazwa nie będzie się zgadzać, ten wpis zostanie oznaczony jako MODIFIED. Jeśli odpowiada elementu nie ma w indeksie, ma stan NEW_ITEM.

Items.poll

w sekcji Items.poll, pobiera z kolejki wpisy o najwyższym priorytecie. Żądane zwrócone wartości stanu wskazują stan oczekujących kolejek lub stanu zwróconych identyfikatorów.

Domyślnie mogą być zwracane wpisy z dowolnej sekcji kolejki, w zależności od tego, . Każdy zwrócony wpis jest zarezerwowany i nie jest zwracany przez inne Liczba połączeń do Items.poll aż do jednego z tych przypadków:

  • Upłynął limit czasu rezerwacji.
  • Wpis został ponownie dodany do kolejki przez użytkownika Items.index.
  • Items.push jest wywoływana z type NOT_MODIFIED, REPOSITORY_ERROR lub REQUEUE.