Când un cache scalează în direcția greșită

În folderul de cache al acestui serviciu stau patru fișiere mici. Cel mai mare are 35 de octeți. Împreună conțin trei numere de contor și sunt citite la absolut fiecare cerere către un contor.

Ele există pentru ca drumul numărării să nu fie nevoit să pună bazei de date patru întrebări la care aproape întotdeauna răspunsul este „nu”. Exclude acest contor vizitele proprii ale proprietarului? Urmărește clicurile spre exterior? Urmărește traseele prin site? Se reîncarcă singur? Pentru mai mult de 99% dintre contoare, fiecare răspuns este nu, iar un fișier care conține cele câteva numere pentru care răspunsul este da este mai ieftin de consultat decât patru interogări indexate.

Este mai ieftin. Este însă genul de ieftin care se inversează.

Ce s-a măsurat

Aceeași întrebare — „este acest contor în listă?” — pusă în două moduri, la șase dimensiuni ale listei. Varianta cu fișier: citirea lui, decodarea JSON-ului, căutarea numărului. Varianta cu baza de date: o singură instrucțiune pregătită pe o coloană indexată. Câte două mii de repetări fiecare, cinci runde, s-a luat mediana.

La dimensiunea de azi, fișierul câștigă de opt ori: 0,0202 milisecunde față de 0,1630. La o mie de numere sunt la egalitate. La zece mii, fișierul costă de douăsprezece ori mai mult, iar la o sută de mii costă de 135 de ori mai mult, pentru că atunci are deja 578 de kilobytes care trebuie citiți și parsați la fiecare accesare.

Linia bazei de date nu se mișcă. 0,16 milisecunde la două rânduri și 0,16 milisecunde la o sută de mii: pentru asta există un index, și e ușor de uitat câtă muncă se ascunde în spatele aspectului plictisitor al acelei linii.

Partea incomodă

Punctul de intersecție se află undeva între 100 și 1.000 de numere. Acest serviciu are 2.218 contoare care au fost active în ultimele treizeci de zile.

Așa că, dacă funcția de excludere ar avea succes — dacă toți cei care au un contor ar activa „nu număra vizitele mele” — fișierul ar conține 2.218 numere, ar cântări 11 kilobytes și ar costa 0,43 milisecunde per accesare în loc de 0,02. La cele 18.423 de accesări de ieri, asta înseamnă opt secunde de muncă pe zi pentru a evita o interogare care ar fi durat trei.

Optimizarea este cea mai rapidă atunci când funcția este cel mai puțin folosită. Nu se degradează treptat odată cu încărcarea, cum face o interogare lentă. Se degradează odată cu adoptarea, care este singura axă pe care nu o urmărește nimeni, pentru că creșterea adoptării ar trebui să fie vestea bună.

De ce este încă acolo

Pentru că astăzi este soluția corectă, iar „corect astăzi” are voie să fie motivul pentru ceva, atâta timp cât cineva a notat când încetează să mai fie adevărat.

Trei numere în trei fișiere. De opt ori mai ieftin decât alternativa, pe o mașină unde drumul numărării este singurul lucru care trebuie să fie rapid. A-l înlocui acum cu interogarea pe care o întrece ar însemna un sistem mai prost, justificat de o ipoteză.

Are nevoie de un semnal de alarmă, nu de o rescriere. Fișierul este scris oricum din baza de date, de codul care modifică o setare — acesta este locul natural pentru a observa că lista a crescut peste câteva sute de intrări și pentru a o semnala. Un cache cu un plafon documentat este o decizie. Un cache fără plafon este un pariu cu care nu a fost de acord nimeni.

Forma generală

Acesta nu este un argument împotriva cache-ului într-un fișier. Este un argument pentru a ști în ce direcție scalează un cache.

Cele mai multe cache-uri devin mai bune sub încărcare: mai multe cereri, mai multe potriviri în cache, un raport mai bun. Acesta este de celălalt fel. Costul lui per cerere depinde de câte date conține, iar ce conține crește odată cu lucrul pe care serviciul încearcă să îl încurajeze. Fiecare citire plătește pentru fiecare intrare, inclusiv pentru cele 2.215 care nu au nicio legătură cu vizitatorul numărat chiar acum.

Întrebarea de pus oricărui tabel de căutare ținut în memorie sau într-un fișier nu este „cât de rapid este”, ci „ce îl face să crească și ce se întâmplă când acel lucru merge bine”. Dacă răspunsul este „devine mai lent”, limita de dimensiune își are locul în cod, lângă lucrul care scrie fișierul, chiar din ziua în care este construit.