Да. 440Hz тоже предлагает обычный вариант — при добавлении нового комментария сбрасывать (удалять) кеш, делать выборку комментариев из базы и выдавать ее и делать новый кеш: Это обычная тривиальная вещь. «при добавлении/изменении данных» — 440Hz, ну что значит «при добавлении» — ну каждую секунду у меня добавляется новый комментрий. Каждую секунду! «я удаляю нужные ключи из кеша» — ну, и каждую секунду ты будешь удалять кеш? Делать новый кеш, а через еще 1 секунду опять его удалять и так далее? Негодится делать кеш на 1 секунду. Теряется его смысл. Вот я о чем.
1. я не каждый камент в кеше храню, а готовый HTML на вывод каментов - нескольких или всех. 2. если каждый камент добавляется в 1 сек, то нагрузка пипец и даже 1 секундное кеширование ООООЧЕНЬ разгрузит базу и сервер у меня вот бывало до 100 запросов в секунду и ниче... не каженный же раз в базу лазить?
вот когда будет такой ресурс и ты ПОСТРОИШЬ архитектуру, позволяющую оперировать большими объемами данных очень быстро - тогда и будешь тут фантазировать. файловый кеш очень медленный. кешировать можно все, что угодно, хоть готовые страницы, хоть SQL запросы. надо понимать что где и как храниться, как выбирается и как доступно. а порассуждать на тему кешев/хешев это можно, но ни к чему не проведет ибо каждый такой проект требует особого подхода.
старик. ну что ты привязался к этой секунде? насри на нее и думай о другом, о том, как спроектировать структуры данных, позволяющие оперировтаь ими быстро и надежно. а твой подход - это решение новичка в лоб. это тупик. такие нагрузки по другому решаются.
это точно - детсад на выезде. придумал себе проблему и даже не решает ее, а мусолит. надо что б в сек. 100 каментов добавлялось - так пусть добавляют. какие проблемы? где-то тормозит? теоритические размышления они хорошим когда есть о чем поговорить и есть опыт. а попиздеть - так это не сюда...
Да, я понял. Это естественно — я храню готовый ХТМЛ фрагмент. Но как ты будешь в этот фрагмент добавлять новые комментарии? Если в конец фрагмента, то да, элементарно. Но они древовидные. В середину тоже можно добавлять комменты. А как ты добавишь в середину своего закешированного ХТМЛ фрагмента какой-нибудь комментарий? Никак. Либо через геморрой. Опа, не знал ((( Хы. Вот те на те. Как-то мои представления о мире не вяжутся с такой простой истиной )))
Неправда, в каментах именно детский сад. И это реальная проблема, а мне предлагают делать кеш каждые 100 секунд. Бугага. А в промежутках между кешами извольте довольствоваться старой версией кеша. Ну не детский сад?
вот я бы перво-наперво сделал линейные каменты, а не стал делать хуйню древовидную в угоду кому-либо. а линейные запросы - они и в африке линейные. 1. храним каменты сразу в кеше, а ингода записываем/сбрасываем их в базу. 2. вот такая схема тебе интересна?
я вот все не могу понять. у тебя реальный проект с такой нагрузкой или "чисто теоретические поползновения"
Мдяяя… Линейные — слишком ненаглядно. Да про линейные я бы даже и не стал топик на форуме поднимать — слишком элементарная задача. Нет, каменты НЕ линейные. Это не обсуждается. Не интересна.
Задача и формулировка очень интересные и уж точно не идиотские. Задача идиотская тогда, когда к статье за все время добавлено всего несколько десятков камментов. Это закешировать без проблем. Когда камменты исчисляются в тысячах, то я не вижу здесь ничего идиотского.
вот смотри. такая вот теория. 1. есть статья. 2. к ней идут каменты с большой скоростью. задача. оптимизировать вывод каментов решение. пользователю ВАЖНо увидеть свой камент в момент добавления. остальное по сути не важно через какой промежуток он увидит новые каменты других. решение. 1. храним в кеше на 60 сек (примерно) каменты (общий ключ) + последние каменты юзера (персональные ключи) 2. при сбросе общего кеша считываем новый список каментов и сбрасываем персональные ключи. все довольны
интересные приколы начинаются от лимона. 1000 - это не интересно. это банально. это обычный MySQL выдержит даже не напрягшись.
придумать "интересную задачу" и ее обсуждать - ну ну... обсуждай. когда надоест - приходи. поможем. з.ы. ни один архитектор не сделает дерево на высоконагруженных проектах, даже если это красиво, а если и будет делать дерево, то 1000 раз подумает о том, чем ему это грозит и "что есть красота" а где ВЫЕБОНЫ. вот у тебя выебоны. удачи.
Про того, кто добавляет комментарий я уже писал — проблема не с ним, проблема с теми, кто зашел только что в статью и решил почитать камменты. Ты сейчас предлагаешь то, что мне предлагали выше, только вместо 100 секунд ты предлагаешь 60 ))). Щас сдохну. Прошло 60 секунд, сделался кеш, следующий кеш опять сделается через 60 секунд. А пользователь зашел в промежутке — на 103 секунде. И что он видит? Он видит старые каменты, ибо кеш еще не обновился.
тебе предлагают решения люди, которые немного смыслят в нагрузках, данных и их хранении/выборках. если твоя задача слишком для них сложна, то извини, мы высказали все что могли. туповаты мы для тебя, наверное. пойду еще раз Кнута перечитаю...
Да, так и есть. А древовидные каменты это вещь! Я тебе точно говорю, не спорь. Гораздо красивее и уж точно не выебоны, как ты выражаешься. Вообщем, тема может быть закрыта. Остановлюсь на версии, что даже кеш на 1 секнду будет успешен и сделает то, что от него требуется.
Абсолютно доходит. Но «прошлогодние данные» (я немного утрирую, с вашего позволения) никому не нужны.
Не читал всю полемику до конца, увидел это сообщение и хочу высказаться в его пользу. Кешировать комменты как-то постранично! Если комментов на странице 100, и кто-то хочет полистать и почитать историю - пусть ползает по кешу. А тем кто хочет видеть текущую инфрмацию online - сидит на первой странице с рефрешем. и вытаскивается по 100 последних коментов напрямую из базы. (надеюсь 2 раза по 100 последних коментов из базы в секунду — это не очень много для скулы) Кеш вообще используют дабы избежать огромной нагрузки на SQL сервер и часть направить на "считывание из памяти" (ну или из файла). Нужно посчитать что выгоднее именно в данной ситуации. И тему переместить скорее к SQL-щикам. При такой населенности сайта, сервер наверняка нужен распределенный, скуэль от файловго сервера. Ай Ай я совсем забыл что каменты древовидные и можно добавлять в середину. Что-же делать!