Hi,
14 nov 2007 kl. 06.39 skrev Jonathan Haddad:
> Has anyone on the list set up cluster for use in a web
> environment? How
> does the performance compare to innodb for selects based off an index?
>
> How well does cluster perform with a lot of mixed reads / writes?
> (say 20
> to 1?) If a table is constantly having rows inserted, are there
> any locking
> issues we should be aware of? Usually we deal with this by
> partitioning
> our tables into multiple machines. Is this necessary anymore?
>
> Initially, there won't be much on here, but I'm expecting it to be
> running
> this on 6x 16GB dual core boxes for the data nodes - will 1 table
> with 500
> million rows and several hundred concurrent selects / inserts per
> second be
>
With 6x 16GB data nodes you should be able to handle 500 million rows if
the records are fairly small. You will have access to about 42 GB's
of Data
and Index Memory and thus can spend about 84 bytes per record in memory.
If you're records are bigger than this, you should be using 5.1 since
it has a
disk data extension.
So as an example you might have the need of 1 Primary key hash index and
one ordered index on the table. Those two together take up about 32
bytes
per record and then the overhead is at least 16 bytes per record, if
you use
any NULL fields add another 4 bytes and if you use any VARCHAR fields
then add about 12 bytes of overhead for the first VARCHAR field.
There is a script ndb_size.pl that will assist in calculating record
sizes.
Non-indexed fields you can put in the disk part.
The performance shouldn't be an issue at all, with 6 dual core boxes as
mentioned above you should be fine with tens of thousands of selects/
inserts
unless the selects are extremely heavy.
Rgrds Mikael
> an issue?
>
> Thanks,
> Jon
> --
> Jon Haddad
> jon@stripped
> Letsgetnuts.com
