Tue Oct 13 03:48:11 CEST 2015
There's no substitute for production experience. If Mnesia is what you
really really really want to use - it's super awesome - just dive in
and use it. As you say, if you run into issues, you can just work
Personally, I'm interested in the physics of a system at scale, less
so the brands involved. Get something in motion, measure it, fix it.
On Mon, Oct 12, 2015 at 8:04 PM, Martin Karlsson
> Hi Steve,
> I'm with you:)
> The negatives are being mentioned a lot and unfortunately put people
> off instead of just being used as good things to know about when you
> are picking your technology.
> If you know about the quirks you can usually come up with a workaround
> that matches your use-case.
> It is about weighing pros and cons. Why not list a few of the
> negatives and what you can do to work around them.
> PROBLEM: Net splits must be manually handled.
> - https://github.com/uwiger/unsplit for automatic healing
> - Use the majority options (when you need to heal you choose the
> majority partition when you pick master nodes). This should reduce
> (eliminate?) risk of data loss.
> PROBLEM: disc_only_copies uses dets and is limited to 2GB
> - Partition the tables
> - Use the mnesia_ex patch with leveldb backend (to be released soon I
> think, it was mentioned in another email just recently)
> - Perhaps you can use disc_copies and hold your data-set in RAM
> PROBLEM: Prone to overloading
> WORKAROUND: Load regulate. Reduce concurrency. I think I read
> somewhere that mnesia and ets works best with a max concurrency of the
> number of scheduler threads and degrades from there on.
> PROBLEM: Slow startup
> WORKAROUND: Increase the number of table loaders.
> PROBLEM: Upgrading table definition. transform_table can have problems
> with big and distributed tables.
> WORKAROUND: Treat large tables like a key value store to reduce risk
> of having to modify the record
> I'm sure there are more problems and workarounds especially if you
> start pushing it (for example like whatsapp did).
> Also I've heard dirty_write is not safe with replicated tables. I
> don't know if this is true but is holding me back from using dirty
> transactions rather than transactions (which I don't need apart from
> safety on replicated tables). If anyone knows about this one please
> let me know.
> Feel free to add/remove/correct items:)
> On 13 October 2015 at 13:08, Steve Davis <> wrote:
>> I’m almost ashamed to say that it’s taken me over 5 years to come around to understanding the value of mnesia.
>> I bought the “well-known” negatives too fast. I have explored relational connectors, DHT solutions and a number of other approaches...
>> It’s dawned on me *finally* that 90% of the time, a well implemented mnesia solution would have been better, faster, and cheaper.
>> Did I mention "better"?
>> Has anyone else had this experience?
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions