|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Тема закрыта
Привет!
Нужно создать поиск по прайсам. Таблица насчитывает свыше 10 мил. записей.
Использую такое выражение:
SELECT prices.marka, MATCH (prices.marka) AGAINST ('Mercedes') AS score
FROM prices
INNER JOIN pricesAccess ON prices.idUser = pricesAccess.idUser
WHERE
MATCH (prices.marka) AGAINST ('+Mercedes*' IN BOOLEAN MODE)
ORDER BY score DESC;
Поиск происходит очень долго (около 20 сек.). Можно ли как-нибуть ускорить процес выборки?
Неактивен
Да, можно не выводить score и не делать дополнительно сортировку
в памяти. Почитайте — полнотекстовый индекс сам выводит в пра-
вильном порядке.
Неактивен
Сейчас попробую убрать сортировку по score. А подскажите еще, если у меня таблица прайсов будет насчитывать скажем 100 мил. строк. как себя повидет полнотекстовый индекс (производительность выборки уменшится или останется та ж сама)? Или FULLTEXT не приспособлен для громадных таблиц? Может есть другие варианты? Спасибо.
Неактивен
При увеличении объема данных индекс будет деградировать как логарифм
от объема (до тех пор, пока не перестанет влезать в память, потом быстрее,
т.к. бегать по диску всегда дороже, ничего не поделаешь).
Альтернатива — sphinx. Он ведет себя приблизительно так же, разумеется.
Неактивен
Вот смотрите, делаю выборку количества строк по критерию:
SELECT COUNT(*) FROM prices
INNER JOIN pricesAccess ON prices.idUser = pricesAccess.idUser
WHERE
MATCH (prices.marka) AGAINST ('+Merced*' IN BOOLEAN MODE);
Среднее время составляет - 14,04с. Это ведь много, это при том что табл. насчитывает всего 2,5 мил. строк. А если туда впихнуть с десяток милионов, то время на выборку увеличится... Разве нет такого решения которое ускоряло б выбору результата на больших таблицах???
Неактивен
Вот мне посоветовали при создании большой таблицы (на сервере она ограничена до 2Г) разбить эту табл. на несколько частей с помощью RAID_TYPE = STRIPED. При таком раскладе как будет вести себе полнотекстовый идекс. Производиетльность выборки (тоисть поиск по таблицам) увеличится или нет?
Отредактированно yuriy (22.04.2011 15:07:54)
Неактивен
А какой размер индекса, и какой размер key_buffer_size?
Разбиение таблицы потенциально увеличит скорость добавления новых строк.
Скорость выборки, соответственно, потенциально уменьшит.
Чтобы не потерять — положу для себя документик, на который буду ссылаться
в следующем ответе 
http://lists.mysql.com/mysql/132647
Кстати, если Вы хотите сделать рубрикатор на базе полнотекстового индекса —
может, имеет смысл нормализовать данные?
Неактивен
16384 - key_buffer_size. Размер индекса - 134М.
Знаете, проблема сосотоит в том, что при проэктировании таблицы нужно учитывать ее быстрое прополнение даными (загрузка прайсов - 500 тис. строк каждый).
Поэтому возникает резонный вопрос: как не потерять производительность поиска по такой большой таблицы, и во-вторых, что делать если таблица достигнит своего пикового размера (4Г)??? Может Вы сможете разяснить мне поподробней что нужно предпринятть в даном случае? С чего начать?
Отредактированно yuriy (22.04.2011 16:17:26)
Неактивен
А почему пиковый размер таблицы 4 гигабайта? Откуда это следует?
key_buffer_size 16 килобайт? А как оно у Вас вообще запустилось?
Сделайте 128 мегабайт хотя бы
Неактивен
У меня в my.cnf - прописано только key_buffer а не key_buffer_size! Хотя может в Денвере это не катит! Прописал
[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
4Г прочитал в справочнике. Так значит размер таблицы может достигать значительно больших размеров? (Каких?).
Так насчет моего вопроса, как не потерять производительность поиска при стонях миллионах стпрок таблицы? Я так думаю FULLTEX слабоват в этом случае! Нужно или таблицу разбивать или...)))
Неактивен
Не нравится — не используйте
Предлагаю объединить оба обсуждения в одно, т.к. вопросы Вы задаете
приблизительно одинаковые и уж точно связанные.
http://sqlinfo.ru/forum/viewtopic.php?pid=24402#p24402
Неактивен
Тема закрыта
Страниц: 1
