Цитата:
Цитата:
|
Эээээ...
Не думал, что когда нибудь такое скажу... НО мне даже очень понравилось кэширвоание на основе БД....:):):) Как ни будь расскажу почему (единственный минус конечно когда на хостингах жмешь кнопку рез. копии, то база вся дампится)... |
Даже smarty - кэш переведу на БД (с такой возможностью)...
|
Вы лучше напишите "почему". Обещали :)
От себя приведу такой пример. На одном сайте в таблице RealURL encode cache больше миллиона записей, в decode cache раза в два меньше. По статистике запросы на выборку из этой таблицы по Primary Key регулярно пишуться в лог относительно медленных запросов (наряду с выборками из tt_news), для этого в t3lib_db добавлен небольшой код. Любая операция со страницей в BE (иногда приходится делать на рабочем сайте) ведет к операции DELETE FROM ... WHERE pid = xx Если делать таблицу MyISAM, то под нагрузкой такая операция практически вешает сервер на 3-7 минут. Если делать InnoDB (как того рекомендует автор Дмитрий Дулепов) то якобы операция удаления не должна блокировать таблицу и все должно продолжать работать. На практике серверу еще хуже. Так как пока очень долго идет операция удаления (десятки минут), то все другие операции с таблицей очень сильно замедляются и LA сервера растет и растет. Даже если вручную снять этот висящий запрос на удаление, то еще пару десятков минут продолжает висеть в списке процессов MySQL некая операция "freeing items" и тоже все тормозит. Так что пока вы кешируете в таблицы что-то небольшое и немного - это удобно. Но в реальной жизни на крупных сайтах все не так радужно. Мне нравиться Redis - с одной стороны использует память как и memcached, с другой данные уже не влезающие в память пишутся на диск, а не просто удаляются. Конечно в Redis и в memcached единственная проблема которая не так красиво решается как в СУБД - это тэгирование записей кэша. Ну я тут не стал выдумывать очередной велосипед и храню пары ключ-тэг в MySQL.MEMORY таблице. Когда-то видел сравнение скорости работы memcached vs MEMORY таблиц, получилось примерно одинаково. |
Цитата:
К примеру у нас есть новости на сайте: Они выводятся в новостях (список новостей с потраничной навигации) сама новость новость в карте сайта блок последних новостей на главной странице блок новости в слайдере на всех страницах... кроме того, может быть в sitemap... Мы можем по определенным тэгам сбросить все это при изменении/добавлении новости - и нет необходимости сбрасывать кэш всего сайта - но это очень актуально на больших и посещяемых проектах... Хотя все таки думаю - что даже это все дело потянет хороший хостинг... Подобную матрешку - пробовал реализовать на файлах... Но, к сожалению, очень не гибко в сравнении с Файлами. 2) С точки зрения записи файлов на кэшах - не знаю почему - но мне показалось что это работает по скорость также как и на БД, а вот с позции манипуляций кэшем на файлах - как-то дольше - в т.ч. удаление.:rolleyes: А с точки зрения минусов - есть один минус, который по прежнему к сожалению вижу... Таблицы кэширования лучше всего переводить в отдельную БД... Т.е. специально для кэшей держать отдельную БД... А то при бэкапах хостинга обычно он бэкапит все в одну кучу... А так было бы 1. Дамп Контента 2. Дамп Кэша (только структура) 3. FTP |
Так вы не внимательно читаете, что я предлагаю выше.
Да, работать с тэгами в БД удобней всего. В файловом кэше их попросту не сделать. В memcached и т.п. вариациях тоже нет встроенных средств для работы с тэгами, надо все равно делать свою логику. Но! Писать BLOB данные в MySQL в большом количестве - это самый плохой вариант использования БД. Никаких преимуществ, одни недостатки. Поэтому, ИМХО, самый лучший вариант - хранить сами данные по ключу в файлах, memcached, redis (кому что нравиться и на что хватает ОЗУ). А вот связь тэги-ключ хранить в БД. Так как именно для этого реляционные БД предназначены - SELECT key FROM key_tags WHERE tag = "abc" и т.п. Плюс табличка key_tags компактна, длинна строк у нее фиксированная и можно заранее просчитать ее максимальный размер. Что позволяет делать ее типа MEMORY. А значит по скорости она будет близка к скорости memcached. Конечно это чуть более сложная логика в PHP. Но все равно проще варианта, когда организуют хранение тэгов в memcached (http://dklab.ru/lib/Dklab_Cache/, http://www.smira.ru/posts/20081029we...mcached-5.html) |
Цитата:
Здесь нужно "собирать опыт" :) Только одно - memcached - для меня не удобно... |
Может кому-нибудь пригодится...
Попробовал перевести кэширование на memcache PHP код:
Теперь таблицы cf_cache_hash 0 cf_cache_hash_tags 0 cf_cache_pages 0 cf_cache_pages_tags 0 cf_cache_pagesection 0 cf_cache_pagesection_tags 0 cf_extbase_object 0 cf_extbase_object_tags 0 cf_extbase_reflection 0 cf_extbase_reflection_tags пустые... что очень хорошо. Все так когда кэш пишется в БД - прихожу к выводу что это ни с какой стороны не удобно! По идее БД должна быть для данных, а не для мусора. - И потом думаю это показатель мобильности проекта... Кроме того, если мы используем для кэширования memcache (а не БД, и не файлы) - у нас получается "чистый проект" - который не захламляется всяким временным мусором - в качестве исключения конечно можно оставить вопрос с папкой typo3temp - но это очень легко исключается при бэкапе в настройках хостинга (мы исключаем ее из резервного копирования, ровно как и папки t3lib, typo3). -- Единственное конечно что еще хотелось бы также что бы было это таблицы cache_extensions cache_imagesizes и таблицы realurl. Если так будет - то на любом проекте можно совершенно спокойно делать копию БД - проекта без всяких извращений и приступать к правкам. Не знаю кто как делает - но для меня проще сделать дамп бд - 5-10 мб с чистыми данными, чем делать бэкап базы lданных со всем что там есть (1Gb+) или еще каким-то путями вырезать таблицы с помощью сторонних решений. А так зашел в админер и все.. И потом memcache - работает на Facebook... Насколько я понял по статьям из интернета. И уверен, что тема тэгизации там есть - сейчас ищу и изучаю... http://ekimoff.ru/329/ Ведь по идее в проекте самое главное это данные (сами записи - новость 1, новость 2) - и исходники, которые эти данные выводят во FE. И все. А все что временное - это временное. Кэширование как вижу - это лишь способ а) увеличить скорость загрузки FE б) уменьшить/снизить нагрузки на сервер (на любой). И потом еще интересным является вопрос о том, что вот зашли 10-человек на сайт - и первый запустил процесс записи кэша, а остальные - им либо ждать пока запишется кэш, либо как? |
Тоже пока используем memcached. Тэгизации там точно нет. Делали как-то отдельные патчи и форки сторонние разработчики, но до сих пор в основную ветку тэги не попали. А потом все переключили внимание на NoSQL, и memcached стабильной, но неразвивающейся технологией (v1.4.15, release notes 2012-9-3).
Если верить http://wiki.typo3.org/Caching_framework, то предпочтительно использовать Redis. Который во многом схож с memcached, но не удаляет данные из ОЗУ при ее нехватке, а пишет на диск. http://wiki.typo3.org/Caching_framew...mcachedBackend Цитата:
Цитата:
|
Цитата:
Про тэгизацию все таки поищу... Думаю что есть алгоритмы - за столько лет существования этого memcache.:) |
Часовой пояс GMT +4, время: 13:42. |
Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot