3 ms·

A lot of good points, the most important to remember is that nowadays mnesia is good only for storing configuration.

jlouis 12y ago
Author here. I've been using Mnesia successfully for other things as well, among that a billing system. The key is to have another data source from which you can reconstruct data should the need arise. The advantage you get is very very fast database queries. This can be very useful at times.
lostcolony 12y ago
I've used it even for fairly small amounts of user data (a few gigs max). What we had, though, was a load balancer out front that would ensure only one node was ever receiving writes (lazily switching on failure), and were relying on it solely for fault tolerance (which, despite the article, Mnesia can do just fine at, with certain caveats; what it can't do is scale). In the event of a network partition, the load balancer is channeling all writes to a single node, and the system rather loudly lets us know that a node disappeared (in the event of a network partition, every node is loudly letting us know that a/some node(s) disappeared), ensuring quick redress. While it's possible that in such an event the node being written to will go down, causing the load balancer to switch to the partitioned node(s) (thereby creating an inconsistency), this is generally over a -very- small time window, as the facility this was deployed into is manned 24 hours. Thus, any inconsistency is confined to a very small window, approximately half of the time between the initial split, and its being addressed (as if the failure that causes the load balancer to switch to the other node happens before then, we could take the switched to node as most canonical, and if it switches after that, we could take the switched from node as most canonical), so even without an express mechanism to resolve consistencies, we're losing very little data, and for such a rare occurrence (multiple years running in multiple locations and we've yet to see it happen), that's an acceptable risk. It just depends on what your requirements are. The author is bang on that Mnesia should not be used for scaling (and in general probably shouldn't be used any time you don't want a full replication on every node, or relying on some other mechanism to reconstruct/deconflict data), but in an environment where split brains are infrequent, where you've got Nagios or similar running to alert you to a split brain, and you've got people on call, where scalability is not a concern, and where in the (extremely) unlikely event you actually lose some data it's okay or easily addressed, Mnesia can be a reasonable solution, since it's so easy to get running with, and quite performant.

Author here. I've been using Mnesia successfully for other things as well, among that a billing system. The key is to have another data source from which you can reconstruct data should the need arise. The advantage you get is very very fast database queries. This can be very useful at times.

lostcolony 12y ago

I've used it even for fairly small amounts of user data (a few gigs max). What we had, though, was a load balancer out front that would ensure only one node was ever receiving writes (lazily switching on failure), and were relying on it solely for fault tolerance (which, despite the article, Mnesia can do just fine at, with certain caveats; what it can't do is scale). In the event of a network partition, the load balancer is channeling all writes to a single node, and the system rather loudly lets us know that a node disappeared (in the event of a network partition, every node is loudly letting us know that a/some node(s) disappeared), ensuring quick redress. While it's possible that in such an event the node being written to will go down, causing the load balancer to switch to the partitioned node(s) (thereby creating an inconsistency), this is generally over a -very- small time window, as the facility this was deployed into is manned 24 hours. Thus, any inconsistency is confined to a very small window, approximately half of the time between the initial split, and its being addressed (as if the failure that causes the load balancer to switch to the other node happens before then, we could take the switched to node as most canonical, and if it switches after that, we could take the switched from node as most canonical), so even without an express mechanism to resolve consistencies, we're losing very little data, and for such a rare occurrence (multiple years running in multiple locations and we've yet to see it happen), that's an acceptable risk. It just depends on what your requirements are. The author is bang on that Mnesia should not be used for scaling (and in general probably shouldn't be used any time you don't want a full replication on every node, or relying on some other mechanism to reconstruct/deconflict data), but in an environment where split brains are infrequent, where you've got Nagios or similar running to alert you to a split brain, and you've got people on call, where scalability is not a concern, and where in the (extremely) unlikely event you actually lose some data it's okay or easily addressed, Mnesia can be a reasonable solution, since it's so easy to get running with, and quite performant.