Come implementare efficienti query di dati con microservizi eterogenei?

Question

Come implementare efficienti query di dati con microservizi eterogenei?

#1 da (2 voti)

5

Il nostro team ha un'idea di implementare un semplice DSL dichiarativo che consenta agli utenti di interrogare il modello di dominio dell'azienda tramite un'unica interfaccia senza preoccuparsi di quali microservizi specifici chiamare per ottenere parti specifiche dei dati e come collegarli e combinarli.

La sintassi suggerita è basata su SQL, ma:

È molto più limitato: nessun raggruppamento o aggregazione, nessuna subquery esplicita, nessuna funzione ecc.
I join non possono essere specificati e sono solo impliciti in base allo schema predefinito (entità e relazioni).

Esempio:

SELECT entityTypeOne.name, entityTypeTwo.value, entityTypeTwo.date
 WHERE entityTypeOne.name LIKE 'Sample%'
   AND entityTypeTwo.date BETWEEN (2015-05-01, 2015-05-31)

Risultato previsto:

╔════════╦═══════╦════════════╗
║  name  ║ value ║    date    ║
╠════════╬═══════╬════════════╣
║ London ║  1000 ║ 01/05/2015 ║
║ London ║  2000 ║ 02/05/2015 ║
║ London ║  3000 ║ 03/05/2015 ║
║ Moscow ║  2000 ║ 02/05/2015 ║
║ Moscow ║  9000 ║ 05/05/2015 ║
║ Tokyo  ║  1000 ║ 30/05/2015 ║
╚════════╩═══════╩════════════╝

Lo schema di relazione entità soggiacente sa che le entità sono correlate in questo modo: entityTypeOne.id = entityTypeTwo.parentId che crea un'unione implicita.

Il "motore di query" dovrebbe sapere che per prima cosa interrogherà il microservizio entityTypeTwo che applica il filtro dell'intervallo di date sul server, quindi il entityTypeOne che applica l' id filtro basato sul risultato della query precedente.

I problemi che vediamo attualmente:

Rappresenta lo schema delle relazioni oggettuali.
Capire l'ordine ottimale di interrogazione.
Denormalizzare i dati risultanti.

Mi chiedevo se questo è un problema noto e se ci sono degli algoritmi da controllare (forse qualcosa dalla teoria dei grafi)?

Questa è la cosa più vicina che ho trovato finora:

Che cos'è una query eterogenea?

Se semplifica le cose, possiamo supporre che i microservizi stiano rivelando dati via OData.

microservices query dsl graph distributed-computing

posta Den 07.05.2015 - 17:28

fonte

1 risposta

Leggi altre domande sui tag microservices query dsl graph distributed-computing

Progettazione OO in una pipeline di elaborazione dati UML: se uno scambio di messaggi di risposta alle richieste asincroni dovesse essere modellato come due porte / interfacce o uno

score 2 · Answer 1

Se quello che stai cercando di fare è presentare un singolo endpoint a molte API, potresti trovare qualche valore in Netflix " Falcor progetto.

Falcor non è un motore di query. È una libreria per "recupero dati efficiente". È un esempio di un crescente set di strumenti che fornisce " Demand Driven Architectures " - alternative al riposo tradizionale servizi che consentono all'autore di uno strumento client di specificare ciò che vogliono in termini relativi a un modello di dati canonico, ovviando quindi alla necessità di sviluppare interfacce utente (la domanda) in tandem con un back-end. Gli strumenti "fetch" traducono il modello canonico in chiamate a singoli servizi di assistenza e una combinazione di cache in-browser e proxy inverso rende le cose efficienti evitando chiamate successive ai servizi dati per gli stessi dati.

Per parafrasare l'autore principale di Falcor, Jafar Husein: immagina il tuo grafico di servizio non come un insieme di servizi discreti, ma come un unico enorme documento grafico JSON. Questo è ciò che gli utenti ritengono di dover fare delle richieste e Falcor gestisce la memorizzazione, il batching e il routing necessari che lo rendono efficiente.

È quasi come se questi strumenti portassero il comportamento della clausola SELECT e WHERE a una raccolta di API REST. E anche se non è esattamente come costruire un'API di query efficiente su REST, potrebbe offrire gli stessi vantaggi, senza dover inventare un efficiente processore di query, che potrebbe richiedere anni.