We were storing relational data all in one field in XML. We now have a
need to search through that data and we're now doing fulltext searches.
And as you can imagine, this is getting painfully slow. We're now
designing a true normalized database (well, normalized within reason)
with table relations rather than storing the XML.
We're using cluster because we need a very fast and highly available
setup. We're beyond that decision.
So if TEXT fieldtypes are stored in a separate table, and Varchar fields
are max length. What am I to do? Why are TINYTEXT fields not useful?
If I setup the fieldtypes with the limiter 'varchar(6)' it'll still
store the maxlength?
[EMAIL PROTECTED] wrote:
I have to do some re-design of a website database that has quickly
outgrown itself. I'm trying to migrate to MySQL Cluster 5.0.15.
Outgrown size or performance?
Cluster 5.0 is memory based, databases are limited to a few gigs.
Throughput can be good if application is _massively_ parallel.
But the unique feature of Cluster is redundancy.
Mostly I've used VarChar fieldtypes in the past, but I want to make sure
I'm using the best fieldtype for alphanumeric indexed fields.
In Cluster 5.0 Varchar is stored with maximum length. This changes
in > 5.0. For indexing, non-binary character sets have high overhead.
Some of the data I'm storing will be fixed in length and some will be
variable in length. I've thought of just going to TINYTEXT and TEXT
fields.
TINYTEXT is not useful, just use Varchar. TEXT is a form of BLOB and
the bulk of it (in Cluster) is stored in a separate table. This is
usually not efficient.
I hope this helps to decide if Cluster is right solution for you.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
