Come funziona CCR & amp; Il modello DSS toolkit è comparabile con altri elementi di scalabilità e amp; approcci di coerenza?

Question

Sono interessato al confronto tra vari approcci alla scalabilità e amp; concorrenza incluso CCR e amp; Modello di framework DSS. Sarei particolarmente interessato al confronto con la concordanza di stile Hadoop ed Erlang

Answer 1

Ho esaminato CCR, DSS ed Erlang, sebbene di questi, ho spedito solo CCR in un codice di produzione significativo. Non ho mai visto Hadoop.

La concorrenza di Erlang deriva dalla sua implementazione del modello di attore. Ogni 'processo' ha una cassetta postale e recupera i messaggi da essa, uno alla volta. Un processo senza messaggi per gestire i blocchi senza thread. Al contrario, i processi con lavoro da svolgere sono programmati su tutta la CPU disponibile senza nessuno dei macchinari sottostanti esposti. Inoltre, i processi comunicano tramite il passaggio di messaggi con la clonazione / l'immutabilità garantendo che P1 e P2 non condividano mai logicamente i messaggi che passano tra di loro.

La mia sensazione è che sia la natura non bloccante dell'invio e della ricezione di messaggi che conferisce a Erlang la sua reputazione di scalabilità su una singola macchina (possibilmente multi-core). In sostanza, i processi con lavoro da svolgere sono programmati in modo efficiente tra le risorse disponibili e i processi in sospensione consumano nient'altro che memoria. Elaborando un messaggio alla volta, ognuno dei quali garantisce la stabilità del messaggio, lo sviluppatore non deve più preoccuparsi di cose come "condizioni di gara".

CCR è un set di primitive di passaggio di messaggi asincroni di basso livello. Uno dei più semplici è Ricevi che riceve una ricezione alla Erlang. Ma ci sono primitive più sofisticate, come Join (ricevi un messaggio da tutti i canali) e Choice (ricevi un messaggio da uno di alcuni canali), che possono essere nidificati e composti in modi interessanti. Questi primitivi sono anche non bloccanti. I ricevitori generano attività (per gestire i messaggi) in 1..n code di attività, che sono servite da un numero limitato di thread.

La mia ipotesi è che, ignorando le (importanti!) differenze di piattaforma, le routine di pianificazione dei compiti di base di ciascuna di esse siano sostanzialmente nello stesso parco. Tuttavia, Erlang è un linguaggio e una piattaforma con un modello fisso (attore) integrato. Il CCR non è una di queste cose, è solo una libreria e puoi usarlo / abusarlo più liberamente.

DSS è un modello di programmazione basato sul CCR. Dispone di servizi (Erlang = processi), impone il passaggio di messaggi asincroni (con la clonazione completa per impostazione predefinita) come unica forma di comunicazione tra servizi e l'unica gestione che il mondo esterno ha a un servizio è il suo URI (Erlang = PID) . Come Erlang, non vi è sostanzialmente alcuna differenza tra invocare un servizio locale e uno remoto, sebbene (de) serializzazione avvenga in quest'ultimo caso.

DSS ha anche un modello RESTful, il che significa che i servizi in genere espongono un insieme di operazioni fisso e comune e che lo stato del servizio deve essere considerato una risorsa manipolata da queste operazioni. In contrasto con Erlang, dove messaggi arbitrari possono essere inviati a un processo. I servizi DSS possono utilizzare l'intero set di primitive CCR per parlare con altri servizi, il che può essere molto utile per cose come le operazioni di raccolta di dispersioni distribuite.

In definitiva, DSS è solo un framework con librerie di supporto, non un linguaggio o una VM, quindi c'è molta più "cerimonia" coinvolta nella scrittura anche di un singolo servizio DSS invece di scrivere un processo Erlang.

In termini di concorrenza, tutti forniscono le primitive necessarie per scrivere codice sicuro ed efficiente in più thread di esecuzione, senza preoccuparsi di quei thread di esecuzione. Penso che sia dove la maggior parte degli sviluppatori vuole andare.

In termini di scalabilità, è più difficile rispondere in quanto riguarda tanto la progettazione del sistema quanto gli strumenti utilizzati. Intendi la scalabilità su un singolo nodo, ovvero quando aggiungi i core o quando aggiungi i nodi? Il CCR non ha nulla da dire su quest'ultimo. Sia DSS che Erlang supportano formati binari abbastanza efficienti per la trasmissione via cavo. DSS eredita la sua visione del mondo orientata alle risorse direttamente da http, il che dovrebbe dirti qualcosa sulla sua potenziale scalabilità, ma lo fa con alcune restrizioni nel modello di programmazione.

Un paio di punti tecnici. Un singolo servizio DSS consuma più memoria (~ 2K) di un singolo processo erlang (300-400 byte). Inoltre, ogni servizio DSS ottiene la propria coda di attività e c'è un limite superiore (~ 10000) sul numero di code di attività che possono essere elaborate in modo efficiente dal CCR. Non ho numeri su tali limiti superiori per Erlang ma sospetto che potrebbe essere superiore a questo.

Detto questo, se sei sulla piattaforma .NET ti faresti un favore dando un'occhiata seria al CCR. L'ho trovato molto potente, soprattutto per i programmi reattivi basati sugli eventi.