Condivisione ottimale del lavoro su sistemi scarsamente distribuiti

7

Che aspetto avrebbe un sistema come BOINC se fosse scritto oggi? Al momento dell'elaborazione di BOINC, i database erano la scelta principale per il mantenimento di uno stato condiviso e della concorrenza tra i nodi.

Da allora, sono stati sviluppati molti approcci per il tasking con concorrenza ottimistica (OT, primitive di sincronizzazione come clock vettoriali, sincronia virtuale, iteratori condivisi ecc.)

Esiste un paradigma per la distribuzione ottimistica di unità di lavoro su sistemi di distribuzione scarsamente distribuiti che comunicano attraverso il passaggio di messaggi?

Scusa se questo è un po 'vago.

P.S. Il concetto di Tuple-spaces è ottimo, ma il blocco è inerente alla sua definizione.

Edit2 :

L'intero sistema è scarsamente distribuito - possono comunicare solo tramite WAN. E la comunicazione può essere lenta e difettosa. La domanda riguarda come distribuire al meglio le unità di lavoro tra di loro senza un coordinatore centrale e con il minor consenso possibile (perché il consenso è costoso).

Le risposte qui sembrano parlare di database: i dati non sono il problema. Il problema è nella distribuzione del lavoro.

Modifica :

Ho già un sistema di federazione che funziona bene. Sto cercando di estenderlo per convincere i clienti a fare unità di lavoro.

    
posta Asti 15.01.2012 - 13:38
fonte

3 risposte

2

Quando sai che cosa il tuo sistema ha veramente bisogno è quando puoi scegliere la soluzione migliore. I più grandi sistemi di dati sono fatti per grandi quantità di dati, se il tuo sistema ha pochi dati (GB), allora una soluzione tipica si adatterà. È necessario pensare che i grandi sistemi di dati sparsi richiedano modelli di dati speciali molto diversi dai modelli di dati tipici di SQL.

I modelli di dati RDBMS non vedono l'ora di rappresentare uno stato coerente in ogni momento, i sistemi distribuiti no (vedi teorema CAP ).

    
risposta data 30.10.2012 - 22:29
fonte
0

La soluzione più semplice è solitamente la migliore. Non c'è niente di sbagliato in un server centrale che distribuisce il lavoro a un numero di lavoratori, purché sia possibile realizzare i lavori in modo tale da non sovraccaricare il sovraccarico. Non ha senso ridisegnare BOINC solo perché le mode sono cambiate.

    
risposta data 15.01.2012 - 14:21
fonte
0

Stai chiedendo se la programmazione è come l'industria dell'abbigliamento, quindi se non ridisegnerai il sistema ogni 2 settimane i tuoi amici rideranno di te perché hai perso la sincronia con la moda? :)

Se fosse stato scritto oggi, probabilmente il team di marketing avrebbe attaccato un grande banner "cloud", richiederebbe 20 nodi amazon per funzionare a una velocità decente e si romperebbe almeno 5 volte al giorno a causa dell'uso più recente e più grande "archiviazione nosql". Quindi dovresti affrontare problemi di scalabilità perché quei sistemi cloud di solito non scalano fuori dalla scatola come promettono, e dovresti essere costretto a ripensare il design.

Oggi è sicuramente un po 'diverso. Ad esempio, è possibile gestire lo stato utilizzando una soluzione nosql matura come memcached per la staging e quindi inserire i dati in SQL. Cosa c'è di sbagliato nel vecchio approccio se puoi ottenere un server con 64 GB di Ram e 24 core per qualcosa come $ 300- $ 500.

    
risposta data 16.01.2012 - 12:14
fonte

Leggi altre domande sui tag