| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	
		
		
			| Re: Полнотекстовый поиск для Firebird [сообщение #4502 является ответом на сообщение #1209] | 
			Mon, 19 February 2024 12:39    | 
		 
		
			
				
				
				
					
						  
						shalamyansky
						 Сообщений: 150 Зарегистрирован: 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
						 Сообщений: 150 Зарегистрирован: 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
						 Сообщений: 150 Зарегистрирован: August 2022 
						
					 | 
					Senior Member  | 
					 | 
		 
		 
	 | 
 
	
		sim_84 писал(а) Mon, 19 February 2024 14:22Данная реализация всегда читает индекс с диска, не кешируя его. По идее файловый кеш должен помогать. 
 
Клал индекс на RAMDisk, там файловый кеш скорее мешать будет, чем помогать. Но в моих условиях это вообще не имеет эффекта, узкое место не в доступе к данным, а в процессорном времени. Даже только по физической памяти алгоритму много бегать приходится. 
 
sim_84 писал(а) Mon, 19 February 2024 14:22 
Можно рассмотреть другие реализации, где UDR обращается к поисковому серверу, но это не быстро. 
 
Если реализуете, и скорость вырастет, будет классно. Спасибо! 
		
		
		
 |  
	| 
		
	 | 
 
 
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 | 
	| 
		
 |