Ja, du kan bruge SOLR som en database, men der er nogle virkelig alvorlige forbehold:
-
SOLRs mest almindelige adgangsmønster, som er over http, reagerer ikke særlig godt på batch-forespørgsler. Desuden streamer SOLR IKKE data --- så du kan ikke dovent iterere gennem millioner af poster ad gangen. Dette betyder, at du skal være meget betænksom, når du designer dataadgangsmønstre i stor skala med SOLR.
-
Selvom SOLR-ydeevnen skalerer horisontalt (flere maskiner, flere kerner osv..) såvel som vertikalt (mere RAM, bedre maskiner osv.), er dens forespørgselsmuligheder stærkt begrænset sammenlignet med en moden RDBMS . Når det er sagt, er der nogle fremragende funktioner, såsom feltstatistikforespørgsler, som er ret praktiske.
-
Udviklere, der er vant til at bruge relationelle databaser, vil ofte løbe ind i problemer, når de bruger de samme DAO-designmønstre i et SOLR-paradigme, på grund af den måde, SOLR bruger filtre i forespørgsler. Der vil være en læringskurve for at udvikle den rigtige tilgang til at bygge en applikation, der bruger SOLR til en del af dens store forespørgsler eller tilstandsfulde ændringer .
-
De "enterprisy"-værktøjer, der giver mulighed for avanceret sessionsstyring og statefull entiteter, som mange avancerede web-frameworks (Ruby, Hibernate, ...) tilbyder, skal smides helt ud af vinduet .
-
Relationelle databaser er beregnet til at håndtere komplekse data og relationer - og de er således ledsaget af state of the art metrikker og automatiserede analyseværktøjer. I SOLR har jeg fundet mig selv i at skrive sådanne værktøjer og manuelt stressteste en masse, hvilket kan være en tidsdræn .
-
Deltager:dette er den store morder. Relationelle databaser understøtter metoder til opbygning og optimering af visninger og forespørgsler, der forbinder tuples baseret på simple prædikater. I SOLR er der ingen robuste metoder til at samle data på tværs af indekser.
-
Robusthed:For høj tilgængelighed bruger SolrCloud et distribueret filsystem nedenunder (dvs. HCFS). Denne model er helt anderledes end en relationel database, som normalt gør modstandsdygtighed ved hjælp af slaver og mastere, eller RAID, og så videre. Så du skal være klar til at levere den robusthedsinfrastruktur, SOLR kræver, hvis du ønsker, at den skal være skyskalerbar og modstandsdygtig.
Når det er sagt - der er masser af åbenlyse fordele ved SOLR til visse opgaver:(se http://wiki. apache.org/solr/WhyUseSolr ) -- løse forespørgsler er meget nemmere at køre og giver meningsfulde resultater. Indeksering udføres som standard, så de fleste vilkårlige forespørgsler kører ret effektivt (i modsætning til et RDBMS, hvor du ofte skal optimere og denormalisere efter kendsgerningen).
Konklusion: Selvom du KAN bruge SOLR som et RDBMS, vil du måske opdage (som jeg har) at der i sidste ende er "ingen gratis frokost" - og omkostningsbesparelserne ved super-cool lucene tekst-søgninger og højtydende, in-memory indeksering, er ofte betalt af mindre fleksibilitet og vedtagelse af nye arbejdsgange for dataadgang.