С появлением и развитием memcached-подобных систем в архитектурах веб-приложений появилось еще одно звено, а именно кеш-серверы. Обычно это машины с большим объемом оперативной памяти, в которой хранятся заранее подготовленные данные. Это могут быть результаты сложных запросов к БД или же отрендеренные динамические части страниц сайта. На самом деле, кеш, как и любая другая система, может использоваться как угодно, чтобы удовлетворить нужды приложения.
Суть кеширования проста. Оно позволяет уменьшить время подготовки данных и, как следствие, время генерации страницы.
В своем проекте мы активно используем кеширование по одной простой причине. Изначально мы заложили в инофрмационную модель принцип супергибкости. Что это значит? А то, что у нас есть два типа таблиц: справочники и связи. Справочники хранят в себе информацию о сущностях, используемых в проекте, а связи, как вы можете догадаться, хранят отношения между этими сущностями. При этом сами связи могут обладать своими свойствами.
Рассмотрим на примере. Есть три сущности: исполнитель, альбом, песня. И есть связи между ними. Все связи должны быть многие-ко-многим. Так как один испольнитель может иметь несколько альбомов, если альбом — сборник, то у него будет несколько исполнителей и т.д. При этом, скажем, связь между исполнителем и исполнителем может иметь свойство «versus», «feat» и другие.
В общем на этом примере, я попытался показать всю сложность связей между сущностями и необходимость в очень гибкой структуре БД.
Но, при такой структуре запросы к БД становяться многоэтажными. Например, чтобы вывести исполнителя и список его албомов, нужно соединить 3 таблицы: исполнитель, связь_исполнитель_альбом и альбом. А теперь еще добавить персонализацию и получить в итоге классический Slow query.
Вот поэтому мы и вынужденны использовать кеширование. И здесь происходит самое интересное. Как я уже говорил, в БД у нас два типа данных: сущности и связи. И кеширование тоже работает по схожему принципу. Каждый объект в системе представлен как экземпляр класса DataObject, который умеет загружать себя из базы и сохранять себя туда. Объект, естественно может быть составным, то есть загружаться и сохраняться из/в несколько таблиц. Это классический принцип, используется повсеместно. При этом объект сам следит за тем закеширован он или нет и за актуальностью своего кеша. У каждого объекта, есть динамические свойства, которые представляют коллекции связанных с ним, других объектов. Например у песни есть свойства артисты и исполнители. Эти свойства инициализируются по требованию, при первом обращении.
Вот с этого места я и хочу поведать о ключевом принципе кеширования коллекций.
Отделяя мух от котлет мы храним цепочки идентификаторов объектов отдельно от самих объектов и вот почему: набор данных один, а представлений у него много. Одна песня может относится к альбому, списку любимых песен определенного пользователя, попасть в эфир и быть еще во многих местах.
Для каждого такой цепочки контента мы генерируем набор идентификаторов (естественно по требованию), и кладем его в кеш на некоторый промежуток времени, так как эти данные могут обновляться.
На примере сценария получения любимых песен пользователя, я покажу как это работает. Мы попадаем в список любимых песен на странице пользователя. При этом создается пользователь, у которого берется динамическое свойство любимые_песни. При попытке получить значение этого свойства инициализируется коллекция любимых песен этого пользователя: проверяется есть ли список идентификаторов в кеше, если нет, то вычитывается из БД. Далее происходит проверка на наличие в кеше всех песен по этим идентификаторам. Составляется список, тех которые отсутсвуют, и с помощью специальной процедуры они вычитываются из БД и кладутся в кеш. После этого массив песен отдается выше в бизнес-логику, которая уже готовит их визуальное представление в виде страницы.
Применение такой архитектуры помогло нам в значительной степени разгрузить сервер БД, и на какое-то время отодвинуло проблему его масштабирования (разнесения на несколько машин).
Ссылки по теме:
memcached
XCache — мы используем его, так как он наиболее производительный в нашем случае.
eAccelerator
Суть кеширования проста. Оно позволяет уменьшить время подготовки данных и, как следствие, время генерации страницы.
В своем проекте мы активно используем кеширование по одной простой причине. Изначально мы заложили в инофрмационную модель принцип супергибкости. Что это значит? А то, что у нас есть два типа таблиц: справочники и связи. Справочники хранят в себе информацию о сущностях, используемых в проекте, а связи, как вы можете догадаться, хранят отношения между этими сущностями. При этом сами связи могут обладать своими свойствами.
Рассмотрим на примере. Есть три сущности: исполнитель, альбом, песня. И есть связи между ними. Все связи должны быть многие-ко-многим. Так как один испольнитель может иметь несколько альбомов, если альбом — сборник, то у него будет несколько исполнителей и т.д. При этом, скажем, связь между исполнителем и исполнителем может иметь свойство «versus», «feat» и другие.
В общем на этом примере, я попытался показать всю сложность связей между сущностями и необходимость в очень гибкой структуре БД.
Но, при такой структуре запросы к БД становяться многоэтажными. Например, чтобы вывести исполнителя и список его албомов, нужно соединить 3 таблицы: исполнитель, связь_исполнитель_альбом и альбом. А теперь еще добавить персонализацию и получить в итоге классический Slow query.
Вот поэтому мы и вынужденны использовать кеширование. И здесь происходит самое интересное. Как я уже говорил, в БД у нас два типа данных: сущности и связи. И кеширование тоже работает по схожему принципу. Каждый объект в системе представлен как экземпляр класса DataObject, который умеет загружать себя из базы и сохранять себя туда. Объект, естественно может быть составным, то есть загружаться и сохраняться из/в несколько таблиц. Это классический принцип, используется повсеместно. При этом объект сам следит за тем закеширован он или нет и за актуальностью своего кеша. У каждого объекта, есть динамические свойства, которые представляют коллекции связанных с ним, других объектов. Например у песни есть свойства артисты и исполнители. Эти свойства инициализируются по требованию, при первом обращении.
Вот с этого места я и хочу поведать о ключевом принципе кеширования коллекций.
Отделяя мух от котлет мы храним цепочки идентификаторов объектов отдельно от самих объектов и вот почему: набор данных один, а представлений у него много. Одна песня может относится к альбому, списку любимых песен определенного пользователя, попасть в эфир и быть еще во многих местах.
Для каждого такой цепочки контента мы генерируем набор идентификаторов (естественно по требованию), и кладем его в кеш на некоторый промежуток времени, так как эти данные могут обновляться.
На примере сценария получения любимых песен пользователя, я покажу как это работает. Мы попадаем в список любимых песен на странице пользователя. При этом создается пользователь, у которого берется динамическое свойство любимые_песни. При попытке получить значение этого свойства инициализируется коллекция любимых песен этого пользователя: проверяется есть ли список идентификаторов в кеше, если нет, то вычитывается из БД. Далее происходит проверка на наличие в кеше всех песен по этим идентификаторам. Составляется список, тех которые отсутсвуют, и с помощью специальной процедуры они вычитываются из БД и кладутся в кеш. После этого массив песен отдается выше в бизнес-логику, которая уже готовит их визуальное представление в виде страницы.
Применение такой архитектуры помогло нам в значительной степени разгрузить сервер БД, и на какое-то время отодвинуло проблему его масштабирования (разнесения на несколько машин).
Ссылки по теме:
memcached
XCache — мы используем его, так как он наиболее производительный в нашем случае.
eAccelerator
