SELECT id,text from articles WHERE uid IN(1,2,3,4,5,10) order by time DESC LIMIT 0,10
так вот, если друзей 500 то запрос этот будет очень грузить базу, так ведь? Можно как-то по-другому эту ленту формировать? А то хочется затрачивать минимум ресурсов... индекс на uid (а значения ведь могут повторяться) насколько я понимаю только частично решит проблему.
Спустя 4 часа, 4 минуты, 30 секунд (26.07.2012 - 00:13) testr написал(а):
по-другому не можете посоветовать да? (
а кто-то сталкивался с подобной задачей?
а кто-то сталкивался с подобной задачей?
Спустя 13 часов, 50 минут, 39 секунд (26.07.2012 - 14:03) testr написал(а):
есть кто живой? (
Спустя 13 минут, 3 секунды (26.07.2012 - 14:17) inpost написал(а):
только индексы. Можно в отдельной таблице хранить новинки для пользователя, будет быстрее выборка, но дополнительный запрос на вставку.
Спустя 27 минут, 22 секунды (26.07.2012 - 14:44) neadekvat написал(а):
| Цитата (inpost @ 26.07.2012 - 15:17) |
| Можно в отдельной таблице хранить новинки для пользователя, будет быстрее выборка, но дополнительный запрос на вставку. |
Ага, а еще ты забыл про количество дублированной информации, которая скопится за очень короткий срок.
Спустя 14 минут, 49 секунд (26.07.2012 - 14:59) inpost написал(а):
neadekvat
Чистить надо. Я свою статистику каждый день кроном очищаю
Чистить надо. Я свою статистику каждый день кроном очищаю
Спустя 45 минут, 37 секунд (26.07.2012 - 15:44) neadekvat написал(а):
inpost, чистить что именно? Это же не временные данные. Невозможность посмотреть свою ленту, например, недельной давности - это уже ограничение, а ограничения пользователи очень не любят.
Плюс не забываем про общие проблемы дублированной информации. Хотя бы актуальность. Представь, что я удалил свою запись, которую уже скопировали в чужие ленты (не "репостнули", а скопировали там, внутри, чтобы показать новость от меня), сколько времени пройдет, пока наш синхронизатор увидит это и удалит запись во всех лентах? Достаточно. А это не rss, которую загрузил - и все, тут важна актуальность.
Так что, пока сервис не вышел на уровень Вконтакте, у которого огромные вычислительные способности (свой дата-центр) и возможности хранить большой объем пользовательской информации, надо думать о том, как оптимизировать работу без дублирования. А уж потом кэширование и то, что предложил ты.
Плюс не забываем про общие проблемы дублированной информации. Хотя бы актуальность. Представь, что я удалил свою запись, которую уже скопировали в чужие ленты (не "репостнули", а скопировали там, внутри, чтобы показать новость от меня), сколько времени пройдет, пока наш синхронизатор увидит это и удалит запись во всех лентах? Достаточно. А это не rss, которую загрузил - и все, тут важна актуальность.
Так что, пока сервис не вышел на уровень Вконтакте, у которого огромные вычислительные способности (свой дата-центр) и возможности хранить большой объем пользовательской информации, надо думать о том, как оптимизировать работу без дублирования. А уж потом кэширование и то, что предложил ты.