Как использовать идентификатор Zend_Cache?

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

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

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

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

Answer 3

Вы можете рассмотреть возможность использования Function frontend для Zend Cache, где вы можете сделать что-то вроде этого:

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

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

Answer 4

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

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

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

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

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

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

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

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

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

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