Cerca API vs. Apache Solr Search

Ho usato il modulo Apache Solr Search in Drupal 6 e sto cercando l' API di ricerca per un'installazione di Drupal 7. Ho visto alcune discussioni qui, ma sto cercando qualsiasi motivo per scegliere l'uno o l'altro.

C'è un motivo per scegliere l'uno rispetto all'altro? Se è così, perché o perché no? Ho sentito che potrebbero esserci problemi di complessità e / o problemi di prestazioni con l'API di ricerca. È vero?

— hross
fonte

Non consiglierei solr per la ricerca multilingue. Dipende da quanto sia importante la ricerca multilingue. La ricerca può richiedere molto tempo. L'installazione può essere dolorosa. Per la ricerca multilingue la tua lingua deve essere supportata da solr. Ci sono regole grammaticali che devono essere impostate per la tua lingua. Inoltre hai bisogno di Java e Solr installati in modo da non poter utilizzare l'hosting condiviso economico. Se stai sviluppando un motore di ricerca, potresti usarlo. Se stai calcolando le risorse di sviluppo, la ricerca del sito Google Payd potrebbe essere un'opzione migliore! Sono anche co-manutentore di gss modulep

— ram4nd

Perché? Qualche benchmark?

— giorgio79,

Ou mi dispiace, penso che l'installazione possa essere dolorosa. Per la ricerca multilingue la tua lingua deve essere supportata da solr. Ci sono regole grammaticali che devono essere impostate per la tua lingua. Inoltre, quando ho esaminato i moduli, erano in stato di sviluppo e avevo bisogno di più lavoro per far funzionare le cose. Ma è il motore di ricerca più veloce. Quindi devi chiederti, quanto è importante la funzione di ricerca per te. Inoltre hai bisogno di Java e Solr installati in modo da non poter utilizzare l'hosting condiviso economico.

— ram4nd

Una delle cose che dovevo trovare in Apache Solr rispetto all'API di ricerca era la ricerca di filtri a selezione multipla. Con l'API di ricerca sembrava impossibile. Solr sembrava avere questa opzione.

— user219492

Vorrei menzionare il supporto multi-sito: SearchAPI non ha supporto multi-sito (utilizzando lo stesso indice SOLR per archiviare contenuti di più siti). Apachesolr, invece, consente di: 1. indicizzare più contenuti contenuti nello stesso indice SOLR 2. filtrare i risultati per un determinato sito 3. eseguire una ricerca solo sul sito locale filtrando i risultati di altri siti

— thePanz

Risposte:

A partire dal 2015, possiamo confrontare i moduli di ricerca API vs Apache Solr Search con i numeri:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

che indica la scelta chiara. L'API di ricerca è stata sviluppata 3 anni dopo ed è riuscita a sfruttare il suo concorrente.

Inoltre, l'API di ricerca fornisce un'architettura molto diversa e più flessibile e viene mantenuta più attivamente. Ciò che è più importante, ha già il supporto per il nuovissimo Drupal 8 e Solr 5.x che Apachesolr non ha ancora.

L'API di ricerca è stata aggiornata ed è più flessibile nella sua configurazione, incluso il supporto Views (per Apachesolr è necessario il modulo aggiuntivo). Ci sono anche molti moduli che ne estendono la funzionalità.

In secondo luogo, per evitare che alcuni problemi della comunità vengano risolti due volte a causa delle differenze nell'architettura di questi moduli, attualmente ci sono alcuni sforzi combinati tra questi due progetti come:

creando il modo comune per mostrare i blocchi di facet tramite l' API di facet (noto anche come filtri),
uno schema comune e file di configurazione solrconfig.xml,
entrambi i manutentori hanno lavorato insieme e migrato le classi di connessione dal modulo Apache Solr Search nell'API di ricerca.

^{Fonte: Battleplan for Search & Solr in Drupal 8 ad Acquia}

Nota, non è consigliabile utilizzare entrambi i moduli nello stesso ambiente.

Per ulteriori analisi tecniche delle differenze, consultare i dettagli di seguito.

API di ricerca

