Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

MySQL 5.1 Improves Performance, Partitioning, Bug Fixes

Posted by CmdrTaco on Sat Apr 12, 2008 10:32 AM
from the not-sure-that-title-quite-parses dept.
Databases Programming Software IT
kylehase writes "CIO.com has a writeup about MySQL's 5.1 release planned for next week. Among the enhancements are many bug fixes from 5.0, some of which may increase performance 20% or more, as well as 'partitioning, events scheduling, row-based replication and disk-based clustering.'"
+ -
story

Related Stories

Submission: MySQL's big leap next week by kylehase (982334)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

MySQL 5.1 Improves Performance, Partitioning, Bug Fixes 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • It's nearly caught up to PostgreSQL. (Score:5, Informative)

    by Anonymous Coward on Saturday April 12 2008, @10:43AM (#23047016)
    MySQL has nearly caught up to PostgreSQL [postgresql.org] in terms of features.

    PostgreSQL's Generalized Search Tree (GiST) indexing is still better than anything MySQL has to offer, in terms of performance and capability.

    The PostgreSQL OpenFTS full text search engine is another marvel of engineering. It routinely outperforms similar extensions for MySQL in terms of performance, memory usage, and concurrency.

    I hope that an upcoming release of MySQL deals with the maximum field size problem. With PostreSQL, there is a max field size of 1 GB. For MySQL, it's a mere 50 MB. For textual representations of certain geographic system data, it's not unusual these days to have individual fields that need to store 500 to 600 MB of data. PostgreSQL handles these fields fine. MySQL fails.

    • Re:It's nearly caught up to PostgreSQL. (Score:5, Informative)

      by IversenX (713302) on Saturday April 12 2008, @11:13AM (#23047224) Homepage
      MySQL fails in many other cases, too.

      Many people see MySQL as the consistent winner in database benchmarks. I don't mean this in a bad way, but a lot of people are so focused on the performance of MySQL vs. PostgreSQL, that they forget that MySQL is usually only fast for really simple queries.

      That would be fine, though, if it weren't for the failing integrity.

      In terms of data integrity, PostgreSQL is kilometers ahead of MySQL. With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. That's simply unacceptable.

      The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure.

      You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much.

      Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

      Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss.

      I know it's popular database, but I would probably not recommend MySQL for any project. If you need something lean and fast, try SQLite. Then you _know_ you don't get any type checks and fancy things like that, so you code for it. If you want to proper, free database, go with PostgreSQL. Half-baked is not my kind of tea. I really hope they will work on data integrity in the upcoming releases, but I fear it's not going to happen.

      • Re: (Score:2, Flamebait)

        by locokamil (850008)
        No offense intended... but how do you bake tea?
        • 1. Pick tea leaves
          2. Preheat oven to 400 degrees farenheit
          3. Arrange leaves on baking sheet
          4. Bake until crispy and dry, but not burnt
          5. ???
          6. Profit!

      • Re:It's nearly caught up to PostgreSQL. (Score:5, Informative)

        by Splab (574204) on Saturday April 12 2008, @12:49PM (#23047822)
        While I generally agree with you a few points and additions.

        Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

        This is not entirely true. MySQL will revert to MyISAM even though you specifically asked for InnoDB - it will however issue a warning that it is doing so, this of course is a moot point since most application programmers never check for warnings.

        And just to feed the flames while we're at it, MySQL will fail to fire triggers on cascading events.

        If you got table A and B and C where B references some information in A and C in B all cascades on updates in A, then any update trigger on C (and possibly B) will fail to fire. This is a very big problem if you are using triggers to keep at least some form of consistency.

        To top it up most replication services in MySQL are at best flaky, usually they replicate by using the binary log, so if the primary fails you lost the X last seconds/minuttes/hours (depending on setup and load) of transactions. Even if you got the binary log on a GFS you are still in big trouble since the secondary still needs to replay all transactions leading to the failure - I've heard of sites where this was taking minuttes to complete! (This might change in the new version)

        Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases, but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.

        • Re:It's nearly caught up to PostgreSQL. (Score:5, Insightful)

          by segedunum (883035) on Saturday April 12 2008, @02:20PM (#23048396) Homepage

          Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases
          I hear this refrain from every terrified analyst who ever wants to bring up the dreaded subject of open source databases, and I see no hard evidence for it. Sorry, but my bullshit detector goes into overdrive when I hear the phrase 'mission critical' and 'toy databases'. MySQL has its shortcomings, and has generally been the web database backend of choice (and it powers quite a few large 'mission critical' web sites), but Postgres really has been the open source database that has kicked on. Failover? Mirroring? Clustering? Yer, there are ways and means of doing that pretty well, and I have seen ample evidence that it can be trusted with lots of 'mission critical' tasks.

          I've managed to start using Postgres in an organisation that has traditionally been all Oracle. The main reasons are the huge cost involved of additional licensing for additional servers, the incredible amount of DBA assistance that all Oracle installations seem to need and which they don't have the resources to provide and Oracle's incredible ability to suck any system resources you have into a black hole on any system. When any 'mission critical' database has the memory footprint of either MySQL or Postgres, and when it can actually start up in time for the end of the next ice age, give me a call.

          but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.
          An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.

          • Re:It's nearly caught up to PostgreSQL. (Score:5, Interesting)

            by Splab (574204) on Saturday April 12 2008, @03:15PM (#23048732)
            Might want to get your BS detector checked then.

            MySQL fails at some very critical points. As I said in previous post it fails to fire triggers on updates.
            Also MySQL believe its better to serve a best effort than a failure - this is probably the biggest NO GO! out there. YOU NEVER EVER do something other than requested in a database. If the transaction model fails you are using no more than an advance file pointer.

            Now PG is a very nice database, they got all the right things implemented, and often better than the competition.

            PG however does not have any support for scaling, if you want to scale you need some form of middleware to handle it - and currently you have to buy continuent for that - which is a nice product, they however don't support stored procedures and triggers.

            And please don't just hit google for PG and scaleability, and come back saying there are all sorts of products out there - most of them are based on triggers and some very bad methods for propergating data - all of them lack the ability to take down primary or secondary server(s) in a running environment and put a new up without interruption in the data flow.

            An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.


            That line alone tells me you got your head so far up your OSS arse you are seeing pink elephants.

            IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online.

            If postgres can handle your situation then fine, but in my environment a database failure means everything comes to a grinding halt. And when you promise clients 99.999% uptime you sure as hell need subsecond failover *hint you can't do that with anything that reads binary logs from primary* and zero loss of transactions.

              • Re:It's nearly caught up to PostgreSQL. (Score:5, Insightful)

                by growse (928427) on Saturday April 12 2008, @04:28PM (#23049250) Homepage

                "Phone Sun" I believe is a reasonable answer to your last point. I also believe they're not the only people who do support.

                But you're right - anyone who picks MySQL or Postgres to power a super-resiliant mission-critical service is an idiot. And anyone who uses Oracle to power a non-resiliant low to medium load webservice is also usually an idiot.

                Tools for the jobs people, tools for the jobs.

              • Re:It's nearly caught up to PostgreSQL. (Score:4, Informative)

                by segedunum (883035) on Sunday April 13 2008, @09:16AM (#23053980) Homepage

                When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan.
                In reality, you have absolutely nowhere to hide and no one else to blame. The downtime still happened, you still have to deal with it and you're the one who picked IBM or whoever. The enterprise vendor doesn't give a fuck because you ponied up the money and you're locked in anyway. The fingers always point at you. Spending other peoples' money in large quantities to cover your ample ass isn't going to help.

                What will you do when your PG installation fail? Go on IRC and ask for help?
                This is another point that gets made by idiot analysts banging on their blogs. Noting the above, that it is always your fault and your responsibility no matter how much money you chuck at an enterprise vendor, you have to have experienced some of the 'enterprise' support from vendors as I have. The caveats on what they will and won't support a lot of the time are unbelievable. In a lot of cases, Google gives you a faster response and more of a hint at the problem - and I've experienced that from everything from databases to server hardware. By the time a consultant arrives, I know more about what's going on than he does.

                Also, I think you save a lot of time, money and stress by putting yourself into situations where dependency on emergency enterprise support is minimised. Just a small hint.

      • Re: (Score:3, Interesting)

        by Anonymous Coward
        SQLite really isn't that fast and lean though. It's really only good for tiny data stores (in which case you can use RAM instead). If you take the same data and stuff it in the various DB systems you will see SQLite databases are huge compared to MySQL or PostgreSQL (lots of wasted space). Then there is the performance which isn't bad but not better than the other databases.

        Don't get me wrong, I like the idea of SQLite. Per-user databases are needed very badly. I just wish SQLite performed better on n

      • Re:It's nearly caught up to PostgreSQL. (Score:5, Informative)

        by consumer (9588) on Sunday April 13 2008, @11:31AM (#23054698)

        With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full.
        Perfect, an anecdote witout details or any way to reproduce the claimed problem.

        The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure.
        Turn on the strict mode.

        You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much.
        Turn on the strict mode.

        Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning.
        That would be a fundamental configuration mistake. You would get a warning, and any time you looked at the table definition it would tell you it was a MyISAM table, not an InnoDB one.

        Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss.
        Turn on the strict mode. Seriously, this stuff has all been there for YEARS and you have only yourself to blame if you haven't figured it out yet.

        If you need something lean and fast, try SQLite.
        Give me a break. SQLite is a neat project and great for times when you don't want to bother installing a database daemon (e.g. the music database in Amarok), but its performance is terrible compared to MySQL, especially for concurrent access.

    • I'm Already Gone (Score:5, Insightful)

      by segedunum (883035) on Saturday April 12 2008, @01:50PM (#23048220) Homepage
      We've already started a migration from MySQL to Postgres, and we're not going back. Full Text Searching was one of the features, but Postgres all round just has a lot more to it. You can make the thing look like an Oracle database if necessary, there's auto vacuuming now, asynchronous commits and a ton of other performance improvements that don't skimp on features.

      I really can't see why anyone would choose MySQL now, apart from inertia and backwards compatibility.
  • From TFA:

    MySQL had said it would release 5.1 in the first quarter, which ended March 31, and some developers have been getting impatient for the new release.

    What?!? I've been running 5.1 on a production server for almost a year now.

    Probably, we should have called it 6.0, because there's so much stuff in there and we've been working on it for a couple of years.

    What?!? The 6.0 alpha has been available for half a year, it's already in developement, OF COURSE you can't call 5.1 6.0 since both are in development. What the hell is this guy on?

        • Re:What?!? (Score:4, Informative)

          by Anonymous Coward on Saturday April 12 2008, @11:09AM (#23047192)
          I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...

          • Re: (Score:2, Insightful)

            by ortholattice (175065)

            I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...

            Both of these applications involve non-critical data. Google doesn't care if two separate searches for the same thing, one immediately after the other, give different results (which is often the case, probably due to different servers not being sync'ed to each other, not saying it's a MySQL problem; the point is that the data is loosey-goosey and non-critical). And,

            • Do some research before you talk about things you dont understand. For starters, Google uses MySQL for their ads, not searches. Searches are done via Bigtable, which is actuall pretty cool. However I find it extremely unlikely that Google would trust their ad system to something they felt was "loosey-goosey".

              Regardless there are plenty of large scale institutions which use MySQL cluster for financial and other critical applications. MySQL Cluster is extremely robust, and thanks to rolling upgrades and b

  • Disk Clustering (Score:3, Interesting)

    by TheLinuxSRC (683475) * <slashdot@@@pagewash...com> on Saturday April 12 2008, @10:48AM (#23047056) Homepage
    I am really looking forward to disk based clustering in MySQL. I have tried the NDB clustering, but the hardware requirements can be hefty. I am also curious about performance in this area. Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. I am curious how the disk based clustering fares compared to NDB clustering and a traditional on-disk MySQL DB.

    • Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. .
      Are you sure this holds up for mysql's shared nothing architecture? Most other DBMSes use a shared block device (a SAN) for clustered databases, which is a whole other perforamnce profile.
    • Disk-based clustering will still use NDB. Previously, NDB tables stored everything in memory. Now, NDB can store data on disk. There are still some limitations. Those columns must be non-indexed, for example.

    • Re: (Score:3, Informative)

      by theantix (466036)
      With NDB Cluster 5.1, all of the indexed columns are still in memory, so the performance impact is minimal for the types of queries and DML that NDB is good for. At least, in my testing it has been.

      For things NDB cluster is really bad at, like querying against non-indexed tables... even the memory based NDB is terrible compared with the innodb/myisam. So you wouldn't be doing that anyway, but the indexed columns would be relatively unaffected by the change.
  • Do they still insist that simply connecting to the server process requires a commercial license if you aren't GPL?

    • Re: (Score:3, Informative)

      by Doug Neal (195160)
      The client library is GPL. There's nothing to stop anyone writing their own client library under another license, but nobody's done that yet (as far as I know).

      • Re:License status. (Score:5, Informative)

        by Fweeky (41046) on Saturday April 12 2008, @12:21PM (#23047654) Homepage
        php-mysqlnd [mysql.com] is a replacement for libmysql, under the PHP license.

      • Re:License status. (Score:4, Informative)

        by DAldredge (2353) <SlashdotEmail@GMail.Com> on Saturday April 12 2008, @12:35PM (#23047754) Journal
        http://www.mysql.com/about/legal/licensing/commercial-license.html [mysql.com] The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source. When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product. Typical examples of MySQL distribution include: * Selling software that includes MySQL to customers who install the software on their own machines. * Selling software that requires customers to install MySQL themselves on their own machines. * Building a hardware system that includes MySQL and selling that hardware system to customers for installation at their own locations. Specifically: * If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. * If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. * If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library. * GPL users have no direct legal relationship with MySQL AB. The commercial license, on the other hand, is MySQL AB's private license, and provides a direct legal relationship with MySQL AB. With a commercial non-GPL MySQL server license, one license is required per database server (single installed MySQL binary). There are no restrictions on the number of connections, number of CPUs, memory or disks to that one MySQL database server. The MaxDB server is licensed per CPU or named user.
    • When will people realize the licensing issues are *solved* now?

      Surely, I can see clueless people 100 years from now still bitching about MySQL's licensing terms.

      • When will people realize the licensing issues are *solved* now?

        They are? So you can write non-GPL software with a MySQL backend now? Great!

        • Re: (Score:3, Informative)

          by kylehase (982334)
          Sure you can, just don't distribute the software. Every commercial case listed in the license above describes distributing MySQL in whole or part.

          I'm no lawyer but it seems if you develop a non-GPL commercial service that runs a community-licensed MySQL backend it's perfectly fine to charge for your service.

  • When shall we get a decent front end? (Score:3, Interesting)

    by bogaboga (793279) on Saturday April 12 2008, @10:57AM (#23047112)
    I am wondering when we shall ever have a free as is OSS, fully programmable front end to MySQL. All the free front ends available suck big time and the non free ones, though somewhat functional, are not available without some kind of restrictions.

    In my opinion, the day MySQL will have a fully programmable front end...I mean one that a programmer can add business logic to, program input masks, direct functionality at widget or control level and use to generate customized reports depending on various metrics, MySQL will kick ass. Right now, all front ends to MYSQL suck big time and there does not appear to be an end in sight - sadly.

    SQL Maestro is very promising but it's not free!

    • Re: (Score:3, Interesting)

      by Animats (122034)

      SQL Maestro is an administrative tool, not a report generator.

      PHP Generator for MySQL [sqlmaestro.com] is free and useful for generating simple database-driven web sites.

      Admittedly, the MySQL Query Browser is clunky, but at least it finally works. For several releases, it was badly broken.

    • Sadly, management tools and report generation are hard, and they require a level of coordination that's easier to achieve in one company and much harder in an open source environment.

      A brilliant programmer can come up with some really solid and innovative code (ex. reiserfs), but to make a nontrivial management tool you need a combination of programmers, designers, and yes, managers, working in tight concert.

      I personally am okay with paying for front ends when they're needed, so we can get kickass scala

    • Re:When shall we get a decent front end? (Score:5, Insightful)

      by NevarMore (248971) on Saturday April 12 2008, @11:33AM (#23047354) Homepage
      Fully programmable front-end for a database?

      You mean like C, C++, Java, Ruby, PHP, Python, OO Calc, ASP, C# ??
      • I'm confused at his request, also. Perl is my mysql front-end and I can do absolutely anything with it. Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin.

        • Re: (Score:3, Informative)

          by Shados (741919)
          He's talking about a 4th gen RAD front end, so yeah, like MS Access, eDeveloper, Oracle Developer (is that still how its called?), etc. There are a few up and coming one in the open source world, but none really that are feature complete.

        • Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin.
          Yes, both of those qualify as a "front-end."

          phpmyadmin fails as it's an unnecessary layer of abstraction -- I shouldn't have to run a webserver on my db engine, or local machine, just to admin my database outside a command shell.

      • I think he means like SQL Server Reporting Services, MS Access and SQL Server Analytic services.

        Hard to be sure though.

        The tools like Mondrian, JasperSoft, Petaho, Navicat, etc. They're all okay, but nothing like as polished as Microsoft's.
    • "... the non free ones, though somewhat functional, are not available without some kind of restrictions."

      Yeah, like they expect you to pay for them.
    • Dunno if its what you are after, but have you tried HeidiSQL?
      • OO.o Base is far from a "copy of MS Access." I tried to use it once and couldn't figure out how to put together a simple form for adding records to a table.
        • I messed around with it a few times. They made some good strides in 2.3. I have yet to try anything with the 2.4 release but it is slowly getting there. It's not a copy of MS Access though - it is all built around a page model which is very odd when creating forms.

      • I'm wondering, thought, how many people still use MS access? I mean you can make a simple web-based app and people can access it from anywhere. Why bother with a full blown app?

        MS Access is the archtypical "toy" database -- useful for very-small projects that don't need to go beyond one computer, or that would otherwise be done by hand using some badly written spreadsheets.

        I've used Access to parse some very large data sets, and I've seen it used as the primary database for limited-run data-sets. Sure, most of these COULD be done via a single server hosting it somewhere... but that's unneeded complexity for the lower end of tasks.

        • You know that Access isn't a database, yes? And that its quite often used on "real" databases? And that if you start with the "toy" database, it can easily later be upgraded to a "real" one? Which is a fairly large part of its usefulness.

        • Re:When shall we get a decent front end? (Score:5, Funny)

          by ianare (1132971) on Saturday April 12 2008, @06:31PM (#23050028)
          Toy database for small, unimportant projects? I don't think so. Access is one of the most stable, reliable, and secure DB systems out there, as the following shows so well:

          Among revelations contained in the memos was information that the Microsoft Access database used by the Diebold system to collect and calculate votes was not protected by a password.
          source [wired.com]
      • Not everybody that uses OSS software is a developer. I'm a system admin and I've done my fair share of shell scripting, PHP and Python but I still can't write every application that I need from scratch. If MySQL had something like Enterprise Studio it would be really nice, phpMyAdmin is ok but it's missing some things.

  • Get PostgreSQL! No, shut up! YOU shut up! (Score:5, Funny)

    by g_adams27 (581237) on Saturday April 12 2008, @11:03AM (#23047146)

    I would simply like to point out that this MySQL update is completely irrelevant because PostgreSQL has had (g_adams27, fill this part in before submitting) for a very long time, and MySQL is simply playing catchup.

    ...

    And now I would like to strongly disagree with g_adams27, who obviously doesn't realize that MySQL is an excellent choice even compared with PostgreSQL, and I wish he'd stop making silly comparisons.

    ...

    In response to that, I say: g_adams27, SHUT UP! You obviously don't recognize the fatal flaws that MySQL still has, in that it still can't (fill this part out later) even after years of development. PostgreSQL is obviously the superior option, and you can take your stupid MySQL advocacy somewhere else.

    ...

    Oh, yeah? Well maybe YOU should shut up! I can't say I'm shocked at g_adams27' mean-spirited response, because that's typical of PostgreSQL jerks. MySQL is AWESOME, and YOU need to shut up, jerk!

    ...

    Well, g_adams27, maybe you should take your TOY MySQL and go play with your dollies, while us REAL sysadmins use a REAL RDBMS to do REAL work! Idiot.

    ...

    And now, allow me, g_adams27, to step in to the middle of this debate and simply point out that you're BOTH right, and that MySQL and PostgreSQL are perfectly good choices.

    Just doing my part to shorten this thread.

    • Not to start a flamewar, but how many of the aforementioned features does PostgreSQL already have (available or planned)?

      Note that I am not asking which DBMS is better for any definition of "better".

    • I must say, I've been sitting at this PostgreSQL machine at this contract web design gig, and I don't know what all of you Postgres people are talking about! I started this 100 row SELECT statement 20 minutes ago, and it STILL hasn't finished. MySQL has it's problems, but seriously, guys!

      Always look over your head for joke before replying. I wish I could find a link to the original post.

  • Decipher for non DB types (Score:3, Insightful)

    by tji (74570) on Saturday April 12 2008, @02:04PM (#23048302)
    I do use databases for various apps and projects, but only enough to do what I need. I am by no means a DB expert.

    So, can someone more DB-literate explain some of the new features?

    - Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)?

    - Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms?

    • Re:Decipher for non DB types (Score:5, Informative)

      by theantix (466036) on Saturday April 12 2008, @03:18PM (#23048760) Journal

      - Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)?
      Disk based clustering only applies to people using the MySQL NDB Cluster product, which is quite different from the traditional MySQL product. So for the vast majority of MySQL users who use MyISAM or InnoDB tables, this doesn't really affect them at all.

      - Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms?
      This means splitting an existing table along logical dividing points, but still acting as a single table. Let's say you partition it by date, well then you would insert/select/update like normal -- but a query or update that looks at the date would only have to look at a smaller partition of the table to know what row needs to be updated.
  • Did they fix perf in subselects and multi-way joins? No? Didn't think so.
  • As a heavy user of Mysql since 4 series, 5.X has been the buggiest, slowest, with the most god-awful slow release schedule of them all. 4.1 alpha was higher quality in terms of bugs/stability than all the stable "5.0" releases and 5.1 just takes forever to get even beta revisions out the door. Mysql is getting slower and slower at getting releases out the door. Expect Mysql 6.0 in 2011 if not later.

    I'm a paid mysql enterprise subscriber and I'm pissed at their pace.

    It's one thing to have a slow stable relea

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.