L'obiettivo è fornire un sistema scalabile che implementa più attività di elaborazione dati che possono essere viste come un grafico. Gli oggetti dati viaggeranno quel grafico. La maggior parte degli oggetti visiterà gli stessi nodi nello stesso ordine, ma a seconda delle proprietà dell'oggetto dati, l'ordine e l'insieme di tak di elaborazione inclusi possono variare.
Supponiamo che ogni menzione di node significhi una macchina fisica dedicata e una client sia una piccola porzione di codice in esecuzione su un nodo responsabile del recupero, della distribuzione alle attività di elaborazione e dell'invio dei dati.
Ho trovato due principi di progettazione:
1) un singolo tak (un singolo tipo da precedere, per le massime prestazioni vogliamo quante più istanze di questa attività possibile). Questo ci dà un buon potenziale di ottimizzazione. Più thread della stessa attività possono condividere strutture di dati comuni. Questa non è solo una possibilità teorica. Alcuni dei nostri algoritmi di elaborazione costruiscono strutture di dati condivise di dimensioni multiple di GB. Lo svantaggio che vedo con questo approccio è che (per l'interpretazione più pura di questo progetto) abbiamo bisogno di una macchina fisica dedicata per ogni singola attività che includiamo nella nostra catena di elaborazione. In pratica, possiamo solo eseguire più client su una singola macchina e lasciare che ogni cliente gestisca il proprio compito. Nelle distribuzioni più estese, in cui vengono utilizzati più nodi, questo approccio alla progettazione sottolinea molto la rete, poiché un singolo oggetto di dati deve visitare ogni nodo almeno una volta.
2) Invece di avere una singola attività per cliente, ogni client implementa tutte le attività. Vantaggio: quando un client riceve un oggetto dati, può essere elaborato completamente senza dover passare ad altri nodi poiché tutte le attività di elaborazione vengono eseguite sullo stesso nodo. Suppongo anche che questa soluzione si riduca leggermente, perché non dobbiamo tenere conto dei diversi consumi di risorse delle singole attività. L'intera catena di compiti su un singolo nodo richiede sempre la stessa somma di potenza e tempo di calcolo, mentre il progetto 1) può forse eseguire 20 thread di un'attività leggera su un nodo ma solo 10 fili su un'attività pesante su un altro nodo. Lo svantaggio è che non esiste alcuna condivisione di risorse tra più istanze della stessa attività, quindi il consumo complessivo di risorse sarà più elevato.
3) Ho detto che c'erano solo due approcci progettuali, ma come sempre in informatica, c'è una via di mezzo. Possiamo raggruppare insieme un piccolo numero di attività ed eseguirle sullo stesso nodo, disponendo di più istanze con risorse condivise di ciascuna attività ma non di quante ne consente il progetto 1.
La metrica che vogliamo ottimizzare la progettazione è la velocità effettiva, il numero di oggetti dati elaborati in un determinato periodo di tempo. La latenza è assolutamente irrilevante. Abbiamo le risorse per un buon numero di nodi e reti ad alta velocità, tuttavia, riducendo al minimo il consumo di risorse (e una risorsa qui è tutto: numero di nodi, velocità della rete, memoria e CPU dei nodi, ...) è il nostro secondario obbiettivo. Il caso migliore: possiamo progettare il sistema in modo tale da poter mettere a punto le massime prestazioni e il consumo di risorse per ogni singola implementazione)
Dovrei aggiungere ulteriori informazioni su come vengono effettivamente implementate le attività: l'obiettivo a lungo termine è quello di fornire attività come librerie condivise che implementano un'interfaccia comune. Tuttavia ad oggi, è molto più brutto. Ci sono ancora molte attività implementate in tutti i modi (applicazioni Java, script Python / Shell, attività che devono essere eseguite su hardware dedicato e accessibili tramite REST, ...). Questo rende la condivisione delle risorse molto più complicata e talvolta impossibile, quindi forse dovrebbe essere ponderata in modo diverso.
Mi piacerebbe sentire il tuo feedback su questi approcci progettuali e quale potrebbe essere una soluzione ottimale. O forse hai qualche idea su ciò che mi mancava e su quali fattori dovrei considerare in aggiunta quando pianifico questo sistema distribuito.