Mnesia dB size limits

[Scott Lystig Fritchie]

>>>>> "pr" == Philip Robinson <philar@REDACTED> writes:

pr> Damir asks:

>> What are the upper limits where system can still be called
>> "production quality" in terms of dB speed?

In a few months, a project I've been working on will go "live" with
approx 6GB total of data in about a half-dozen 'disc_copies' tables,
using both replication and fragmentation (though only on 2 machines,
but they have 16GB RAM each :-).

pr> When I wanted to retrieve a specific event there was no noticable
pr> delay, but most of my queries were for a date/time range.

It all depends on how the index(s) is defined and whether you were
using foldl/3 or index_match_object/3 or match_object/1 or
scary-but-works-quite-well-at-what-it-does select/2.

pr> I think the mnesia issues being mentioned on this list were to do
pr> with database recovery across nodes after a node failure...?

Step 0: Decide when to start the dead node.
Step 1: Start the dead node.
Step 2: There is no step 2.

Overall throughput can take a hit when starting a dead node, because
all out-of-date tables will be copied as-is from a live node.  So
doing Step 1 during your 1% or 5% peak usage time isn't a good idea.

Dealing with network partitions is trickier.  But if you're
clustering, then you've probably also got some kind of infrastructure
build for dealing with logging messages, events (of whatever sort,
including 'mnesia_down' events from Mnesia itself), alarms, etc
... and all that makes it tricky enough to wuss out with an answer
like, "It depends."

-Scott