Un magazin pe Odoo cu peste o sută de mii de produse are o problemă pe care baza demo nu o arată niciodată: căutarea încetează să fie instantanee. La noi dura opt–zece secunde cu filtrele aplicate. Depozitul aștepta, vânzătorii așteptau, și toți învățaseră să deschidă un al doilea tab cât timp primul se gândea.
Ce era de fapt lent
Primul impuls este să dai vina pe server și aproape întotdeauna este greșit. Memoria ajungea, discurile nu erau ocupate. Timpul se ducea într-o singură interogare, iar planul de execuție explica de ce.
O căutare în catalog nu este o singură întrebare, ci mai multe deodată: găsește rândurile al căror text conține un fragment, restrânge-le după câteva atribute și numără câte produse rămân în spatele fiecărei valori de filtru, ca cifrele de lângă bife să fie corecte. La câteva mii de produse asta e gratis. La o sută zece mii de rânduri cu descrieri lungi și mai multe tabele de atribute alăturate, baza trebuie să parcurgă aproape tot - la fiecare tastă și pentru fiecare vizitator.
Indecșii nu salvează asta. O căutare după un fragment din mijlocul cuvântului nu poate folosi un index obișnuit, iar contoarele filtrelor se recalculează prin definiție la fiecare cerere: depind de ce a ales deja vizitatorul.
Iar catalogul nu era singur pe mașina aceea. Același Odoo servea încă treizeci și nouă de magazine dintr-un pool comun de workeri, așa că fiecare căutare lentă lua un worker de la toate deodată.
Întâi măsoară
Două numere decid ce urmează: cât stă baza de date pe interogare și cât stă browserul pe tot restul. Dacă răspunsul ar fi fost browserul, am fi optimizat o săptămână jumătatea greșită a sistemului.
Nu era browserul. Jurnalul interogărilor lente și planul de execuție arătau spre același loc, iar asta a făcut decizia ușoară.
Ce s-a schimbat
Căutarea s-a mutat din bază în Elasticsearch, care își ține propriul index și este construit exact pentru această întrebare: text, filtre și contoare deodată. Câmpul de căutare de pe site a rămas unde era, iar cel care scrie în el nu vede nimic nou - în afară de faptul că rezultatele sunt deja acolo.
Contează direcția săgeții. Odoo rămâne sursa adevărului: produsele, prețurile și stocurile trăiesc și se editează acolo. Indexul se construiește din bază și se reconstruiește când se schimbă înregistrările - niciodată invers. Dacă indexul se pierde, poate fi aruncat și refăcut: nu se păstrează nimic valoros în el.
Din ce este construit
Nimic de aici nu a fost scris de la zero de dragul scrisului. Modulul pentru Elasticsearch a fost cumpărat și apoi refăcut, iar peste el stă o punte către tema magazinului, ca să vorbească cu indexul, nu cu baza de date: câmpul de căutare, pagina de catalog și filtrele.
Între Odoo și depozite stă un serviciu mic scris în Go. El construiește interogarea cu filtre, întreabă Elasticsearch, numără fațetele și ține bucățile grele ale paginii de produs în Redis, cu un timeout de zeci de milisecunde - dacă nu răspunde la timp, nimeni nu îl așteaptă.
De ce un serviciu separat: pe un Odoo găzduit nu poți rula propriul daemon alături, nu ai acces. Așa că serviciul stă în afară și răspunde prin HTTP. Pe serverul propriu se mută în aceeași subrețea, iar saltul nu costă aproape nimic.
Iar magazinul continuă să funcționeze când serviciul nu funcționează. Aceeași logică de filtrare există în Odoo în Python curat: mai lent, dar corect. Acel drum nu este o rămășiță - datorită lui un deploy al serviciului nu mai este un eveniment de planificat.
Cât costă
Un răspuns onest include prețul, și nu e doar munca de mutare a căutării. Acum rulează un al doilea serviciu, care trebuie pornit, monitorizat și salvat. Indexul lui trebuie refăcut după importuri masive. Cineva trebuie să observe când rămâne în urmă, iar sistemul are nevoie de un comportament rezonabil pentru minutul în care nu este disponibil.
Acesta este schimbul real: o bucată permanentă de infrastructură în locul unei căutări care nu mai face oamenii să aștepte. Pentru un catalog de mărimea asta schimbul merită evident. Pentru un catalog de cinci mii de produse, de obicei nu.
Când nu aveți nevoie de nimic din toate astea
Dacă este lentă căutarea pe un catalog mic, cauza aproape niciodată nu este volumul datelor. Mai des este o interogare care alătură mai mult decât trebuie, un index lipsă pe un câmp după care se filtrează pe fiecare pagină, o imagine care blochează afișarea sau un snippet care redesenează toată lista la fiecare tastă. Astea costă o după-amiază, nu un serviciu nou în producție.
De aceea primul pas este mereu același: întâi măsoară, apoi schimbă. Măsurătoarea durează o oră și economisește săptămâna pierdută pe jumătatea greșită.
Încă alegeți sistemul în sine? Atunci aritmetica vine înaintea arhitecturii: cât plătește de fapt o echipă de zece la Odoo, Salesforce, HubSpot și SAP.
Cum se comportă aceleași sisteme zi de zi? Odoo în producție: ce duce, ce se strică, ce nu scrie în manual.