Здравствуйте
Есть каталог товаров. Счетчики комментариев, лайков и просмотров вынес в отдельную таблицу. Если делать обычную выборку товаров, то запрос кешируется с помощью встроенного механизма кэширования и соответственно последующие результаты выборки по этому же запросу берутся из кэша, что значительно ускоряет работу.
Необходимо реализовать возможность сортировки по количеству просмотров и лайкам, но для реализации сего, необходимо соединить обе таблицы (товары и счетчики) с помощью JOIN LEFT. Но такие запросы уже менее эффективны, так как при каждом обновлении счетчика, результат запроса удаляется из кэша, из-за чего запрос становится медленней почти в 20 раз.
Как грамотно реализовать систему счетчиков и сортировки, что бы это отрицательно не повлияло на производительность?
Виталий: С индексами конечно. Например первый запрос проходит за 0.002 с, а следующий раз, после кэширования, этот же запрос проходит за 0.0001 с. Но так как он включает в себя таблицу с счетчиками, которые очень часто обновляются, соответственно, почти каждый раз запрос будет проходить за 0.002 с. Мелочь, но если собрать все в кучу...
hunter_outlaw: ок, собираем в кучу 1000 запросов за раз, (трудно представить что-то такое на 1000 запросов в секунду, это 60 000 в минуту, 360 0000 в час и пусть 1 000 000 в сутки, ну ладно), итого 2 секунды? Странички у вас грузиться будут дольше. И хочу посмотреть на ваш твитер с 1000 пользователей в секунду )
Собсно в чем проблема? У вас виснет сервер, не хватает соединений к базе? Пользователи прут стремительным домкратом и сервер не успевает отдавать незакешенные запросы?
Если нет - какие проблемы? Так есть и так должно быть, выборка из таблиц с актуальными данными всегда будет происходить из базы напрямую, если джоин не включает 4 таблицы по овер 10 мильёнов записей - все будет работать быстро, ну, если структура верная. А если нет - смотрите как оптимизировать базы, кеш здесь вообще как бы ниочем.
Я не жду, пока начнет виснуть сервер. Уже был случай, когда нахлынули пользователи (на то время, на старом сервере, вместо 100 онлайн было 600-700) и тогда уже не было времени оптимизировать скрипты и базу. Поэтому хочу заранее предусмотреть все такой случай и максимально оптимизировать работу скрипта и базы
hunter_outlaw: проверьте индексы на базах, сделайте 1 запрос с explain - посмотрите план запроса, посмотрите что можно улучшить, в целом задержек быть не должно, базы держат огромные нагрузки при должной настройке.
Средний
