Ответ 1

Я бы настоятельно рекомендовал Sphinx Search Server, который лучше всего оптимизирован для полнотекстового поиска. Посетите http://sphinxsearch.com/.

Он предназначен для работы с MySQL, поэтому это дополнение к вашей текущей рабочей области.

Ответ 2

Я не претендую на то, чтобы иметь решение, но вот мои идеи. Во-первых, я, как и вы, за долгие запросы LIKE %%: я бы выполнил запрос, ограниченный несколькими ответами в MySQL, например, дюжину, вернуть его пользователю и подождать, чтобы узнать, хочет ли пользователь больше совпадающих записей или запускает в фоновом режиме полный запрос, в зависимости от ваших потребностей в индексации для будущих поисков.

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

Вот почему я думаю, что решение, которое я видел в "программном обеспечении с открытым исходным кодом" (я не помню его имени), не так уж плохо для текстового поиска в сообщениях: каждый раз, когда данные вставляются, таблица под названием "Слова" хранятся следы каждого существующего слова и другая таблица (пусть говорят "WordsLinks" ) связь между каждым словом и сообщениями, которые появляются. Такое решение имеет некоторые недостатки:

• Каждая вставка, удаление, обновление в базе данных намного медленнее
• Должен предвидеть выбор данных для поисковой системы: если вы решили сохранить два слова, которые вы никогда не сохраняли, слишком поздно для уже записанных данных, если только вы не начнете полную обработку данных.
• Вы должны позаботиться о DELETE, а также UPDATE и INSERT

Но я думаю, что есть некоторые большие преимущества:

• Время вычисления, вероятно, совпадает с "решением памяти" (в конечном итоге), но оно разделяется в каждой базе данных "Создать/обновить/удалить", а не во время запроса.
• Поиск целого слова или слов "начиная с" происходит мгновенно: при индексировании поиск в таблице "Слова" является дихотомическим. И запрос таблицы WordLinks очень быстрый либо с индексом.
• Поиск нескольких слов одновременно может быть простым: собрать группу "WordLinks" для каждого найденного Word и выполнить пересечение на них, чтобы сохранить только "Идентификаторы базы данных", общие для всех этих групп. Например, со словами "дерево" и "лист", первый из них может содержать записи таблицы {1, 4, 6}, а второй - {1, 3, 6, 9}. Таким образом, с пересечением просто хранить только общие части: {1, 6}.
• "Подобно %%" в таблице с одним столбцом, вероятно, быстрее, чем много "Like %%" в разных полях разных таблиц. И каждый движок базы данных обрабатывает некоторый кеш: таблица "Words" может быть немного достаточной для хранения в памяти.
• Я думаю, что существует небольшой риск проблем с производительностью и памятью, если данные становятся огромными.
• Поскольку каждый поиск выполняется быстро, вы можете даже искать синонимы. Например, найдите "сеть", если пользователь ничего не нашел с "ethernet".
• Вы можете применять правила, например, расщеплять слова верблюда для генерации, например, трех слов "дерево", "X", "woodX" из "woodX". Каждое "слово" очень легкое для хранения и поиска, поэтому вы можете многое сделать.

Я думаю, что решение, в котором вы нуждаетесь, может быть сочетанием методов: например, вы можете сохранять облегченные UPDATE, INSERT, DELETE и запускать "Words" и "WordsLinks", подавая TRIGGER.

Просто для анекдота я увидел программное обеспечение, разработанное моей компанией, в котором было принято решение сохранить "все" (!) в памяти. Это позволяет нам рекомендовать нашим клиентам покупать серверы с 64 ГБ оперативной памяти. Немного дороже. Это объясняет, почему я очень осмотрителен, когда вижу решения, которые могут в конечном итоге привести к заполнению памяти.

Ответ 3

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

Вот возможное решение:

• Перепроектируйте свою базу данных, чтобы содержать только авторитетные данные, но не производные данные. Таким образом, все записи кэша должны исчезнуть из MySQL.

• Храните данные только в течение продолжительности запроса в памяти в приложении. Это значительно упрощает дизайн вашего приложения (думаю, условия гонки) и позволяет масштабировать до разумного числа клиентов.

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

Вы можете взглянуть на Redis или Memcached для слоя кеширования. Я думаю, что стратегия LRU должна соответствовать здесь. В зависимости от того, насколько сложны ваши запросы, может иметь смысл и выделенный механизм индексированного поиска, такой как Lucene.

Ответ 4

Я уверен, что это может быть реализовано в MySQL, но было бы гораздо меньше усилий, чтобы просто использовать существующую поисковую базу данных, такую ​​как Elasticsearch. Он использует библиотеку Lucene для реализации инвертированного индекса, имеет обширную документацию, поддерживает горизонтальное масштабирование, довольно простой язык запросов и так далее. Я думаю, что было довольно много работы, чтобы зайти так далеко, и будет еще больше работать с кешами, условиями гонки, ошибками, проблемами производительности и т.д., Чтобы сделать решение "класс производства".