WordPress-sökning i världsklass är inte mer reserverad för Fortune 500-företag med WPSOLR

Bryter din sökning din WordPress-webbplats?

Förmodligen, om din webbplats innehåller mer än några hundra inlägg eller produkter, eller om dina besökare behöver hitta resultat med noggrannhet.

WordPress-sökning med MySQL

Bild wpsolr-wordpress-search.png av Varför WPSOLR?

För att förstå hur WPSOLR kan integrera Apache Solr och WordPress-sökningen, låt oss först dyka lite i den dolda världen av WordPress-kärnfunktioner. Om du spenderar några ögonblick på att förstå följande dokumentation, kommer du att vara mycket mer beväpnad för att ställa in WPSOLR. Låt oss gå !

Här är de (förenklade) vanliga WordPress-arbetsflödesstegen, som också representeras i filmen ovan:

  • En sida laddas, till exempel genom att en användare klickar på en länk på din webbplats.
  • WordPress-kärnan extraherar sidadressen, med alla dess parametrar. Till exempel: /? S = röd + skor & post_type = produkt för en WooCommerce-sökning.
  • URL-parametrarna är vana vid bygg ett WP_Query-objekt, en WordPress-API på hög nivå för att bygga SQL-frågor.
  • WordPress producerar ett SQL-uttalande från WP_Query, och anropar databasen med rätt SQL-dialekt (MySQL, PostgreSQL, ...). Denna SQL är ofta komplex och slår samman resultat från flera SQL-tabeller (som produkter och attribut för att hämta färg och storlekar på skor).
  • WordPress-databasen kör SQL-uttalandetoch returnerar resultat som lagras i WP_Query-objektet. Lägg märke till att ibland endast resultaten Ids returneras, vilket kommer att leda till mer SQL-exekverade för att få andra resultatinformation.
  • WordPress kommer nu ladda en php-fil med namnet en mall. Mallen lagras i den aktuella aktiva temakatalogen. Vilken mall som laddas beror på standarden mallhierarki (ett sätt att länka webbadresser och mallfilsnamn), eller på temat eller plugins filter / åtgärder. Lägg märke till att det finns alla typer av sökmallar, från search.php, till kategorilister, tagglistor och många andra.
  • Mallen kommer nu slinga på resultaten av det globala WP_Query-objektet (loopen) och använd vad som helst för att presentera dem (css, javascript, html, ....).

vs

WordPress-sökning med WPSOLR

Bild wpsolr-wpsolr-search-non-ajax-principer-1.png av Varför WPSOLR?

Jämfört med standard WordPress-sökning, stegen som skiljer sig är:

  • WPSOLR ersätter WP_Query-objektet med sitt eget underklassobjekt WPSOLR_Query.
  • WPSOLR_Query extraherar parametrar från url, från WPSOLR PRO-tillägg, Eller från din egen filterkod.
  • WPSOLR bygger en Elasticsearch / Solr-fråga med Elastica php-bibliotek / Solarium php-bibliotek.
  • WPSOLR frågar Elasticsearch / Solr index för att få de dokument som passar frågan.
  • WPSOLR extraherar dokument-id: n.
  • WPSOLR hämtar inläggstyperna (inlägg, sida, produkt eller vilken posttyp) som helst från WordPress-databasen med ett enda SQL-uttalande.
  • WPSOLR “förbättrar” innehållet på inläggstyperna: geolokaliseringsavstånd, markerade nyckelord i utdraget, ...
  • WPSOLR lagrar inläggstypernas resultat

När temat sökmall laddas, beter sig det som vanligt, omedveten om att de inläggstyper det får från WordPress-standardslingan först kom från en Elasticsearch / Apache Solr-fråga.

 

 

Hur är WPSOLR snabbare då?

Du har antagligen märkt att nu två frågor utförs i stället för en i standardsökningen: en till Elasticsearch / Solr-indexet och en för att hämta inläggstyper från dokument-id: erna.

Ändå är det mycket snabbare, för så snart du får en betydande mängd inläggstyper i din databas (några tusentals, till många tusentals), Elasticsearch / Solr-frågan går otroligt snabbare än en WP_Query SQL-fulltextsökning.

Och den andra frågan för att hämta inläggstyper från id: erna är också mycket snabbt, som det frågar om tabellfält-id: er, som indexeras.

Det svåra jobbet, fulltextsökning, är utförd av Elasticsearch / Apache Solr, som har byggts just för det.

