|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Полнотекстовый поиск для Firebird [сообщение #4502 является ответом на сообщение #1209] |
Mon, 19 February 2024 12:39   |
shalamyansky
Сообщений: 149
Зарегистрирован: August 2022
|
Senior Member |
|
|
Перевожу свою систему и прилагаемый к ней FTS на боевые рельсы. Новый сервер с внушительным числом ядер и невообразимым количеством физической памяти. В качестве накопителей NVM SSD диски. Скорость последовательного чтения с такого диска, судя по тесту, 3,5 Gb/s. Firebird 5.0.
В качестве объекта FTS выступает одна таблица с 30 млн. записей и 8 индексируемыми полями размером от 10 до 200 символов. Соответственно построен 1 FTS индекс из 8 сегментов. На диске он занимает 4 Gb.
Так вот, время поиска по этому индексу составляет 3,5 сек., причем оно практически не зависит от сложности запроса. Время поиска я считаю как длительность исполнения процедуры FTS$SEARCH без дополнительных обвязок.
Задача в том, чтобы сократить время поиска, 3,5 сек. - это многовато. Пробовал перенести весь индекс FTS в физическую память (RAMDisk) - эффект нулевой. (Это даже при том, что скорость последовательного чтения с RAMDisk оказалась ниже, чем с NVM раза в 2).
Из данного наблюдения я делаю вывод, что время поиска в данных условиях определяется не скоростью чтения с накопителя, а скоростью исполнения алгоритма поиска, потребным процессорным временем. Наблюдая за процессом Firebird до, во время и после поиска, вижу, что число рабочих потоков не меняется, всю поисковую работу исполняет один-единственный поток того коннекта, который поиск и вызвал. Что обидно, потому что при этом вхолостую простаивают десятки свободных потоков.
В связи с этим следует вопрос. А нельзя ли ввести (включить, добавить) многопоточность в поиск? По смыслу задачи поиска она вроде как подлежит распараллеливанию.
Вопрос в первую голову автору, понятно. Но, может, у кого еще появятся соображения.
Спасибо!
[Обновления: Mon, 19 February 2024 12:40] Известить модератора |
|
|
|
|
|
| Re: Полнотекстовый поиск для Firebird [сообщение #4504 является ответом на сообщение #4503] |
Mon, 19 February 2024 13:12 |
shalamyansky
Сообщений: 149
Зарегистрирован: August 2022
|
Senior Member |
|
|
sim_84 писал(а) Mon, 19 February 2024 12:59Я лишь адаптировал библиотеку.
Я знаю. Но я подумал, может, там в библиотеке есть какой-нибудь волшебный флажок "Включить многопоточность". А что, а вдруг?
sim_84 писал(а) Mon, 19 February 2024 12:59
Хотелось бы уточнить: время поиска по индексу постоянно или первый поиск (внутри сессии) дольше?
Постоянно. Стабильно, почти как швейцарские часы. Все необходимое уже в памяти, быстрее никак.
sim_84 писал(а) Mon, 19 February 2024 12:59
ЗЫ. По идее скорость могла быть намного больше, если бы использовался не поисковый движок внутри UDR, а поисковый сервер, к которому бы обращалась UDR. Тогда бы кешированием и другой лабудой вроде распараллеливания уже занимался поисковый сервер.
Не собираетесь этим заняться? Так, на всякий случай спрашиваю. При наличии сервера можно было бы и напрямую с клиента к нему обращаться, тогда и UDR не нужна была бы.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Полнотекстовый поиск для Firebird [сообщение #4509 является ответом на сообщение #4508] |
Mon, 19 February 2024 14:35 |
shalamyansky
Сообщений: 149
Зарегистрирован: August 2022
|
Senior Member |
|
|
sim_84 писал(а) Mon, 19 February 2024 14:22Данная реализация всегда читает индекс с диска, не кешируя его. По идее файловый кеш должен помогать.
Клал индекс на RAMDisk, там файловый кеш скорее мешать будет, чем помогать. Но в моих условиях это вообще не имеет эффекта, узкое место не в доступе к данным, а в процессорном времени. Даже только по физической памяти алгоритму много бегать приходится.
sim_84 писал(а) Mon, 19 February 2024 14:22
Можно рассмотреть другие реализации, где UDR обращается к поисковому серверу, но это не быстро.
Если реализуете, и скорость вырастет, будет классно. Спасибо!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
