Должен разъяснить. Дело в том, что MySQL по-разному оптимизирует LIKE в зависимости от того, какой параметр используется для поиска. Если LIKE используется без % в начале (например, LIKE 'слово%'), то MySQL будет использовать ключ фиксированного размера на соответствующем поле VARCHAR.Поэтому такая выборка работает очень быстро - не нужно ничего искать, MySQL уже знает, в каких строках таблицы слов находятся подходящие слова. Поэтому такой LIKE смело можно назвать не поиском, а выборкой по ключу. И по сути индексированный поиск WP FullText Search - это тоже не поиск, а выборка по ключу :-) поэтому и быстрый.
Если же LIKE используется с % в начале параметра (например, LIKE '%слово%'), то использование ключа становится невозможным. MySQL приходится проверять весь текст полностью, сравнивая '%слово%' со строкой в цикле. И это уже реальный поиск.
Совсем неочевидно, сколько ещё будет результатов кроме одного найденного малорелевантного. Может быть десяток, а может быть, этот результат будет вообще один-единственный. Во всяком случае, мы не можем решать за пользователя, хочет ли он просмотреть все найденные документы или ему достаточно лишь 30% от найденного. Бывает, что запрос сложный.
Про сортировку на клиенте речи не было. Весь поиск, сортировка и генерация страницы с результатами поиска производится на стороне PHP, то есть, на сервере.
Нет ничего плохого гонять большие объёмы информации. Это бесплатно. В отличие от аренды VPS с root-доступом и программистом, который может всё настроить, или облачного решения для поиска. Хотя многие склоняются к такому варианту и вполне счастливы.
Всё очень индивидуально на самом деле. Зависит от мощностей сервера на котором крутится MySQL, от размеров RAM и innodb_cache в частности. На практике мы получали результаты менее секунды при 400к постов, правда там и сервер не самый плохой - 16 Гбт памяти, MySQL настроен как нужно, 2048 Mb отдано под php memory_limit. Опять же хочу добавить, что алгоритм не ставит целью победить по скорости современные поисковые системы. Тут речь про инструмент, нативно работающий под WordPress.
Для разбора файлов мы используем свой собственный сервис Textmill.io. В бесплатной версии (которая в репе WordPress) нет этого функционала, он есть только в платной версии.
Но для гика всё просто на самом деле - при индексировании каждого поста WP вызывается хук wpfts_index_post, и мы можем проверить тип поста. Если он "attachment", то есть медиафайл, то мы берём ссылку на файл, передаём его в Textmill.io, в ответ получаем разобранный файл в виде JSON, который уже индексируем как обычный текст.
Кстати в платной версии встроена библиотека для разбора PDF на PHP. Работает она неплохо, но очень большие файлы не тянет. Так что если у клиента есть необходимость искать только PDF, он может поставить побольше memory_limit, отключить Textmill.io и пользоваться только внутренним экстрактором.
Это микросервис fire-flare. На поиск он не влияет и единственный его смысл в том, чтобы уведомлять фронтенд о происходящих на сервере (внутри индексатора) событиях. Всё может работать и без этого микросервиса, но тогда приходится периодически (довольно часто, 1 раз в 5 секунд) делать запросы с клиента на сервер WP, отчего сильно увеличивается загрузка, особенно если открыто 10 вкладок одной и той же админки.
Зачем уведомлять фронтенд? В админке есть блок статистики, показывающий текущее состояние индекса (сколько документов проиндексировано, сколько в очереди и всё такое прочее) - эта информация динамично меняется и хотелось бы обновлять её 1 раз в 5 секунд хотя бы. Вот для того, чтобы не мучать WP мы и сделали такой внешний ретранслятор коротких информационных пакетов.
Первичного отбора по релевантности нет, нам показалось логичным, что право на попадание в список результатов могут получить абсолютно все документы, даже те, в которых есть одно-единственное малорелевантное слово. Таким образом, выборка векторов производится абсолютно по всем совпадениям.
Одна из операций выборки - это получение полного списка подходящих слов из таблицы слов. Тут используется LIKE 'слово%' либо LIKE '%слово%' (в зависимости от режима работы - есть два режима "простой поиск" и "глубокий поиск"). Но такой способ использования LIKE использует ключи, поэтому он очень быстр. А вот полнотекстовый поиск с использованием LIKE 'слово%' невозможен, потому что он будет искать слово только в начале текста, а в середине текста находить не будет. Поэтому в WordPress нативно используется только LIKE '%слово%', который ключи не использует и поэтому крайне медленный на больших объёмах данных.
Отдельно могу сказать по MATCH AGAINST. Да, скорее всего внутри MySQL используется похожий принцип, вот только настроить этот поиск никак невозможно. Есть несколько параметров внутри глобального конфига my.ini/my.cnf, которыми можно задать, например, минимальную длину слова (она по умолчанию выставлена в 3), то есть слова короче 3 символов просто игнорируются, независимо от их важности. Релевантность он считает по каким-то своим формулам. Изменить глобальный конфиг через PHP тоже не получится на большинстве хостингов.
И да, тесты показали, что MATCH AGAINST работает медленно на больших массивах. Наш алгоритм быстрее.
Я планирую в ближайшее время написать ещё одну статью с детальным разбором алгоритма релевантности и проведу сравнение с нативным LIKE-поиском и вариантом с MATCH AGAINST. Не хотелось перегружать обзорную статью техническими деталями.
Действительно, п.2 может вернуть очень много записей. Но, к счастью, это очень короткие записи (каждая содержит только ID слова и ID документа), и это ничего, если их будет пара-тройка миллионов, PHP сегодня быстр и такие данные обрабатывает влёт. Всё-таки самая долгая операция в этом алгоритме - запрос к MySQL, поэтому он максимально простой.
Относительная релевантность слова на данный момент определяется просто по длине. Длина искомого слова делится на длину найденного слова (получается всегда меньше 1) и это как раз является коэффициентом релевантности слова.
Сейчас алгоритм не различает смыслов слов. Если по запросу "мышь" пользователь будет получать "мышь полёвка", то он сможет уточнить запрос добавлением "комп" или "прово", что уже однозначно выдаст искомый результат.
Первая версия, которую зарелизили и "показали миру" была очень простая, хотя уже имела функционал индексирования. Там была куча багов и вообще непонятно как люди качали и пользовались. Время разработки от идеи до первого релиза было, думаю, месяца три-четыре.
Не думаю, что этим вопросом эйчары "конвертируют" энтузиастов в формалистов. Скорее это способ узнать кто человек психологически и задачи какого рода он будет выполнять в своей работе лучше. Где-то необходим формализм, где-то - энтузиазм.
Вопрос в том - какие цели ставит себе человек при найме. Если заработать денег - он штукатурит стену, остальное ему неинтересно. Если участвовать в создании полезных продуктов - скорее всего второе.
"У трёх каменщиков спросили - что ты делаешь?
Первый сказал: я таскаю камни и дроблю их на мелкие части.
Второй сказал: я зарабатываю деньги, чтобы кормить семью.
Ну каждый может делать что угодно, мы же не про различные маргинальные способы использования технологий тут рассуждаем :) Можно и отвёрткой хлеб нарезать так-то, но это не проблема отвёртки.
Во-первых, redux хранилищ может быть несколько, и это очень удобно, когда надо отделить сложный модуль в свою инфраструктуру. Например, это может быть виджет или страница. Это что касается "глобальных стейтов".
Во-вторых, в useSelector можно с помощью несложной функции проверять изменение только некоторых полей и очень точно задавать условия, при которых какой-то компонент должен быть перерисован.
Без сомнения, useState вне конкуренции, когда нужно работать с локальными состояниями компонента. Но речь как я понимаю именно про состояния, выходящие за пределы компонента.
Именно в этом и суть. Надо найти ТУ компанию и ту сферу деятельности, в которой вы можете максимально проявить свои способности и принести их в этот мир через вашего работодателя. Если запросы работодателя и ваши интересы/способности не совпадают - надо просто менять работу.
Ну раз вы ярко выраженный индивидуалист, то работать под чьим-то "мудрым" руководством у вас вряд ли получится. У меня вот не получилось - поэтому пришлось сперва уйти на фриланс, а потом и вовсе начать пилить свои проекты. Действительно, все люди разные, кому-то нормально в офисе, а кто-то не умеет идти в общей упряжке и работать в команде.
Сам смысл статьи для меня не очень понятен - очень похоже, что вы просто сетуете на жизнь. Так не работает, к сожалению.
Не хочется отвечать банально, но, автор, начни с анализа ценностей в своей жизни. В процессе чтения статьи возникает ощущение, что ты идёшь в айти только для того, чтобы "заработать денег". Работодатели это чувствуют и, поверь, они против того, чтобы люди приходили к ним только за деньгами. То, что работодателю нужно - это отдача от работника и максимальный прогресс по проектам.
Почему бы тебе не взять на вооружение какой-нибудь икигай или подобную штукенцию (хотя икигай очень хорош) и выяснить - какие ценности ты можешь привнести от себя в этот мир и потом, уже отталкиваясь от этого, прийти к выводу - какой компании и чем ты мог бы помочь.
На каждую реплику у меня есть логичный ответ, но я предпочту не отвечать, чтобы не продолжать общаться в подобном тоне.
Должен разъяснить. Дело в том, что MySQL по-разному оптимизирует LIKE в зависимости от того, какой параметр используется для поиска. Если LIKE используется без % в начале (например, LIKE 'слово%'), то MySQL будет использовать ключ фиксированного размера на соответствующем поле VARCHAR.Поэтому такая выборка работает очень быстро - не нужно ничего искать, MySQL уже знает, в каких строках таблицы слов находятся подходящие слова. Поэтому такой LIKE смело можно назвать не поиском, а выборкой по ключу. И по сути индексированный поиск WP FullText Search - это тоже не поиск, а выборка по ключу :-) поэтому и быстрый.
Если же LIKE используется с % в начале параметра (например, LIKE '%слово%'), то использование ключа становится невозможным. MySQL приходится проверять весь текст полностью, сравнивая '%слово%' со строкой в цикле. И это уже реальный поиск.
Есть немного информации тут
https://stackoverflow.com/questions/2042269/how-to-speed-up-select-like-queries-in-mysql-on-multiple-columns
Совсем неочевидно, сколько ещё будет результатов кроме одного найденного малорелевантного. Может быть десяток, а может быть, этот результат будет вообще один-единственный. Во всяком случае, мы не можем решать за пользователя, хочет ли он просмотреть все найденные документы или ему достаточно лишь 30% от найденного. Бывает, что запрос сложный.
Про сортировку на клиенте речи не было. Весь поиск, сортировка и генерация страницы с результатами поиска производится на стороне PHP, то есть, на сервере.
Нет ничего плохого гонять большие объёмы информации. Это бесплатно. В отличие от аренды VPS с root-доступом и программистом, который может всё настроить, или облачного решения для поиска. Хотя многие склоняются к такому варианту и вполне счастливы.
Всё очень индивидуально на самом деле. Зависит от мощностей сервера на котором крутится MySQL, от размеров RAM и innodb_cache в частности. На практике мы получали результаты менее секунды при 400к постов, правда там и сервер не самый плохой - 16 Гбт памяти, MySQL настроен как нужно, 2048 Mb отдано под php memory_limit. Опять же хочу добавить, что алгоритм не ставит целью победить по скорости современные поисковые системы. Тут речь про инструмент, нативно работающий под WordPress.
Можно скачать напрямую из репозитория WordPress, он в открытом доступе
http://plugins.svn.wordpress.org/
Для разбора файлов мы используем свой собственный сервис Textmill.io. В бесплатной версии (которая в репе WordPress) нет этого функционала, он есть только в платной версии.
Но для гика всё просто на самом деле - при индексировании каждого поста WP вызывается хук wpfts_index_post, и мы можем проверить тип поста. Если он "attachment", то есть медиафайл, то мы берём ссылку на файл, передаём его в Textmill.io, в ответ получаем разобранный файл в виде JSON, который уже индексируем как обычный текст.
Кстати в платной версии встроена библиотека для разбора PDF на PHP. Работает она неплохо, но очень большие файлы не тянет. Так что если у клиента есть необходимость искать только PDF, он может поставить побольше memory_limit, отключить Textmill.io и пользоваться только внутренним экстрактором.
Это микросервис fire-flare. На поиск он не влияет и единственный его смысл в том, чтобы уведомлять фронтенд о происходящих на сервере (внутри индексатора) событиях. Всё может работать и без этого микросервиса, но тогда приходится периодически (довольно часто, 1 раз в 5 секунд) делать запросы с клиента на сервер WP, отчего сильно увеличивается загрузка, особенно если открыто 10 вкладок одной и той же админки.
Зачем уведомлять фронтенд? В админке есть блок статистики, показывающий текущее состояние индекса (сколько документов проиндексировано, сколько в очереди и всё такое прочее) - эта информация динамично меняется и хотелось бы обновлять её 1 раз в 5 секунд хотя бы. Вот для того, чтобы не мучать WP мы и сделали такой внешний ретранслятор коротких информационных пакетов.
повтор, удалено
Первичного отбора по релевантности нет, нам показалось логичным, что право на попадание в список результатов могут получить абсолютно все документы, даже те, в которых есть одно-единственное малорелевантное слово. Таким образом, выборка векторов производится абсолютно по всем совпадениям.
Одна из операций выборки - это получение полного списка подходящих слов из таблицы слов. Тут используется LIKE 'слово%' либо LIKE '%слово%' (в зависимости от режима работы - есть два режима "простой поиск" и "глубокий поиск"). Но такой способ использования LIKE использует ключи, поэтому он очень быстр. А вот полнотекстовый поиск с использованием LIKE 'слово%' невозможен, потому что он будет искать слово только в начале текста, а в середине текста находить не будет. Поэтому в WordPress нативно используется только LIKE '%слово%', который ключи не использует и поэтому крайне медленный на больших объёмах данных.
Отдельно могу сказать по MATCH AGAINST. Да, скорее всего внутри MySQL используется похожий принцип, вот только настроить этот поиск никак невозможно. Есть несколько параметров внутри глобального конфига my.ini/my.cnf, которыми можно задать, например, минимальную длину слова (она по умолчанию выставлена в 3), то есть слова короче 3 символов просто игнорируются, независимо от их важности. Релевантность он считает по каким-то своим формулам. Изменить глобальный конфиг через PHP тоже не получится на большинстве хостингов.
И да, тесты показали, что MATCH AGAINST работает медленно на больших массивах. Наш алгоритм быстрее.
Я планирую в ближайшее время написать ещё одну статью с детальным разбором алгоритма релевантности и проведу сравнение с нативным LIKE-поиском и вариантом с MATCH AGAINST. Не хотелось перегружать обзорную статью техническими деталями.
Действительно, п.2 может вернуть очень много записей. Но, к счастью, это очень короткие записи (каждая содержит только ID слова и ID документа), и это ничего, если их будет пара-тройка миллионов, PHP сегодня быстр и такие данные обрабатывает влёт. Всё-таки самая долгая операция в этом алгоритме - запрос к MySQL, поэтому он максимально простой.
Пока, увы, до битрикса не дошли руки.
Относительная релевантность слова на данный момент определяется просто по длине. Длина искомого слова делится на длину найденного слова (получается всегда меньше 1) и это как раз является коэффициентом релевантности слова.
Сейчас алгоритм не различает смыслов слов. Если по запросу "мышь" пользователь будет получать "мышь полёвка", то он сможет уточнить запрос добавлением "комп" или "прово", что уже однозначно выдаст искомый результат.
Первая версия, которую зарелизили и "показали миру" была очень простая, хотя уже имела функционал индексирования. Там была куча багов и вообще непонятно как люди качали и пользовались. Время разработки от идеи до первого релиза было, думаю, месяца три-четыре.
А я уже могу писать, могу писать!
Могу тетрадку показать, и даже полистать.
Ого, да ты учёным стал, скажи, о чём ты написал?
А мне откуда это знать? Я сам хотел бы знать.
Ведь я сказал - могу писать! Писать, а не читать!
(c) Владимир Орлов
Не думаю, что этим вопросом эйчары "конвертируют" энтузиастов в формалистов. Скорее это способ узнать кто человек психологически и задачи какого рода он будет выполнять в своей работе лучше. Где-то необходим формализм, где-то - энтузиазм.
Вопрос в том - какие цели ставит себе человек при найме. Если заработать денег - он штукатурит стену, остальное ему неинтересно. Если участвовать в создании полезных продуктов - скорее всего второе.
"У трёх каменщиков спросили - что ты делаешь?
Первый сказал: я таскаю камни и дроблю их на мелкие части.
Второй сказал: я зарабатываю деньги, чтобы кормить семью.
Третий сказал: я строю храм."
Возможно вы не до конца разобрались в концепции правильного использования этого удобного и гибкого инструмента.
Ну каждый может делать что угодно, мы же не про различные маргинальные способы использования технологий тут рассуждаем :) Можно и отвёрткой хлеб нарезать так-то, но это не проблема отвёртки.
Во-первых, redux хранилищ может быть несколько, и это очень удобно, когда надо отделить сложный модуль в свою инфраструктуру. Например, это может быть виджет или страница. Это что касается "глобальных стейтов".
Во-вторых, в useSelector можно с помощью несложной функции проверять изменение только некоторых полей и очень точно задавать условия, при которых какой-то компонент должен быть перерисован.
Без сомнения, useState вне конкуренции, когда нужно работать с локальными состояниями компонента. Но речь как я понимаю именно про состояния, выходящие за пределы компонента.
Какой, например?
Именно в этом и суть. Надо найти ТУ компанию и ту сферу деятельности, в которой вы можете максимально проявить свои способности и принести их в этот мир через вашего работодателя. Если запросы работодателя и ваши интересы/способности не совпадают - надо просто менять работу.
Ну раз вы ярко выраженный индивидуалист, то работать под чьим-то "мудрым" руководством у вас вряд ли получится. У меня вот не получилось - поэтому пришлось сперва уйти на фриланс, а потом и вовсе начать пилить свои проекты. Действительно, все люди разные, кому-то нормально в офисе, а кто-то не умеет идти в общей упряжке и работать в команде.
Сам смысл статьи для меня не очень понятен - очень похоже, что вы просто сетуете на жизнь. Так не работает, к сожалению.
Не хочется отвечать банально, но, автор, начни с анализа ценностей в своей жизни. В процессе чтения статьи возникает ощущение, что ты идёшь в айти только для того, чтобы "заработать денег". Работодатели это чувствуют и, поверь, они против того, чтобы люди приходили к ним только за деньгами. То, что работодателю нужно - это отдача от работника и максимальный прогресс по проектам.
Почему бы тебе не взять на вооружение какой-нибудь икигай или подобную штукенцию (хотя икигай очень хорош) и выяснить - какие ценности ты можешь привнести от себя в этот мир и потом, уже отталкиваясь от этого, прийти к выводу - какой компании и чем ты мог бы помочь.
Именно помочь, а не нагреть их на деньги.