Ma gandesc ca poate ma depaseste total subiectul insa macar intreb…
Se da urmatoarea problema : "O baza de date de cativa gb… "
Din ce am descoperit pe elastic search pentru 30.000 de cautari returnarea a unui rezultat dureaza cam … 5-10 secunde.
Mai nou am auzit si de ceea ce numeste exasol(merge bine pe… symfony framework, insa ma intereseaza ceva pentru laravel) si ar fi foarte performant , pe partea de … javascript ca si alernativa ar fi typescript inpreuna cu algolia insa e cu plata iar asta nu ma prea incanta…
Din ce am inteles ca si “drive” postgresql ar fi ceva mai indicat, ma gandesc ca e nevoie de ceva arhitectura, scalabilitate pentru asta asta fiind principalul motiv pentru care am intrebat aici.
Nu optimizezi daca vrei cautare pe toate datele, elastic-search e mai mult decat de ajuns, adaugi doar servere si memorie.
Problema ta e cu banii, optimizeaza aici, algolia e practic elasticsearch gazduit pe un ditamai cloud. Orice optimizare o fac o realizaza cu un cloud care face cache la cele mai utilizate cuvinte.
Cea mai ieftina solutie e sa rulezi elasticsearch pe amazon aws/microsoft azure.
Altfel nici nu merita sa rulezi elasticsearch pe un server cu mai putin de 64Gb RAM fiindca nu vei putea vedea unde sunt problemele, din cate imi amintesc logica e start big, scale down.
La o baza de date de cativa Gb si MySQL iti va returna o cautare fulltext intr-o secunda cu index-uri si destula memorie.
O alta problema pe care o pot vedea e ca rulezi elasticsearch pe un vps cu procesorul/HDD-ul foarte limitat la I/O. Adica degeaba ai 16 gb memorie daca procesorul poate cauta doar cu 1 gb/s. Asta se intampla si daca se trece memoria in swap.
Si ai nevoie de acces rapid la toate datele tot timpul?
De exemplu la un proiect aveam o baza de date care continea multe date istorice si care nu erau folosite am putut sa rezolv cu un index care sa contina datele curente iar un al doilea folosit pentru toate datele. >95% din cereri se rezolvau in indexul optimizat.
Ca si regula generala cand e vorba de cautare e bine sa fie toate datele in memorie, daca ai un index pe disk de vreo 30 GB trebuie sa poti stoca tot indexul in RAM pentru a evita disk I/O.
Sunt doua procese de indexare separate care lucreaza cu doua index-uri separate:
A. index date curente
B. index toate datele
Pentru (A) avem un filtru care trimite la indexare doar datele noi + un cron job care face cleanup la datele mai vechi de un an. La noi criteriul era sa avem datele pentru ultimele 12 luni cautabile.
Datele de la (B) erau folosite doar in backend pentru procese de raportare + alte cautari pe cand (A) era folosit pe frontend la majoritatea actiunilor, pentru (B) performanta nu era critica.
dar nu e exclusa nici varianta de sa fie la Tb dar momentan o iau usurel…