Как использовать Zend_Cache Identifier?

Question

я думаю, что я схожу с ума, я пытаюсь реализовать Zend_Cache для кэширования моего запроса к базе данных. Я знаю, как это работает и как настроить.

Но я не могу найти хороший способ установить идентификатор для записей кэша. У меня есть метод для поиска записей в моей базе данных (на основе массива с поисковыми значениями).

/**
 * Find Record(s)
 * Returns one record, or array with objects
 *
 * @param array   $search Search columns => value
 * @param integer $limit  Limit results
 * @return array One record , or array with objects
 */
public function find(array $search, $limit = null)
{
    $identifier = 'NoIdea';

    if (!($data = $this->_cache->load($identifier))) {
        // fetch
        // save to cache with $identifier..
    }

Но какой идентификатор можно использовать в этой ситуации?

Answer 1

Идентификатор должен быть уникальной строкой для представления записи в кэше.

Возможно, вы захотите назвать их на основе таблиц и полей базы данных, например, db_tablename_primarykey_1

Если у вас есть метод с несколькими аргументами, будет сложно создать строку, содержащую их все. В качестве альтернативы вы можете объединить аргументы функции и db_tablename для создания строки для хеширования. Например:

$identifier = md5('db_tablename_find' . serialize(func_get_args()));

Answer 2

У меня такая же проблема. Я не знаю, нашли ли вы решение, но у меня есть временное решение (потому что оно не очень эффективно):

1. Создайте каталог кеша для каждой таблицы, к которой вы собираетесь обращаться, и кешируйте результаты.

2. Всякий раз, когда вы запрашиваете эту таблицу, сохраняйте результат, используя уникальный идентификатор. Вот проблема с моим решением. Вы не можете использовать запрос в качестве идентификатора, поскольку он может быть слишком длинным, и некоторые операционные системы могут отклонить его. Поэтому я решил сохранить все запросы в другом файле вместе с автоматически увеличивающимся идентификатором, например так:

   0->>SELECT * FROM table
   1->>SELECT * FROM table WHERE foo = bar
   

Вы поняли идею. Поэтому перед выполнением запроса проверьте этот файл, чтобы увидеть, существует ли текущий запрос, если он есть, получить идентификатор и загрузить с использованием этого идентификатора. Вы можете сохранить этот файл в той же директории кэша.

3. Всякий раз, когда вы обновляете, вставляете или удаляете данные в этой таблице, просто очищайте кэшированные записи следующим образом: $ cache-> clean ('all'). Вам не нужно удалять файл идентификатора, так как будут выполняться те же запросы. И если вам интересно, он будет очищать только файлы кэша в этом каталоге, следовательно, нужен каталог для каждой таблицы.

хорошо. Вам даже не нужно устанавливать время жизни (они могут существовать вечно) или автоочистку для вашего кэша, поскольку вы очищаете его каждый раз, когда запускаете обновление, вставку или удаление.

Уродливый. Любой тест, загрузка или сохранение будут выполнять два (или три, когда нам нужно сохранить новый идентификатор для нового запроса) запросов к файловой системе.

Я использовал это, и он отлично работает, используя Zend_Cache_Core и Zend_Cache_Backend_File. Я не использую полную платформу, но я использую модуль Zend_Cache, поэтому, если вы используете всю платформу, вам может понадобиться создать класс абстрактной модели, который будет создавать каталоги, файлы идентификаторов и кэшировать для ваших дочерних классов модели. (который затем расширит его).

Я видел здесь, что использование md5 может быть решением для создания файла идентификатора для каждой таблицы. Я попробую и вернусь к вам. Я не знаю, как это будет работать с Apc.

Answer 3

Возможно, вы захотите использовать Внешний интерфейс функции для Zend Cache, где вы можете сделать что-то вроде этого:

$cache->call('veryExpensiveFunc', $params);

и ключ будет создан автоматически (хотя может быть и длинным). Вы можете использовать интерфейс класса, который позволит вам прозрачно кэшировать все методы класса.

Answer 4

Что происходит, когда ваши базовые данные изменяются? Ну, все применимые записи кэша должны быть удалены. Вот такая баночка червей!

Как насчет выгрузки этого кэширования данных в вашу СУБД?

Например, MySQL Query Cache обрабатывает это для вас, аннулируя устаревшие записи кэша соответствующим образом.