Dette spørgsmål kræver et meget bredt svar, der skal besvares i alle aspekter. Der er meget vel visse specifikationer, der kan gøre et system overlegent i forhold til et andet til en speciel brug, men jeg vil gerne dække det grundlæggende her.
Jeg vil helt beskæftige mig med Solr som eksempel for flere søgemaskiner, der fungerer nogenlunde på samme måde.
Jeg vil starte med nogle hårde fakta:
-
Du kan ikke stole på Solr/Lucene som en sikker database. Der er en liste over fakta hvorfor, men de består for det meste af manglende gendannelsesmuligheder, mangel på sure transaktioner, mulige komplikationer osv. Hvis du beslutter dig for at bruge solr, skal du udfylde dit indeks fra en anden kilde som en SQL-tabel. Faktisk er solr perfekt til at gemme dokumenter, der inkluderer data fra flere tabeller og relationer, som ellers ville kræve komplekse sammenføjninger for at blive konstrueret.
-
Solr/Lucene tilbyder overvældende tekstanalyse / stemming / fuldtekstsøgning scoring / fuzziness-funktioner. Ting du bare ikke kan med MySQL. Faktisk er fuldtekstsøgning i MySql begrænset til MyIsam, og scoring er meget trivielt og begrænset. Vægtning af felter, boostning af dokumenter på visse metrics, score resultater baseret på sætningsnærhed, matchende nøjagtighed osv. er meget hårdt arbejde til næsten umuligt.
-
I Solr/Lucene har du dokumenter. Du kan ikke rigtig gemme relationer og processer. Nå, du kan selvfølgelig indeksere nøglerne til andre dokumenter inde i et felt med flere værdier i et dokument, så på denne måde kan du faktisk gemme 1:n relationer og gøre det begge måder for at få n:n, men dets data overhead. Misforstå mig ikke, det er perfekt og effektivt til mange formål (for eksempel til et produktkatalog, hvor du vil gemme distributører for produkter, og du kun vil søge efter dele, der er tilgængelige hos visse distributører eller noget). Men du når slutningen af muligheder med HAR / HAR IKKE. Du kan næsten ikke gøre noget som "få alle produkter, der er tilgængelige hos mindst 3 forhandlere".
-
Solr/Lucene har meget gode facetterfunktioner og postsøgningsanalyse. For eksempel:Efter en meget bred søgning, der havde 40000 hits, kan du vise, at du kun ville få 3 hits, hvis du forfinede din søgning til kombinationen af at have dette felt denne værdi og det felt den værdi. Ting, der har brug for yderligere forespørgsler i MySQL, udføres effektivt og bekvemt.
Så lad os opsummere
-
Styrken ved Lucene er tekstsøgning/analyse. Det er også uhyggeligt hurtigt på grund af den omvendte indeksstruktur. Du kan virkelig lave en masse efterbehandling og tilfredsstille andre behov. Selvom det er dokumentorienteret og ikke har nogen "grafforespørgsel", som triple stores gør med SPARQL, er grundlæggende N:M-relationer mulige at gemme og forespørge på. Hvis din applikation er fokuseret på tekstsøgning, bør du helt sikkert gå efter Solr/Lucene, hvis du ikke har gode grunde, som f.eks. meget komplekse filterforespørgsler med flere dimensioner, til at gøre noget andet.
-
Hvis du ikke har tekstsøgning, men snarere noget, hvor du kan pege og klikke på noget, men ikke indtaste tekst, er gode gamle relationsdatabaser nok en bedre vej at gå.