Strict Standards: Resource ID#18 used as offset, casting to integer (18) in /home/tvoyweb/domains/tvoyweb.ru/public_html/forums/include/fm.class.php on line 401

Strict Standards: Resource ID#24 used as offset, casting to integer (24) in /home/tvoyweb/domains/tvoyweb.ru/public_html/forums/include/fm.class.php on line 401

Strict Standards: Resource ID#26 used as offset, casting to integer (26) in /home/tvoyweb/domains/tvoyweb.ru/public_html/forums/include/fm.class.php on line 401

Strict Standards: Resource ID#27 used as offset, casting to integer (27) in /home/tvoyweb/domains/tvoyweb.ru/public_html/forums/include/fm.class.php on line 401
ТвойWeb :: Что делать с поиском форума? [4]
ТвойWeb ТвойWeb
Качественный Европейский хостинг
Форум для чайников
 Чат на форуме      Помощь      Поиск      Пользователи


 Страниц (9): « 1 2 3 [4] 5 6 7 8 9 »   

> Описание: Обсуждение механизма поиска новой версии форума
Alone
Отправлено: 04 Февраля, 2007 - 16:12:19
Post Id



Super Member


Покинул форум
Сообщений всего: 2393
Дата рег-ции: Дек. 2004  

Карма 8




Xvost пишет:
А по-подробнее можно?

Хостера меняй Улыбка
 
 Top
TvoyWeb Администратор
Отправлено: 05 Февраля, 2007 - 23:24:49
Post Id



Главный здесь


Покинул форум
Сообщений всего: 7072
Дата рег-ции: Нояб. 2003  
Откуда: Tashkent Uz

Карма 52




cosc
Нет. это не пойдет. Ты предлагаешь для каждого раздела создать такую базу, а значит поиск по всему форуму займет куда больше времени чем поиск о котором говорю я.
В поиске который я предлагаю, при поиске по всему разделу открывается файлов ровно по числу разделов и не больше. То есть на один раздел один файл. В твоем случае, если к примеру в поисковой фразе будет три слова и все они будут начинаться с разных букв, будет открыто файлов в три раза больше чем в моем варианте. Затем ты не учитываешь другой вариант. Вот вы все хотите чтобы открывалось конкретное сообщение, но такого нет даже на форумах с использованием MySQL. А если фраза будет найдена в нескольких сообщениях темы? Как быть в таком случае? Как выводить такой результат?
Забудьте про конкретное сообщение!!!
Возвращаясь к твоему варианту, мало того что количество открытых файлов в твоем варианте увеличивается по сравнению с моим, нужно сделать еще кучу операций.
В моем варианте все банально просто:
CODE:
foreach ($allforums as $forum_id => $forum) {
if (($result = CheckWords($forum_id)) !== FALSE) {
$total += count($result);
$main_array[$forum_id] = $result;
}
}
function CheckWords($forum_id) {
global $fm;

$search = $fm->_Read('search/db/forum'.$forum_id.'.php');

$result_array = preg_grep("#(список матерных слов)#is", $search);

return (count($result_array) !== 0) ? array_keys($result_array):FALSE;
}

ИМХО твой вариант не годится.
 
 Top
cosc
Отправлено: 06 Февраля, 2007 - 03:44:20
Post Id



Full Member


Покинул форум
Сообщений всего: 188
Дата рег-ции: Апр. 2006  

Карма 2




TvoyWeb
Да твой вариант пожалуй быстрее будет. ХОтя я не знаю, что больше всего напрягеает хостер, открытие большого числа небольших файлов, или хранение в оперативной памяти одного большого файла (в твоем варианте 1 файл может достигать нескольких мегабайт) и обработка его процессором. У меня главная идея была за счет усложнение алгоритма разгрузить процессор, так как у тебя он будет делать множество одинаковых операций главная нагрузка наверно будет на исполнение этого: $result_array = preg_grep("#(список матерных слов)#is", $search); ) , а у меня меньше операций, но разных.

TvoyWeb пишет:
Затем ты не учитываешь другой вариант. Вот вы все хотите чтобы открывалось конкретное сообщение, но такого нет даже на форумах с использованием MySQL. А если фраза будет найдена в нескольких сообщениях темы? Как быть в таком случае? Как выводить такой результат?


Об таком я писал выше. В случае если фраза будет найдена в нескольких сообщениях темы будет дана ссылка на всю тему, если же фраза будет найдена в одном сообщении, то на конкретное сообщение. Просто на форумах с MySql такое, когда надо сначала найти тему, а потому искать в этой теме, когда тебе надо найти что-то конкретное, да еще если тебе выдается несколько похожих тем, каждая из которых немаленькая, очень мешает. Если я правильно понимаю, то такое можно сделать и в твоем варианте. Конечно если подобное трудно реализовать, то тогда придется без этого обойтись.

(Отредактировано автором: 06 Февраля, 2007 - 03:45:16)

 
 Top
TvoyWeb Администратор
Отправлено: 07 Февраля, 2007 - 02:11:12
Post Id



Главный здесь


