Il miglior sistema di cache in-erlang cross network nodes = mnesia?

Question

Mattino tutti

Sono nuovo di casa, ma sto cercando di progettare il mio primo progetto su erlang per essere il migliore che posso. Qui ho bisogno di qualche suggerimento per il sistema di cache in-memory di erlang.

1. La voce della cache è di stoccaggio di valori-chiave based. La chiave è in genere una stringa ASCII; valore è tipi di erlang includono numero/elenco/tupla/ecc.
2. L'elemento della cache può essere impostato da qualsiasi nodo.
3. L'elemento della cache può essere recuperato da qualsiasi nodo.
4. L'elemento della cache è condiviso tra tutti i nodi anche su server diversi
5. dirty-read è consentito, non voglio alcun blocco o transazione per ridurre le prestazioni.
6. Totalmente distribuito, nessuna macchina o servizio centralizzato.
7. Buona prestazione
8. Facile installare & distribuzione & configurazione & manutenzione

Prima scelta mi sembra è mnesia, ma non ho experence su di esso. soddisfa i miei requisiti? Come posso aspettarmi la prestazione?

Un'altra opzione è memcached - Ma temo che le prestazioni siano inferiori a mnesia perché serializzazione/deserializzazione extra vengono eseguite come daemon memcached da un altro processo del sistema operativo.

Qualsiasi suggerimento è di aiuto :)

Answer 1

Sì. Mnesia soddisfa le tue esigenze. Tuttavia, come hai detto tu, uno strumento è buono quando chi lo usa lo capisce in profondità. Abbiamo utilizzato mnesia su un distributed authentication system e finora non abbiamo riscontrato alcun problema. Quando mnesia viene usato come cache, è meglio che memcached, per una ragione "Memcached non può garantire che ciò che scrivi, puoi leggere in qualsiasi momento, a causa di problemi di memoria e cose" (seguire here).

Tuttavia, ciò significa che il sistema distribuito verrà costruito su Erlang. Infatti mnesia nel tuo caso batte la maggior parte delle soluzioni cache NoSQL perché i loro sistemi sono Eventually consistent. Mnesia è coerente, purché la disponibilità della rete possa essere garantita attraverso il cluster. Per un sistema di cache distribuita, non si desidera una situazione in cui si leggano valori diversi per la stessa chiave da nodi diversi, quindi la coerenza di mnesia è utile qui.

Qualcosa a cui dovresti pensare, è che è possibile avere una cache di memoria centralizzata per un sistema distribuito. Funziona in questo modo: il server RABBITMQ è in esecuzione e accessibile dai client AMQP su ciascun nodo del cluster. I sistemi interagiscono tramite l'interfaccia AMQP. Poiché la cache è centralizzata, la coerenza è garantita dal processo/sistema responsabile della scrittura e della lettura dalla cache. Gli altri sistemi mettono semplicemente una richiesta per una chiave, su AMQP message bus, e il sistema responsabile per la cache riceve questo messaggio e lo risponde con il valore.

Abbiamo utilizzato il Message bus Architecture using RABBITMQ per un sistema recente che implicava l'integrazione con sistemi bancari, un sistema ERP e un servizio pubblico in linea. Quello che abbiamo costruito è stato responsabile della fusione di tutti questi elementi e siamo lieti che abbiamo utilizzato RABBITMQ.I dettagli sono molti, ma quello che abbiamo fatto è stato quello di creare un formato di messaggio e un meccanismo di identificazione del sistema. Tutti i sistemi devono avere un client RABBITMQ per scrivere e leggere dal bus dei messaggi. Quindi si creerebbe una lettura Queue per ciascun sistema, in modo che l'altro sistema scriva le loro richieste in quella coda, il cui nome all'interno di RABBITMQ, sia lo stesso del sistema che lo possiede. Quindi, in seguito, è necessario crittografare i messaggi che passano sul bus. Alla fine, i sistemi sono collegati tra loro su grandi distanze/attraverso stati, ma con una rete efficiente, non crederete alla velocità con cui RABBITMQ lega questi sistemi. Comunque, anche RABBITMQ può essere raggruppato, e dovrei dirti che è Mnesia che alimenta RABBITMQ (che ti dice quanto può essere buona la mnesia).

Un'altra cosa è che dovresti leggere e scrivere molti programmi finché non ti senti a tuo agio.