Индексация plain индексов и kill-list

[serhio]

@tomat

может вы соберете пример который можно воспроизвести локально и расследовать?

Это сделать пока сложно. Для этого нужна база источник, в которой нужно так же постоянно вносить изменения в записях: обновлять, добавлять и отмечать записи для удаления.

@tomat

как вы считаете количество документов - не понятно

Несколькими способами:

1. Это запросом с count котором идет выборка записей для индексации main:

• из Источника:

SELECT count(id) FROM product WHERE is_removed = 'f'

где is_removed - это флаг отметки на удаление документа: f - значит не удаленный

• из индекса: получаем индексированные документы из лога с collected
• из индекса: запросом с count для main:

SELECT count(*) FROM products_main_0, ... products_main_15

2. Это запросом с count котором идет выборка записей для индексации delta:

• из Источника:

sql_query_range: |
        SELECT (SELECT EXTRACT(EPOCH FROM data_relevant_to AT TIME ZONE 'Europe/Moscow') FROM manticore_indexer WHERE index_name='INDEX_MAIN') min, \
          (SELECT EXTRACT(EPOCH FROM indexing_started_at AT TIME ZONE 'Europe/Moscow') FROM manticore_indexer WHERE index_name='INDEX_DELTA') max
sql_query_where:
        delta: |
          WHERE is_removed = 'f' AND changed_at_timestamp >= $start AND changed_at_timestamp <= $end AND (id % CHUNK_SIZE) = CHUNK_MOD

где is_removed - это флаг отметки на удаление документа: f - значит не удаленный

• из индекса: получаем индексированные документы из лога с collected
• из индекса: запросом с count для delta:

SELECT count(*) FROM products_delta_0, ... products_delta_15

Это же количество совпадет из статистики:

show table products_main_0 status LIKE 'indexed_documents';
...
show table products_main_15 status LIKE 'indexed_documents';

Аналогично для delta.
На это же построен мониторинг.
По аналогии получаю количество для kill-list запросом из конфигурации:

SELECT count(id) FROM product \
            WHERE changed_at_timestamp >= (SELECT EXTRACT(EPOCH FROM data_relevant_to AT TIME ZONE 'Europe/Moscow') FROM manticore_indexer WHERE index_name='INDEX_MAIN')::int \
            AND changed_at_timestamp <= (SELECT EXTRACT(EPOCH FROM indexing_started_at AT TIME ZONE 'Europe/Moscow') FROM manticore_indexer WHERE index_name='INDEX_DELTA')::int AND (id % CHUNK_SIZE) = CHUNK_MOD
    sql_query_check_rotate:

где CHUNK_SIZE = 16, а CHUNK_MOD = от 0 до 15.

@tomat

какие номера документов лишние - не понятно
именно документы лишние или статистика по индексам кривая - не понятно

Тут не лишние, а delta с kill-list подавляет не правильно в новом индексе main.

@tomat

ну и другой вопрос если у вас сотни тысяч или миллионы документов в индексе, почему вы не используете RT индекс и постинг данных напрямую, без индексации?

В Источнике у нас порядка 2028927 записей и столько же должено быть в индексе.
Мы на текущий момент на RT и по ряду причин пытаемся перейти на plain индексацию, вместо RT.

@tomat

тк в main при каждой индексации имеет не правльное количество документов - как такое получается - не понятно

Сам main индекс приходит правильный после ротации. А вот последующая delta, собранная уже с новым диапазоном, которая содержит малое количество документов и kill-list применяется, но что-то в Manticore идет не так и мы теряем документы.

Опытным путем была выявлена одна закономерность, связанная с установкой даты для последующей индексации delta.
В Источнике (PostgreSQL) есть специальная таблица для индексации:

                                                                               Таблица "public.manticore_indexer"
           Столбец            |              Тип               | Правило сортировки | Допустимость NULL |           По умолчанию            | Хранилище | Сжатие | Цель для статистики | Описание  
-------------------------------+--------------------------------+--------------------+-------------------+-----------------------------------+-----------+--------+---------------------+----------
index_name                    | character varying(50)          |                    | not null          |                                   | extended  |        |                     |  
indexing_started_at           | timestamp(0) without time zone |                    | not null          | CURRENT_TIMESTAMP                 | plain     |        |                     |  
data_relevant_to              | timestamp(0) without time zone |                    | not null          | CURRENT_TIMESTAMP                 | plain     |        |                     |  
indexing_ended_at             | timestamp(0) without time zone |                    | not null          | CURRENT_TIMESTAMP                 | plain     |        |                     |  
indexing_product_changed_from | timestamp(0) without time zone |                    |                   | NULL::timestamp without time zone | plain     |        |                     |  
indexing_product_changed_to   | timestamp(0) without time zone |                    |                   | NULL::timestamp without time zone | plain     |        |                     |  
data_relevant_to_old          | timestamp(0) without time zone |                    | not null          | CURRENT_TIMESTAMP                 | plain     |        |                     |  
rotate_ended_at               | timestamp(0) without time zone |                    |                   | NULL::timestamp without time zone | plain     |        |                     |  
Индексы:
   "manticore_indexer_pkey" PRIMARY KEY, btree (index_name)
Метод доступа: heap

По окончанию индексации main на уровне утилиты indexer устанавливалась дата data_relevant_to в sql_query_post_index:

        INSERT INTO manticore_indexer (index_name, data_relevant_to) \
          VALUES ('INDEX_MAIN', (SELECT indexing_started_at FROM manticore_indexer WHERE index_name='INDEX_MAIN')) \
          ON CONFLICT (index_name) DO UPDATE SET data_relevant_to = EXCLUDED.data_relevant_to

data_relevant_to = indexing_started_at, т.е. началу индексации

В этом случае картина была иная:

Хронология событий:

1 delta отрабатывают на 0 минуте часа и все хорошо. Она собирает документы от прошлой полной индексации main до начала текущей индексации delta, т.е. уже за 1 час.

2, 3, 4 delta отрабатывают на 1, 2, 3 минуте часа и подавляет документы во все еще старом индексе main, но собранным с уже новым диапазоном от новой индексации main.
Но, т.к. дата data_relevant_to устанавливается в sql_query_post_index, то сам индекс еще не доставлен и не применен на поисковых node.

Затем на почти конце 3 минуты приходит ротация нового main и количество документов верное, совпадает с источником. А последующие delta не подавляют большое количество документов и вроде все хорошо.

Чтобы это исправить, запрос sql_query_post_index для main был исправлен на:

sql_query_post_index: |
        INSERT INTO manticore_indexer (index_name, indexing_ended_at) \
          VALUES ('INDEX_MAIN', (SELECT indexing_started_at FROM manticore_indexer WHERE index_name='INDEX_MAIN')) \
          ON CONFLICT (index_name) DO UPDATE SET indexing_ended_at = EXCLUDED.indexing_ended_at

Здесь устанавливается indexing_ended_at вместо data_relevant_to.
indexing_ended_at** это только для истории устанавливается и отслеживания работы.

А data_relevant_to устанавливается в скрипте уже после доставки и фактической ротации индекса main на поисковых node.
Но в этом случае имеем ситуацию как описал в начале - подавление большого количества документов в новом индексе main.

Ведь собранный индекс delta, который содержит в себе новые документы и список kill-list для подавления должен быть применен к main корректно на основе того, что собрал.
В обоих случаях есть не корректное применение kill-list к main ДО или ПОСЛЕ.
Вот это и не понятно.

Уж не знаю, есть ли какой способ узнать как внутри применяется kill-list? Т.к. в логах этого нет, кроме простой записи, чтоб применялся некий kill-list.