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

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет всем. имеется база с следующей таблицей:
CREATE TABLE IndexedPages
(
idx BIGINT NOT NULL AUTO_INCREMENT,
page_url TEXT,
page_text MEDIUMTEXT,
page_title TEXT,
page_meta TEXT,
page_pr INT,
date_indexed DATETIME,
date_modify DATETIME,
obj_images INT,
obj_videos INT,
page_thumbn_path BLOB,
thumb_last_modifyed DATETIME DEFAULT 0,
PRIMARY KEY(idx),
FULLTEXT KEY 'all_fields' (page_title,page_text,page_meta,page_url),
FULLTEXT KEY 'page_title' (page_title),
FULLTEXT KEY 'page_text' (page_text),
FULLTEXT KEY 'page_meta' (page_meta),
FULLTEXT KEY 'page_url' (page_url)
) ENGINE = MyISAM;
в ней содержится на данный момент порядка 65.000 записей.
в общем смысл в чем - есть титл, текст, метатег, урл.
мне нужно сделать выборку по кейворду, учитывая того, что вес слова встречающегося в титле больше чем в метатеге, в метатеге больше чем в странице и т.д.
ну, в общем сделал я следующий запрос для этого:
SELECT SQL_CALC_FOUND_ROWS *,page_url,page_pr,date_modify,page_title,obj_images,obj_videos,page_thumbn_path FROM IndexedPages WHERE( MATCH(page_title) AGAINST (' +keyword' IN BOOLEAN MODE)*8 + MATCH(page_text) AGAINST (' +keyword' IN BOOLEAN MODE)*4 + MATCH(page_meta) AGAINST (' +keyword' IN BOOLEAN MODE)*2 + MATCH(page_url) AGAINST (' +keyword' IN BOOLEAN MODE)*1 ) > 5 ORDER BY date_modify DESC LIMIT 0,10
т.е. релевантность высчитаная мускулем - умножается на коэффициент и складывается, потом выбираются записи с коэффициентом большим 5..
но есть проблема - когда записей было немного, то это нормально быстро работало..
а вот когда записей стало уже больше и больше - начал жутко тормозить.
такой вот запрос может 3-5 секунд обробатываться... а хотелось бы его сделать более эффективным..
подскажите, плиз, что я не так сделал? как это дело оптимизировать?
как это дело оптимизировать?
Сделать еще одну таблицу - ИНДЕКС, по которой и осуществлять поиск. В этом случае "тормознутось" скрипта не будет зависеть от размера основной таблицы.
Сделать еще одну таблицу - ИНДЕКС, по которой и осуществлять поиск. В этом случае "тормознутось" скрипта не будет зависеть от размера основной таблицы.
Объясни плиз.
что в этой таблице хранить нужно будет?
В BOOLEAN MODE все релевантности равны 1 или 0, да и если мы правильно помним, boolean mode ведет себя как like, т.е. в частности - полнотекстовый индекс не особо ему помогает, так скажем.
По Вашему вопросу - как сделать быстрее. Мы решали аналогичную задачу недавно, получилось неплохо, хотя наверное можно было бы сделать лучше.
На Вашем месте мы бы завели отдельную таблицу, в одно поле складировали бы 8 штук page_title, к нему 1 штуку page_url присоединяли и т.д., вешали бы индекс на это поле отдельной таблицы и по нему бы уже искали. К тому же эту таблицу при создании можно чистить от "мусора" - тэгов например и т.д. И ещё мы бы выкинули boolean mode, раз Вам действительно нужна релевантность, а не точные вхождения набора букв (в boolean оно найдет abc в abcd, в отличии от "стандартного" фултекста, но и результат будет 1 или 0, а не релевантность).
Объясни плиз.
что в этой таблице хранить нужно будет?
Точнее, надо не одну, а две таблицы.
В одной хранишь слова(в нормализованном виде), а во второй таблице "координаты" мест (в твоем случае это id записи основной базы), где эти слова встречаются и их тип (в твоем случае, это заголовок, урл и т.д.).
Выставлять коэффициенты релевантности можно, а может даже и нужно, не средствами MySQL, а потом, сортируя выборку в виде массива.
Спасибо. будем пробовать..