Налаштування та оптимізація повнотекстового пошуку
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Одна з найважливіших умов підвищення продуктивності – регулярне обслуговування повнотекстових індексів. Через велику кількість слів у типових документах та структурі дворівневого B-дерева повнотекстові індекси страждають від фрагментації більше, ніж звичайні. Для усунення фрагментації намагайтеся якнайчастіше виконувати команду OPTIMIZE TABLE. Якщо сервер виконує багато операцій вводу/виводу, то набагато швидше буде періодично видаляти та наново створювати повнотекстові індекси.
Щоб сервер ефективно здійснював повнотекстовий пошук, потрібно виділити достатньо пам'яті під буфери ключів, щоб повнотекстові індекси повністю містилися в ОЗУ, - у цьому випадку вони функціонують значно краще. Можна використовувати окремі буфери ключів, щоб інші індекси не витісняли повнотекстовий з пам'яті. Щоб отримати додаткові відомості про буфери ключів MyISAM, див. “Кеш ключів MyISAM” на стор.
Важливо також створити якісний перелік стоп-слів. Список, запропонований за умовчанням, «заточений» під англомовну прозу, але інших мов або вузькоспеціалізованих, наприклад технічних, текстів годиться. Наприклад, при індексуванні документа, відносячи-
ся до MySQL, має сенс зробити «mysql» стоп-словом, оскільки воно зустрічається занадто часто і тому марно.
Найчастіше вдається підвищити продуктивність з допомогою ігнорування коротких слів. Мінімальна довжина задається за допомогою ft_min_word_len. Якщо збільшити значення за замовчуванням, то буде пропускатися більше слів, тому індекс стане коротшим і швидшим, щоправда, ціною зниження точності пошуку. Не забувайте, втім, що для якихось спеціальних цілей може бутизначущі і дуже короткі слова. Наприклад, якщо шукати на запит cd player у документах про побутову електроніку, то при забороні на короткі слова може бути видано багато нерелевантних результатів. Користувач навряд чи хоче бачити документи про MP3 і DVD-плеєри, але, якщо мінімальна довжина слова становить 4 символи, то буде здійснено пошук тільки за словом «player» і, отже, повернуто документи, що стосуються взагалі всіх плеєрів.
Завдання списку стоп-слів та мінімальної довжини запиту може прискорити пошук за рахунок виключення деяких слів з індексу, але якість пошуку при цьому постраждає. Відповідний баланс залежить від програми. Якщо потрібна хороша продуктивність і висока якість пошуку, то доведеться налаштувати обидва параметри. Було б розумно інтегрувати в додаток якийсь механізм протоколювання, виконати типовий пошук, нетиповий пошук, пошук, який не повертає жодних результатів, і пошук, що повертає дуже багато результатів, і подивитися, що виходить. Таким чином, можна отримати корисну інформацію про користувачів програми та характер вмісту своїх документів, а потім скористатися нею для підвищення швидкості та якості пошуку.
Майте на увазі, що після зміни мінімальної довжини слова необхідно перебудувати індекс командою OPTIMIZE TABLE, щоб нове значення набуло чинності. Існує також параметр ft_max_word_len, який страхує від індексування надто довгих слів.
Якщо ви імпортуєте багато даних у таблиці, що містять проіндексовані текстові стовпці, перед початком імпорту відключіть повнотекстові індекси командою DISABLE KEYS, а після завершення увімкніть командою ENABLE KEYS. Зазвичай це дає суттєвий виграш у часі завантаження через високу вартість оновлення індексу для кожного рядка. А вяк премію ви отримуєте ще й дефрагментований індекс.
Якщо набір даних дуже великий, то має сенс вручну розподілити інформацію по кількох вузлах і шукати на них паралельно. Це непросте завдання, тому можливо краще скористатися зовнішньою системою повнотекстового пошуку, наприклад Lucene або Sphinx. Наш досвід показує, що вони можуть забезпечити продуктивність на кілька вище.