Как Google непрерывно обновляет индекс и удаляет старые данные, не замедляя работу поиска с помощью механизма «Эпох»

Термины и определения

Accessible Range (Доступный диапазон)

Определенный диапазон данных в репозитории (заданный начальной и конечной позициями), который доступен для поисковых запросов в данный момент времени. Обеспечивает консистентность данных для запросов.

DeleteItems / Delete List (Список на удаление)

Список, специфичный для каждой эпохи, содержащий идентификаторы частей репозитория (например, старых версий документов), которые должны быть удалены, когда они больше не используются активными потоками.

Epoch (Эпоха)

Определенный период времени, используемый для синхронизации обновлений и запросов. Эпохи следуют последовательно и не пересекаются.

FIFOArray (Массив FIFO)

Структура данных типа First-In-First-Out. Данные добавляются только в конец («back end») и удаляются только из начала («front end»). Используется для хранения основного репозитория токенов и индекса.

Garbage Collection (Сборка мусора)

Процесс физического удаления недействительных (устаревших) данных (Stale Data) из репозитория и восстановления занимаемого ими места.

GTokenID (Global Token Identifier)

Уникальный идентификатор, присваиваемый каждому уникальному токену (слову, тегу и т.д.) в наборе документов.

Invalidation (Инвалидация)

Процесс пометки документа или данных как устаревших или недействительных (например, при появлении новой версии). Инвалидация не является немедленным удалением.

ThreadCount (Счетчик потоков)

Счетчик, специфичный для каждой эпохи, который отслеживает количество активных потоков (поисковых запросов), начатых в эту эпоху, которые потенциально могут ссылаться на данные, помеченные для удаления.

Tokenspace Repository (Репозиторий пространства токенов)

Основное хранилище, где документы хранятся как непрерывная последовательность токенов (GTokenIDs).

Treadmilling («Беговая дорожка»)

Процесс управления памятью в FIFOArray. Поскольку удаление возможно только из начала массива, действительные данные из начала периодически копируются в конец, а их исходные копии в начале инвалидируются. Это позволяет освободить место, занимаемое устаревшими данными.

Ключевые утверждения (Анализ Claims)

Патент описывает внутренние процессы управления данными Google без прямых рекомендаций для SEO. Он фокусируется на методологии сборки мусора при параллельной обработке запросов.

Claim 1 (Независимый пункт): Описывает основной метод обновления данных с использованием двух последовательных эпох.

1. Система хранит документы в репозитории.
2. Во время первой эпохи:
   • Инициируется выполнение первого набора запросов в нескольких потоках.
   • В первый список на удаление (Delete List A) добавляются идентификаторы частей репозитория, подлежащих удалению (например, устаревшие документы).
   • Поддерживается первый счетчик (Count A) потоков, которые потенциально ссылаются на данные в Delete List A.
3. При выполнении условия окончания эпохи первая эпоха завершается, начинается вторая.
4. Во время второй эпохи:
   • Инициируется выполнение второго набора запросов.
   • Во второй список на удаление (Delete List B) добавляются новые идентификаторы для удаления.
   • Продолжается поддержка Count A (он уменьшается по мере завершения запросов первой эпохи).
   • Поддерживается второй счетчик (Count B) для Delete List B.
5. После окончания первой эпохи: Когда Count A достигает предопределенного значения (обычно 0), все части репозитория, указанные в Delete List A, удаляются.

Ключевая идея: данные, устаревшие в Эпоху 1, не удаляются до тех пор, пока все запросы, начатые в Эпоху 1 (и, следовательно, видевшие эти данные), не завершатся, что может произойти уже во время Эпохи 2 или позже.

Claim 4 (Независимый пункт): Обобщает Claim 1 на последовательность непересекающихся эпох.

1. В каждую эпоху система инициирует запросы, добавляет элементы в специфичный для эпохи список удаления и поддерживает специфичный для эпохи счетчик потоков.
2. Система также поддерживает счетчики всех предыдущих эпох, которые еще не достигли финального значения (0).
3. После окончания эпохи, когда ее счетчик достигает финального значения, соответствующие данные удаляются.

Где и как применяется

Изобретение является частью базовой инфраструктуры хранения и обработки данных, связывая этапы индексирования и ранжирования.

CRAWLING & INDEXING – Сканирование, Сбор данных и Индексирование
На этих этапах работают процессоры записи (Write Processors/Threads). Они получают новые или обновленные документы, токенизируют их и добавляют в Tokenspace Repository. При обновлении существующего документа старая версия инвалидируется и добавляется в Garbage Collection List текущей эпохи. Механизм Treadmilling также управляется этими процессами для реорганизации хранилища.

RANKING – Ранжирование
На этом этапе работают процессоры запросов (Query Processors/Threads). Они читают данные из Tokenspace Repository и Индекса. Описанный механизм синхронизации гарантирует, что эти потоки могут выполнять чтение без прерываний и блокировок со стороны процессов записи. Каждый поток запроса взаимодействует с менеджером эпох в начале и в конце запроса для обновления ThreadCount.

