|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Как получить оптимальную схему для работы MySQL БД с таблицей в которой присутствует FULLTEXT индекс поля VARCHAR(255).
Каждый день в таблицу добавляется 200 000 строк и запрос должен всегда использовать полнотекстовый поиск по этому FULLTEXT индексу.
В самой таблице и этих данных ограничений по времени нет - в запросе нужно просматривать все данные из этого поля, всегда.
Когда в таблице 3-4 млн записей, уже к этому моменту запрос MATCH ... AGAINST вызывает 100% нагрузку CPU достаточно современного сервера, пока не получит результат запроса.
И даже не могу предположить, в каком направлении двигаться, чтобы уменьшить нагрузку на CPU в поиске этой информации в этой таблице.
Если кто-нибудь в курсе, как и что можно изменить, посоветуйте пожалуйста.
Неактивен
Очевидный ответ — никак. Индекс (если он построен правильно и правильно используется) — самый быстрый способ получить нужные данные. Проверьте, что индекс влезает в память хотя бы большей частью, может, Вы просто по диску бегаете постоянно?
Архитектура MySQL не позволит использовать более одного ядра на запрос, соответственно, 100% на одном запросе — это абсолютно нормально, это просто максимальная производительность запроса. Как правило в OLTP-нагрузке это не является проблемой, т.к. запросов параллельно много, и они распределяются по ядрам.
Если запросы редкие, то можно придумать какие-то костыли. Например, разбить табличку на несколько, в клиентском приложении сделать N запросов, а потом в нем же переранжировать (в этом месте могут быть проблемы, но попробовать можно).
Также посмотрите на sphinx или lucene, возможно, удастся вытащить бо́льшую производительность из них (в расчете на ядро).
Неактивен
Мы тут еще пообсуждали — Вы уверены, что запрос идет по индексу? Он может дофильтровывать на процессоре? Можете показать план?
Неактивен
Запрос по индексу, проблема именно в объеме данных в индексе.
Вот идея разбить на несколько таблиц или партиций и сделать вместо одного 10 запросов, уже рабочая версия для теста.
Сотрудник Гугла в недавнем обсуждении указывал, что у них помимо полнотекстового индекса документа, есть индекс-индекса, и еще указатель этого индекс-индекса.
Вот пытаюсь осмыслить это как и как такое реализовать тоже.
Отредактированно AlexSDF (04.03.2021 13:23:45)
Неактивен
Проблему частично решил костылем, обучением модели выборки методом свертывающейся сети. Нашел наборы, сколько именно записей и до какой даты чаще всего возвращают результат по запросу. В итоге, в 97% размер данных и индекса оказался приемлемым, именно такой период и кол-во записей и оставил в основной таблице, остальное вынес в отдельную. И 3% запросов теперь идут в большие данные, а остальные быстрыми в основную таблицу.
Сил уже не осталось бодаться, поэтому спрошу еще один вопрос по проблеме, с которой столкнулся на таких таблицах с большими индексами. Может кто сталкивался с таким и подскажет куда посмотреть.
Таблицы MyISAM данные 1,8Gb Индекс 700Мб (не только fulltext полно прочих цифровых индексов).
Проблема одинаково появляется что с KEY_DELAY_WRITE=1 что без него.
При удалении записей из большой таблицы этой, DELETE (хоть с QUICK хоть без него) таблица крашится.
Еще более удивительно, после DELETE когда всё прошло хорошо, или после восстановления таблицы, сразу сделать OPTIMIZE TABLE - ... матные слова... таблица крашится.
Никаких логов, все чисто, никаких ошибок - таблица ...матные слова... крашится.
Куда смотреть, как проверить, что именно не так, запись-ли на диск индекса, или еще что, в чем проблему искать 
При вставке данных в таблицу - никогда не происходит краша - никогда.
Отредактированно AlexSDF (05.03.2021 12:38:19)
Неактивен
Страниц: 1
