- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброй ночи!
Под статьей выводится блок похожих статей по теме (ссылки).
Было когда-то давно через LIKE, потом переделал через fulltext / against.
Сейчас база чуть выросла и такой поиск занимает 10 секунд и выше, что существенно увеличивает время загрузки страницы. Что посоветуете с этим делать?
Отдельную таблицу создать и кешировать в ней на некоторое время результаты поиска похожих статей? С имеющейся больше ничего нельзя сделать для ускорения?
`id` int(8) unsigned NOT NULL AUTO_INCREMENT,
`date` int(4) unsigned DEFAULT NULL,
`section` int(1) unsigned DEFAULT NULL,
`title` varchar(255) DEFAULT NULL,
`text` text,
...
PRIMARY KEY (`id`),
KEY `section` (`section`),
FULLTEXT KEY `title` (`title`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=423210 ;
SELECT * FROM news WHERE MATCH (title) AGAINST ('isis вернулась воевавшая домой израильтянка') AND id<>100 ORDER BY date DESC LIMIT 10
кешировать похожие статьи либо в бд прописать для самой статьи id похожих а при последующих запросах выводить уже готовые похожие по id а не делать каждый раз фуллтекст поиск
на сколько выросла что поиск занимает 10 сек?
возможно хостинг сменить нужно
Что посоветуете с этим делать?
поставить на сайт поиск от Яндекса или Гугла ))) а если это не подходит то посмотрите эту статью по оптимизации MYSQL http://code.tutsplus.com/tutorials/top-20-mysql-best-practices--net-7855
Ну сейчас AUTO_INCREMENT=423210, раньше помню когда было 200к записей. Не помню когда именно менял алгоритм, возможно как раз когда было 200к.
Хостинг врядли. Двиг писался больше 6 лет назад, опыта было мало, хостил на хостинге за $1 в месяц. Когда меня оттуда турнули за нагрузку пару лет назад я перебрался сразу на VPS - база загнулась за пол часа после переезда, после чего я все максимально оптимизировал что мог. На серваке еще ресурсы есть, кроме этого сайта там еще несколько, при этом нагрузка CPU не 100%. Не думаю что нужно менять хостинг.
Единственное что я пока не понимаю - раньше было 10к в сутки посетителей, но с начала года Яндекс что-то мутит и с февраля у меня 1-2к, а тормоза жестче стали.
ОК, так и думал что нужно результаты поиска кешировать на скажем пару суток, чтобы новые статьи в "похожие" добавлялись, но поиск шел по индексам и нагрузка была меньше. Для самой статьи нет, только в отдельную таблицу. Просто очень не хочу делать теги как в DLE - мне такая реализация не нравится.
Поиск от Яндекса ерунда, чтобы он был актуален нужно быстрое попадание в индекс чего сейчас нет.
Указанную статью когда-то читал, половина из этого уже применяется.
поставить sphinx и не мучать mysql. Или эта беда на хостинге?
Из базуки по воробьям... Обычный поиск по сайту, зачем там сложные поисковые движки.
Это не главное, я изначально говорил о подборе похожих новостей по теме.
---------- Добавлено 03.10.2015 в 15:50 ----------
Еще один вопрос, позволю себе задать тут же, хотя тема другая.
В каждой категории идет постраничный вывод новостей от новых к старым. Как уменьшить время запросов вида
для очень больших номеров страниц?
SELECT * FROM table JOIN (SELECT id FROM table ORDER BY id LIMIT 1000000, 10) as b ON b.id = table.id
для очень больших номеров страниц?
какое значение номер страницы может иметь на время запроса? БД без разницы откуда делать выборку из начала таблицы или из конца, главное чтобы у вас нормальные индексы были прописаны.
---------- Добавлено 03.10.2015 в 20:48 ----------
Из базуки по воробьям...
это про использование fulltext для вывода похожих новостей)
С "читайте также" разобрался, через пару дней сравню среднюю нагрузку с прошлым периодом.
Грубо говоря 5000 страниц по 20 постов на страницу дают то самое значение индекса из запроса. У меня свой лог медленных запросов, включающий время запроса, адрес запрошенной страницы, сам запрос и еще много чего. В нем полно подобных запросов для больших номеров страниц т.е. больших значений индекса.
Практика показывает что это не так. Возможно из-за прохода по большому файлу с записями переменной толщины.
индекс id и категория - все по чему делается WHERE.
А в чем прикол? Все равно идет чтение индексов из таблицы с динамическим размером записи, а потом по этим индексам подтягиваются остальные поля.
Ну попробуйте для разнообразия optimize table . Обычно это бесполезная операция, но для таких индексов может помочь.
А в чем прикол? Все равно идет чтение индексов из таблицы с динамическим размером записи, а потом по этим индексам подтягиваются остальные поля.
Ну если новостей тысячи то прикол есть. Можете по експерементировать.