Входные данные:

• Новые и обновленные документы (для записи).
• Поисковые запросы (для чтения).
• Системные данные: текущий Accessible Range репозитория, статус эпох и ThreadCounts.

Выходные данные:

• Обновленный репозиторий и индекс.
• Результаты поисковых запросов.
• Освобожденное пространство памяти после сборки мусора.

На что влияет

• Конкретные типы контента: Влияет на все типы индексируемого контента. Механизм критически важен для контента, требующего высокой частоты обновления (новости, блоги, социальные сети, быстро меняющиеся товарные остатки в e-commerce).
• Специфические запросы: Влияет на запросы, где свежесть является важным фактором (QDF - Query Deserves Freshness). Патент предоставляет инфраструктуру, позволяющую быстро сделать свежий контент доступным для ранжирования.

Когда применяется

• При каких условиях работает алгоритм: Алгоритм работает непрерывно. Управление эпохами и счетчиками потоков происходит при каждом поисковом запросе и каждом обновлении документа.
• Триггеры активации:
  • Сборка мусора активируется, когда ThreadCount для определенной эпохи достигает предопределенного значения (0), при условии, что счетчики всех предыдущих эпох также достигли этого значения.
  • Новая эпоха начинается при выполнении условий окончания текущей эпохи (Epoch ending condition). В патенте упоминаются условия, такие как истечение заданного времени или достижение определенного количества инвалидированных документов.

Пошаговый алгоритм

Процесс А: Обработка поискового запроса (Query Thread)

1. Получение запроса.
2. Синхронизация (Начало): Поток захватывает глобальную блокировку (Lock).
3. Определение диапазона: Поток фиксирует текущий Accessible Range репозитория.
4. Регистрация в эпохе: Поток увеличивает ThreadCount для текущей эпохи.
5. Освобождение блокировки: Блокировка снимается (этот этап максимально короткий).
6. Выполнение запроса: Запрос выполняется с использованием зафиксированного Accessible Range. Во время выполнения репозиторий может обновляться другими потоками, но этот запрос видит консистентный снимок данных.
7. Синхронизация (Конец): Поток снова захватывает глобальную блокировку.
8. Дерегистрация из эпохи: Поток уменьшает ThreadCount той эпохи, в которой он был зарегистрирован (даже если текущая эпоха уже сменилась).
9. Освобождение блокировки.

Процесс Б: Обновление документа и управление эпохами (Write Thread)

1. Получение обновления (Новая версия V2).
2. Запись данных: V2 добавляется в конец Tokenspace Repository (изначально может быть за пределами доступного диапазона). Индекс обновляется.
3. Синхронизация и Публикация: Поток захватывает глобальную блокировку.
4. Обновление диапазона: Accessible Range расширяется, чтобы включить V2.
5. Инвалидация старой версии (V1): V1 помечается как недействительная. (Патент указывает, что инвалидация может происходить после обновления доступного диапазона).
6. Планирование удаления: Идентификаторы V1 добавляются в Delete List текущей эпохи.
7. Освобождение блокировки. Новые запросы теперь будут видеть V2. Старые запросы могут продолжать использовать V1.
8. Мониторинг окончания эпохи: Проверка условий (время, количество обновлений).
9. Завершение эпохи: При выполнении условий поток захватывает блокировку, завершает текущую эпоху и начинает новую (с нулевым ThreadCount и пустым Delete List). Освобождает блокировку.

Процесс В: Сборка мусора (Garbage Collector)

1. Мониторинг счетчиков: Система отслеживает ThreadCounts завершенных эпох.
2. Идентификация безопасного удаления: Определяется эпоха (N), для которой ThreadCount достиг предопределенного значения (0), и счетчики всех предыдущих эпох также равны 0.
3. Удаление данных: Данные, указанные в Delete List этой эпохи (N), физически удаляются из репозитория.
4. Восстановление пространства: Занимаемое ими место помечается как свободное (например, путем переназначения блоков данных).
5. Планирование очистки индекса: Записи в индексе, соответствующие удаленным документам Эпохи N, добавляются в список удаления следующей Эпохи (N+1) для последующей сборки мусора.

Какие данные и как использует

Патент является инфраструктурным и фокусируется на управлении доступом к данным, а не на анализе их содержимого для ранжирования.

Данные на входе

• Контентные факторы: Сами документы, представленные как последовательности токенов (GTokenIDs).
• Технические факторы: Используются внутренние системные идентификаторы: позиции токенов (TokenPos), глобальные и локальные идентификаторы документов (GDocID, LDocID), указатели и смещения в структурах данных FIFOArray.
• Системные данные: Статус потоков выполнения (активен/завершен), текущая эпоха, списки сборки мусора (Garbage Collection List).

Какие метрики используются и как они считаются

