Первичный кэш в Kohana 3 с использованием тегов

[dohlik]

Эмм… Скажите, а почему не расширить стандартный Cache_File до Cache_Filetag по аналогии с Cache_Memcachetag? Изменений будет немного, заново придумывать (или выдергивать из стандартного Cache_File) основные методы не надо. Если уж на то пошло, файловый кэш с тэгами существовал в версии 2.3.4, так что выдернуть оттуда его несложно.

[dohlik]

Еще дополню.

1. Зря Вы храните все файлы кэша в одной директории. В оригинальном модуле кэш сохраняется в поддиректории, имена которых берутся их хэша имени файла (т.е. что-то типа cache/ab/cd/abcdef.txt).
2. Ну и поиск по тэгам у Вас неуклюжий получается. Надо считать строку из файла. Опять же, в 2.3.4 тэги хранятся прямо в имени файла, что облегчает их поиск (там через glob() все сделано).

[AndreDerMorgenstern]

Сказать честно, я пользуюсь Kohana с версии 3.0, поэтому файловый кэш с тегами не застал. Нужно будет изучить эту реализацию. Остальные замечания всенепременнейше учту в JetCache 2.0 )

[dohlik]

Гм… Если Вы начнете с моего первого замечания, то JetCache v2 просто не будет :) Напишите Cache_Filetag и предложите его сообществу. Это и будет Kohana way.

[AndreDerMorgenstern]

Ну или так )

Правда, у них уже есть готовое решение. Интересно, почему оно не вошло в 3 версию.

[dohlik]

Вероятно из-за тормознутости файлового кэша. Хотите более удобной и быстрой работы кэша — используйте, к примеру. Memcache/Memcachetag

[AndreDerMorgenstern]

Может быть. Но в условиях сайтов с невысокой посещаемостью, размещенных на стандартных хостингах, такие варианты не применимы из-за отсутствия Memcache и других замечательных вещей. Остаются только файлы.

[WebSpider]

А ещё есть sqlite-кеш. Он тоже поддерживает теги

[AndreDerMorgenstern]

Как было сказано в постановке задачи, в данном случае подходят только файлы )

К тому же, я придерживаюсь мнения, что если есть возможность использовать использовать софт из дополнительного набора, лучше использовать Memcache или Xcache. Например, в документации скорость работы Sqlite оценена как «Poor» — так же, как и у файлового кэша: kohanaframework.org/3.1/guide/cache#choosing-a-cache-provider

[dohlik]

Дык poor в случае с файлами — это еще без тэгов :) С тэгами он может стать ugly

[AndreDerMorgenstern]

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

[AndreDerMorgenstern]

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

[WebSpider]

А sqlite — это не файл? Или на хостинге нет поддержки PDO?

[AndreDerMorgenstern]

Это верно. Но вопрос в том, стоит ли использовать Sqlite для кэширования данных, извлеченных из MySQL? Особенно если можно использовать более быстрые методы.

[Lond]

Делал похожий механизм для ZF, сейчас переношу его на проект, написанный на Kohana 3.1, но с небольшими дополнениями — есть такая задумка определять теги автоматически, разобрав sql-запрос и выбрав из него все используемые таблицы, используя их как теги при модификации (для сброса) и выборке (для сохранения). Решение довольно деревянное, но для сайтов с не слишком хитрой структурой кэша подойдет прекрасно.

[AndreDerMorgenstern]

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

[egorinsk]

Ох, господи, вот люди верхов нахватаются и полезут «кеширование» делать, еще и на файлах (а, еще есть оригиналы из Друпала, они вообще где-то в базе данные кешируют). Объясните, какой смысл тормозным скриптом лазать по иерархической файловой системе, открывать каждый файл и перечитывать теги (это же быдлокод), когда можно просто добавить ключики, вроде filebank_files_update_time и что там у вас еще есть, и при чтении из кеша проверять дату обновления этих ключей, если запись в кеше зависит от них, и она старше — знаичт, она устарела.

У вас когда будут тысячи файлов в этом недокеше, вы тоже каждый открывать будете?