Panoramica API:

Framework per creare facilmente ricerche
Estratti da origini dati e implementazioni back-end
Grande ecosistema con estensioni, ad esempio backend
Integrazione API facet
Fortemente basato sull'API Entity
- Fornisce metadati
- Utilizzato per configurazioni di indice e server

Funzioni di estensione:

Completamento automatico dell'API di ricerca
allegati
Ricerche salvate
Posizione
Sentieri sfaccettati
Dispositivo di scorrimento (intervalli API di ricerca)
e molti altri.

Struttura basilare:

Struttura di base del modulo di ricerca API Solr

Caratteristiche dell'indice:

Origini dati diverse
Un'origine dati: entità
Basato sull'API Entity:
- Ogni proprietà può essere indicizzata
- Le proprietà delle entità correlate possono essere indicizzate

Come configurare il tuo indice - campi:

Come configurare il tuo indice - campi in Ricerca API Solr

Cerca nelle API API:

Supporto per visualizzazioni complete
Visualizza qualsiasi proprietà di un'entità
Utilizzare qualsiasi campo indicizzato come filtro, argomento o ordinamento
La maggior parte del codice si basa sull'integrazione delle visualizzazioni dell'API di entità
Per impostazione predefinita: dati recuperati tramite carico entità
- Può essere bypassato (impostazione "Recupera dati da Solr" nel server)
Alternativa: cerca nelle pagine API

Cerca ricette API:

Ganci CRUD per indici e server
Ganci per l'aggiunta
- Origine dei dati
- backend
- alterazioni dei dati
- processori
Amo sparato durante l'indicizzazione degli oggetti
Hook sparato durante l'esecuzione di una ricerca

Apachesolr

Funzioni di estensione:

Allegati (nessun supporto multimediale, codifica personalizzata per allegati ad altre entità)
Posizione (Apachesolr geo, posizione di Apachesolr)

Ricette Apachesolr:

Piattaforma di ricerca aziendale open source
Fondazione Apache
Ricerca full-text, evidenziazione, ricerca sfaccettata, clustering, gestione avanzata dei documenti
distribuito
Replica / scalabile
Giava
REST HTTP e risposte in XML / JSON e alcuni altri
Non relazionale

Fonte: API di ricerca e presentazione di Apachesolr

Guarda anche:

— kenorb
fonte

