Indeksen / kjerna (som kan sammenlignes med en tabell og en database i RDBMS) bygges ofte fra en eksisterende database eller datagrunnlag.
Vi bruker litt ekstra tid når det skjer en oppdatering, framfor å bruke tid hver gang vi skal hente ut eller finne informasjon.
I stedet for å lagre en id som peker til en annen "tabell" er det ofte mer fornuftig å lagre selve verdien, slik at vi kan gjøre andre operasjoner på navnet eller teksten.
Google (kommersielt tilgjengelig som Google Search Appliance (GSA))
FAST (tidligere kommersielt tilgjengelig som FAST ESP (Enterprise Search Platform - NOW WITH SUPPORT FOR JAVA ENTERPRISE BEANS), nå kjent som .. Microsoft FAST Search Server 2010 for SharePoint.)
Lucene er et Apache-prosjekt og et generelt bibliotek for å drive med søk og gjenfinning av informasjon. Hovedprosjektet er skrevet i Java, men det finnes mer eller mindre gode implementasjoner i litt for mange språk.
Gir deg tilgang til egenbygd og tilpasset søk uten å forholde deg til alt som er vanskelig med søk
Leveres med innebygd Jetty (last ned og start opp lokalt!), ellers funker også Tomcat fint
solrconfig.xml - Setter opp selve backend-biten av kjerna. Generelt sett en fil du rører lite rundt i med mindre ting går til helvete.
schema.xml - Beskriver dataene som skal lagres i kjerna, hvilke datatyper som er tilgjengelige (og innstillingene for dem), hvilke datatyper hvert felt har, hvorvidt feltet skal lagres eller bare indekseres, og annen metadata som angår datagrunnlaget.
Lar oss splitte opp data og prosessere data i en fornuftig form, helt automagisk etter hva vi har definert for et felt:
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="../../stopwords.txt"/>
<filter class="solr.WordDelimiterFilterFactory" .. splitOnCaseChange="1"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" language="Norwegian"/>
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
"Jeg skriver PHP som jeg skriver Java og ikke JavaScript" => "Jeg", "skriver", "PHP", "som", "jeg", "skriver", "Java", "og", "ikke", "JavaScript"
<filter class="solr.StopFilterFactory" ignoreCase="true" words="../../stopwords.txt"/>
"Jeg", "skriver", "PHP", "som", "jeg", "skriver", "Java" => "skriver", "PHP", "skriver", "Java", "JavaScript"
<filter class="solr.WordDelimiterFilterFactory" .. splitOnCaseChange="1"/>
"skriver", "PHP", "skriver", "Java", "JavaScript" => [..], "Java", "Script", "JavaScript"
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" language="Norwegian"/>
=> "skriv", "php", "skriv", "java", "java", "script", "javascript"
Gjør om flertalls- og bøyde former til ordstammer, slik at vi ikke lenger er avhengige av at folk skriver 'spillene' for å finne 'spill' og 'spillet'.
Søke på uttalelsen av ord i stedet for skrivemåten
Autocomplete, Suggestions, etc, der vi vil finne substrenger i ord
Mocking => Ubrukelig
Eksplisitt liste, eller bare ord innenfor en gitt lengde (f.eks. BARE fem bokstaver!)
Filtre og tokenizers er (forholdsvis) enkel kode - jeg har klart å skrive en!
Send data over i JSON eller XML, du angir selv hvilke update handlers du vil ha tilgjengelig i solrconfig.xml.
MySQL, PostgreSQL, etc. (Nesten) eneste krav er at det eksisterer en brukbar driver som DataImportHandler-en kan bruke.
(og flere andre måter, og du kan selvsagt også skrive din egen.. Det er imidlertid kanskje et tegn på at du har gjort noe veldig galt, og fortjener å straffes for det.)
feltnavn:<verdi> / <verdi> alene
+mats +lindh +solr
php java javascript
lang:en lang:no
lang:en AND name:Foo
name^8 language^4 allFields^2
(Bruk <copyFields> for å bygge catch-all/catch-some felt)
Gir deg alle verdier for et felt og antallet dokumenter som har den verdien i feltet
Gir deg teksten rundt der søket ditt faktisk matchet i en større tekst, slik at du kan vise den sammen med søkeresultatet.
Gi Solr en id til et dokument du har indeksert og hvilket felt du ønsker å sammenligne på, så gir Solr deg et antall dokument som kan klassifiseres som "Dette ligner" tilbake.
Ved å scanne indeksen for hvilke termer som faktisk finnes i dokumentene, gir Solr deg forslag tilbake på hva det kanskje var du egentlig forsøkte å skrive.
Støtter også repeatere, slik at du kan bygge et hierarki med noder for større installasjoner.
Kan settes opp når-som-helst, uten at du må gjøre masse knot med dataene som allerede eksisterer, eller finne ut at du trenger replikering før du setter i gang.
Hver server lagrer sin del av indeksen, og noden du sender forespørselen til (sammen med en liste over shards) henter informasjonen fra alle serverene, gjør scoring og returnerer et ferdig resultat til deg, den heldige utvikleren.
I stedet for manuell håndtering av shards, gjør SolrCloud hele jobben for deg, og lar deg angi hvor mange noder som et dokument i tillegg skal replikeres til. Bygd på replication + sharding med en passende mengde magi mellom, og fungerer overraskende bra til å være ny i Solr 4.0.
Tradisjonell "Finn nærmeste", skal også kunne brukes til å vekte avstand sammenlignet med andre faktorer i din egen scoring-modell.
Lar deg angi senterpunkt og deretter x antall meter i radius fra dette punktet.
Egner seg for å kunne gi søkeresultater svært raskt, men har større risiko for datatap (uten å nødvendigvis sende ting til disk, f.eks.).
Solr er uansett rask nok for de aller fleste applikasjoner, så dette er kun nyttig dersom du har et enormt oppdateringstempo - noe de færreste datasett har.
Bruker Apache Tika til å parse og hente ut data og metadata fra PDF-er, Word-dokumenter og andre properitære format.
Kan brukes for å finne igjen informasjon i dokumentsamlinger (en dokumentsøkemotor brukt til å finne igjen faktiske dokument!) på et intranett, eller for å gjøre noe fornuftig ut av alt det som folk legger ut.
Preprosessering rocks!
Krevende, men kan f.eks. gjøres på en dedikert server (via replikering) og så caches for oppslag.