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

General Discussions - Russian
21

Проверил еще один кейс:

  • с начала нового часа и после окончания индексации и ротации нового main отключил индексацию delta

  • при ротации main был применен повторно kill-list, об этом есть в доке:

    If any of the tables from killlist_target are rotated, the kill-list is reapplied to these tables.

    Полагаю применяется какой-то из последних прошлых? Но откуда он его загружает: так же из файла или памяти?

  • выгрузил все индексированные id (2030055) из main:
    командой indextool --dumpdocids products_${index_type}_${inx},

    index_type: main и delta, inx: от 0 до 15

  • запустил проверку поиска по этим всем id через proxy (по распределенному индексу)

  • из 2030055 найдено 2029750, а 305 не найдено

Проверил все id из 305 - это из kill-list, которые были отмечены на удаление в Источнике с флагом is_removed = t. Т.е. здесь все ОК.

Далее вернул индексацию delta и после ее ротации получаем подавление документов в main на 15К и это не верно. Откуда был взят такой kill-list?
При этом в новой delta всего было проиндексировано 57 документов. Что тоже верно.

Непонятная логика с подавлением kill-list и что все-таки происходит внутри Manticoire при ротации? Остается вопросом.

22

все еще не понятно.
Я объясню как оно работает - все изменения klist остаются навсегда.
Если вы ротируете много delta внутри часа, то изменения от каждой delta применяются на одну и ту же main таблицу и остаются в таблице main навсегда.

Если вы ротируете main - тогда

  • если в этот момент delta пустая, то main не поменяется
  • если у вас в delta есть klist - то он применится на новый main
23

возможно вам подойдет --drop-src опция при мерже delta таблицы в main таблицу описаная в мануале Data creation and modification > Adding data from external storages > Adding data to tables > Merging tables | Manticore Search Manual

24

Так я и расписал как это настроено.
Ведь согласно документации есть main, который большой и индексируется не часто и есть delta, маленькая и несет в себе изменения, которые применяются к delta из kill-list (в зависимости от режима killlist_target).

У нас main индексируется каждый час, а delta каждую минуту.
Т.е. собрали main, а к нему применяем новые delta.
И вся проблема в том, что как только собрали новую delta - с новым диапазоном от последней индексации main, а это всего 3-4 минуты, то получаем подавление документов в main. И эти документы недоступны для поиска. А их id при этом нет в последней новой delta и ее kill-list.

25

Вот здесь можете объяснить про какую delta идет речь?

У нас есть последняя delta, собранная на диапазоне от старого main и примененная на старом main ДО новой индексации и ротации main.
Затем идет новый main, применяется и к нему применяется kill-list верный (об этом выше писал).
Теперь у нас новый main с примененным kill-list.
Но как только проходит ротации новой detla, то все идет не так. Как это объяснить? kill-list был применен при ротации main и все было ОК, а при новой delta уже не верно. Здесь даже не ее kill-list был применен.
Больше никакой delta нет в этот момент.

При этом на старой версии 6.0.2 вроде, которая из курса такого поведения нет. Там конечно простой пример, но в нем специально проверял изменения и индексацию main и delta и затем еще раз main (после изменений в БД) и после delta. Все корректно там.

26

если в момент ротации main индекса в демоне есть delta у которой есть killlist_target в котором фигурирует main, то эта delta применится к новому main

27

Тогда здесь все в порядке. Я выше об этом писал:

Проверил все id из 305 - это из kill-list, которые были отмечены на удаление в Источнике с флагом is_removed = t . Т.е. здесь все ОК.

Проблема то идет с новой delta уже после ротации нового main. При этом это не ее kill-list применяется, вот это и не понятно.

28

когда вы ротировали новый main у вас был delta индекс в демоне?
если был delta индекс и он был не пустой, то в новом main индексе подавились документы из этого delta индекса

29

