Práticas recomendadas de programação funcional Scala ou Clojure

11

Fiz muita codificação de auto-estudo, adquiri alguma experiência com modelos de programação paralela: atores, memória transacional de software e fluxo de dados.

Quando estou tentando aplicar essas arquiteturas à vida real - em aplicativos da Web de alta carga -, qualquer modelo não suporta durabilidade e persistência de dados. As tarefas da vida real exigem salvar dados no final. Isso significa que ainda preciso usar DB e capturar sincronizações de DB, possíveis gargalos de garrafa de escalabilidade etc.

Alguém conhece um bom exemplo de arquitetura (src ou texto ou diagrama ou planta) que usa os Akka Actors ou a Memória de transação de software e implementa a persistência no final?

Qualquer bom exemplo / idéia para espaços de memória transacional, atores, fluxo de dados e tupla em aplicações da vida real é bem-vindo.

scala clojure functional-programming

— mosquito
fonte

Você precisa de akka e stm?

— Om-nom-nom

Parece incomum que você considere a persistência "no final". Acredito que "capturar sincronizações de banco de dados, possíveis gargalos de escalabilidade etc." são um problema justamente porque estão no meio das coisas, e não no fim.

— Dan Burton

Concorde que a persistência acontece com mais frequência do que no final

@Stas Como a questão está relacionada com (1) Scala e Clojure, (2) melhores práticas? O que eu li é (1) independente de idioma e (2) relacionado apenas à simultaneidade (em particular Durabilidade / Persistência).

— Sakisk

5

Os modelos de ator / STM e a persistência do banco de dados são um tanto ortogonais - você pode facilmente ter um sem o outro, e acho que há o risco de confundir os dois.

Atingir a durabilidade (o D no ACID) é extremamente complexo em um ambiente transacional e, particularmente, em um ambiente distribuído onde você tem atores / processos sendo coordenados pela passagem de mensagens. Você se depara com questões difíceis, como o problema dos generais bizantinos .

Como resultado, acho que sempre haverá um certo grau de adaptação da solução para atender aos seus requisitos de persistência específicos. Não há soluções "tamanho único".

Vale a pena olhar (perspectiva de Clojure):

— Mikera
fonte

5

O modelo de ator funciona muito bem com a Segregação de responsabilidade de comando / consulta (CQRS) , pois as mensagens para atores que executam manipulação de dados podem ser usadas como equivalentes de "Comando".

Então, o que isso tem a ver com o seu problema de persistência? Bem, você trabalha com memória e grava todos os comandos em um log, o que é uma operação mais barata porque é apenas anexável e despeja instantâneos de tempos em tempos para reduzir o tempo necessário para recarregar o banco de dados, se necessário (além de possibilitar recuperar espaço usado pelo log).

Esta é uma técnica bastante comum. Veja o VoltDB e o Redis para obter mais inspiração.

— Daniel C. Sobral
fonte

4

Rich Hickey tem uma ideia nova chamada Datomic. É uma nova abordagem para persistência, dissociação de armazenamento, gerenciamento de transações e consultas. Ele é baseado em registros imutáveis e usa uma linguagem de consulta chamada Datalog (compartilha recursos com o Prolog). O objetivo principal era permitir fácil distribuição e implantação na nuvem. Ele se baseia no armazenamento como um serviço (portanto, não uma implementação concreta, mas acoplada livremente por meio de uma API sem fio).

Em Clojure, temos o STM, o que nos dá ACI, o D ausente. Datomic adiciona o D.

— Marko Topolnik
fonte