Fantastico scrivere, grazie! Domanda 1: perché si consiglia di non utilizzare entrambi i moduli nello stesso ambiente? Domanda 2: Le differenze di prestazioni tra i moduli sono trascurabili a questo punto (capisco che l'API di ricerca con Solr ora può indicizzare più campi, quindi il carico dell'entità non è più necessario per visualizzare ad esempio l'immagine in miniatura con i risultati della ricerca)?

— Jordan Magnuson,

@JordanMagnuson 1. Non usi entrambi i moduli allo stesso tempo, perché non sono molto compatibili e la maggior parte dei siti Web ha a che fare solo con un'istanza di ricerca Solr, quindi non ha senso usare entrambi, a meno che tu non non importa duplicare il lavoro. Ad esempio, quando è necessario creare una vista di ricerca, entrambi i moduli offrono un'integrazione separata con il modulo viste, quindi è necessario creare due viste.

— Kenorb,

@JordanMagnuson 2. Non sono sicuro delle prestazioni, non ne ho mai avuto uno specifico e probabilmente cambia ogni versione (stavo usando Apachesolr molto tempo fa). Se stai usando viste e sfaccettature, di solito usi il meccanismo della cache delle viste, quindi non ti preoccupi molto del tempo di elaborazione e ovviamente memcached, APC / XCache, ecc. Le prestazioni dipendono davvero dalla struttura del sito e da come i moduli interagiscono ciascuno altro.

— Kenorb,

Divertente che l'API di ricerca sia più utilizzata, tuttavia Acquia stessa consiglia di utilizzare il modulo Apache Solr docs.acquia.com/acquia-search/search-api#animated

— AlxVallejo

@AlxVallejo Penso che lo raccomandino per la produzione, perché hanno file di configurazione Apachesolr stabili e ben scritti per supportare le loro istanze Solia Acquia Cloud (condivisa) (questa è l'unica ragione immagino) e dato che l'API di ricerca era attivamente nello stato di sviluppo, quindi il rischio coinvolto includeva che i file di configurazione dovevano essere aggiornati più spesso. Lo hanno consigliato anche al nostro (grande) progetto, ma dopo un breve periodo di gioco e controllo dei nostri requisiti, abbiamo cambiato la loro raccomandazione in API di ricerca. Non avevano file di configurazione stabili, tuttavia ne abbiamo fornito uno nostro.

— Kenorb,

Ho provato a usare entrambi e posso dire questo: dipende dalla tua situazione.

Attualmente, la versione stabile 7 del modulo di integrazione ApacheSolr può solo indicizzare i nodi. Pertanto, se si dispone di entità non nodi che è necessario indicizzare, è necessario utilizzare la patch multientity ancora in corso . L'integrazione di ApacheSolr può memorizzare molti dati diversi di contenuto se configurato correttamente.

L'API di ricerca indica le entità e ha scritto molte cose meravigliose. Tuttavia, l'API di ricerca recupera solo l'ID dei dati che stai cercando. Questo significa che caricare più dati diversi dall'ID richiederà un entity_load, colpendo il tuo database o qualunque livello di cache tu abbia messo in atto. Per i siti pesanti di ricerca, questa potrebbe non essere la soluzione più ottimizzata.

Ecco una grande presentazione fatta a drupalcon Chicago sul modulo di integrazione di ApacheSolr, minuto 16 per le menzioni all'API di ricerca.

— LSU_JBob
fonte

panoramica eccezionale. esattamente quello che volevo sapere. Grazie!

— dal

Se questo ha risposto correttamente alla tua domanda puoi per favore contrassegnarla come risposta? Grazie!

— LSU_JBob,

Per quelli che si chiedono, la multientità è ora nel ramo dev dell'integrazione di Apache Solr, quindi dovrebbe uscire con la prossima beta.

— LSU_JBob,

Per coloro che leggono questo thread. Un fattore attenuante delle prestazioni è l'API di ricerca che consente ora l'indicizzazione e il recupero dei dati del nodo. C'è una discussione sulle prestazioni qui .

— hross

Questa risposta non è aggiornata, dai un'occhiata a drupal.org/node/1999392 search_api_solr ora ha opzioni multisito, inoltre consente di restituire non solo il NID. Una forte crescita della base di installazione di search_api_solr nel 2014 ha superato l'utilizzo D7 di apachesolr.

— Duncanmoo,

Penso che devi davvero provare entrambi e prendere una decisione informata. Ma considera fortemente che apachesolr non ha ancora una beta per Drupal 8.

Nell'API di ricerca non è possibile combinare entità sullo stesso indice SearchAPI. Quindi profili, utenti, nodi si trovano su indici diversi. C'è un modulo per consentire ricerche multiindex, non ha soddisfatto le mie esigenze, ma YMMV. Se hai molti tipi di contenuto e molti campi sullo stesso indice, la definizione dell'indice può diventare piuttosto ingombrante. (NB SearchAPI D8 riporta per supportare la ricerca multiindice)

Apachesolr consente la modifica dei campi in base al contenuto, il che può essere più semplice, ma non ha la possibilità di aggiungere contenuti correlati a un documento, infatti si aspetta di dover scrivere un codice personalizzato per includere informazioni da raccolte di campi, riferimenti e altri campi. Apachesolr D7 non supporta ajax, a meno che tu non usi le viste, ma usando le viste perdi sfaccettature. Detto questo ... modificare le informazioni memorizzate nell'indice è abbastanza semplice se sei contento di programmare gli hook.

L'idea di cercare gli ID entità e quindi renderizzarli singolarmente (può essere utilizzato da entrambi i moduli) sembrerebbe un incubo di prestazioni, ma, se si memorizza nella cache l'entità viene visualizzata, potrebbe essere più efficiente del rendering dalla risposta solr.

— DMCG
fonte