Disaccoppia complesso di query di servizio da archivio dati

2

Abbiamo un servizio di ricerca molto ampio (scritto in golang se è importante) che funziona su ElasticSearch, riceve richieste, costruisce la query corrispondente e restituisce i risultati (con qualche post-elaborazione). Il servizio gestisce migliaia di richieste al secondo e dovrebbe essere in grado di servire le richieste in modo rapido ed efficiente.

Poiché il servizio si limita a leggere dal database (le scritture vengono gestite all'esterno del servizio, asincrono) e crea query molto complesse che variano tra utenti, richieste e test AB eseguiti in produzione, la maggior parte del codice nel servizio è codice responsabile della creazione della query.

Attualmente, la query ElasticSearch viene costruita combinando la logica aziendale (test AB in esecuzione in produzione, classificazione dell'utente, ecc.). Nella classica applicazione OO con database relazionali probabilmente utilizzerei un DAL, la riceve una richiesta e sa come analizzarla su SQL, quindi converte il valore restituito in qualcosa che il BL sa come gestire.

Costruire un tale meccanismo (un'astrazione della nostra query, una lingua intermedia tra la nostra query sulla lingua del dominio e il linguaggio di query ES) sembra un sovraccarico. Poiché tutto il nostro servizio è realmente accoppiato a ElasticSearch, prende in considerazione molte funzionalità ES al fine di aumentare le prestazioni, sembra che semplicemente costruiremo i nostri oggetti che sono oggetti ES replicati e quindi faremo il mapping.

D'altra parte, pensiamo alla possibilità di voler sostituire il pacchetto con l'interrogazione di ES, o vorremmo aggiornare la versione di ES e passerà attraverso cambiamenti bruschi, e dovremo cambiare molto di codice, sparsi per l'intero servizio e non centralizzati.

Qualunque consiglio o aiuto sarebbe apprezzato. Grazie.

    
posta DotnetProg 15.01.2018 - 14:18
fonte

1 risposta

1

Inoltre non penso che sia necessario disaccoppiare i due se la tua unica preoccupazione è che ElasticSearch stia aggiornando l'interfaccia. Se hai un layer disaccoppiato allora dovrebbe essere più o meno lo stesso sforzo per cambiare il codice nel livello intermedio o nel codice accoppiato.

Un motivo per disaccoppiare il codice sarebbe che vuoi collegare il tuo BL a un nuovo sistema di underlaying come (SolR, SQL, ...), allora avresti solo bisogno di adattare il livello.

In alternativa, potresti anche cercare un connettore ElasticSearch esistente. Ci sono connettori che potrebbero adattarsi al tuo BL. Ad esempio, potresti utilizzare un connettore SQL se il tuo livello aziendale è già scritto in SQL.

    
risposta data 18.01.2018 - 14:31
fonte

Leggi altre domande sui tag