Replica Elasticsearch di altri dati di sistema?

Supponiamo che io voglia usare elasticsearch per implementare una ricerca generica su un sito web. Ci si aspetta che la barra di ricerca in alto trovi risorse di tutti i tipi diversi attraverso il sito. Documenti di sicuro (caricati / indicizzati tramite tika) ma anche cose come clienti, account, altre persone, ecc.

Per ragioni architettoniche, la maggior parte delle cose non documentali (clienti, account) saranno presenti in un database relazionale.

Quando si implementa questa ricerca, l’opzione # 1 sarebbe quella di creare versioni di documenti di tutto, e quindi usare semplicemente elasticsearch per eseguire tutti gli aspetti della ricerca, non basandosi affatto sul database relazionale per trovare diversi tipi di oggetti.

L’opzione n. 2 sarebbe quella di utilizzare elasticsearch solo per l’indicizzazione dei documenti, il che significherebbe per una funzione generale di “ricerca del sito”, si dovranno generare più ricerche su più sistemi, quindi aggregare i risultati prima di restituirli.

L’opzione n. 1 sembra di gran lunga superiore, ma il lato negativo è che richiede che la ricerca elastica abbia in pratica una copia di moltissime cose nel database relazionale di produzione, oltre al fatto che tali copie siano mantenute fresche man mano che le cose cambiano.

Qual è l’opzione migliore per mantenere sincronizzati questi negozi e ho ragione nel ritenere che per la ricerca generale l’opzione n. 1 sia superiore? C’è un’opzione # 3?

    Hai praticamente elencato le due opzioni principali che ci sono quando si tratta di cercare tra più archivi di dati, cioè cercare in un archivio dati centrale (opzione # 1) o cercare in tutti gli archivi di dati e aggregare i risultati (opzione # 2).

    Entrambe le opzioni funzionerebbero, anche se l’opzione # 2 ha due svantaggi principali:

    1. Richiederà una notevole quantità di logica da sviluppare nell’applicazione per “estendere” le ricerche ai vari archivi di dati e aggregare i risultati ottenuti.
    2. I tempi di risposta potrebbero essere diversi per ogni data store e, quindi, dovrai aspettare che l’archivio dati più lento risponda per presentare i risultati della ricerca all’utente (a meno che non lo elimini utilizzando diverse tecnologie asincrone, come Ajax , websocket, ecc.)

    Se si desidera fornire un’esperienza di ricerca migliore e più affidabile, l’opzione n. 1 otterrebbe chiaramente il mio voto (in questo modo prendo la maggior parte del tempo in realtà). Come hai giustamente affermato, il principale “svantaggio” di questa opzione è che è necessario mantenere Elasticsearch in sincrono con le modifiche negli altri archivi di dati master.

    Poiché i tuoi altri archivi di dati saranno database relazionali, hai alcune opzioni diverse per tenerli sincronizzati con Elasticsearch, vale a dire:

    • utilizzando l’ ingresso JDBC di Logstash
    • utilizzando lo strumento di importazione JDBC

    Queste prime due opzioni funzionano alla grande ma hanno uno svantaggio principale, ovvero non catturano DELETE sul tuo tavolo, ma catturano solo INSERT e UPDATE. Ciò significa che se elimini un utente, un account, ecc., Non sarai in grado di sapere che devi eliminare il documento corrispondente in Elasticsearch. A meno che, naturalmente, non decida di eliminare l’indice Elasticsearch prima di ogni sessione di importazione.

    Per alleggerirlo, puoi usare un altro strumento che si basa sul binlog MySQL e sarà quindi in grado di catturare ogni evento. Ce n’è uno scritto in Go , uno in Java e uno in Python .