SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 03.03.2021 11:50:18

AlexSDF
Участник
Зарегистрирован: 03.03.2021
Сообщений: 3

Оптимизация схемы для работы с FULLTEXT индексом

Как получить оптимальную схему для работы MySQL БД с таблицей в которой присутствует FULLTEXT индекс поля VARCHAR(255).

Каждый день в таблицу добавляется 200 000 строк и запрос должен всегда использовать полнотекстовый поиск по этому FULLTEXT индексу.

В самой таблице и этих данных ограничений по времени нет - в запросе нужно просматривать все данные из этого поля, всегда.

Когда в таблице 3-4 млн записей, уже к этому моменту запрос MATCH ... AGAINST вызывает 100% нагрузку CPU достаточно современного сервера, пока не получит результат запроса.

И даже не могу предположить, в каком направлении двигаться, чтобы уменьшить нагрузку на CPU в поиске этой информации в этой таблице.

Если кто-нибудь в курсе, как и что можно изменить, посоветуйте пожалуйста.

Неактивен

 

#2 03.03.2021 19:20:33

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Оптимизация схемы для работы с FULLTEXT индексом

Очевидный ответ — никак. Индекс (если он построен правильно и правильно используется) — самый быстрый способ получить нужные данные. Проверьте, что индекс влезает в память хотя бы большей частью, может, Вы просто по диску бегаете постоянно?

Архитектура MySQL не позволит использовать более одного ядра на запрос, соответственно, 100% на одном запросе — это абсолютно нормально, это просто максимальная производительность запроса. Как правило в OLTP-нагрузке это не является проблемой, т.к. запросов параллельно много, и они распределяются по ядрам.

Если запросы редкие, то можно придумать какие-то костыли. Например, разбить табличку на несколько, в клиентском приложении сделать N запросов, а потом в нем же переранжировать (в этом месте могут быть проблемы, но попробовать можно).

Также посмотрите на sphinx или lucene, возможно, удастся вытащить бо́льшую производительность из них (в расчете на ядро).

Неактивен

 

#3 03.03.2021 20:28:48

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Оптимизация схемы для работы с FULLTEXT индексом

Мы тут еще пообсуждали — Вы уверены, что запрос идет по индексу? Он может дофильтровывать на процессоре? Можете показать план?

Неактивен

 

#4 04.03.2021 13:22:33

AlexSDF
Участник
Зарегистрирован: 03.03.2021
Сообщений: 3

Re: Оптимизация схемы для работы с FULLTEXT индексом

Запрос по индексу, проблема именно в объеме данных в индексе.
Вот идея разбить на несколько таблиц или партиций и сделать вместо одного 10 запросов, уже рабочая версия для теста.

Сотрудник Гугла в недавнем обсуждении указывал, что у них помимо полнотекстового индекса документа, есть индекс-индекса,  и еще указатель этого индекс-индекса.
Вот пытаюсь осмыслить это как и как такое реализовать тоже.

Отредактированно AlexSDF (04.03.2021 13:23:45)

Неактивен

 

#5 05.03.2021 12:37:36

AlexSDF
Участник
Зарегистрирован: 03.03.2021
Сообщений: 3

Re: Оптимизация схемы для работы с FULLTEXT индексом

Проблему частично решил костылем, обучением модели выборки методом свертывающейся сети. Нашел наборы, сколько именно записей и до какой даты чаще всего возвращают результат по запросу. В итоге, в 97% размер данных  и индекса оказался приемлемым, именно такой период и кол-во записей и оставил в основной таблице, остальное вынес в отдельную. И 3% запросов теперь идут в большие данные, а остальные быстрыми в основную таблицу.


Сил уже не осталось бодаться, поэтому спрошу еще один вопрос по проблеме, с которой столкнулся на таких таблицах с большими индексами. Может кто сталкивался с таким и подскажет куда посмотреть.

Таблицы MyISAM данные 1,8Gb Индекс 700Мб (не только fulltext полно прочих цифровых индексов).
Проблема одинаково появляется что с KEY_DELAY_WRITE=1 что без него.

При удалении записей из большой таблицы этой, DELETE (хоть с QUICK хоть без него) таблица крашится.
Еще более удивительно, после DELETE когда всё прошло хорошо, или после восстановления таблицы, сразу сделать OPTIMIZE TABLE - ... матные слова... таблица крашится.

Никаких логов, все чисто, никаких ошибок - таблица ...матные слова... крашится.

Куда смотреть, как проверить, что именно не так, запись-ли на диск индекса, или еще что, в чем проблему искать sad
При вставке данных в таблицу - никогда не происходит краша - никогда.

Отредактированно AlexSDF (05.03.2021 12:38:19)

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson