Xvost пишет:
А по-подробнее можно?
Хостера меняй
31. Alone - 04 Февраля, 2007 - 16:12:19 - перейти к сообщению
Хостера меняй
32. TvoyWeb - 05 Февраля, 2007 - 23:24:49 - перейти к сообщению
cosc
Нет. это не пойдет. Ты предлагаешь для каждого раздела создать такую базу, а значит поиск по всему форуму займет куда больше времени чем поиск о котором говорю я.
В поиске который я предлагаю, при поиске по всему разделу открывается файлов ровно по числу разделов и не больше. То есть на один раздел один файл. В твоем случае, если к примеру в поисковой фразе будет три слова и все они будут начинаться с разных букв, будет открыто файлов в три раза больше чем в моем варианте. Затем ты не учитываешь другой вариант. Вот вы все хотите чтобы открывалось конкретное сообщение, но такого нет даже на форумах с использованием MySQL. А если фраза будет найдена в нескольких сообщениях темы? Как быть в таком случае? Как выводить такой результат?
Забудьте про конкретное сообщение!!!
Возвращаясь к твоему варианту, мало того что количество открытых файлов в твоем варианте увеличивается по сравнению с моим, нужно сделать еще кучу операций.
В моем варианте все банально просто:
ИМХО твой вариант не годится.
Нет. это не пойдет. Ты предлагаешь для каждого раздела создать такую базу, а значит поиск по всему форуму займет куда больше времени чем поиск о котором говорю я.
В поиске который я предлагаю, при поиске по всему разделу открывается файлов ровно по числу разделов и не больше. То есть на один раздел один файл. В твоем случае, если к примеру в поисковой фразе будет три слова и все они будут начинаться с разных букв, будет открыто файлов в три раза больше чем в моем варианте. Затем ты не учитываешь другой вариант. Вот вы все хотите чтобы открывалось конкретное сообщение, но такого нет даже на форумах с использованием 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;
}
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;
}
ИМХО твой вариант не годится.
33. cosc - 06 Февраля, 2007 - 03:44:20 - перейти к сообщению
TvoyWeb
Да твой вариант пожалуй быстрее будет. ХОтя я не знаю, что больше всего напрягеает хостер, открытие большого числа небольших файлов, или хранение в оперативной памяти одного большого файла (в твоем варианте 1 файл может достигать нескольких мегабайт) и обработка его процессором. У меня главная идея была за счет усложнение алгоритма разгрузить процессор, так как у тебя он будет делать множество одинаковых операций главная нагрузка наверно будет на исполнение этого: $result_array = preg_grep("#(список матерных слов)#is", $search); ) , а у меня меньше операций, но разных.
Об таком я писал выше. В случае если фраза будет найдена в нескольких сообщениях темы будет дана ссылка на всю тему, если же фраза будет найдена в одном сообщении, то на конкретное сообщение. Просто на форумах с MySql такое, когда надо сначала найти тему, а потому искать в этой теме, когда тебе надо найти что-то конкретное, да еще если тебе выдается несколько похожих тем, каждая из которых немаленькая, очень мешает. Если я правильно понимаю, то такое можно сделать и в твоем варианте. Конечно если подобное трудно реализовать, то тогда придется без этого обойтись.
Да твой вариант пожалуй быстрее будет. ХОтя я не знаю, что больше всего напрягеает хостер, открытие большого числа небольших файлов, или хранение в оперативной памяти одного большого файла (в твоем варианте 1 файл может достигать нескольких мегабайт) и обработка его процессором. У меня главная идея была за счет усложнение алгоритма разгрузить процессор, так как у тебя он будет делать множество одинаковых операций главная нагрузка наверно будет на исполнение этого: $result_array = preg_grep("#(список матерных слов)#is", $search); ) , а у меня меньше операций, но разных.
TvoyWeb пишет:
Затем ты не учитываешь другой вариант. Вот вы все хотите чтобы открывалось конкретное сообщение, но такого нет даже на форумах с использованием MySQL. А если фраза будет найдена в нескольких сообщениях темы? Как быть в таком случае? Как выводить такой результат?
Об таком я писал выше. В случае если фраза будет найдена в нескольких сообщениях темы будет дана ссылка на всю тему, если же фраза будет найдена в одном сообщении, то на конкретное сообщение. Просто на форумах с MySql такое, когда надо сначала найти тему, а потому искать в этой теме, когда тебе надо найти что-то конкретное, да еще если тебе выдается несколько похожих тем, каждая из которых немаленькая, очень мешает. Если я правильно понимаю, то такое можно сделать и в твоем варианте. Конечно если подобное трудно реализовать, то тогда придется без этого обойтись.
34. TvoyWeb - 07 Февраля, 2007 - 02:11:12 - перейти к сообщению
По поводу ссылки на конкретный пост. Я уже реализовал изначально, что в списке найденных тем ссылки ведут на версию для печати с одновременным поиском по постам. Осталось только в постах поставить ссылки на эти посты в теле самой темы.. ИМХО это самый лучший выход из ситуации.
Ок я попробую сделать индекс слов по твоему.... посмотрим что из этого выйдет... Правда я сомневаюсь очень в скорости и объясню почему.
Если делать как ты говоришь
То придется вытаскивать слова регулярными выражениями, так как к слову цепляется еще флаг темы и поста, а значит время точно увеличиться, так как регулярка будет вызываться ровно столько раз сколько слов в файле.
Предположим вариант такой:
Файл А.тхт
Здесь тоже не очень, потому как если искать целиковое слово то можно просто использовать
но если нужно искать совпадение внутри слова, например "грамм" придется перебирать весь массив слов и проверять его регулярками. Плюс эти флаги на тему и пост очень сильно увеличать в размере базу.
Поверь я хочу найти простое и правильное решение, но в моем случае где самый большой файл индекса весит 1 600kb и плюс два файла по 1 200kb (остальные меньше 800kb) база не спресованна, то есть в базе на каждую тему есть повторяющиеся слова.
Если оставить только уникальные слова, то думаю база сильно похудеет. Я не удалял уникальные слова только потому, что хотел чтобы поиск мог выдать возможно точное совпадение фразы. Ни в твоем варианте, ни в моем, если оставить только уникальные слова, сделать этого не получится. Хотя и в моем нынешнем это не на 100% так как оригинальный текст уже претерпел изменения (вырезка всего лишнего).
Вот и думаю что делать дальше.
Может быть все таки сегодня доделаю свой вариант и посмотрим как будет работать.
Ок я попробую сделать индекс слов по твоему.... посмотрим что из этого выйдет... Правда я сомневаюсь очень в скорости и объясню почему.
Если делать как ты говоришь
Цитата:
{абрикос{1:2}}
арбуз{3:4}
ананас{6:8}
арбуз{3:4}
ананас{6:8}
То придется вытаскивать слова регулярными выражениями, так как к слову цепляется еще флаг темы и поста, а значит время точно увеличиться, так как регулярка будет вызываться ровно столько раз сколько слов в файле.
Предположим вариант такой:
Файл А.тхт
CODE:
array (
[арбуз] => 3:1170751460,145:1172161460,
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
)
[арбуз] => 3:1170751460,145:1172161460,
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
)
Здесь тоже не очень, потому как если искать целиковое слово то можно просто использовать
CODE:
if (isset($words_a['арбуз'])) {
определяем какая тема и пост
}
определяем какая тема и пост
}
но если нужно искать совпадение внутри слова, например "грамм" придется перебирать весь массив слов и проверять его регулярками. Плюс эти флаги на тему и пост очень сильно увеличать в размере базу.
Поверь я хочу найти простое и правильное решение, но в моем случае где самый большой файл индекса весит 1 600kb и плюс два файла по 1 200kb (остальные меньше 800kb) база не спресованна, то есть в базе на каждую тему есть повторяющиеся слова.
Если оставить только уникальные слова, то думаю база сильно похудеет. Я не удалял уникальные слова только потому, что хотел чтобы поиск мог выдать возможно точное совпадение фразы. Ни в твоем варианте, ни в моем, если оставить только уникальные слова, сделать этого не получится. Хотя и в моем нынешнем это не на 100% так как оригинальный текст уже претерпел изменения (вырезка всего лишнего).
Вот и думаю что делать дальше.
Может быть все таки сегодня доделаю свой вариант и посмотрим как будет работать.
35. Alone - 07 Февраля, 2007 - 02:46:50 - перейти к сообщению
Мысль по поводу ускорения поиска:
Есть например 10 форумов 1,2,3,4,5,6,7,8,9,10.
Для каждого форума создать отдельный файл индексации. То есть не один общий файл, а для каждого свой.
И разделить поиск по выбору в select-е конкретного форума (и также задавать поиск в постах или заголовках для этого форума).
А если нужно искать везде то поиск сделать последовательно: открывается вначале файл форума_1, потом файл форума_2 .... файл форума_10.
А инфа о результате поиска выводилась постепенно по мере проведения поиска где-нить внизу по типу: "Результат поиска в форуме_1", "Результат поиска в форуме_2", ... "Результат поиска в форуме_10".
Есть например 10 форумов 1,2,3,4,5,6,7,8,9,10.
Для каждого форума создать отдельный файл индексации. То есть не один общий файл, а для каждого свой.
И разделить поиск по выбору в select-е конкретного форума (и также задавать поиск в постах или заголовках для этого форума).
А если нужно искать везде то поиск сделать последовательно: открывается вначале файл форума_1, потом файл форума_2 .... файл форума_10.
А инфа о результате поиска выводилась постепенно по мере проведения поиска где-нить внизу по типу: "Результат поиска в форуме_1", "Результат поиска в форуме_2", ... "Результат поиска в форуме_10".
36. cosc - 07 Февраля, 2007 - 07:18:17 - перейти к сообщению
TvoyWeb пишет:
Я уже реализовал изначально, что в списке найденных тем ссылки ведут на версию для печати с одновременным поиском по постам. Осталось только в постах поставить ссылки на эти посты в теле самой темы.. ИМХО это самый лучший выход из ситуации.
Ну да согласен, пожалуй тут это наилучший вариант.
Насчет форматы базы индексов. Я просто взял за основу как данные хранятся на этом форуме. Согласен, что получилось не очень оптимально. Наверго лучше взять этот вариант:
TvoyWeb пишет:
Файл А.тхт
CODE:А=array (
[арбуз] => 3:1170751460,145:1172161460,
[анаграмма] => 3:1170751460,145:1172161460,
[ананас] => 215:1170751460,314:1172161460
)
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
...),
....
)
[р]=>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;
....
$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;
....
37. Леголегс - 09 Февраля, 2007 - 00:41:09 - перейти к сообщению
TvoyWeb
Я последнее время сильно занят, но мимо этой темы пройти не могу. Я двумя руками поддерживаю идею cosc, т.к. у самого были похожие мысли. Разбиение базы по алфавиту имеет то преимущество, что размер файликов получается в 43 раза меньшим, чем при обычном способе. Они откроются без матюков хостера по поводу памяти и поиск по ним можно делать быстро. Можно пойти дальше и разделить базу на 43*43 файлов, т.е. по второй букве на уровне файлов (если тыщща файлов в одной директории нежелательна, то можно сделать 43 диры по 43 файла). Тогда файлики получаются вообще смешного размера, можно искать вдоль и поперёк.
Я последнее время сильно занят, но мимо этой темы пройти не могу. Я двумя руками поддерживаю идею cosc, т.к. у самого были похожие мысли. Разбиение базы по алфавиту имеет то преимущество, что размер файликов получается в 43 раза меньшим, чем при обычном способе. Они откроются без матюков хостера по поводу памяти и поиск по ним можно делать быстро. Можно пойти дальше и разделить базу на 43*43 файлов, т.е. по второй букве на уровне файлов (если тыщща файлов в одной директории нежелательна, то можно сделать 43 диры по 43 файла). Тогда файлики получаются вообще смешного размера, можно искать вдоль и поперёк.
38. cosc - 09 Февраля, 2007 - 04:35:32 - перейти к сообщению
Леголегс пишет:
Можно пойти дальше и разделить базу на 43*43 файлов,
Я насчет этого думал, но просто тут я опасался того, что при добавлении и редактировании постов нужно будет менять значительную часть файлов из этого раздела форума и я не знаю, что быстрее изменить кучу файлов смешного размера или меньше файлов размера не больше 40-50 килобайт..... Тут надо найти оптимальный вариант.
39. Леголегс - 09 Февраля, 2007 - 08:42:46 - перейти к сообщению
cosc пишет:
Там больше гораздо. Где-то я слышал про десятиметровые индексы. Вот в таком случае в среднем будет 230 КБ, а для популярных букв ( "П" ) будет раза в 2 больше. Сервер точно будет разгружен при использовании очень мелких файлов.файлов размера не больше 40-50 килобайт.....
Есть такая проблема: при добавлении/удалении/редактировании поста индекс тоже может обновляться на лету и это хорошо, но если на полпути произойдёт сбой и процесс прервётся, то будет половина поста не проиндексировано. Надо обеспечить журналирование как на файловых системах, короче не удивительно, что Маркусу не улыбается такого монстра писать
40. cosc - 09 Февраля, 2007 - 10:29:45 - перейти к сообщению
Насчет индексов просто основывался на данные маркуса о том, что у него из разделов самый большой индекс получился 1,6 мегабайта...
Насчет журналирования - не знаю, возможно это уже слишком но в любом случае такой вариант получается отнюдь не самым простым
Насчет журналирования - не знаю, возможно это уже слишком
но в любом случае такой вариант получается отнюдь не самым простым