[aklug] Re: information on MySQL cluster

Well I was doing some research and found out that the NDB stores data
differently than the MyISAM. This is that for a varchar(50) in MyISAM it
only takes up as many bytes that you used in that record, for instance if
you 31 charactors the record size for that would be 32bytes of storage.
However in the NDB it would be 51bytes because it reserves 51 bytes per
record no matter how many charactors you actually use in the record. This
just means we have to slim down some of out UID's and UNIQUE KEYS, because
the database / web designer likes to have huge UID's and UNIQUE KEYS for
some odd reason. with the database I was trying to get put in I found the
UNIQUE KEY to be a varchar(100) but the most any record used was
21charactors, so I changed the table UID to be varchar(30) and I fit the
entire database in the cluster. Now I just have to go through all the other
databases and make sure that there are no hug UNIQUE KEYS or KEYS..

Richard Moore

On Mon, Aug 25, 2008 at 2:40 AM, Christopher E. Brown <cbrown@woods.net>wrote:

> On Wed, 20 Aug 2008, Richard Moore wrote:
>
> I was wondering if anyone in the list has experience with MySQL cluster,
>> other name would be NDBCLUSTER. I have the cluster set up and working
>> perfectly, using disk data storage and everything. my question is however,
>> if anyone knows a way to get UNIQUE KEYS to be stored in disk data
>> storage,
>> or a way to make them not take up so much space. I am currently testing
>> the
>> cluster for storage for our new ERP, as well as the storage for our DBMS.
>> If
>> there is no way of doing this I will just be putting 8 gigs of ram in each
>> of the data nodes. My current configuration has 4 data nodes, 2 management
>> nodes with the sql node on the management node. all of the computers are
>> the
>> same, they each have 250 gig hdd, with quad core processors, with 2 gigs
>> of
>> ram. We would be willing to spend the extra couple hundred dollars for 8
>> gigs of ram for each of the data nodes if I cannot store the UNIQUE KEYS
>> in
>> the DISK DATA STORAGE.
>>
>> Richard Moore
>>
>
>
> Not at this point. Unique keys (specially the primary one) are the
> selectors for the table, and are kept in memory for fast access. Disk
> storage in an NDB cluser is mainly for secondary data, normally pulled as
> part of a record(s) chosen based on one of the keys.
>
>
> I suppose that (in theory) this could change, but I have not heard any
> about it being planned.
>
>
> I have seen discussions about adding to what can be stored on (instead of
> just snap-shotted to) disk, but only for non-indexed fields.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Aug 26 07:31:56 2008