-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Кэширование запросов
- Автор темы riki-tik
- Дата начала
- Статус
Правильно сказал Breaze, кешировать нужно результат, и то в случае, если уперся в производительность СУБД.
Обратился к нам хороший человек, мол помогите, уволили директора IT а на сайте какая-то херня, какие-то новости на языке незалежной.... В общем, ковырялся у нас сотрудник с говнокодом с комментами типа "азазаза, бля, опасно". Контент удаляем с админки, а он как был так и осталось. Выяснилось что это млять кеширование SQL запросов. Идиоты.
Причем хранят они в виде md5 сумм SQL запроса. Идиоты. Как они его будут удалять из кеша я ХЗ.
Причем нужно понимать что СУБД работает с ОЗУ, и зачастую таблицы лежат полностью в памяти, и проще сделать SQL запрос, а не обращаться к ФС, зачастую файловая система является самым узким местом на сервере.
CoolKid
Новичок
А мы тут что по-твоему обсуждаем? Как хранить сам текст запроса?)
А это вот ты к чему написал? Пример как можно реализовать кеширование через жопу? ОК, принимается в копилку говнокода.
Но если человек не предусмотрел методы удаления данных их кеша, если он кеширует все подряд - это не недостаток инструмента как такового, это неумение этим самым инструментом пользоваться.
Вот у меня под рукой таблица news, в ней 543780 строк на текущий момент. Она прям вся в памяти?
CoolKid,
Как в предоженном вами коде
Будете удалять кеш при необходимости?
Как в предоженном вами коде
PHP:
<?php
Cache::init('filesystem');$sql = "SELECT * FROM users";
if (!Cache::hasKey(md5($sql))) {$data = DB::query($sql)->fetchAssoc();Cache::set(md5($sql), $data, 600)); // последний параметр это ttl - время жизни кеша} else {$data = Cache::get(md5($sql));
}var_dump($data);
Последнее редактирование:
Как сказал я, первый мой пост в треде. И разговора о кешировании чего-то там не было, был вопрос кешировать результат. Надеюсь это автор понимает.
CoolKid
Новичок
1. У кеша есть время жизни, которое передается 3-м параметром, если не передано, используется дефолтное значение например 10 минут
2. При изменении модели делаем Cache::flush() или «блять, Cache::delete('a4fc5c1e8c543e92a123211bce782272')» если хотим удалить что-то конкретное.
Плюс хочу напомнить что я сам не кеширую результаты SQL ни этим ни каким-либо другим способом на стороне PHP. Я либо настраиваю сервер БД правильно, либо кеширую контент-блоки.
riki-tik
Новичок
Ох, не ожидал что на мой пост у вас будет такая реакция. Я вообще за мир, а тут люди ссорятся друг с другом. Поэтому немного поясню ситуацию.
Во-первых как я уже говорил я не все запросы будут кэшироваться, лишь те, к которым будет добавлен параметр true при вызове запроса. Например у сайта есть таблица с опциями и при вызове функции get_option('name') происходит запрос 'SELECT value FROM options WHERE name = "name"'. Логично что такой запрос может повторяться, и было бы правильно его закэшировать. Но это просто пример, а то вы снова начнете возражать мол такие запросы сохраняются в памяти и время их выполнение быстрое. А механизм кэширования результатов я уже реализовал ранее, он работает следующим образом Cache::get('key'); Cache:
ut('key'); Cache::forget('key'), результаты хранятся в файлах, но тут нужно четко знать какое время он должен храниться, для запросов же я хотел сделать этот процесс автоматическим и хранить минимальное время.
Во-вторых эти данные не будут храниться долгое время, я реализую чтобы это просто было быстрым запросом. Очищаться кэш будет сам.
В-третьих, мне просто было интересно узнать как лучше хранить запросы. Я вначале хранил их в массиве $GLOBALS где ключом был сам запрос, и очень сомневался что можно так делать, тем более что в запросе присутствую пробелы, о md5 даже не задумывался.
Спасибо всем за помощь!
Во-первых как я уже говорил я не все запросы будут кэшироваться, лишь те, к которым будет добавлен параметр true при вызове запроса. Например у сайта есть таблица с опциями и при вызове функции get_option('name') происходит запрос 'SELECT value FROM options WHERE name = "name"'. Логично что такой запрос может повторяться, и было бы правильно его закэшировать. Но это просто пример, а то вы снова начнете возражать мол такие запросы сохраняются в памяти и время их выполнение быстрое. А механизм кэширования результатов я уже реализовал ранее, он работает следующим образом Cache::get('key'); Cache:
ut('key'); Cache::forget('key'), результаты хранятся в файлах, но тут нужно четко знать какое время он должен храниться, для запросов же я хотел сделать этот процесс автоматическим и хранить минимальное время.Во-вторых эти данные не будут храниться долгое время, я реализую чтобы это просто было быстрым запросом. Очищаться кэш будет сам.
В-третьих, мне просто было интересно узнать как лучше хранить запросы. Я вначале хранил их в массиве $GLOBALS где ключом был сам запрос, и очень сомневался что можно так делать, тем более что в запросе присутствую пробелы, о md5 даже не задумывался.
Спасибо всем за помощь!
riki-tik, не пробывал писать ООП стиле с использованием Модель-Вид-Контролер (MVC) ?
На примере настроек сайта
class Setting_model
{
private $settings = array();
public function __construct()
{
// считываем все из базы
// в цикле по всем результатам
{
$this->settings[$row['key']] = $row['value'];
}
}
public function getSetting($key)
{
// проверки и обработки существования
return $this->settings[$key];
}
public function setSetting($key,$value)
{
// запрос на сохранение в базу
}
}
И вот тебе альтернатива кеширование запросов вида select value from ... where key='значение'
если настроек много а нужно всего несколько , то конструктор ничего не считывает а метод принимает вид
public function getSetting($key)
{
if(!isset($this->settings[$key])){
$this->settings[$key] = присвоить результат выборки значения из базы по ключу
}
return $this->settings[$key];
}
и нет режущего глаз GLOBALS
На примере настроек сайта
class Setting_model
{
private $settings = array();
public function __construct()
{
// считываем все из базы
// в цикле по всем результатам
{
$this->settings[$row['key']] = $row['value'];
}
}
public function getSetting($key)
{
// проверки и обработки существования
return $this->settings[$key];
}
public function setSetting($key,$value)
{
// запрос на сохранение в базу
}
}
И вот тебе альтернатива кеширование запросов вида select value from ... where key='значение'
если настроек много а нужно всего несколько , то конструктор ничего не считывает а метод принимает вид
public function getSetting($key)
{
if(!isset($this->settings[$key])){
$this->settings[$key] = присвоить результат выборки значения из базы по ключу
}
return $this->settings[$key];
}
и нет режущего глаз GLOBALS
CoolKid, твое решение сказали по каким критериям не совсем правильное. В частности - неудобство удаления ключей. Количество сообщений тут не при чем.
Я уже описал почему md5() или любой хэш от самого запроса будет геморроем. Автор, надеюсь, перечитает тред и сделает как-то более или менее нормально, раз уж он так уперся в кеширование =)
Я уже описал почему md5() или любой хэш от самого запроса будет геморроем. Автор, надеюсь, перечитает тред и сделает как-то более или менее нормально, раз уж он так уперся в кеширование =)
- Статус