Поиск большого количества постоянно обновляемого текста в MySQL

Question

У меня есть база данных mysql, в которую постоянно добавляется большое количество текста.(10 страниц текста в час).Текст хранится в виде открытого текста в текстовых полях.Каждая строка связывается со страницей или двумя текстами.

Мне нужно регулярно выполнять полнотекстовый поиск (искать ключевое слово в тексте и выполнять сложные запросы) в этой базе данных.Мне просто нужно искать недавно добавленный текст.Но очень важно, чтобы добавленный текст был сразу доступен для поиска (в течение минуты или двух).

Из того, что я прочитал, полный текст с mysql очень неэффективен.Я знаю, что lucene - это вариант, но я пока не уверен, насколько быстро он может индексировать новый текст.

Итак, какие у меня есть варианты?Есть ли способ сделать MySQL более эффективным?Lucene мое лучшее решение?что-нибудь более подходящее?

спасибо

Answer 1

Я провел бенчмаркинг для Indexing Times для Sphinx & Solr. Sphinx значительно опережает Solr в отношении алгоритмов индексации (сверхбыстрое время индексации и небольшой размер индекса).

Когда вы произносите 10 страниц текста, кажется, что вам даже не требуется индексирование сфинкса в реальном времени . Вы можете следовать схеме main + delta indexing в Sphinx (вы можете найти это в документации Sphinx). Это было бы очень быстро и почти в реальном времени. Если вам нужна дополнительная помощь по этому вопросу, пожалуйста, не стесняйтесь спрашивать, будем рады объяснить вам.

Solr великолепен, но когда дело доходит до оптимизированных алгоритмов, Sphinx качается !! Попробуйте Сфинкс.

Возвращаясь к вашим вопросам в комментарии, Solr / Lucene поддерживает инкрементную индексацию (известную как дельта-импорт в их терминологии) и легко настраивается, однако они довольно медленны по сравнению с методом, используемым Sphinx.

Main + Delta достаточно быстр, потому что вы можете создать временную таблицу, в которой вы будете хранить новый текст и индексировать его. Согласно документации: Sphinx поддерживает «живые» (почти в реальном времени) обновления индекса, и его можно реализовать с помощью так называемая схема "главный + дельта". Идея состоит в том, чтобы настроить два источника и два индекса, с одним «основным» индексом для данных и одним «дельта» для новых документов.

Скажем, например, у вас есть 10 миллионов записей, чтобы вы могли сохранить их в качестве основного индекса, и все новые документы будут добавлены в новую таблицу, которая будет действовать как дельта. Эта новая таблица может быть проиндексирована время от времени (скажем, каждые 1 час), и данные становятся доступными для поиска в течение нескольких секунд, поскольку у вас есть 10 страниц текста. Теперь после поиска новых записей вы можете объединить документы основной таблицы + дельта-таблицы, что может быть выполнено без вмешательства в ваш поиск. Когда документы объединены, очистите новую таблицу и снова через час вы сможете снова выполнить весь процесс. Я надеюсь, что вы получили что-то еще, пожалуйста, не стесняйтесь задавать любые вопросы.

Answer 2

У вас есть несколько вариантов:

• Поиск сфинкса : Может напрямую интегрироваться с вашей базой данных MySQL.Имеет поддержку индексов в реальном времени с ограничениями

• Solr / Lucene : подача данных через JSON или XML из вашей БД.Имеет богатые возможности запросов.Текущие версии не в режиме реального времени без некоторых краевых сборок.Вы должны повторно проиндексировать свои данные и зафиксировать их для появления изменений.Который в зависимости от вашего количества данных, вы можете делать коммит каждые 10 минут.Это не будет проблемой до тех пор, пока у вас не будет документов размером 100 КБ / 1 млн. +, Поскольку Lucene очень быстро индексирует.10 страниц в час - это довольно тривиально.

• ElasticSearch : Основан на Java, как Solr / Lucene, но, по-видимому, достаточно "почти в реальном времени".Он спроектирован из коробки для распределения и поддержки линейного масштабирования.Вы передаете им данные через JSON и запрашиваете через JSON.

Это действительно зависит от ваших потребностей и возможностей.Сфинкс может быть проще всего начать.Но ограничения индекса реального времени могут не сработать.