Покинул форум
Сообщений всего: 7072
Дата рег-ции: Нояб. 2003  
Откуда: Tashkent Uz

Карма 52




По поводу ссылки на конкретный пост. Я уже реализовал изначально, что в списке найденных тем ссылки ведут на версию для печати с одновременным поиском по постам. Осталось только в постах поставить ссылки на эти посты в теле самой темы.. ИМХО это самый лучший выход из ситуации.
Ок я попробую сделать индекс слов по твоему.... посмотрим что из этого выйдет... Правда я сомневаюсь очень в скорости и объясню почему.
Если делать как ты говоришь
Цитата:
{абрикос{1:2}}
арбуз{3:4}
ананас{6:8}

То придется вытаскивать слова регулярными выражениями, так как к слову цепляется еще флаг темы и поста, а значит время точно увеличиться, так как регулярка будет вызываться ровно столько раз сколько слов в файле.
Предположим вариант такой:
Файл А.тхт
CODE:
array (
[арбуз] => 3:1170751460,145:1172161460,
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
)

Здесь тоже не очень, потому как если искать целиковое слово то можно просто использовать
CODE:
if (isset($words_a['арбуз'])) {
определяем какая тема и пост
}

но если нужно искать совпадение внутри слова, например "грамм" придется перебирать весь массив слов и проверять его регулярками. Плюс эти флаги на тему и пост очень сильно увеличать в размере базу.
Поверь я хочу найти простое и правильное решение, но в моем случае где самый большой файл индекса весит 1 600kb и плюс два файла по 1 200kb (остальные меньше 800kb) база не спресованна, то есть в базе на каждую тему есть повторяющиеся слова.
Если оставить только уникальные слова, то думаю база сильно похудеет. Я не удалял уникальные слова только потому, что хотел чтобы поиск мог выдать возможно точное совпадение фразы. Ни в твоем варианте, ни в моем, если оставить только уникальные слова, сделать этого не получится. Хотя и в моем нынешнем это не на 100% так как оригинальный текст уже претерпел изменения (вырезка всего лишнего).
Вот и думаю что делать дальше.
Может быть все таки сегодня доделаю свой вариант и посмотрим как будет работать.
 
 Top
Alone
Отправлено: 07 Февраля, 2007 - 02:46:50
Post Id



Super Member


Покинул форум
Сообщений всего: 2393
Дата рег-ции: Дек. 2004  

Карма 8




Мысль по поводу ускорения поиска:

Есть например 10 форумов 1,2,3,4,5,6,7,8,9,10.
Для каждого форума создать отдельный файл индексации. То есть не один общий файл, а для каждого свой.
И разделить поиск по выбору в select-е конкретного форума (и также задавать поиск в постах или заголовках для этого форума).
А если нужно искать везде то поиск сделать последовательно: открывается вначале файл форума_1, потом файл форума_2 .... файл форума_10.
А инфа о результате поиска выводилась постепенно по мере проведения поиска где-нить внизу по типу: "Результат поиска в форуме_1", "Результат поиска в форуме_2", ... "Результат поиска в форуме_10".
 
 Top
cosc
Отправлено: 07 Февраля, 2007 - 07:18:17
Post Id



Full Member


Покинул форум
Сообщений всего: 188
Дата рег-ции: Апр. 2006  

Карма 2




TvoyWeb пишет:
Я уже реализовал изначально, что в списке найденных тем ссылки ведут на версию для печати с одновременным поиском по постам. Осталось только в постах поставить ссылки на эти посты в теле самой темы.. ИМХО это самый лучший выход из ситуации.

Ну да согласен, пожалуй тут это наилучший вариант.

Насчет форматы базы индексов. Я просто взял за основу как данные хранятся на этом форуме. Согласен, что получилось не очень оптимально. Наверго лучше взять этот вариант:
TvoyWeb пишет:
Файл А.тхт

CODE:А=array (
[арбуз] => 3:1170751460,145:1172161460,
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
)

Так как тут в дальнейшем можно изменять элементы этого массива если потребуется добавить новые слова или удалить старые. Насчет поиска внутри слова - да это минус такого варианта, слово грамм он не сможет найти в принципе, так как будет искать это слово, в файле Г.txt. Но я думаю, если все остальное было бы в порядке, то этим можно было бы и пожертовать, ведь не часто делаются такие запросы внутри слова. Только я не знаю, можно ли организовать поиск по ключам массива, что бы он нашел слово анаграм.
Тогда кстати можно еще ускорить поиск в массиве, если сделать сортировку по 2 буквам слова, тогда массив будет выглядеть так.

CODE:
А=array (
[р]=>array(
[арбуз] => 3:1170751460,145:1172161460
....
),
[н]=>array(
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
...),
....
)

И искать в этом случае слово арбуз только в массиве $А[р]. Так как в этом последнем массив (а точнее части файла А.txt) будет не более нескольких сот элементов, то его не долго будет перебрать на худой конец и при помощи циклов или регулярных выражений.
TvoyWeb пишет:
Поверь я хочу найти простое и правильное решение,