[AndreDerMorgenstern]

Почти на все вопросы ответ содержится в постановке задачи )

На файлах потому, что нет другого выхода — ограничения хостинга. Записывать все данные в имена файлов было бы можно, но для конкретной задачи, как мне кажется, не обязательно. К тому же, скорость чтения файла будет выше, если обратиться к нему по полному имени, а не по маске.

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

Таким образом, СУБД разгружена, у клиентов скорость чтения увеличена. А администратор может потерпеть ) Тысяч файлов, опять же, не будет из-за относительно небольшого объема информации.

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

[egorinsk]

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

[dohlik]

Об этом я и писал выше. В оригинальной библиотеке Cache v2.3.4 имена файлов были вида id~tag1+tag2+tag3~lifetime, и для обработки тэгов и lifetime достаточно обработать имя файле, не заглядывая внутрь.

[AndreDerMorgenstern]

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

[dohlik]

Почему это для администраторов? По идее, тэги должны использоваться самой системой для своевременного удаления кэша при наступлении соответствующего события. Например, добавилась статья в категорию N — и кэш с тэгом categoryN должен быть очищен. Не администратор же вручную должен этим управлять.

[AndreDerMorgenstern]

Так здесь статьи добавляются только администратором ) Такое решение было выбрано с учетом этой особенности, я это указывал.

[dohlik]

Комментарии, фотографии и т.д.

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

[AndreDerMorgenstern]

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

[kamazee]

А Вы читали о стиле оформления кода и соглашениях об именовании в Kohana?

[AndreDerMorgenstern]

Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.

Многие вещи в соглашении Коханы расходятся с моими моральными принципами. Например, для того, чтобы написать так:

// Correct:
$db = new Database; 

мне нужно фактически переступить через себя ) Я привык писать «неправильно»:

// Incorrect:
$db = new Database();

Все-таки, в случае, если код не будет включаться в какой-то общий проект, тонкости оформления кода, такие как, где ставить скобки или пробелы — это вопрос вкуса. К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.

[dohlik]

Ну Вы хотя бы соблюдайте один и тот же стиль :) А то protected-методы с подчеркивания начинаются, а свойства — нет. То у Вас CamelCase-методы, то опять с подчеркиваниями. Как будто писали разные люди.

[AndreDerMorgenstern]

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

Методы бывают как публичные, так и защищенные, поэтому защищенные я выделяю подчеркиванием в начале, чтобы при чтении кода было понятно, что вызывается защищенный метод, вызов которого извне не предусмотрен.

В основном я использую CamelCase. Здесь через подчеркивание назвал аналоги методов из класса Cache_File.

[kamazee]

Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.

Тут нужно или трусы надеть, или крестик снять.
Если 'в Kohana' — то можно было расширить (или заново реализовать), файловый кеш который уже существует, прикрутив к нему теги (как справедливо предложил dohlik), до кучи переступив через себя и приведя код в соответствие с принятыми в сообществе стандартами.
Если нет — слово Kohana скорее лишнее. Тем более, что в предлагаемом классе используется разве что конфиг, который из зависимостей при большом желании выпиливается ну просто на раз-два.
Небольшая ремарка. Сами кохановцы делают зависимость от конфига ещё более слабой, обратите внимание. Обращение к классу Config (или прокси Kohana::config) используется в основном только во вспомогательных статических методах, которые передают уже полученный конфиг в виде массива в конструктор.

К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.

Не настроенное под конкретную ситуацию автоформатирование.
Не надо сваливать на настройки IDE, поставляемые с ней по умолчанию.

[AndreDerMorgenstern]

Я не ищу оправданий в стандартном стиле IDE, я привел его как пример зависимости тонкостей стиля написания кода от вкусов человека, пишущего код.

Наверно, конечно, вы правы в том, что при публикации материалов о фреймворке приведение кода к его стандартам является плюсом. Но разве при разработке под каждый фреймворк обязательно нужно соблюдать индивидуальный стиль кода его дистрибутива? Например, у Zend framework'а другие стандарты, а переключаться в голове между разными стилями не так просто )