Best practice per la programmazione funzionale Scala o Clojure

11

Ho fatto molta codifica di autoapprendimento, ho avuto qualche esperienza con i modelli di programmazione parallela: attori, memoria transazionale software, flusso di dati.

Quando sto provando ad applicare queste architetture alla 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 il salvataggio dei dati alla fine. Ciò significa che devo ancora utilizzare DB e intrappolare sincronizzazioni DB, possibili colli di bottiglia di scalabilità ecc.

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

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

scala clojure functional-programming

— moscerino
fonte

Ti servono sia akka che stm?

— om-nom-nom,

Sembra insolito che tu consideri la persistenza "alla fine". Credo che il "trapping di sincronizzazioni DB, possibili colli di bottiglia della scalabilità ecc." sono un problema proprio perché sono nel mezzo delle cose, piuttosto che alla fine.

— Dan Burton,

Concordo sul fatto che la persistenza si verifichi più spesso che alla fine

@Stas In che modo è correlata la domanda con (1) Scala and Clojure, (2) best practice? Quello che ho letto è (1) indipendente dalla lingua e (2) correlato solo alla concorrenza (in particolare Durabilità / Persistenza).

— sakisk,

5

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 esista il pericolo di confondere i due.

Il raggiungimento della durabilità (la D in ACID) è estremamente complesso in un contesto transazionale, in particolare in un contesto distribuito in cui attori / processi sono coordinati dal passaggio dei messaggi. Ti imbatti in problemi spinosi come il problema dei generali bizantini .

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

Vale la pena guardare (prospettiva Clojure):

— mikera
fonte

5

Il modello dell'attore funziona perfettamente con la Segregazione di responsabilità comando / query (CQRS) , poiché i messaggi agli attori che eseguono la manipolazione dei dati possono essere usati come equivalenti "Comando".

Quindi, cosa c'entra questo con il tuo problema di persistenza? Bene, lavori sulla memoria e scrivi tutti i comandi in un registro, che è un'operazione più economica perché è solo append, e scarica le istantanee di volta in volta per ridurre il tempo necessario per ricaricare il database se necessario (oltre a rendere possibile recuperare spazio utilizzato dal registro).

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

— Daniel C. Sobral
fonte

4

Rich Hickey ha un nuovissimo frutto chiamato Datomic. È un nuovo approccio alla persistenza, disaccoppiamento dell'archiviazione, gestione delle transazioni e query. Si basa su record immutabili e utilizza un linguaggio di query chiamato Datalog (condivide le funzionalità con Prolog). L'obiettivo principale era quello di consentire una facile distribuzione e distribuzione cloud. Si basa sull'archiviazione come servizio (quindi non un'implementazione concreta, ma liberamente associata a un'API over-the-wire).

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

— Marko Topolnik
fonte