Да был ранее индексированный и примененный. И с этим нет проблемы.
На примере:

  • в 18:02 была delta и применена к еще текущему main - все ОК
  • в 18:03:09 был применен новый mian и после его ротации к нему применен повторно kill-list - тут все ОК, документы все доступны для поиска и нет пропажи
  • в 18:04 запускается новая delta с новым диапазоном изменений от 18:00 до 18:04, проходит ротация и применяется к новому main. И вот здесь мы теряем документы в несколько тысяч. А этого быть не должно. В новой delta допустим 50 документов, а ее kill-list состоит только из id удаленных документов. А killlist_target задан как killlist_target: "INDEX_MAIN", т.е. id из delta и id kill-list (только с is_removed = 't').

Что в этом случае должно произойти?

30

Ниже представлен пример в рамках курса: Manticore Search - Main+delta schema

Собираем main:

root@maindelta-6f4db574f-2cq47:/# sudo -u manticore indexer main
Manticore 6.0.4 1a3a4ea82@230314
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
Copyright (c) 2017-2023, Manticore Software LTD (https://manticoresearch.com)

using config file '/etc/manticoresearch/manticore.conf'...
WARNING: key 'read_timeout' is deprecated in /etc/manticoresearch/manticore.conf line 45; use 'network_timeout' instead.
WARNING: key 'max_children' was permanently removed from configuration. Refer to documentation for details.
WARNING: key 'preopen_indexes' is deprecated in /etc/manticoresearch/manticore.conf line 48; use 'preopen_tables' instead.
WARNING: key 'workers' is deprecated in /etc/manticoresearch/manticore.conf line 50; use 'default value' instead.
indexing table 'main'...
collected 9 docs, 0.0 MB
creating lookup: 0.0 Kdocs, 100.0% done
sorted 0.0 Mhits, 100.0% done
total 9 docs, 117 bytes
total 176.703 sec, 0 bytes/sec, 0.05 docs/sec
total 3 reads, 0.000 sec, 0.1 kb/call avg, 0.0 msec/call avg
total 17 writes, 0.000 sec, 0.1 kb/call avg, 0.0 msec/call avg

Выполняем ротацию и проверяем main:

root@maindelta-6f4db574f-2cq47:/# mysql -P9306 -h0
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 6.0.4 1a3a4ea82@230314 git branch HEAD (no branch)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> RELOAD TABLES;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM main;
+------+----------------+------------+
| id   | title          | updated    |
+------+----------------+------------+
|    1 | Document One   | 1719397970 |
|    2 | Document Two   | 1719397970 |
|    3 | Document Three | 1719397970 |
|    4 | Document Four  | 1719397970 |
|    5 | Document Five  | 1719397970 |
|    6 | Document Six   | 1719397970 |
|    7 | Document Seven | 1719397970 |
|    8 | Document Eight | 1719397970 |
|    9 | Document Nine  | 1719397970 |
+------+----------------+------------+
9 rows in set (0.00 sec)

Далее вносим правки в Источнике:

root@maindelta-6f4db574f-2cq47:/# mysql test -u user --password=pass123
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.40 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> INSERT INTO documents VALUES(10,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE documents SET title='Altered document Six' WHERE id=6;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE documents SET deleted=1 WHERE id=5;exit;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Собираем, выполняем ротацию и проверяем delta:

root@maindelta-6f4db574f-2cq47:/# sudo -u manticore indexer delta
Manticore 6.0.4 1a3a4ea82@230314
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
Copyright (c) 2017-2023, Manticore Software LTD (https://manticoresearch.com)

using config file '/etc/manticoresearch/manticore.conf'...
WARNING: key 'read_timeout' is deprecated in /etc/manticoresearch/manticore.conf line 45; use 'network_timeout' instead.
WARNING: key 'max_children' was permanently removed from configuration. Refer to documentation for details.
WARNING: key 'preopen_indexes' is deprecated in /etc/manticoresearch/manticore.conf line 48; use 'preopen_tables' instead.
WARNING: key 'workers' is deprecated in /etc/manticoresearch/manticore.conf line 50; use 'default value' instead.
indexing table 'delta'...
collected 2 docs, 0.0 MB
creating lookup: 0.0 Kdocs, 100.0% done
sorted 0.0 Mhits, 100.0% done
total 2 docs, 32 bytes
total 1.702 sec, 18 bytes/sec, 1.17 docs/sec
total 3 reads, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
total 18 writes, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
root@maindelta-6f4db574f-2cq47:/# mysql -P9306 -h0
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 6.0.4 1a3a4ea82@230314 git branch HEAD (no branch)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> RELOAD TABLES;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM delta;
+------+----------------------+------------+
| id   | title                | updated    |
+------+----------------------+------------+
|    6 | Altered document Six | 1752045845 |
|   10 | Document Ten         | 1752045844 |
+------+----------------------+------------+
2 rows in set (0.00 sec)

Проверяем main:

mysql> SELECT * FROM main;
+------+----------------+------------+
| id   | title          | updated    |
+------+----------------+------------+
|    1 | Document One   | 1719397970 |
|    2 | Document Two   | 1719397970 |
|    3 | Document Three | 1719397970 |
|    4 | Document Four  | 1719397970 |
|    7 | Document Seven | 1719397970 |
|    8 | Document Eight | 1719397970 |
|    9 | Document Nine  | 1719397970 |
+------+----------------+------------+
7 rows in set (0.00 sec)

И смотрим в распределенной таблице общий результат:

mysql> SELECT * FROM mytable;
+------+----------------------+------------+
| id   | title                | updated    |
+------+----------------------+------------+
|    6 | Altered document Six | 1752045845 |
|    1 | Document One         | 1719397970 |
|    2 | Document Two         | 1719397970 |
|   10 | Document Ten         | 1752045844 |
|    3 | Document Three       | 1719397970 |
|    4 | Document Four        | 1719397970 |
|    7 | Document Seven       | 1719397970 |
|    8 | Document Eight       | 1719397970 |
|    9 | Document Nine        | 1719397970 |
+------+----------------------+------------+
9 rows in set (0.00 sec)

Внесем правки в Источнике:

root@maindelta-6f4db574f-2cq47:/# mysql test -u user --password=pass123
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.7.40 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> INSERT INTO documents VALUES(11,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.02 sec)

mysql> INSERT INTO documents VALUES(12,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE documents SET title='Altered documentssssx' WHERE id=7;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE documents SET title='Altered dRRRR' WHERE id=3;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE documents SET deleted=1 WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Соберем и выполним ротацию main:

root@maindelta-6f4db574f-2cq47:/# sudo -u manticore indexer main --rotate
Manticore 6.0.4 1a3a4ea82@230314
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
Copyright (c) 2017-2023, Manticore Software LTD (https://manticoresearch.com)

using config file '/etc/manticoresearch/manticore.conf'...
WARNING: key 'read_timeout' is deprecated in /etc/manticoresearch/manticore.conf line 45; use 'network_timeout' instead.
WARNING: key 'max_children' was permanently removed from configuration. Refer to documentation for details.
WARNING: key 'preopen_indexes' is deprecated in /etc/manticoresearch/manticore.conf line 48; use 'preopen_tables' instead.
WARNING: key 'workers' is deprecated in /etc/manticoresearch/manticore.conf line 50; use 'default value' instead.
indexing table 'main'...
collected 10 docs, 0.0 MB
creating lookup: 0.0 Kdocs, 100.0% done
sorted 0.0 Mhits, 100.0% done
total 10 docs, 142 bytes
total 178.896 sec, 0 bytes/sec, 0.05 docs/sec
total 3 reads, 0.000 sec, 0.1 kb/call avg, 0.0 msec/call avg
total 17 writes, 0.000 sec, 0.1 kb/call avg, 0.0 msec/call avg
rotating tables: successfully sent SIGHUP to searchd (pid=42).

Проверяем распределенный индекс:

mysql> SELECT * FROM mytable;
+------+-----------------------+------------+
| id   | title                 | updated    |
+------+-----------------------+------------+
|    2 | Document Two          | 1719397970 |
|    6 | Altered document Six  | 1752045845 |
|    4 | Document Four         | 1719397970 |
|   10 | Document Ten          | 1752045844 |
|    8 | Document Eight        | 1719397970 |
|    9 | Document Nine         | 1719397970 |
|   11 | Document Ten          | 1752045965 |
|   12 | Document Ten          | 1752045968 |
|    3 | Altered dRRRR         | 1752045986 |
|    7 | Altered documentssssx | 1752045978 |
+------+-----------------------+------------+
10 rows in set (0.00 sec)

Внесем теперь правки в Источник:

root@maindelta-6f4db574f-2cq47:/# mysql test -u user --password=pass123
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.7.40 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> UPDATE documents SET title='AltereTTTTx' WHERE id=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE documents SET title='AltereTTTTx' WHERE id=10;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> INSERT INTO documents VALUES(13,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO documents VALUES(14,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO documents VALUES(15,'Document Ten',NOW(),0);
Query OK, 1 row affected (0.08 sec)

И соберем и выполним ротацию уже новой delta к новому main:

root@maindelta-6f4db574f-2cq47:/# sudo -u manticore indexer delta --rotate
Manticore 6.0.4 1a3a4ea82@230314
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
Copyright (c) 2017-2023, Manticore Software LTD (https://manticoresearch.com)

using config file '/etc/manticoresearch/manticore.conf'...
WARNING: key 'read_timeout' is deprecated in /etc/manticoresearch/manticore.conf line 45; use 'network_timeout' instead.
WARNING: key 'max_children' was permanently removed from configuration. Refer to documentation for details.
WARNING: key 'preopen_indexes' is deprecated in /etc/manticoresearch/manticore.conf line 48; use 'preopen_tables' instead.
WARNING: key 'workers' is deprecated in /etc/manticoresearch/manticore.conf line 50; use 'default value' instead.
indexing table 'delta'...
collected 5 docs, 0.0 MB
creating lookup: 0.0 Kdocs, 100.0% done
sorted 0.0 Mhits, 100.0% done
total 5 docs, 58 bytes
total 1.702 sec, 34 bytes/sec, 2.93 docs/sec
total 3 reads, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
total 18 writes, 0.000 sec, 0.0 kb/call avg, 0.0 msec/call avg
rotating tables: successfully sent SIGHUP to searchd (pid=42).

Проверяем распределенный индекс:

mysql> SELECT * FROM mytable;
+------+-----------------------+------------+
| id   | title                 | updated    |
+------+-----------------------+------------+
|    4 | AltereTTTTx           | 1752046237 |
|    2 | Document Two          | 1719397970 |
|   10 | AltereTTTTx           | 1752046241 |
|   13 | Document Ten          | 1752046249 |
|    8 | Document Eight        | 1719397970 |
|    9 | Document Nine         | 1719397970 |
|   14 | Document Ten          | 1752046252 |
|   15 | Document Ten          | 1752046256 |
|   11 | Document Ten          | 1752045965 |
|   12 | Document Ten          | 1752045968 |
|    3 | Altered dRRRR         | 1752045986 |
|    7 | Altered documentssssx | 1752045978 |
+------+-----------------------+------------+
12 rows in set (0.00 sec)

Итого:

  • собрали и применили main
  • внесли правки в Источнике
  • собрали и применили delta к main
  • результат ОК
  • внесли правки в Источнике
  • собрали уже новый main и выполнили ротацию
  • результат ОК
  • внесли правки в Источнике
  • собрали уже новую delta и применили к новому main
  • результат ОК
    Все документы: новые, измененные и старые на месте. Удаленные и обновленные подавлены. Т.е. проблемы нет.

Это на старой версии 6.0.4. Такой же результат ожидается на 7.0.0.

Отличительная разница в примере и нашем случае:

  • в примере данных слишком мало и сборка main быстрая (относительно)
  • дата created_at в таблице deltabreaker устанавливает раньше чем нужно, ведь фактически индексация main еще может быть не закончена и тем более не применена в Manticore

У нас же дата для нового диапазона устанавливается не в sql_query_post_index, а после синхронизации на поисковые node и фактической ротации main.
И как писал ранее от этого диапазона зависит результат сборки и применения delta к main:

  • если дату ставить раньше чем нужно в sql_query_post_index, то delta будет собирается с новым диапазоном и после ротации к еще старому main начнет подавлять документы в нем ДО новой ротации main, а этого быть не должно
  • если дату ставить после фактической ротации нового main, то delta будет собирается с новым диапазоном (это верно) и после ротации к уже новому main будет подавлено большое количество документов. При этом это не соответствует числу документов в новой delta и ее kill-list вне зависимости от режима.
31

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

тк мне до сих пор не понятен как выглядит конкретно “плохая” ротация, какие именно документы удаляются неправильно

вот этот пункт тоже не понятен

У нас же дата для нового диапазона устанавливается не в sql_query_post_index , а после синхронизации на поисковые node и фактической ротации main.

если индексация завершилась с каким то таймстампом, а вы ставите другой тайстамп (после ротации файлов индекса) - то у вас получается gap при следующей индексации

и про это вопрос

  • если дату ставить раньше чем нужно в sql_query_post_index, то delta будет собирается с новым диапазоном и после ротации к еще старому main начнет подавлять документы в нем ДО новой ротации main, а этого быть не должно

ротация нового main должна происходить при delta с пустым killist. Если вы ротируете новый main, а у вас в delta есть killist - то он применится к новому main. killist_target всегда применяется, он не смотрит на даты файлов \ новее \ старее - там всеравно

32

Я об этом как раз выше писал с примерам.
Вот повторно.
На примере:

  • в 18:02 была delta и применена к еще текущему main - все ОК
  • в 18:03:09 был применен новый mian и после его ротации к нему применен повторно kill-list - тут все ОК, документы все доступны для поиска и нет пропажи
  • в 18:04 запускается новая delta с новым диапазоном изменений от 18:00 до 18:04, проходит ротация и применяется к новому main. И вот здесь мы теряем документы в несколько тысяч. А этого быть не должно. В новой delta допустим 50 документов, а ее kill-list состоит только из id удаленных документов. А killlist_target задан как killlist_target: "INDEX_MAIN", т.е. id из delta и id kill-list (только с is_removed = 't').

Поясню что здесь происходит.
Полная индексация у нас запускается 1 раз в час и занимает ~2-3 минуты включая ротацию, т.е. от начала задачи и до конца.
delta индексируется каждую минуты ~9-15 секунд на все, включая ротацию.

На примере выше:

  • в 18:00:01 запускается индексация main и начинает собирать по каждому chunks документы… На этом этапе этот индекс еще не доставлен и не применен на поисковых node. Это ОК
  • в 18:00:01 запускается delta с еще старым диапазоном от 17:00:01 и до 18:00:01 (это запуск текущей delta) и применяется к текущему main - все ОК
  • в 18:01:01 запускается delta с еще старым диапазоном от 17:00:01 и до 18:01:01 (это запуск текущей delta) и применяется к текущему main - все ОК
  • в 18:02:01 запускается delta с еще старым диапазоном от 17:00:01 и до 18:02:01 (это запуск текущей delta) и применяется к текущему main - все ОК
  • в 18:03:00 и примерно до 18:03:40 идет параллельная синхронизация main на поисковые node
  • в 18:03:40 запускается параллельная ротация main и после этого выполняется запрос в Источник для установки дат запросом:
          INSERT INTO manticore_indexer (index_name, data_relevant_to, data_relevant_to_old, rotate_ended_at)
          VALUES (
            'INDEX_MAIN',
            (SELECT indexing_started_at FROM manticore_indexer WHERE index_name='INDEX_MAIN'),
            (SELECT data_relevant_to FROM manticore_indexer WHERE index_name='INDEX_MAIN'),
            NOW()
          )
          ON CONFLICT (index_name) DO UPDATE SET data_relevant_to = EXCLUDED.data_relevant_to, data_relevant_to_old = EXCLUDED.data_relevant_to_old, rotate_ended_at = EXCLUDED.rotate_ended_at;
    delta:
    При этой же ротации применяется kill-list повторно. После этого у нас все документы доступны для поиска, кроме удаленных документов. Это ОК.
  • в 18:03:01 запускается delta с еще старым диапазоном от 17:00:01 и до 18:03:01 (это запуск текущей delta), но пропускается, т.к. уже был применен новый main
  • в 18:04:01 запускается delta уже с новым диапазоном от 18:00:01 и до 18:04:01 (это запуск текущей delta), и применяется к текущему main - и мы получаем большое количество подавленных документов. Это не правильно из даже нет в новой delta и ее kill-list.
  • в 18:05:01 запускается delta с новым диапазоном от 18:00:01 и до 18:05:01 (это запуск текущей delta), и применяется к текущему main - тут ОК
    Все последующие delta корректно работает до следующей полной индексации и ротации main.

А при ротации новой delta к новому main почему-то подавляются все id документов, которые не были изменены (значение в changed_at_timestamp таблице источника) до нового часа, а именно ДО 18:00 включительно до 01 минуты.

Об этом тоже писал здесь: Индексация plain индексов и kill-list - #20 by serhio

И как уже ранее говорил это зависит на прямую от диапазона с каким собрать delta.
Ведь индексация и доставка main не мгновенная и занимает до 3-4 минут, а это значит что нельзя менять дату индексации для 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_killlist:

SELECT 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

При этом даже если собрать main еще раз в течении этого же часа, то с последующей первой delta будет непонятное подавление большого количества документов.

Надеюсь так понятнее.

33

Как это можно сделать?
Например, если сделать костыль через ALTER для killlist_target и обнулить его? А после ротации вернуть обратно.

Это понятно, что при ротации main применяется повторно kill-list. Но после этого проблемы нет. Она возникает только с новой delta примененной к новому main, а последующие delta проходят корректно.

34

возможно вам подойдет --drop-src опция при мерже delta таблицы в main таблицу описанная в мануале Data creation and modification > Adding data from external storages > Adding data to tables > Merging tables | Manticore Search Manual

35

Ротация сейчас применяется SQL командой RELOAD TABLE <plain_table>;.
Это сделано для того, чтобы можно было выполнять ротацию только нужных индексов.

36

ну как я уже и писал - нужен или маленький пример как вы сделали

в рамках курса: Manticore Search - Main+delta schema

но на котором бы было видно, как воспроизводится проблема

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

  • добавили какой-то не нужный документ в источник и подавляли его дельтой
  • выполняли запрос SELECT * FROM idx WHERE id='non_sence' OPTION comment=‘rotation_gen_num’` - который бы показал наличие или подавление этого документа
  • дальше если демон запущен с опцией --logdebug то в логе демона будут логированы события с файлами, в том числе и начало и окончание ротации файлов. И эти события можно было бы сравнить в тайстампом из query.log для запроса с меткой rotation_gen_num

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

(это запуск текущей delta), и применяется к текущему main - и мы получаем большое количество подавленных документов. Это не правильно из даже нет в новой delta и ее kill-list.

чтобы были видны все события и их можно было соотнести одно с другим