Когато кешът се мащабира в грешната посока

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

Те съществуват, за да не се налага пътят на броенето да задава на базата данни четири въпроса, на които тя почти винаги отговаря с „не“. Изключва ли този брояч собствените посещения на собственика си? Проследява ли изходящите кликове? Проследява ли пътищата през сайта? Презарежда ли се сам? За над 99% от броячите всеки отговор е не, а файл, който съдържа шепата номера, при които отговорът е да, е по-евтин за справка от четири заявки с индекс.

По-евтин е. Но е и от онзи вид евтино, което се обръща.

Какво беше измерено

Един и същ въпрос — „в списъка ли е този брояч?“ — зададен по два начина при шест размера на списъка. Чрез файла: прочита се, JSON се декодира, търси се номерът. Чрез базата данни: една подготвена заявка срещу колона с индекс. По две хиляди повторения, пет кръга, взета е медианата.

При днешния размер файлът печели осем пъти: 0,0202 милисекунди срещу 0,1630. При хиляда номера са наравно. При десет хиляди файлът струва дванадесет пъти повече, а при сто хиляди — 135 пъти повече, защото дотогава той е 578 килобайта, които трябва да се прочетат и анализират при всяко посещение.

Линията на базата данни не помръдва. 0,16 милисекунди при два реда и 0,16 милисекунди при сто хиляди: за това е индексът и лесно се забравя колко работа се крие зад това колко скучно изглежда тази линия.

Неудобната част

Пресечната точка е някъде между 100 и 1 000 номера. Тази услуга има 2 218 брояча, които са били активни през последните тридесет дни.

Така че ако функцията за изключване имаше успех — ако всеки, който има брояч, включи „не брой собствените ми посещения“ — файлът би съдържал 2 218 номера, би тежал 11 килобайта и би струвал 0,43 милисекунди на посещение вместо 0,02. При вчерашните 18 423 посещения това са осем секунди работа на ден, за да се избегне заявка, която би отнела три.

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

Защо все още е там

Защото днес е правилна, а „правилно днес“ може да бъде причина за нещо, стига някой да е записал кога това престава да е вярно.

Три номера в три файла. Осем пъти по-евтино от алтернативата, на машина, където пътят на броенето е единственото нещо, което трябва да е бързо. Да я заменим сега със заявката, която тя бие, би означавало по-лоша система, оправдана с хипотеза.

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

Общата форма

Това не е аргумент срещу кеширането във файл. Това е аргумент да се знае в каква посока се мащабира един кеш.

Повечето кешове се подобряват под натоварване: повече заявки, повече попадения, по-добро съотношение. Този е от другия вид. Цената му на заявка зависи от това колко данни съдържа, а съдържанието му расте заедно с онова, което услугата се опитва да насърчи. Всяко четене плаща за всеки запис, включително за 2 215-те, които нямат нищо общо с посетителя, който се брои в момента.

Въпросът, който трябва да се зададе за всяка справочна таблица, държана в паметта или във файл, не е „колко е бърза“, а „какво я кара да расте и какво става, когато това нещо върви добре“. Ако отговорът е „става по-бавна“, ограничението на размера трябва да е в кода, до онова, което записва файла, още в деня, в който то бъде изградено.