The first public release of MySQL 5.1 is available now. The MySQL 5.1.3 alpha release is a developer preview that gives early adopters, fans, and hard-core database geeks a chance to kick the tires of the next big release.
Major new features include:
Partitioned tables. You can have single tables spread across multiple disks based on how you define them at table creation time.
A Plugin API and support for dynamically loading new modules of code into the server. The first example of this is pluggable full-text parsers. That means you'll be able to write a custom parser to index any sort of oddball textual data you might want to store and retrieve. MySQL still handles the details of executing the queries, so you need only worry about the specifics of parsing your data.
The instance manager has been beefed up with additional SHOW commands for getting at information about log files. You can also issue SET commands that change configuration options which get written back to the configuration file.
VARCHAR fields on cluster tables really are VARCHAR fields now.
And there's lots more. The MySQL documentation, as always, has the gory details.
Posted by jzawodn at December 02, 2005 07:16 PM
the bit about VARCHAR fields is specifically about cluster. earlier versions would always allocate space for the full possible length, now it only allocates as much space as the value actually needs. other storage engines had no such issue.
hey a lil birdy told me u needed gmail invites and i ahve 99 i'll nvr use.
So... I've been looking forward to partitioning, as it would seem to help a great deal with time-series data, which I'm always dealing with. Am I right that it would make sense to partition by date, putting old data (data that's not part of current analysis) to lower-performance hardware, leaving it available (but slow) when we want to analyze the historical data? And as a lovely side-effect, the speed of analyzing current data would go up, since it would be smaller? I've done nothing (except write this comment) to see how others use partitioning on other DBMSs.
There are different ways of partitioning. Whatyou are talking about is RANGE based partitioning:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-range.html
How we can able to write a custom parser to index any sort of oddball textual data..??
Nick,
Yes and No. Initially, I would tell you that what you are talking about is archiving your data, which puts it on separate physical hardware. MySQL partitioning won't allow you to partition across multiple servers, just across partitions in your filesystem. But... I would assume that you could fake out MySQL. You could mount and directory from slower hardware to your MySQL server, via NFS. By having this NFS mount as "part" of your local filesystem on your MySQL server, you should be able to include the local path to the mount for partitioning purposes, in essence, allowing you to actually push data to the lower-performance hardware.
I'll mention another possible scenario. Let's say you have a server with 6 hard drives. You could create two Raid 5 devices across 3 drives each. You would then partition the filesystem for your OS accordingly. By having your filesytem, and MySQL data, spread across two separate storage devices, I would imagine that you could accomplish a phenomenal increase in peformance, in the instance that you are actually paritioning based on date.
