1 |
On Thu, 28 Oct 2004, Billy wrote: |
2 |
|
3 |
> http://mysql.mirror.nedlinux.nl/tech-resources/articles/storage-engine/part_2.html |
4 |
> |
5 |
> While nodes keep their data entirely in memory for maximum performance, |
6 |
> the durability requirement of ACID transactions is maintained by the |
7 |
> cluster making sure that at least two nodes in each group have the a |
8 |
> copy of the data. On-disk "redo" logs are maintained for recovery |
9 |
> purposes., and each node requires sufficient disk space to store its |
10 |
> entire fragment for cold starts. |
11 |
> |
12 |
> [This tells me that each node doesn't need to store the entire database, |
13 |
> just the portion of the database that's responsible for. The more nodes |
14 |
> you have, the less memory each node requires.] |
15 |
> |
16 |
> Because MySQL Cluster is main-memory based it is extremely fast. MySQL |
17 |
> Cluster has good scalability by adding more memory and/or more nodes to |
18 |
> a configuration. |
19 |
> |
20 |
|
21 |
Alright, I'm still having trouble wrapping my head around this, |
22 |
but it's starting to make sense. Supposing I have a 4 GB database and two |
23 |
computers with two nodes a piece, how much RAM do I need in each computer? |
24 |
If I'm understanding this correctly I'd need to allocate 2GB per node or |
25 |
4GB per server. Assuming that's correct then where this would start making |
26 |
sense is at say four servers with 2 nodes a piece. My 4GB database becomes |
27 |
four partitions * 2 for ACID compliance or 8GB across the 4 servers. So |
28 |
scalibility sucks at < 3 servers like all n+1 solutions. |
29 |
|
30 |
Is this right? |
31 |
|
32 |
kashani |