Inverted index

Инвертированный индекс сопоставляет каждый термин со списком документов (postings), где он встречается — базовая структура быстрого полнотекстового поиска. Вместо сканирования всех документов движок ищет термин и пересекает списки вхождений.

					термин "клавиатура" → [doc1, doc7, doc42]
термин "беспроводная" → [doc1, doc9]
запрос AND           → [doc1]
				

В posting часто хранятся позиции и payloads для фразовых запросов и scoring. Сегменты на диске неизменяемы; новые записи идут в свежие сегменты до merge. Refresh открывает новые сегменты для читателей поиска.

На интервью: объясните, почему инвертированный индекс быстр для токенов, но слаб для произвольных подстрок и неиндексированных полей; свяжите postings с BM25; назовите merge и refresh как ручки latency vs freshness.

Типовые ошибки: ждать быстрый `contains` по неанализированной подстроке; гигантские posting lists по стоп-словам без фильтрации; не понимать, что удаления часто — tombstone до merge; путать инвертированный индекс с B-tree по первичному ключу.

Компромисс — молниеносный поиск по токенам против накладных расходов на хранение, CPU на merge и необходимости заранее спроектировать поля и анализаторы.

Чеклист:

• Определите отображение термин → postings list.
• Объясните boolean/phrase через пересечение списков.
• Свяжите сегменты, merge и refresh с видимостью в поиске.
• Сравните с прямым сканом документов и B-tree equality.
• Отметьте, что scoring использует частоту термина в postings.