[aklug] Re: information on MySQL cluster

Ouch

I tend to favor use of unsigned bigint as a UID, rather than a char based
value.

For session ids and similar md5 (32 char) or sha1 (40 char) are common,
but only as temp IDs, like a username/servername/login-time hash/other
hash.

Any yes, NDB tend to use fixed record sizes. I know there has been talk
about possible changes, but I understand it is tied in with the way the
multi-server partitioning/redundancy functions and is non-trivial.

On Tue, 26 Aug 2008, Richard Moore wrote:

> 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.
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Aug 26 19:51:03 2008