|
|
|
|
|
для: heed
(11.08.2009 в 14:10)
| | Разобрался
под WinXP_SP_3 нехотел с mysql работать Stable 0.9.8 релиз
ни с libmysql от самой mysql 5.1.36 ни даже с libmysql.dll от php
скачал sphinx 0.9.8 beta , в нём была libmysql, но небыло libexpat.dll
добавил , и всё заработало | |
|
|
|
|
|
|
|
для: pol_uha
(11.08.2009 в 12:29)
| | скачал , отрыл доку, похоже что-то стоящее того чтобы поставить ещё одного демона.
Осталось понять как это ставится :) | |
|
|
|
|
|
|
|
для: Loki
(11.08.2009 в 12:19)
| | IN BOOLEAN MODE в основном и используется
просто если сделать 4 как по умолчанию то многое не индексируется из того что нужно
Вообще былбы тоже вариант если можно былобы совсем не хранить в таблице данные
, а хранить только индекс, но такое разработчиками не предусмотренно | |
|
|
|
|
|
|
|
для: heed
(11.08.2009 в 05:53)
| | Если вы что либо ищете в больших объемах, НИ В КОЕМ СЛУЧАЕ НЕ ПОЛЬЗУЙТЕСЬ FULLTEXT-ом ставьте стороннее решение, например sphinx, индексы делает много грамотней | |
|
|
|
|
|
|
|
для: heed
(11.08.2009 в 11:34)
| | >и ещё ft_min_word_len=3 не хотелось-бы менять
Попробуйте IN BOOLEAN MODE - там эти ограничения не действуют. | |
|
|
|
|
|
|
|
для: Trianon
(11.08.2009 в 08:48)
| | >Чем
Были сомнения по поводу вообще человечности такого обращения с mysql :)
и ещё ft_min_word_len=3 не хотелось-бы менять
Немного обнадёжили. Почитаю подумаю ещё насчёт списка StopWords.
и наверное так и сделаю.
Спасибо | |
|
|
|
|
|
|
|
для: heed
(11.08.2009 в 05:53)
| | >первый вариант кажется удобнее тем что всегда поиск так-же будет по одной таблице
но уже настораживает такой размер таблицы
Чем настораживает?
>(создание FULLTEXT индекса наверное получится минут на 15)
Это же разовая операция. | |
|
|
|
|
|
|
|
для: heed
(11.08.2009 в 05:53)
| | нечаяно не там создал тему, извиняюсь. | |
|
|
|
|
|
|
| У меня такой вопрос,
нужно записать в db чтото около трёх ГигаБайт текстовых данных
(LONGTEXT) и как обычно названия, описания, ключи
И их можно условно разделить на три большие группы(0.5G/0.8G/1.7G) или на 20 маленьких групп.
Pаньше всё лежало в одной таблице, поиск без особых усложнений работал довольнотаки неплохо.
,если не слишком много результатов (SELECT SQL_CALC_FOUND_ROWS), извлекались только номера записей.
Но было меньше, <1G
теперь не могу выбрать грузить все 3G также в одну таблицу,
или всётаки разделить на 3
первый вариант кажется удобнее тем что всегда поиск так-же будет по одной таблице
но уже настораживает такой размер таблицы (создание FULLTEXT индекса наверное получится минут на 15)
второй лучше тем что позволяет по отдельности управлять таблицами,
но поиск сразу в трёх таблицах тоже настораживает
(запросов будет примерно половина ко всем трём, потомучто в каждая из 20и групп раскидана поэтим трём)
возможно со временем все три почти уровнялись-бы в размерах
на 20 таблиц мне совсем не представляется как сделать поиск например по 8и из них сразу
в среднем будет гдето по 3м таблицам
Какой из вариантов мне выбрать ? или нужно разбирать ещё по подгруппам и сделать 5 таблиц? | |
|
|
|
|