mneisa table fragmentation vs manually splitting

Zohan matan.levy@REDACTED
Thu Oct 1 00:31:49 CEST 2009


For the manual split option you describe, why do you claim
the application should know how to use a specific node to write to a
specific key,
in order to use master-slave duplicated database scheme?
What are the master-slave relations you assume in the 10 machine


On Sep 27, 8:40 am, vim <ofer.aff...@REDACTED> wrote:
> hi,
> i am working on a erlang based distributed architecture, at the end i
> intend to use it on EC2. my application included a database, and since
> i want to spread the load on the database, i thought of splitting the
> table.
> the question is should i choose mnesia built-in feature 'fragmented
> table' over manually splitting the database into clusters?
> i.e. suppose i have a simple key-value sets which i need to store in
> my database. and suppose i have 1000 keys, and i did some measurements
> and i want only 10 keys on each machine (for better performance) so i
> need 100 machines.  thus, if i understand correctly the
> documentation, i have at least two options:
> 1. manual split:
> i can set up clusters of 10 machines each. on each machine i will have
> a node with a running mnesia, and on a such cluster all the mnesia
> nodes will be connected. furthermore, i can use master-slave
> duplicated database scheme, if my application will know how to use a
> specific node to write to a specific key. i assume here that *all* the
> nodes in my world (100) are erlang connected, and on each 10 machine
> cluster there is a connected (shared) mnesia database.
> 2. table fragmentation:
> i can connect all my 100 machines with single mnesia schema, and
> fragment the table into 10 pieces, where each cluster of 10 machines
> will share each piece. again, i can use the same master-slave scheme i
> described above to access my database.
> am i correct with those assumptions?
> should i prefer one method over the other?
> thanks for your help,
> vim.
> ________________________________________________________________
> erlang-questions mailing list. See
> erlang-questions (at)

More information about the erlang-questions mailing list