Теория на кеша

Кеширането е неразделна част от всички сложни системи. Кеширането ви позволява значително да увеличите скоростта на приложението чрез съхраняване на трудни за изчисляване данни за по-късна употреба. Въпреки това, няма да навлизам в дефиниции, повечето разработчици знаят много добре какво е това.

В тази статия ще се опитам да разреша проблема с кеширането, който е фокусиран предимно върху сайтове и системи за управление на съдържанието.Веднага предупреждавам, че това са мои лични съображения, които не претендират за истина от последна инстанция. Цялата терминология също е моя, можете да я използвате, ако сметнете за добре по свое усмотрение. Градивната критика е добре дошла.

Основни проблеми с кеширането

При кеширане на данни, като правило, няма проблеми при запазването и повторното им използване. Основният проблем е да се определи кога кешът е остарял. Тоест да се определи дали данните от кеша могат да се използват или тези данни трябва да се преизчислят, защото може нещо да се е променило. Ще нарека това проблем със свежестта на кеша (моя терминология).

Вторият проблем с кеширането е проблемът със скоростта. Нашият алгоритъм не работи ли по-бързо без кеширане, отколкото с кеширане? Въпреки абсурда на пръв поглед, това е повече от факт. Факт е, че кеширащите алгоритми също консумират ресурси и лесно може да се случи количеството ресурси, консумирани от кеша, да надвишава количеството ресурси за изчисляване на самите данни. Това често се случва в 2 случая. Първият случай е, когато сайт от 10 страници е поставен върху мощна рамка. Тук всичко е просто - първоначалните данни са толкова малки, че скоростта на изчисление е много висока, а кеширането само се забавяработа. Вторият случай е обратен – когато сайтът е толкова голям, че размерът на кеша нараства до обеми, което води до значително забавяне на търсенето им в кеша.

Не е възможно да се решат и двата проблема. Възможно е само да изберете метода, който осигурява максимална производителност. И още по-добре - че този метод ще бъде избран автоматично.

Проблемът с производителността не е толкова спешен и се решава или чрез деактивиране на използването на кеширане в конфигурацията, или чрез периодично физическо изтриване на кеширани данни и преминаване към по-бърз хардуер.

Но що се отнася до проблема с уместността, тук всичко е много по-сложно ...

Теория на кеша

Авторът разграничава 4 основни вида кеширане на информация:

1. Независим или статичен- има място, когато не е необходимо да се проверява дали обектът е променен. Алгоритъмът е прост - ако има данни в кеша, върнете данните, в противен случай ги изчислете. Ефективен в рамките на един процес, когато се изисква често използване на резултатите от сложни междинни изчисления. След като процесът приключи, статичният кеш умира и всички данни се преизчисляват за повторен процес. Като цяло във всеки език за програмиране всички временни променливи не са нищо повече от статичен кеш. Ако се изисква кеширане на резултатите от функцията, тогава можете да използвате следния алгоритъм, като използвате статични променливи, като използвате примера на PHP:

функция getData($id) static $data = array();

if (isset($data[$id])) върне $data[$id];

// изчисляване на данни $data[$ > върни $данни[$id]; >

2. Изрично зависим- възниква, когато решението за актуализиране на кеша е взето по някакъв лесно изчислим атрибут. Това включва предимно кеширане на данни, взети от конкретен файл, както икеширане на времето. В тези случаи е лесно да се разбере дали файлът е променен или дали кешът е изтекъл (а кешътизричнозависи от тези фактори). Алгоритмите тук също са доста прости - те се свеждат до проверки на условия, но за разлика от статичния кеш, той може да се използва независимо от различни процеси.

3. Implicit-Dependent- Възниква, когато промяната в обекта на кеша зависи от много фактори. Например, един обект съдържа много други обекти, които също могат да се променят. Тоест, обектътимплицитно(не директно) зависи от други, които също могат да зависят от други и т.н. Комбинацията от тези фактори еимплицитни зависимостина обекта и за да решите дали обектът се е променил, трябва да „разпитате“ всички тях, което не винаги е възможно или препоръчително. Например функция, която показва информация, взета от база данни. Можем да кешираме резултата от функцията, но трябва да знаем кога данните се променят, за да ги актуализираме. И това е еквивалентно на достъп до таблицата, което по отношение на потреблението на ресурси е еквивалентно на изпълнение на функция. Ами ако има много маси? Значението на кеша се губи.

Това се разкрива чрез така наречената"таблица на зависимостите". Тази таблица има 2 колони: обекти и времето, когато са били променени. При смяна на обекти е необходимо да се актуализират техните времена в таблицата. Скоростта на достъп до самата таблица е много висока (като правило тя е в статичен или изрично зависим кеш) и можем много бързо да получим времето за промяна на всички обекти, от които се нуждаем. И ако поне едно време за промяна на желаните обекти надвиши времето за кеширане, тогава кешът трябва да бъде нулиран. Така неявните зависимости се превръщат в явни - обектът зависи от определен набор от времена в таблицата на зависимостите.

4.Условно зависим- възниква, когато имплицитно зависим кеш може да бъде направен изрично зависим или статичен, ако е изпълнено някакво условие. Например, можете да кажете, че последното модифицирано време на таблица на зависимости е последният път, когато данните в сайта са били модифицирани. Ако на страницата няма уникални данни за потребителя (четете - той не е влязъл), тогава цялата страница ще зависи само от таблицата на зависимостите. Това означава, че цялата страница може да бъде поставена в кеша при това условие. Това включва и кеша, който в точното време просто се изтрива физически.

Заключение

Както можете да видите, кеширането на данни е много сложен процес, който изисква голямо количество ресурси за разработването му. Не забравяйте, че в наше време цената на хардуера може да бъде по-евтина от цената за разработване на сложни алгоритми. Ето защо, ако има проблеми със скоростта на сайта, тогава може да си струва да закупите просто по-мощен сървър - в някои случаи ще се окаже по-евтино.

И тук можете да получите грант за тестов период на Yandex.Cloud. Необходимо е само да въведете "Habr" в полето "секретна парола".

---