есть какие-то трудности по масштабированию мемкеш в данном случае? не вижу трудности по применению
если можно, объясните, что вы имеете ввиду — видимо я не вижу какие-то очевидные проблемы
опять же есть особенности конкретной архитектуры и особенности проекта, универсального рецета нет
фактически вы говорите что в ваших проектах вам кеш не нужен
для битторрентов для повышения производительности пишется клиент, который держит сотни тысяч коннектов на обычном сервере, но это же не повод говорить всем что следует писать такие клиенты для каждого проекта
видимо вы не сталкивались с ситуацией когда база данных отказывает от того, что к ней слишком много обращений и надо любыми средствами ограничить количество количество запросов к базе
если для вас все равно — миллисекунду или микросекунду выполняется запрос — то я вам ничего не могу ответить
используйте встроенные средства MySQL, если они вас устраивают и отвечают вашим тербованиям
а насчет масштабируемости немного непонятно, что вас не устраивает, поподробнее пожалуйста
спасибо за разъяснение, я вас не правильно понял насчет фронтенд/бекенд, в таком случае, прошу прощения
когда вы говорите о сторогом разделении бизнес логики от отображения, то имеете ввиду MVC, или что-то другое? если дизайн вынесен в Smarty, этого не достаточно? если я сильно туплю, то можно ссылку на соответсвующую статью, чтобы до меня наконец дошло
обычно данные подготавливаются и передаются в Smarty шаблон, который это дело отображает, к тому же есть модификаторы и функции в Smarty для специфических случаев
сайт в конкретном случае работает на одном сервере, а база данных расположена на другом.
Помещая данные мемкешед мы экономим время на сетевых издержках, а так же на времени, которое MySQL тратит на разбор запросов.
Что такое «очень быстро» в вашем понятии? можно конкретные цифры
"«Чем чаще данные меняются, тем менее эффективен кеш.» — это полнейшая глупость" —
при изменении данных рано или поздно происходит сброс кеша, что снижает его эффективность —
это прописная истина
а об остальном уже говорилось.
«обновление кеша происходит при обращении фронтенда к бэкенду, а это в корне не правильный подход, который сниджает эфективность кеширования на 10-80%» — если вы имеете в виду расположение memcached, то это никак не зависит от метода, который был описан
memcached вы можете расположить где угодно. Лучше, конечно, на фронтенде, как вы и написали
«Если уж беретесь кешировать данные, то будьте добры — обеспечьте обновление данных где-то в фоне.» — обновление данных происходит по мере выполнения запросов, наверное вас ввел в заблуждение комментарий пользователя Unechka
Насчет «второго», так весь смысл в том чтобы уйти от базы данных и перейти к memcached, который на порядок быстрее MySQL за счет своей простоты и расположения целиком в памяти
в статье не было сказано о том чтобы ложить записи всей таблицы в память
если закешированы некоторые запросы, то они будут считаться неактуальными сразу же, как только одна из учавствующих в запросах таблиц будет изменена, при этом никаких выгрузок таблиц и глобальных чтений не происходит.
Одной записи в кеш достаточно, чтобы пометить таблицу как измененную, а все связанные с ней результаты запросов как устаревшие
такой метод — супер, горазде эффективнее, чем просто кеширование запросов.
Smarty поддерживает такой подход, надо будет дойти до использования этой возможности www.smarty.net/manual/ru/caching.php
не вижу смысла отвечать вам на этом комментарий
если вы прочтете материал более менее внимательно и напишите грамотный и корректный комментарий, то с удовольствием продолжу нашу дискуссию
такой метод — супер, горазде эффективнее, чем просто кеширование запросов.
Smarty поддерживает такой подход, надо будет дойти до использования этой возможности www.smarty.net/manual/ru/caching.php
не знал о таких особенностях memcachedb.
Была потребность в аналоге Memcache, но с возможностью долговременно хранить записи — думаю Memcachedb здесь подходит идеально.
Как вы используйте Memcachedb и если можно с конкретными примерами, а еще лучше обсудить этот вопрос в вашем топике
если можно, объясните, что вы имеете ввиду — видимо я не вижу какие-то очевидные проблемы
фактически вы говорите что в ваших проектах вам кеш не нужен
для битторрентов для повышения производительности пишется клиент, который держит сотни тысяч коннектов на обычном сервере, но это же не повод говорить всем что следует писать такие клиенты для каждого проекта
если для вас все равно — миллисекунду или микросекунду выполняется запрос — то я вам ничего не могу ответить
используйте встроенные средства MySQL, если они вас устраивают и отвечают вашим тербованиям
а насчет масштабируемости немного непонятно, что вас не устраивает, поподробнее пожалуйста
когда вы говорите о сторогом разделении бизнес логики от отображения, то имеете ввиду MVC, или что-то другое? если дизайн вынесен в Smarty, этого не достаточно? если я сильно туплю, то можно ссылку на соответсвующую статью, чтобы до меня наконец дошло
обычно данные подготавливаются и передаются в Smarty шаблон, который это дело отображает, к тому же есть модификаторы и функции в Smarty для специфических случаев
сайт в конкретном случае работает на одном сервере, а база данных расположена на другом.
Помещая данные мемкешед мы экономим время на сетевых издержках, а так же на времени, которое MySQL тратит на разбор запросов.
Что такое «очень быстро» в вашем понятии? можно конкретные цифры
при изменении данных рано или поздно происходит сброс кеша, что снижает его эффективность —
это прописная истина
а об остальном уже говорилось.
memcached вы можете расположить где угодно. Лучше, конечно, на фронтенде, как вы и написали
«Если уж беретесь кешировать данные, то будьте добры — обеспечьте обновление данных где-то в фоне.» — обновление данных происходит по мере выполнения запросов, наверное вас ввел в заблуждение комментарий пользователя Unechka
Насчет «второго», так весь смысл в том чтобы уйти от базы данных и перейти к memcached, который на порядок быстрее MySQL за счет своей простоты и расположения целиком в памяти
если закешированы некоторые запросы, то они будут считаться неактуальными сразу же, как только одна из учавствующих в запросах таблиц будет изменена, при этом никаких выгрузок таблиц и глобальных чтений не происходит.
Одной записи в кеш достаточно, чтобы пометить таблицу как измененную, а все связанные с ней результаты запросов как устаревшие
Smarty поддерживает такой подход, надо будет дойти до использования этой возможности www.smarty.net/manual/ru/caching.php
если вы прочтете материал более менее внимательно и напишите грамотный и корректный комментарий, то с удовольствием продолжу нашу дискуссию
Smarty поддерживает такой подход, надо будет дойти до использования этой возможности www.smarty.net/manual/ru/caching.php
Была потребность в аналоге Memcache, но с возможностью долговременно хранить записи — думаю Memcachedb здесь подходит идеально.
Как вы используйте Memcachedb и если можно с конкретными примерами, а еще лучше обсудить этот вопрос в вашем топике