Se da o baza de date mysql de produse care are clasicele campuri titlu,descriere,brand,culori etc. Vreau sa fac un sistem de cautare cat mai apropiat de relevanta google. Adica sa stie sinonime, greseli mici de scriere, importanta anumitor termeni impreuna sau cat de apropiati sunt, de numarul de repetitii.
Am acces la un server pe care pot instala ce vreau si ideal ar fi sa stie sa se conecteze direct la sql-ul de baza (care e populat constant) si sa pot interoga direct din php.
As vrea niste recomandari de tehnologie care a fost deja folosita de voi si deja puteti evalua ca e una relativ usor de deprins, ofera documentatie, exista un community…adica una pe care chiar a-ti folosi-o la urmatorul proiect de gen.
Pentru a avea si un benchmark ma astept ca aceasta cautare sa dea rezultate in max 2s pt 1 milion de inregistrari in index.
N-am folosit încă, dar ce zici tu sună ca un candidat pentru Elastic Search. Are fuzzy iar interogările sunt super rapide. Singura problemă ar putea fi la cerințele hardware (minimum 8Gb RAM, SSD).
Dacă nu te deranjează un SaaS, poți încerca Algolia.
Dacă vrei musai mysql și ești dispus să accepți niște compromisuri:
Elasticsearch e făcut fix pentru situația descrisă de tine, dar e o curba de învătare semnificativă, mai ales dacă nu ai un sysadmin care să se ocupe de instalare/configurare/scalare cum trebuie.
elastic si sphinx mi-au aparut de cele mai multe ori in documentare pana acum
cumva am ramas cu impresia ca elastic e overhead pt ce-mi trebuie, adica stiu sigur ca n-or sa fie mai mult de 1 milion de rows si as vrea ca totul sa stea pe aceeasi masina ca un monolith, nu ma incalzeste ca functioneaza pe “hundred of machines with peta bytes”
sphinx pare ca a fost ceva acum cativa ani dar i-au luat-o altele mai scalabila in fata
algolia e o solutie easy to use dar scump pentru acest proiect
tntsearch pare ca se apropie de specificatii. am dubii de viteza avand in vedere ca inteleg ca tine index-ul intr-un fisier. incerc si revin cu feedback
putin offtopic: oare mai exista apache solr?
ceva mai ontopic: desi nu am ajuns sa implementez inca, elasticsearch era raspunsul pentru o intrebare similara la care am cautat raspuns in urma cu cateva luni.
Solr sau Elasticsearch ar fi cele mai bune doua solutii, ambele sunt facute pentru asa ceva.
Cateva chestii la care sa fii atent in cazul in care alegi una din solutiile respective:
Schema documentului de indexat - alegerea potrivita a tipurilor de date si configurarea procesarilor la indexare si la cautare. Nu lasa configurarea default.
Citeste despre stop words, stemming, synonyms si multe alte chestii ce trebuiesc configurate pentru a merge cautarea ok pe o anumita limba. Va trebui sa folosesti configurari/procesari/indexari diferite pentru fiecare cultura in parte.
Nu stiu sa fie solutie out of the box care sa faca tot ce trebuie din prima zi, va trebui sa faci fine tuning la solutie pe parcurs, lumea in general crede ca alegi o solutie de genul si in mod magic cautarea functioneaza ok.
intre timp am inceput ceva cu elasticsearch, instalarea a fost floare la ureche, acum ma dumiresc cu restul. deocamdata mi se pare dubios ca nu exista o varianta usoara pt a avea o interfata wyswyg pt a face diverse.
Am revenit cu concluzia. Un astfel de feature pare a fi un proiect in sine si nu vreau sa-l fac sa fie asa.
Pana la urma am facut un tabel separat de tip myisam care cloneaza informatiile despre produse (luate inclusiv din alte tabele) intr-un singur string (si deja procesat sa ignore stopwords, duplicates) pe care am facut un index fulltext.
Pare acceptabil de rapid so far (sub 1sec).
Adica intr-un final e o cautare simpla de tip MATCH AGAINST intr-un string de genul:
Nu stie inca de sinonime si fuzzy si nu m-am lamurit daca “boolean” ar da rezultate mai relevante decat “natural” dar pare un mare plus fata de ce era inainte.
Daca mai apar sugestii va rog sa fie legate strict de cautarea asta de tip fulltext in mysql.
Mă alătur tuturor celor care recomandă ElasticSearch. E un proiect în sine, dar mai mult de 2-3 zile nu îți ia. În timp înveți să-l configurezi și să întorci rezultate din ce în ce mai bune; la căutarea aia cu rochii ar fi ok ca primul rezultat să fie o categorie, apoi articole cu rochii în titlu și la urmă cele cu rochii în text; plus că pentru roochii și rochi o să obții cam aceleași rezultate.
Dacă nu, următoarea soluție e Google Custom Search (caută în indexul Google și apar diferențe, dar e mai ok ca search-ul full text în db).
Căutarea în db, mai bine o scoți de tot și lași doar navigarea prin categorii. În exemplul tău merge și cu unul și cu 2 de i, dar cu 3 nu, iar peste 90% din români nu știu câți de i să pună… pe lângă alte greșeli de gramatică, de tastare sau în textul tău.
Daca faci query intr-un singur tabel si nu folosesti operatorul like, cautarea (chiar dupa text) va fi sub o secunda chiar daca ai multe milioane de inregistrari.
poti porni in 2-3 zile dar tot bagajul pe care tre sa-l porti ulterior in cazul meu nu-si justifica implementarea (ca one only developer pt un side project)
strict pt cazul meu pare ca functioneaza metoda asta. cautarea oricum porneste de la un autocomplete care-l duce spre categorii, branduri si combinatii si sub 10% mai ajung in cautarea fulltext
oricum e bine ca m-am lamurit si cu folosirea in practica a acestui elasticsearch. sigur ma va ajuta cu luarea unor decizii candva
Si eu am folosit tntsearch, care s-a mentionat mai sus.
L-am folosit in laravel pentru api-ul unei aplicatii mobile multitenant, cauta in produsele unui restaurant. Search-ul se face prin websockets, si este foarteeee rapid. L-am incetinit eu putin ca sa nu loveasca serverul la fiecare apasare de tasta (pentru ca este livesearch).
Are fuzzyness, poti tasta cuvinte gresit si le gaseste. Nu am avut ocazia sa il folosesc pe baze de date foarte mari.
Am folosit si elasticsearch si il recomand, este foarte avansat, dar putin mai greu de folosit.
