Тюним поиск

[melnikaite]

а как ее очистить, если нет доступа к базе, есть только фтп?
генератором db_apdate файлов сделать?

Код: Выделить всё

TRUNCATE `phpbb_search_wordlist`;

я думал мод сам очистит
это ничего что phpbb все русские слова пишет в верхнем регистре а мод индексирует в нижнем?

[Kir-Dagoor]

Братцы, нашел ошибку в процедуре add_search_words (includes\functions_search.php)

Она приводит к дублированию слов в таблице search_wordlist, непомерному разрастанию таблицы search_wordmatch, и как следствие - тормоза при постинге. Все это справедливо для форумов на базе mysql.

В моем форуме 11 тыс постов, таблица search_wordmatch разрасталась до 8 млн записей и весила 200 Мб. Реиндексирование базы длилось 8 часов.

После исправления ошибки базы переиндексировались за 20 минут , размер search_wordlist составил 44 тыс записей и ~1 Мб, search_wordmatch составил 250 тыс записей и ~5 Мб. по весу


Смотрим:

Код: Выделить всё

#-----[ OPEN ]------------------------------------------
#
includes/functions_search.php

#
#-----[ FIND ]------------------------------------------
#
	$sql = "SELECT word_id, word_text     
	FROM " . SEARCH_WORD_TABLE . " 
	WHERE word_text IN ($word_text_sql)";
#
#-----[ BEFORE, ADD ]------------------------------------------
#
	case 'mysql':
	case 'mysql4':

#
#-----[ SAVE/CLOSE ALL FILES ]------------------------------------------
#
# EoM

Суть ошибки в том, что для баз mysql слова в каждом новом посте не проверялись на совпадение с уже занесенными в базу. Получалось дублирование. Особенно это заметно при квотировании.

З.Ы. Народ, кто способный по англицки, донесите плз данный глюк до разработчиков форума, ведь это фактически делает поиск неработоспособным и его попросту отрубают.



Добавлено спустя 14 минут 5 секунд:

Вот еще в качестве тюнинга.

На моем хостинге некорректно работает процедура php strtolower с русскими символами. Плюс к этому фильтр работает неоптимально. Поэтому:

Код: Выделить всё

#
#-----[ OPEN ]------------------------------------------
#
includes/functions_search.php

#
#-----[ FIND ]------------------------------------------
#
	static $drop_char_match =   array('^', '$', '&', '(', ')', '<', '>', '`', '\'', '"', '|', ',', '@', '_', '?', '%', '-', '~', '+', '.', '[', ']', '{', '}', ':', '\\', '/', '=', '#', '\'', ';', '!');
	static $drop_char_replace = array(' ', ' ', ' ', ' ', ' ', ' ', ' ', '',  '',   ' ', ' ', ' ', ' ', '',  ' ', ' ', '',  ' ',  ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' , ' ', ' ', ' ', ' ',  ' ', ' ');

	$entry = ' ' . strip_tags(strtolower($entry)) . ' ';
#
#-----[ REPLACE ]------------------------------------------
#
	static $drop_char_match =   array('A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', "А", "Б", "В", "Г", "Д", "Е", "Ё", "ё", "Ж", "З", "И", "Й", "К", "Л", "М", "Н", "О", "П", "Р", "С", "Т", "У", "Ф", "Х", "Ц", "Ч", "Ш", "Щ", "Ъ", "Ы", "Ь", "Э", "Ю", "Я", '•', '^', '$', '&', '(', ')', '<', '>', '`', '\'', '"', '|', ',', '@', '_', '?', '%', '-', '~', '+', '.', '[', ']', '{', '}', ':', '\\', '/', '=', '#', '\'', ';', '!', "«", "»", "“", "”", "©",  "№");
	static $drop_char_replace = array('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', "а", "б", "в", "г", "д", "е", "е", "е", "ж", "з", "и", "и", "к", "л", "м", "н", "о", "п", "р", "с", "т", "у", "ф", "х", "ц", "ч", "ш", "щ", "ъ", "ы", "ь", "э", "ю", "я", ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', '',  '',   ' ', ' ', ' ', ' ', '',  ' ', ' ', '',  ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' , ' ', ' ', ' ', ' ' , ' ', ' ', ' ', ' ', ' ', ' ', ' ',  ' ');

	$entry = ' ' . strip_tags($entry) . ' ';


#
#-----[ FIND ]------------------------------------------
#

	$entry = preg_replace('/[ ]([\S]{1,2}|[\S]{21,})[ ]/',' ', $entry);
	}
