audetv
commented
1 year ago Почитал, подумал, протестировал на общей библиотеку 7733 книг. При тесте был установлен .wslconfig для эмуляции текущих ресурсов сервера
# Settings apply across all Linux distros running on WSL 2
[wsl2]
memory=2GB
processors=2
swap=2GBИзменил настройки файла конфигурации manticore
source common_library {
type = pgsql
sql_host = postgres
sql_user = app
sql_pass = secret
sql_db = common-library
sql_query_range = SELECT MIN(id),MAX(id) FROM db_pg_paragraphs
sql_range_step = 1000
sql_query = SELECT id, uuid, book_id, book_name, text, position, length from db_pg_paragraphs WHERE id>=$start AND id<=$end
sql_attr_uint = book_id
sql_attr_string = uuid
sql_attr_string = book_name
sql_field_string = text
sql_attr_uint = position
sql_attr_uint = length
}Далее установил значения как в примере из документации: Ranged queries
Main query, which needs to fetch all the documents, can impose a read lock on the whole table and stall the concurrent queries (eg. INSERTs to MyISAM table), waste a lot of memory for result set, etc. To avoid this, Manticore supports so-called ranged queries. With ranged queries, Manticore first fetches min and max document IDs from the table, and then substitutes different ID intervals into main query text and runs the modified query to fetch another chunk of documents. Here's an example.
Ranged query usage example:
sql_query_range = SELECT MIN(id),MAX(id) FROM documents sql_range_step = 1000 sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end If the table contains document IDs from 1 to, say, 2345, then sql_query would be run three times:
with $start replaced with 1 and $end replaced with 1000; with $start replaced with 1001 and $end replaced with 2000; with $start replaced with 2001 and $end replaced with 2345. Obviously, that's not much of a difference for 2000-row table, but when it comes to indexing 10-million-row table, ranged queries might be of some help.
Строка sql_query_range = SELECT MIN(id),MAX(id) FROM db_pg_paragraphs — задает максимальное и минимальное значение для диапазона
sql_range_step = 1000 — задаёт шаг для диапазона
sql_query = SELECT id, uuid, book_id, book_name, text, position, length from db_pg_paragraphs WHERE id>=$start AND id<=$end — сам запрос из таблицы с учетом запроса по диапазону значений.
UPD: Чтение в память происходит пакетами по 1000 записей, затем производится запись в индекс и читается следующий пакет.
Очистил предыдущий индекс мантикоры и запустил, получил такой результат:
В процессе индексирования документов:
Памяти было задействовано около 550 МБ и только в конце процесса показатели подскочили до 1.3Гб
Итого volume — 22.7Гб
И финальный скриншот 22.7 млн документов — 957 сек:
На 2Гб оперативной памяти и 2х процессорах В процессе индексирования наблюдал за дисками, так вот по ощущениям запись идет сразу в volume. т.к. в процессе там было замечено увеличение диска. На боевом сервере еще не тестировал, протестирую, если все будет хорошо, я предполагаю, то это сильно упрощает процесс обновления индексов. Т.к. скорость индексирования 957 сек, много меньше, чем загружать уже собранный индекс с локальной машины, но плюс к этому, я думаю, что в таком режиме открывается больше вариантов автоматизации.
Далее в планах протестировать distributed tables. хочу разбить индекс на несколько таблиц 1,2,3,4 и соединить их через destrubed таблицу, по описанием это может дать прирост в скорости поиска, так как поиск будет происходить параллельно в 4 таблицах, ( если сделать 4) Distributed-searching
To scale well, Manticore has distributed searching capabilities. Distributed searching is useful to improve query latency (i.e. search time) and throughput (ie. max queries/sec) in multi-server, multi-CPU or multi-core environments. This is essential for applications which need to search through huge amounts data (ie. billions of records and terabytes of text).
The key idea is to horizontally partition searched data across search nodes and then process it in parallel.
Partitioning is done manually. You should:
setup several instances of Manticore on different servers put different parts of your dataset to different instances configure a special distributed table on some of the searchd instances and route your queries to the distributedtable This kind of table only contains references to other local and remote tables - so it could not be directly reindexed, and you should reindex those tables which it references instead.
When Manticore receives a query against distributed table, it does the following:
connects to configured remote agents issues the query to them at the same time searches configured local tables (while the remote agents are searching) retrieves remote agent's search results merges all the results together, removing the duplicates sends the merged results to client From the application's point of view, there are no differences between searching through a regular table, or a distributed table at all. That is, distributed tables are fully transparent to the application, and actually there's no way to tell whether the table you queried was distributed or local.
Read more about remote nodes.
В планах проверить.
iprst
Возможно имеет смысл локально имитировать работу ограниченных конфигураций сервера для проверки разных подходов к оптимизации и эффективности проектов и того, как они себя будут вести на малых ресурсах, где у них бутылочные горлышки, возможно ли что-то улучшить в сценариях.
Пока совсем не понятно и тёмный лес. Для некоммерческих проектов это критично.
Цель оправдывают средства (с)