- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Про полнотекстный (fulltext) поиск ни слова. А LIKE очень тормозная конструкция.
В данном запросе полноностью согласен, но с индексами не намного тормознутее любой другой функции сравнения. Если пользоваться таблицей синонимов, то и ЛИКЕ не нужен. Качество поиска и скорость fulltext также оставляет желать лучшего, в отличие от правильно составленных запросов без него.
antono, читайте внимательно статью, там и про полнотекстовый поиск и про тормознутость LIKE написано.
Извиняюсь, не заметил маленький абзац про него.
В данном запросе полноностью согласен, но с индексами не намного тормознутее любой другой функции сравнения. Если пользоваться таблицей синонимов, то и ЛИКЕ не нужен. Качество поиска и скорость fulltext также оставляет желать лучшего, в отличие от правильно составленных запросов без него.
Качество поиска фултекст зависит от составленного запроса к базе. Можно добиться хорошего качества, ничем не уступающего LIKE, а вот скорость в десятки раз быстрее. По крайней мере мне не удалось сделать быстрый поиск по базе из 150000 записей с текстами около килобайта с помощью LIKE, а фултекстом удалось. Может просто я не до конца понял как обращаться с LIKE.
Извиняюсь, не заметил маленький абзац про него.
Качество поиска фултекст зависит от составленного запроса к базе. Можно добиться хорошего качества, ничем не уступающего LIKE, а вот скорость в десятки раз быстрее. По крайней мере мне не удалось сделать быстрый поиск по базе из 150000 записей с текстами около килобайта с помощью LIKE, а фултекстом удалось. Может просто я не до конца понял как обращаться с LIKE.
Чтобы лайк летал он должен быть индексом. Попробуй создать отдельную таблицу для поиска, загнать в нее все ключевики текста, положение слов на странице и поиск будет на порядок быстрее и гибче фултекста. Но в таком варианте и Лайк не обязателен можна использовать "=", если использовать только корни или доп таблицу словоформ. Для сранения тестил на базе из примерно 200 тыс записей. Результаты: Лайк - 1,2 - 2,0 сек (качество поиска на 4), Фултекст 0,6 - 0,9 сек (качество поиска 3), Предложенный способ: 0,05 - 0,1 сек, качество поиска зависит только от фантазии исполнителя
З.Ы. Прошу прощения не дочитал сразу статью до конца, все написано очень грамотно, и для sql я думаю это лучший вариант поиска. Сам использую похожую схему. Скорость и качество поиска очень высокие.
Чтобы лайк летал он должен быть индексом.
согласен. + насколько я помню, по объемным полям можно делать индекс не на все поле, а на первые несколько символов.
Yukko
Сергей, LIKE, начинающийся с %, не использует индексы.
Бресь Сергей, знаю :)
Yukko
Сергей, LIKE, начинающийся с %, не использует индексы.
Дочитайте до конца, он даже по текстовым полям не ищет а только по целочисленным.
DIMON-UA, ему читать не надо ничего ;) поверьте на слово 🚬
Yukko, вместо предложенных Вами эвристик, касающихся морфологии, я бы предложил (на выбор) три возможных алгоритма:
1) Построение на основе ispell полного русского словаря (всех словоформ), и поиск по нему всех нормальных словоформ. Объем словаря будет очень большим, т.к. нужно будет хранить все словоформы, полученные из ispell.
2) Поиск основной формы слова (также по ispell) на основе алгоритма, описанного здесь:
http://xpoint.ru/know-how/VebAlgoritmyi/RabotaSTekstami/RabotaSRusskoyMorfologieyPriPomoschiSlovaryaIspell
В базе потребуется хранить только исходный ispell-овский словарь.
3) Вовсе без словаря -- использовать стеммер Портера (это, насколько мне известно, единственный более-менее приемлемый стеммер для русского языка). Я, кстати предпочитаю именно этот вариант. Оригинальное описание здесь: http://snowball.tartarus.org/algorithms/russian/stemmer.html
У Котерова есть неплохая реализация: http://forum.dklab.ru/php/advises/HeuristicWithoutTheDictionaryExtractionOfARootFromRussianWord.html
Могу поделиться и своей, но у Дмитрия сделано проще и изящнее.
Nick Bubelo, полезные дополнения :)
PS. +1 pf ispell ;)