[erlang-questions] Mnesia

[Garrett Smith]

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
around them.

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
<martink@REDACTED> wrote:
> 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.
> WORKAROUND:
> - 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
> WORKAROUND:
> - 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:)
>
> Cheers,
> Martin
>
>
> On 13 October 2015 at 13:08, Steve Davis <steven.charles.davis@REDACTED> wrote:
>> Hi,
>>
>> 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?
>>
>> /s
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions