разработать очень большую базу данных для поиска текста

Question

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

У нас будет:

• около 200 000 статей, добавляемых каждый день
• текст каждой статьи составляет около 2 КБ
• статьи хранятся в течение 6 месяцев

Для этого мы пришли к следующему решению:

• создать репозиторий SOLR для хранения статей
• использовать базу данных MySQL для хранения дополнительной информации о статье

Система будет искать SOLR по ключевым словам, а затем будет искать результаты в MySQL для получения дополнительной информации.

Итак, будет ли это хорошим подходом?

Еслибольшинство поисков будет осуществляться только по статьям, добавленным в прошлом месяце. Было бы неплохо сохранить две базы данных, в одной из которых статьи были добавлены в прошлом месяце для большинства поисков и другихr со всеми статьями?

Если у вас есть какие-либо советы / хитрости о том, как улучшить это, это будет с благодарностью.

Заранее спасибо!

Answer 1

Вместо того, чтобы хранить данные в MySQL и Solr, вы можете попробовать MySQL 5.6 сейчас. Вы должны иметь возможность использовать один механизм хранения для всех ваших требований.

MySQL фактически поддерживает полнотекстовый поиск в течение многих лет, но только на устаревшем MyISAM движке таблиц. MySQL 5.6 поддерживает эту функцию для InnoDB таблиц, что делает ее гораздо более актуальной для таких сред, как Ruby on Rails, например.

Документация для полнотекстового поиска MySQL находится по адресу:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html

Синтаксис запроса, который может представлять особый интерес для тех, кто сравнивает его с функциями Solr, находится по адресу:

http://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html

Answer 2

Я думаю, что ваше решение довольно хорошее.Я бы оценил размещение экземпляра memcache перед SOLR, если вы хотите получить более быстрые ответы на общие запросы.

Я не уверен насчет двух баз данных, вам нужно было бы увидеть, в чем заключается выигрыш в производительности по сравнению с бременем перемещения записей из первой во вторую БД по мере их старения.Я сомневаюсь, что есть огромная выгода, но это просто интуитивное чувство, не принимайте мои слова и не проводите эксперименты.

Кроме того, рассматриваете ли вы тот факт, что вам может потребоваться какое-то горизонтально масштабируемое решение, если ваш набор данныхстановится очень большим?

Answer 3

На самом деле, я не имею ни малейшего представления об использовании Solr Search Platform, но, по моему мнению, вы можете использовать Java Content Repository JCR, это позволит вам получать данные в вашей базе данных в древовидном формате.Таким образом, поиск будет экспоненциально быстрее, чем обычно.Вы должны взглянуть на эту ссылку, чтобы получить больше информации об этом

http://onjava.com/onjava/2006/10/04/what-is-java-content-repository.html

Надеюсь, что помогает

Answer 4

Вы хотите, чтобы для каждого из столбцов (Column1, Column2, Column3) был поиск индекса, а не сканирование таблицы для такой большой таблицы.

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

Если вы сделаете один индекс больше (Column1, Column2, Column3), он все равно будет выполнять сканирование таблицы для каждого поиска, поскольку при использовании индекса для, например, Column1, он все равно должен проверять ключевое слово поиска в Column2 иColumn3 тоже в то же время, и они не заказаны.- индекс упорядочен только для столбца 1;Столбец 2 и Столбец 2 расположены в случайном порядке

Таким образом, у вас есть 2 решения: либо вы измените макет таблицы, чтобы у вас не было Столбца 1, Столбца 2 и Столбца 3, а только один столбец с ключевым словом поиска: cname, и есливам нужно знать, был ли это столбец 1,2 или 3, затем добавьте другой столбец с целым числом, которое говорит 1,2 или 3. Поместите индекс в этот столбец cname, и ваши поиски будут идти быстро.Но в зависимости от других ваших столбцов это может означать, что вы дублируете некоторые данные.

Это то, что я бы сделал.Если этого недостаточно, тогда даже разделите таблицу, чтобы у вас была только таблица (id, cname), и, используя идентификатор, вы можете искать другие нужные вам столбцы из другой таблицы.Если таблица становится слишком длинной, вы можете даже разделить ее, создайте cnameAM, который содержит слова, начинающиеся с A до M, и cnameNZ, который содержит остальное.

Если вы не можете изменить макет таблицы: вместо использования 1запрос, используйте несколько запросов

Поместите индекс для каждого столбца и используйте 3 запроса.Поэтому создайте индекс для (id, Column1), создайте индекс для (id, Column2) и (id, Column3) и выполните:

SELECT * FROM 'SearchTable' WHERE Column1='$SearchKeyword'
SELECT * FROM 'SearchTable' WHERE Column2='$SearchKeyword'
SELECT * FROM 'SearchTable' WHERE Column3='$SearchKeyword'

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