• ThreadCount (Счетчик потоков): Ключевая метрика синхронизации. Целочисленный счетчик, специфичный для эпохи. Увеличивается при старте запроса в эпоху, уменьшается при его завершении.
• Predefined Value (Предопределенное значение): Пороговое значение для ThreadCount (обычно 0), при достижении которого возможна безопасная сборка мусора.
• Epoch Ending Condition (Условие окончания эпохи): Метрики, определяющие длительность эпохи. Упоминаются:
  • Истекшее время с начала эпохи.
  • Количество документов, запланированных к удалению (инвалидированных) в течение эпохи.
• Accessible Range (Доступный диапазон): Метрики BeginRepositoryPos и EndRepositoryPos, определяющие границы видимой части репозитория.

1. Инфраструктура для свежести: Патент описывает не алгоритм ранжирования по свежести, а критически важную инфраструктуру, которая делает его возможным. Система спроектирована так, чтобы минимизировать задержку между получением обновленного контента и его доступностью в поиске (low latency updates).
2. Параллелизм с низкими издержками: Основная цель изобретения — позволить процессам записи (индексирование) и чтения (поиск) работать одновременно с минимальными издержками на синхронизацию. Захват глобальной блокировки происходит только на очень короткие моменты для обновления счетчиков или изменения Accessible Range.
3. Консистентность через снимки данных: Механизм эпох гарантирует, что каждый поисковый запрос работает с консистентным снимком индекса, каким он был на момент начала запроса. Запрос никогда не увидит частично обновленные данные.
4. Инвалидация ≠ Удаление: Существует четкое разделение между инвалидацией документа (пометка как устаревшего) и его физическим удалением. Удаление откладывается до момента, когда это безопасно (ThreadCount = 0).
5. Управление хранилищем (Treadmilling): Использование структуры FIFOArray для основного репозитория вводит необходимость в механизме Treadmilling для восстановления пространства. Это компромисс для достижения эффективности записи и чтения, требующий дополнительных фоновых операций по копированию данных.

Best practices (это мы делаем)

Хотя патент инфраструктурный, он дает понимание возможностей Google, что влияет на SEO-практики.

• Ориентация на скорость доставки контента: Поскольку Google способен индексировать обновления с минимальной задержкой, критически важно обеспечить быструю отдачу контента роботам (оптимизация скорости загрузки, быстрая генерация страниц) и своевременное уведомление о новинках (Sitemaps, Indexing API, WebSub для новостей).
• Публикация своевременного контента: В тематиках, где важна свежесть (QDF), следует максимально быстро публиковать качественный контент. Технических барьеров для попадания в индекс на стороне инфраструктуры Google практически нет, благодаря описанной архитектуре.
• Поддержание актуальности «вечнозеленого» контента: Регулярное обновление существующих статей является хорошей практикой. Система гарантирует, что пользователи будут переключены на новую версию практически мгновенно после ее индексации, в то время как старая версия будет корректно удалена.

Worst practices (это делать не надо)

• Предположение о долгих задержках индексации: Не стоит думать, что у Google уйдут дни или недели на обновление индекса из-за инфраструктурных ограничений. Архитектура спроектирована для работы в режиме, близком к реальному времени.
• Игнорирование скорости сайта для роботов: Если сайт медленно отвечает на запросы краулера, это сводит на нет преимущества быстрой инфраструктуры индексирования Google. Краулинговый бюджет будет расходоваться неэффективно, и свежесть контента пострадает.

Стратегическое значение

Этот патент подтверждает, что Google проектировал свою инфраструктуру с прицелом на максимальную свежесть и производительность. Для SEO-специалистов это означает, что конкуренция в реальном времени (Real-Time SEO), особенно в новостных и трендовых нишах, технически возможна и поддерживается базовой архитектурой поиска. Стратегия должна учитывать, что скорость реакции и публикации контента является важным элементом успеха.

Практические примеры

Патент описывает инфраструктуру, поэтому прямых SEO-примеров по оптимизации нет. Можно привести пример работы системы.

Сценарий: Обновление главной новости во время крупного события

1. Эпоха 1 (10:00:00): Новостной сайт публикует статью А («Событие началось»). Google индексирует ее. Множество пользователей ищут информацию. ThreadCount Эпохи 1 высокий.
2. Эпоха 2 (10:01:00): Сайт обновляет статью до версии Б («Важные новости о событии»). Google индексирует версию Б.
3. Действие системы:
   • Версия Б добавляется в репозиторий.
   • Accessible Range обновляется, чтобы включить Б.
   • Версия А инвалидируется и добавляется в Delete List Эпохи 2.
4. Поведение пользователей:
   • Пользователи, начавшие запрос в Эпоху 1, продолжают видеть версию А в выдаче (консистентный снимок).
   • Пользователи, начинающие запрос в Эпоху 2, видят версию Б.
5. Эпоха 3 (10:02:00): Запросы из Эпохи 1 завершаются. ThreadCount Эпохи 1 падает до 0.
6. Сборка мусора: Система безопасно удаляет версию А из индекса.

Результат: Переход от версии А к версии Б произошел быстро, без даунтайма и без показа пользователям некорректных или смешанных результатов.