Solr Faces против MySQL схемы отношений

Question

Мне интересно узнать, какой самый лучший / самый быстрый (самый эффективный) способ запроса solr в настройках solr / mysql / app. У меня есть mysql DB, которая имеет одну большую главную таблицу и несколько небольших таблиц в реляционной схеме. Я также создаю приложение, которое использует иерархию и создает меню на основе данных в связанных таблицах.

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

Это быстрее / лучше:

1.) Сохраняйте связанные таблицы в mysql, также настраивайте фасеты для каждой строки в связанных таблицах. Связать их как-нибудь, когда я сделаю запрос к maintable? Это звучит как самый быстрый вариант, но может быть сложным (придется сопоставить 2 разных массива) в моем приложении.

2) Держите связанные таблицы в mysql и вызывайте / подсчитывайте данные в главной индексированной таблице для каждого из связанных элементов во время выполнения. например для меню брендов мне нужно будет получить счетчик каждого бренда, требуя, чтобы я отправлял каждый пункт меню как запрос к solr (чтобы получить счетчик). Я понимаю, что каждый запрос довольно быстрый, но может быть несколько сотен или тысяч брендов.

3) Просто поместить все данные в solr и использовать фасеты? - но как определить каждый аспект и определить соответствующую информацию в таблицах mysql для каждого аспекта? Каждая запись в связанных таблицах mysql имеет заголовок, описание, отформатированный URL-адрес, метаданные, должна ли соответствующая информация также храниться в solr? в другом индексе? в этом случае я должен полностью избавиться от mysql?

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

Приветствия Ke

Answer 1

Solr создан для поиска - он оптимизирован для аспектов и тому подобного, используя собственный язык запросов и механизмы кэширования. Я был бы очень удивлен, если бы вы могли кодировать что-то (на основе MySQL), которое может превзойти Solr с точки зрения производительности поисковых запросов / результатов.

Посмотрите, как Solr индексирует свои данные (или на самом деле то, что вам нужно, чтобы передать их для правильной индексации. Есть хорошая стартовая документация по этому вопросу. Возможно, в итоге вы получите 60% индексации Solr и 40 % MySQL - в любом случае, из того, что я прочитал о ваших планах, Solr очень стоит изучить.

Обычный подход для веб-приложений:

1) создайте схему индекса, которая соответствует вашим данным и поисковым запросам для Solr 2) создать импорт данных MySQL в Solr (также есть инструменты) 3) создать приложение внешнего интерфейса, которое переводит пользовательские запросы в запросы Solr 4) отправить эти запросы в Solr 5) разобрать результат и адаптировать запросы для создания новых аспектов 6) кэшируйте все, что можете

НТН, Matt