Я понимаю тебя, просто похоже (хорошо, если я ошибаюсь), что в данном случае правильное решение простым не получится и потому думаю о разных вариантах. Ведь в поисковые системы типа поиска Яндекса по своему компьютера вряд ли являются простыми, а междую тем, несмотря на многочасовую индексацию и размер базы индексов в несколько гигабайт, осуществляют поиск всего в течение долей секунды. Свой вариант я придумал по аналогии с орфографическим словарем, где очень много слов, но благодаря тому, что они все отсортированы по алфавиту поиск не занимает много времени, хотя и требует дополнительно знания алфавита.
Твой вариант очень простой, хотя я уже не знаю, что еще там можно ускорить без ущерба для качества поиска.
TvoyWeb пишет:
Ни в твоем варианте, ни в моем, если оставить только уникальные слова, сделать этого не получится.

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


Кстати, думаю надо бы в поиск в моем и твоем варианте добавить в нескольких частях что-то типа

CODE:
$mtime = microtime();
$mtime = explode(' ',$mtime);
$ms=$mtime[0]+$mtime[1];
<код поиска>
$mtime = microtime();
$mtime = explode(' ',$mtime);

$totaltime = round($mtime[1] + $mtime[0] - $ms,4);
$ms=$mtime[1] + $mtime[0];
print '<br>Время работы 1 части поиска:'.$totaltime;
<код поиска>
$mtime = microtime();
$mtime = explode(' ',$mtime);

$totaltime = round($mtime[1] + $mtime[0] - $ms,4);
$ms=$mtime[1] + $mtime[0];
print '<br>Время работы 2 части поиска:'.$totaltime;
....
Что бы в дальнейшем знать какую конкретно часть поиска надо оптимизировать.

(Отредактировано автором: 07 Февраля, 2007 - 07:51:49)

 
 Top
Леголегс Администратор
Отправлено: 09 Февраля, 2007 - 00:41:09
Post Id



JS-маньяк


Покинул форум
Сообщений всего: 2109
Дата рег-ции: Июль 2004  
Откуда: Липецк

Карма 17




TvoyWeb
Я последнее время сильно занят, но мимо этой темы пройти не могу. Я двумя руками поддерживаю идею cosc, т.к. у самого были похожие мысли. Разбиение базы по алфавиту имеет то преимущество, что размер файликов получается в 43 раза меньшим, чем при обычном способе. Они откроются без матюков хостера по поводу памяти и поиск по ним можно делать быстро. Можно пойти дальше и разделить базу на 43*43 файлов, т.е. по второй букве на уровне файлов (если тыщща файлов в одной директории нежелательна, то можно сделать 43 диры по 43 файла). Тогда файлики получаются вообще смешного размера, можно искать вдоль и поперёк.
 
 Top
cosc
Отправлено: 09 Февраля, 2007 - 04:35:32
Post Id



Full Member


Покинул форум
Сообщений всего: 188
Дата рег-ции: Апр. 2006  

Карма 2




Леголегс пишет:
Можно пойти дальше и разделить базу на 43*43 файлов,

Я насчет этого думал, но просто тут я опасался того, что при добавлении и редактировании постов нужно будет менять значительную часть файлов из этого раздела форума и я не знаю, что быстрее изменить кучу файлов смешного размера или меньше файлов размера не больше 40-50 килобайт..... Тут надо найти оптимальный вариант.
 
 Top
Леголегс Администратор
Отправлено: 09 Февраля, 2007 - 08:42:46
Post Id



JS-маньяк


Покинул форум
Сообщений всего: 2109
Дата рег-ции: Июль 2004  
Откуда: Липецк

Карма 17




cosc пишет:
файлов размера не больше 40-50 килобайт.....
Там больше гораздо. Где-то я слышал про десятиметровые индексы. Вот в таком случае в среднем будет 230 КБ, а для популярных букв ( "П" ) будет раза в 2 больше. Сервер точно будет разгружен при использовании очень мелких файлов.
Есть такая проблема: при добавлении/удалении/редактировании поста индекс тоже может обновляться на лету и это хорошо, но если на полпути произойдёт сбой и процесс прервётся, то будет половина поста не проиндексировано. Надо обеспечить журналирование как на файловых системах, короче не удивительно, что Маркусу не улыбается такого монстра писать Подмигивание
 
 Top
cosc
Отправлено: 09 Февраля, 2007 - 10:29:45
Post Id



Full Member


Покинул форум
Сообщений всего: 188
Дата рег-ции: Апр. 2006  

Карма 2




Насчет индексов просто основывался на данные маркуса о том, что у него из разделов самый большой индекс получился 1,6 мегабайта...
Насчет журналирования - не знаю, возможно это уже слишком Подмигивание но в любом случае такой вариант получается отнюдь не самым простым Улыбка
 
 Top
Страниц (9): « 1 2 3 [4] 5 6 7 8 9 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0, скрытых: 0)
« ExBB Full Mods »


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



Форум на AlfaSpace.NET


Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.0442]     [ Gzipped ]