Le migliori pratiche di programmazione funzionale Scala o Clojure

Question

Le migliori pratiche di programmazione funzionale Scala o Clojure

#1 da (5 voti)
#2 da (5 voti)
#3 da (4 voti)

11

Ho fatto molti codici di autoapprendimento, ho avuto esperienza con i modelli di programmazione parallela: attori, memoria transazionale del software, flusso di dati.

Quando cerco di applicare queste architetture nella vita reale - in un'applicazione web ad alto carico - qualsiasi modello non supporta la durabilità e la persistenza dei dati. Le attività della vita reale richiedono di salvare i dati alla fine. Ciò significa che devo ancora usare DB e intrappolare le sincronizzazioni DB, possibili strozzature di scalabilità ecc.

Qualcuno conosce un buon esempio di architettura (src o testo o diagramma o blueprint) che usa Akka Actors o Software Transaction Memory e implementa la persistenza alla fine?

Qualsiasi buon esempio / idea per memoria transazionale, attori, flusso di dati, spazi di tupla nelle applicazioni della vita reale è il benvenuto.

functional-programming scala clojure

posta gnat 25.05.2012 - 23:54

fonte

3 risposte

Leggi altre domande sui tag functional-programming scala clojure

Bug che possono essere evitati con gli standard di codifica [chiuso] Esistono limitazioni di un'applicazione web HTML5 idealistica

score 5 · Answer 1

I modelli di attore / STM e la persistenza del database sono in qualche modo ortogonali - puoi facilmente averne uno senza l'altro, e penso che ci sia il rischio di confondere i due.

Raggiungere la durabilità (la D in ACID) è estremamente complessa in un ambiente transazionale, in particolare in un'impostazione distribuita in cui gli attori / processi sono coordinati dal passaggio dei messaggi. Hai problemi spinosi come il Problema dei generali bizantini .

Di conseguenza, penso che ci sarà sempre un certo grado di personalizzazione della soluzione per soddisfare i tuoi specifici requisiti di persistenza. Non ci sono soluzioni "taglia unica".

Vale la pena guardare (prospettiva Clojure):

score 5 · Answer 2

Il modello di attore funziona bene con Comando / Query Responsibility Segregation (CQRS) , come messaggi agli attori che eseguono i dati la manipolazione può essere usata come "Command" equivalenti.

Quindi, che cosa ha a che fare con il tuo problema di persistenza? Bene, si lavora sulla memoria e si scrivono tutti i comandi su un registro, un'operazione meno costosa in quanto è solo per le aggiunte, e di tanto in tanto si scaricano istantanee per ridurre il tempo necessario per ricaricare il database, se necessario (oltre a renderlo possibile recuperare lo spazio utilizzato dal registro).

Questa è una tecnica abbastanza comune. Guarda VoltDB e Redis per ulteriore ispirazione.

score 4 · Answer 3

Rich Hickey ha una creatura nuova di zecca chiamata Datomic. È un nuovo approccio alla persistenza, al disaccoppiamento dello storage, alla gestione delle transazioni e alle query. È basato su record immutabili e utilizza un linguaggio di query denominato Datalog (condivide le funzionalità con Prolog). L'obiettivo principale era consentire una facile distribuzione e l'implementazione del cloud. Si basa sullo storage come servizio (quindi non su un'implementazione concreta, ma accoppiato in modo lasco tramite un'API over-the-wire).

In Clojure abbiamo STM che ci dà ACI, il D mancante. Datomic aggiunge la D.