Всетаки - кэширование с использованием БД - это очень не удобно!

dmartynenko · 02.07.2013, 13:11

Вы лучше напишите "почему". Обещали

От себя приведу такой пример. На одном сайте в таблице 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 таблиц, получилось примерно одинаково.

Ивано++ · 02.09.2013, 20:29

Цитата:

Сообщение от dmartynenko

Вы лучше напишите "почему". Обещали

1) С точки зрения управления кэшированием на основе БД - можно сделать более сложную логику - в виде "матрешки". Где кроме того, можно еще и по определенным тэгам удалять отдельные кэши.

К примеру у нас есть новости на сайте:

Они выводятся в

новостях (список новостей с потраничной навигации)
сама новость
новость в карте сайта
блок последних новостей на главной странице
блок новости в слайдере на всех страницах...
кроме того, может быть в sitemap...

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

Хотя все таки думаю - что даже это все дело потянет хороший хостинг...

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

2) С точки зрения записи файлов на кэшах - не знаю почему - но мне показалось что это работает по скорость также как и на БД, а вот с позции манипуляций кэшем на файлах - как-то дольше - в т.ч. удаление.

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

А то при бэкапах хостинга обычно он бэкапит все в одну кучу...
А так было бы

1. Дамп Контента
2. Дамп Кэша (только структура)
3. FTP

dmartynenko · 03.09.2013, 13:58

Так вы не внимательно читаете, что я предлагаю выше.

Да, работать с тэгами в БД удобней всего.

В файловом кэше их попросту не сделать. В 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)

Ивано++ · 03.09.2013, 18:08

Цитата:

Сообщение от dmartynenko

Так вы не внимательно читаете, что я предлагаю выше.

Да, работать с тэгами в БД удобней всего.

В файловом кэше их попросту не сделать. В 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 - для меня не удобно...

Ивано++ · 26.09.2013, 18:28

Может кому-нибудь пригодится...

Попробовал перевести кэширование на memcache

PHP код:


			

$TYPO3_CONF_VARS['SYS']['useCachingFramework'] = '1';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['options'] = array(
     'servers' => array('localhost:11211'),
     );
     
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['options'] = array(
     'servers' => array('localhost:11211'),
     );
     
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['options'] = array(
     'servers' => array('localhost:11211'),
     );
    
        /*
        
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
    
        */

Теперь таблицы
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-человек на сайт - и первый запустил процесс записи кэша, а остальные - им либо ждать пока запишется кэш, либо как?

dmartynenko · 26.09.2013, 18:41

Тоже пока используем 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

Цитата:

Warning and design constraints

Memcached is by design a simple key-value store. Values must be strings and there is no relation between keys. Since the caching framework needs to structure it to store the identifier-data-tags relations, for each cache entry it stores an identifier->data, identifier->tags and a tag->identifiers entry.

This leads to structural problems:
If memcache runs out of memory but must store new entries, it will toss *some* other entry out of the cache (this is called an eviction in memcached speak).
If data is shared over multiple memcache servers and some server fails, key/value pairs on this system will just vanish from cache.

http://wiki.typo3.org/Caching_framew...d_RedisBackend

Цитата:

t3lib_cache_backend_RedisBackend

Redis is a key-value storage/database. In contrast to memcached, it allows structured values. Data is stored in RAM but it allows persistence to disk and doesn't suffer from the design problems which exist with the memcached backend implementation. The redis backend can be used as an alternative of the database backend for big cache tables and helps to reduce load on database servers this way. The implementation can handle millions of cache entries each with hundreds of tags if the underlying server has enough memory.

Но сами редиску не пробовали, по привычке везде memcached.

Ивано++ · 26.09.2013, 18:45

Цитата:

Сообщение от dmartynenko

Тоже пока используем memcached. Тэгизации там точно нет.

Тоже решил остановиться на memcache.

Про тэгизацию все таки поищу...
Думаю что есть алгоритмы - за столько лет существования этого memcache.

dmartynenko · 26.09.2013, 18:53

Цитата:

Сообщение от Ивано++

Если так будет - то на любом проекте можно совершенно спокойно делать копию БД - проекта без всяких извращений и приступать к правкам.[/color][/b]

Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.

Таблицы realurl вряд ли можно вынести в memcached. Во первых в memcached не структурированные данные, и возможно realurl по разным полям поиск делает. Во вторых, у нас на одном проекте до 2 гигов таблицы realurl занимают. Сильно жирно столько памяти на один realurl выделять

Ивано++ · 26.09.2013, 19:07

Цитата:

Сообщение от dmartynenko

Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.

Есть такое расширение "truncate_tables" - суть его в том, что там где сброс кэшей - появляется новая молния. При нажатии на нее очищается список указанных таблиц. Я немного модифицировал его в одном из расшриений - и он у меня чистит все таблицы, которые содержат *cache*, А также sys_log и другие которые содержат временные данные.

Можно сделать "еще одну молнию на основе этого SSH->PHP скрипта" - при нажатии на нее будет создаваться бэк ап БД сайта и ложится в папку fileadmin/__temp__/ - но пока не знаю на сколько это нужно? Либо еще круче - нажал на кнопку и получил бэкап БД. Просто я обычно делаю дамп БД через Админер - после нажатия на синию молнию (ну восстановятся кэши потом - не 100 раз же на дню я ее нажимаю синуюю молнию) - получаю чистую БД без кэшей...

--
Просто все таки стремлюсь сделать саму БД - чистой.
Вот как таблица excel - мы же пишем там только нужные данные, а весь старый мусор бросаем в корзину...

26.09.2013, 18:28	#5
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	Может кому-нибудь пригодится... Попробовал перевести кэширование на memcache PHP код: $TYPO3_CONF_VARS['SYS']['useCachingFramework'] = '1'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = 't3lib_cache_backend_MemcachedBackend'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['options'] = array( 'servers' => array('localhost:11211'), ); $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = 't3lib_cache_backend_MemcachedBackend'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['options'] = array( 'servers' => array('localhost:11211'), ); $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = 't3lib_cache_backend_MemcachedBackend'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['options'] = array( 'servers' => array('localhost:11211'), ); /* $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['frontend'] = 't3lib_cache_frontend_VariableFrontend'; $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend'; / Теперь таблицы 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-человек на сайт - и первый запустил процесс записи кэша, а остальные - им либо ждать пока запишется кэш, либо как? Последний раз редактировалось Ивано++; 26.09.2013 в 18:41*

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
Cлишком сложно показалось?	carlos	Вопросы выбора CMS	5	04.07.2007 16:37

02.07.2013, 13:11	#1
dmartynenko Senior Member Регистрация: 20.07.2007 Адрес: Беларусь, Минск Сообщений: 957	Вы лучше напишите "почему". Обещали От себя приведу такой пример. На одном сайте в таблице 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 таблиц, получилось примерно одинаково.

03.09.2013, 13:58	#3
dmartynenko Senior Member Регистрация: 20.07.2007 Адрес: Беларусь, Минск Сообщений: 957	Так вы не внимательно читаете, что я предлагаю выше. Да, работать с тэгами в БД удобней всего. В файловом кэше их попросту не сделать. В 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)