#
#-----[ REPLACE ]------------------------------------------
#

	while (ereg('[[:space:]]+([[:alnum:]]{1,3}|[:alnum:]{21,})[[:space:]]+', $entry)) {
			$entry = ereg_replace('[[:space:]]+([[:alnum:]]{1,3}|[:alnum:]{21,})[[:space:]]+',' ', $entry);
			$entry = ereg_replace('[[:space:]]+',' ', $entry);
			}
	}
	$entry = ereg_replace('[[:digit:]][[:alnum:]]{1,4}',' ', $entry);

#
#-----[ SAVE/CLOSE ALL FILES ]------------------------------------------
#
# EoM 

[avm]

Братцы, нашел ошибку в процедуре add_search_words

мда... точно так и есть.

[Xpert]

Kir-Dagoor
Мда...
Спасибо... пошел писать разработчикам.

Добавлено спустя 11 минут 38 секунд:

Донес, ждем...

[Admin_777]

По моему все проще. Там значения в данном поле уникальные, поэтому дубликатов быть не должно.
Однако, лучше следить за этим на уровне кода, т.к. при восстановлении базы при аварии, админ предыдущего нашего хостинга при восстановлении базы форума, не долго думая, сменил в таблице search_wordlist поле word_text на индексируемое поле (а должно быть первичным ключом), отчего значения внутри него перестали быть уникальными.

[Kir-Dagoor]

Кстати, да. Почему-то отсутствовал первичный ключ в таблице search_wordlist. Странно. В дефолтной базе ключ есть.

Возможно в этом свете заявленная ошибка таковой не является.

[Admin_777]

В этом свете да, но как показала практика, некоторые на этом серьезно горят. Пока разберешься что к чему...

[Marka]

А скажите, пожалуйста, сколько ориентировочно будет длиться обновление поисковой базы для БД размером 80 метров (написано в админке, есси бэкапишь то 49, сообщений накидано 67032) с помощью db maintance и rebuild_search?

[Admin_777]

Точной информации не даст никто.
1. Время зависит от железа (в особенности от HDD и количества ОЗУ, хотя CPU тоже со счетов нельзя сбрасывать).
2. Время зависит от настроек MySQL.
3. Обычно на сервере по мимо форума еще куча пользователей, которые в этот момент вдруг тоже захотят что-то сделать со своей базой.
4. Ну и самое последнее (не менее главное), время зависит от размера сообщений. Если это рассказы - долго все будет. Если несколько строчные сообщения, то гораздо быстрее.

[neznayka]

переиндексировал базу с помощбю reindex_mod
теперь при восстанавливании базы из бэкапа выдает кучу ошибок ERROR 1062: Duplicte entry '...' for key 1

кажется проблема в регистре символов

Сделано тоже-самое и такие же ошибки. Предварительно были очищены таблицы: "phpbb_search_results", "phpbb_search_wordlist" и "search_wordmatch".
Похоже, проблема с регистром.
Кодировка соединения - cp_1251_general_ci (многоязычный, нечувствительный к регистру).

CREATE TABLE `phpbb_search_wordlist` (
`word_text` varchar(50) character set cp1251 collate cp1251_bin NOT NULL default '',
`word_id` mediumint(8) unsigned NOT NULL auto_increment,
`word_common` tinyint(1) unsigned NOT NULL default '0',
PRIMARY KEY (`word_text`),
KEY `word_id` (`word_id`),
FULLTEXT KEY `word_text` (`word_text`),
FULLTEXT KEY `word_text_2` (`word_text`),
FULLTEXT KEY `word_text_3` (`word_text`)
) ENGINE=MyISAM AUTO_INCREMENT=46172 DEFAULT CHARSET=cp1251;

Вроде все правильно... Куда рыть-то?

[MAzZY]

DROP TABLE IF EXISTS phpbb_search_wordlist;

[neznayka]

Может кому поможет. Решение моей проблемы (см.выше) заключалось в том, что нужно было всего-навсего убрать в параметре `word_text` в колонке "Сравнение" значение (у меня было cp_1251_bin), оставить строку пустой. После этого, в вышеупомянутой строке автоматически установилось значение SQL-соединения по-умолчанию. У меня оно "cp_1251_general_ci" (нечувствительный к регистру), что было и нужно. После запуска "Rebuild Search", поиск стал работать. 8)

[Jovani]

Разрешите справочку. Это если залить стоп-вордс и синонимы и запустить переиндексацию, размер базы в целом может в теории уменьшиться?

По моему, это не справочка, а вопрос ...

Ответ - может уменьшится, а может - увеличится.
Зависит от многих факторов.
Кроме того, большой список стоп-слов может сильно тормознуть постинг.
То есть, отправку сообщений.
Стоп-слова, лучше удалять отдельным скриптом ИМХО, и через несколько списков, а не через один.

[Змей]

Может конечно я ошибаюсь, но попробуй перед переиндексацией, в functions_search.php
Изменить:
remove_common('single', 4/10, $word);

Скажем на:
remove_common('single', 1/30, $word);

Можно простым языком пояснить - что это даст?

вообще-то, у меня тоже были проблемы со временем переиндексации, и я ее проводил частями. То есть, был сделан скрипт и временно создана была дополнительная таблица, куда записывался ID последнего индексированного сообщения ...
Постепенно, за недельку, пока был в онлайн, я все переиндексировал.

А поделиться скриптом и способом его применения не можете?

Попробуй закинуть в корень и выполнить этот скрипт

Попробовал - быстро! Записей в таблицах чуть меньше, чем после reindex_mod. Для более глубокого сравнения результатов моих знаний недостаточно. Хотелось бы понять - в чем фишка, скорость - не в ущерб качеству?

[Слономатка]

После ребилда с помощью reindex_mod в статистике форума появился следующий лаг: "Сообщений в день" == "Кол-во сообщений" !!! Перерыл всё, до чего додумался, единственная зацепка в admin/index.php:

Код: Выделить всё

        if($posts_per_day > $total_posts)
        {
                $posts_per_day = $total_posts;
        }

Только не пойму, с чего бы вдруг $posts_per_day стало больше, чем $total_posts, если $posts_per_day = sprintf("%.2f", $total_posts / $boarddays), а $boarddays у меня не изменился? К примеру "Тем в день" и "Пользователей в день" отображается правильно. Чё за фигня?!

Добавлено спустя 5 минут 59 секунд:

Ксати, этот мод после того, как делает своё чёрное дело, форумы обратно не разблокирует, приходится вручную блин.

Добавлено спустя 17 минут 57 секунд:

Э-э-э... на втором форуме всё прошло гладко. Чё щас делать?

Добавлено спустя 1 час 55 минут 36 секунд:

Только что проверил, сути происходящего не понял:

Код: Выделить всё

print_r($posts_per_day.' :: '.$total_posts);

        if($posts_per_day > $total_posts)
        {
                $posts_per_day = $total_posts;
        }

print_r($posts_per_day.' :: '.$total_posts);

Первый принт выдал: 6,24 :: 2196

Второй принт выдал: 2196 :: 2196

Вопрос: у кого глюки?

Добавлено спустя 1 час 35 минут 22 секунды:

Ответ: у меня.

Почему всё так получилось: чтобы работал регистронезависимый поиск, я раскомментировал в lang_main.php строку, в которой задаётся локаль. В результате функция sprintf(), форматирующая в частности $posts_per_day, привела эту переменную в привычный для русскоязычных юзеров вид, т.е. отделила дробную часть числа не точкой, а запятой, вследствие чего PHP воспринимает его уже не как число, а как строку. Отсюда все ошибки в логических операциях (строка сравнивается с числом на больше/меньше). Ладно, проехали. Если у кого-то вдруг произойдёт та же фигня, а правдивость статистики форума нужна будет позарез, тогда в файле admin/index.php сделайте например так:

Найдите:

Код: Выделить всё

        if($posts_per_day > $total_posts)
        {
                $posts_per_day = $total_posts;
        }

        if($topics_per_day > $total_topics)
        {
                $topics_per_day = $total_topics;
        }

        if($users_per_day > $total_users)
        {
                $users_per_day = $total_users;
        }

Замените на:

Код: Выделить всё

        if(str_replace(',' ,'.' ,$posts_per_day) > $total_posts)
        {
                $posts_per_day = $total_posts;
        }

        if(str_replace(',' ,'.' ,$topics_per_day) > $total_topics)
        {
                $topics_per_day = $total_topics;
        }

        if(str_replace(',' ,'.' ,$users_per_day) > $total_users)
        {
                $users_per_day = $total_users;
        }

P.S.: Я тут никому не мешаю?