MySQL saknar ren fulltextsökning

MySQL kan hämta det tredje skåpet i den andra raden. Men det kan inte hämta effektivt skåpet som innehåller en fil med titeln "MySQL är inte så bra med texter".

MySQL är inte rätt verktyg

WordPress är helt byggt på MySQL. Både för att bygga sidor och hämta information i text.

Men MySQL är en relationsdatabas: den är byggd med det enda syftet att hämta data från en identifierare. 
Hämta till exempel inlägget med ID '345678' och alla dess relaterade bild-ID: n.

Att hämta data från dess textinnehåll kallas "fulltext" -sökning. Medan MySQL levereras med en fulltextsökningstillägg, byggdes den aldrig för det ändamålet.
Därför är sökningen i MySQL (och WordPress) långsam och felaktig.
Bild wpsolr-header-solr-elasticsearch-4.png av Varför WPSOLR?
Bild wpsolr-header-solr-elasticsearch-3.png av Varför WPSOLR?

Solr och Elasticsearch, gratis öppen källkod för fulltext, ledare för sökningen.
I anslutning till WordPress med WPSOLR kan de göra mirakel.

Solr eller Elasticsearch - mästare i fulltext

När det gäller extraordinär sökning nuförtiden stiger två mästare över de andra: Apache Solr och Elasticsearch.

Båda delar samma motor, "Lucene". 

Båda är byggda för hastighet och söknoggrannhet.

Båda är gratis och öppen källkod: du kan installera dem på din server gratis.

Båda kan ställas in med tusentals parametrar: språkligt på 50 språk, fasetter, synonymer, ordböcker, NLP. Och så vidare.

Men ännu viktigare, bot är sömlöst integrerat i WordPress, tack vare WPSOLR-plugin. 

Ingen annan plugin gör det: du kan söka med Elasticsearch på franska medan du söker på japanska med Solr.

 

Varför du inte kan använda ett rent plugin

Rena plugins kan förbättra din sökhastighet och noggrannhet, upp till en viss nivå.
Vi kan inte nämna andra:
- Relevanssi
- FacetWP
- SökWP
- AJAX Search Pro

Anledningen är att de fortfarande använder MySQL för att driva din sökning. Och som vi nämnde är sökning inte den bästa tillgången till MySQL. Den kommer att brytas så snart för mycket data söks eller för många besökare finns på din webbplats. Vilket är dåligt eftersom du vill ha fler besökare, nej?

Men också kan de helt enkelt inte tävla när det gäller funktioner och hastighet med Elasticsearch eller Solr. Dessa 2 är vilda djur, byggda av 500K kodrader, av hundratals utvecklare. Och bara för ett syfte: att tillhandahålla det bästa sökverktyget i världen.

Så istället för att uppfinna hjulet på nytt valde WPSOLR att använda Elasticsearch och Solr.

Du får det bästa av det bästa, men med en enkel touch. Du behöver inte vara expert på sökning.

Och kom ihåg att vi är där för att konfigurera din sökning med din rättegång. Gratis!

Bild dave-NGea7mBq8Ak-unsplash-scaled.jpg av Varför WPSOLR?

WPSOLR valde att integrera med det bästa av den bästa sökteknologin. Snarare än att återuppfinna hjulet.

Starkare och billigare än du kan förvänta dig

Det är ganska enkelt att vara snabb, på en mycket dyr server med bara ett fåtal dokument eller några få samtidiga besökare

Men tänk om du har tusentals, eller hundratusentals dokument eller WooCommerce-produkter som några av våra kunder?



Och vad händer om du på Black Friday plötsligt får hundratals samtidiga besökare, men din sökning bryter ner din server?



Och vad händer om du ännu inte har verksamheten att spendera tusentals varje månad på dyra dedicerad hårdvara eller värdtjänster?

Med WPSOLR, inga bekymmer!

  • Vissa kunder lever lyckligt med hundratusentals produkter, inlägg eller ämnen.
  • Vissa kunder har hundratals besökare varje dag utan att bromsa lite.
  • WPSOLR kräver billig hårdvara och inte kostsamt abonnemang på begäran.
Bild damir-spanic-22L7do1cOho-unsplash-scaled.jpg av Varför WPSOLR?

WPSOLR kan söka i stora mängder dokument, med ett stort antal besökare, på en billig hårdvara, efter ett litet fast abonnemang. Vad är bäst?

en English
X