2009-07-28 18 views
5

Sto scrivendo un bittorrent tracker in erlang. Data la natura del servizio, non avrò bisogno di coerenza assoluta (ad esempio un cliente può essere perfettamente soddisfatto di un elenco di peer o stato di torrent leggermente obsoleto).Eventualmente coerente database mnesia con erlang. Le migliori pratiche a nessuno?

La mia strategia è stata finora quella di creare tabelle mnesia nella RAM con disk_copies abilitate, in modo da avere mnesia automaticamente il dump della memoria su disco quando le dimensioni del registro superano una certa dimensione.

Se il server si arresta in modo anomalo, alcune informazioni andranno perse. Non un grande affare.

Un approccio diverso potrebbe essere l'istanza di due tabelle (una ram solo e un solo disco) e una copia di processo da ram a disco ogni minuto o così. Questo è più ingenuo, ma consentirebbe di scaricare solo un sottoinsieme di ciò che è in memoria, riducendo il sovraccarico generale del disco ed eventualmente evitare l'uso di un registro del tutto (in realtà non sono sicuro di quest'ultima dichiarazione).

Sono sicuro che ci sono molti altri modi per farlo. Qual è il tuo?

-teo

risposta

2

È possibile effettuare il checkout redis & erldis. Redis prende il secondo approccio: tutto viene archiviato in memoria e poi periodicamente scaricato su disco.

1

Questo è certamente fuori tema rispetto alla domanda originale, ma se si sta veramente scrivendo un tracker puro, allora potrebbe essere meglio rinunciare completamente alla persistenza e conservare i dati esclusivamente in memoria.

Per un tracker minimale, un annuncio pesa solo di pochi byte: 16 byte per l'hash SHA1, 6 byte per l'IP e la porta del peer e alcuni altri byte in quanto è necessario mantenere un timestamp come bene. Ma anche con un po 'di overhead, sarai in grado di mantenere letteralmente milioni di record in memoria.

+1

Attualmente i dati di annuncio e torrent sono memorizzati in tabelle mnesia di sola memoria (mantengo ancora il disco copiato disabilitato), che è ovviamente estremamente veloce. Persistere su disco renderebbe comunque il servizio più resiliente a un errore di sistema (anche tenendo conto della resilienza implicita di bitter) e per mantenere nel tempo le informazioni minime relative al torrente (numero di download completati). (http://mcaprari.github.com/peasy-torrent-tracker/) –