Posted by
Hemos
on from the lock-yer-rows-gentlemen dept.
egerlach writes "All you DB admins out there might be interested to know that MySQL 4.0 has finally been released! It's only 4.0.0 alpha, but you can download it here. You can also check out a full list of changes."
In other news, PostgreSQL announced that it has all the features that MySQL 4.0 has, has had them for a long time, is GPL'd, and is very stable (as in not alpha). Get it here
OK, maybe that wasn't announced, but it should have been.
Re:In other news
by
tzanger
·
· Score: 5, Insightful
Sometimes speed is everything...
Which MySQL hasn't got, no matter how you look at it.
Postgres has shown time and time again that it blows the shit out of MySQL for any kind of select statement where your 'where' clause is even just slightly more complicated than 'x = y'. Even for simple selects, Postgres performance scales waaaaay better than MySQL. We're not talking hundreds of clients, either; we're talking dozens. MySQL falls flat on its face under heavy load.
And if your application just requires the simplest of simple selects, a hashed flat file is faster than MySQL because you don't actually have to parse up the SQL statement and return the result in a formatted fashion!
Face it: MySQL is a neat toy but that's about it. All this pandering about what 4.0's got now and how they think it's mission-critical-ready is bullshit, plain and simple. We've got an open-source, free ACID-compliant database already. MySQL has lost, they just don't know it yet.
Does this really warrant a 4.0 release?
by
jedrek
·
· Score: 5, Interesting
I hate to be a spoilsport, but does this really warrant a 4.0 release? I don't really see anything in the changelog that would support a 1.+ release. Maybe a.1+, but not a 1.+.
Hm... I keep going over it and see stuff like 'Removed all Gemini hooks from MySQL' or 'New character set latin_de which provides correct German sorting'. The only major things I'm seeing right now are the SSL support, support for UNION and boolean fulltext search.
Am I missing something?
Transactions, foreign keys
by
blackcat++
·
· Score: 5, Informative
I hate to disappoint you but transactions, foreign keys and row-level locking are available and seem to work quite well.
The real reason for this release
by
joshv
·
· Score: 5, Insightful
From the release notes:
"Removed all Gemini hooks"
See:
http://www.mysql.com/news/article-75.html
And you will understand. There probably are not enough changes to warrant a +1 increment in the release number, but this gives them a new version that does not support NuSphere's attempt to usurp MySQL's copyright and trademark rights.
-josh
Re:But why?
by
micromoog
·
· Score: 5, Informative
SubSelects: You don't need to do these, it can be worked around pretty easily.
Views: Good ridance. A maintenance nightmare.
You clearly have no knowledge whatsoever of databases. Maybe you don't use subselects in CS102: Intro to Databases, but there are many things that can ONLY be accomplished with subselects. The simplest subselects would be worked around using temporary tables (which unnecessarily complicates the application), and the more complex requirements cannot be worked around at all (go look up "nested subquery").
Views are one of the greatest things ever to happen to a real-world database system. Various applications like their data organized in different ways, and the creation of views allows a single dataset to be used for all. The workaround is to create and populate separate tables (now that's a "maintenance nightmare").
The bottom line: a "mission-critical" database needs to support these things, and the others listed above. People would much rather use a different system that supports these features than rewrite their existing applications around the limitations of MySQL.
Lets see if they get it right this time
by
SnapperHead
·
· Score: 5, Informative
MySQL has been missing some very important key parts, which makes life very difficault working cross database.
timestamp field doesn't follow SQL standards
Sub-selects
Triggers would be nice
select disinct on (field_name)... would also be nice
To sum it all up, I hope they plan on following SQL standards this time around.
-- until (succeed) try { again(); }
Still on the wrong track!
by
MattRog
·
· Score: 5, Insightful
If you're listening MySQL -- who really cares about SSL and unicode. Granted I've had them in my RDBMS that I use but still you're missing the big picture.
The people who post funny things like 'MySQL Mad libs' are on to something - Slashdot is full of 'arm chair' DBAs (and programmers and network engineers and etc. etc. etc.) who know just enough to think they know exactly what is wrong and how to fix it. It's kind of like the people who have used a computer for a while and start trying to troubleshoot their friend's computers - 'You may have run out of Megahertz' or 'You probably need more memory to download files faster'. Yes, subqueries, locking issues, etc. are very important. However, these are 'surface' level flaws in MySQL. There are some very, very large problems in the underlying architecture which need to be addressed. Since they're not as glamorous (or as understood) as subqueries and pretty much ignored by 90% of the users they never see the light of day - but they impact almost 100% of the users in one way or another.
Fix things like this:
Filesystem buffered writes. Transactional support is great - it allows me to roll-back aborted transactions. However, due to the inability to control whether or not my tables are write-buffered means that MySQL may *think* it has performed a write even though it is still in the write-cache. I can then turn off the system and voila -- corruption! Part of the fault lies in the OS who tells MySQL it was written even though it is in the cache, but I have a simple solution. Devise a way to selectively turn off buffered writes for certain tables / databases. This way if I know I have a critical table which has a lot of writes I can turn buffering off and be ASSURED that writes will be performed when asked. I suspect a lot of 1040 and other table corruptions are caused by something like this. Yes, performance will take a hit but I think it is a very acceptable trade-off for data corruption. Obviously all system tables should NOT be buffered.
Inability to use more than one index on a table in a query -- most enterprise RDBMS' can use more than one index on a table for a query. This can easily save a table scan or the use of a single, less-efficient index. Given an example query - 'SELECT bob FROM sometable WHERE somecol = 45 and somecol2 = 44' - if I have two indexes on sometable (somecol and somecol2) it can join the two indexes together and
Clustered indexes. These basically physically sort the table based on particular columns. This allows you to ORDER BY username ASC without using anything special since the rows are already sorted on username (if you have a users table and cluster the username col). This also greatly speeds up BETWEEN clauses. And yes, to people who know a little bit of SQL but don't know as much about clustered indexes -- you can create an index with a bobcol ASC but clustering the actual data is faster and more efficient if you are grabbing data which is not on the index. For example, SELECT * FROM table ORDER BY username ASC will not be as efficient as the same query clustered on the username. If you had a sorted index on username it will probably read the index sequentially and then visit the table. That extra operation = more disk seeks = more time / cpu to execute (and it really adds up as the table size increases). However, if you are doing something like 'select username, password from user order by username' it would be better to create a sorted index on username ASC, password. That way it will read the index only and not visit the table at all.
on-line backups. In today's internet world your site has to be 24/7. This means you cannot have significant performance problems (or even offline-ing your dB!) when you make a dump -- Sybase, etc. have done this from as far back as I can remember.
backups to something other than CSV files. MS SQL, Sybase, Oracle, they all dump to a compressed binary file. Saves a TON of space and is MUCH FASTER to dump and load. I can dump a 6GB Sybase DB in under 5 minutes. Loading it all (from scratch) and then bringing the DB online is about the same amount of time.
Ability to specify the number of files to dump to. What happens if you have a dump which is larger than 2GB? Most linux distros cannot handle a single file of 2GB or more. Give users a way to, within the dump statement, split the dump over two files. Sybase has the 'STRIPE ON' clause (originally to dump to two tape drives at once but works fine on filesystem files as well) to split the dump equally over an unlimited number of files.
cleaner way to view query plans of statements. EXPLAIN... is great and all, but the resulting table is a PAIN to read. What I want to know is simple:
Query is using XYZ, ABC tables. Table XYZ is using index 123 which is sorted so I do not need to create a temp table to sort ASC.
Since you have all the columns in your select statement in the index I do not have to visit the actual table - I can pull it all from the index. Because of this, I will read the index from start to finish.
ABC is using index 23dsf which is not sorted so I must create a temp table to sort that. Also, since it is a join, I do not need to perform an index scan but a positioned search (table scan is to a WHERE clause with no index AS index scan is to an index which is not selective enough or needs to read all columns.)
Simple, easy and pretty much even a NOVICE can see that their query is a good performer or a bad performer.
Along with more in-depth EXPLAIN, also provide me with a way to see what the optimizer is doing with the query. In MS SQL and Sybase you have 'trace flags' which you can turn on before your query to see EXACTLY what Sybase is doing - why does it think this index is better than this other one, why is it table scanning when you think it should index sort, etc. Give me an easy way to say 'verbose on; explain xxx;'.
Ability to delve deeply into performance of the system. If there is one job a DBA must know it's how to tell what the heck is going on when something is slow. Currently MySQL gives you meaningless info like 'slow queries'. Great, I see 200,000 of them. What queries are they? What good is it in a large application which may contain 3000 lines of SQL to tell me the raw number of queries which are slow? I want to know the EXACT SQL of the query(s) which are slow and I want to find the one taking up the most CPU time and blocking all the rest. I want to know how MySQL is managing it's data cache so I can see if I need more ram (e.g. it is swapping lots of data to/from the cache) or if I am I/O bound. Don't tell me to look at 'free' or 'top' - half the time it is wrong because you (MySQL) tell it misleading figures. I want *you* to tell me exactly what you are doing since you would know best! If you've ever seen a sp_sysmon output from Sybase ASE you'd know what I'm talking about.
Hire people who are accomplished relational algebra freaks. Pay them a lot of money - it is well worth it!!! If I see another changelog entry like this I'm going to scream:
Optimized queries of type: SELECT DISTINCT * from table_name ORDER by key_part1 LIMIT #
So does that mean these queries were NOT AT ALL optimized before? It doesn't read 'FURTHER optimized'.
"ORDER BY... DESC can now use keys."
Does that mean it was table scanning each time? Jebus! Get these wiz-bangs to overhaul your query optimizer. Hands down this is one of the most important things in the database -- knowing how to use the database statistics and knowing when to use a merge-join vs. a hash-join etc. are CRITIAL to database performance. Trust me when I say that this is a MAJOR priority - especially over SSH or Unicode since it impacts EACH AND EVERY statement which MySQL parses.
Small things which can really raise the respect of MySQL in the eyes of people who matter - the CTOs and CIOs of the world who might be considering something like Postgres or MySQL but opt for MS SQL, Sybase, or Oracle because of the more advanced (but less flashy) features.
Of course, integrated row (or in the least page) locking and full support of subqueries and the like are also VERY HIGH priorities.
I think addressing these issues will vastly improve MySQL -- they're not flames really, just gripes:D
Slashdot Mirror
In other news, PostgreSQL announced that it has all the features that MySQL 4.0 has, has had them for a long time, is GPL'd, and is very stable (as in not alpha). Get it here
OK, maybe that wasn't announced, but it should have been.
I hate to be a spoilsport, but does this really warrant a 4.0 release? I don't really see anything in the changelog that would support a 1.+ release. Maybe a .1+, but not a 1.+.
Hm... I keep going over it and see stuff like 'Removed all Gemini hooks from MySQL' or 'New character set latin_de which provides correct German sorting'. The only major things I'm seeing right now are the SSL support, support for UNION and boolean fulltext search.
Am I missing something?
I hate to disappoint you but transactions, foreign keys and row-level locking are available and seem to work quite well.
From the release notes:
"Removed all Gemini hooks"
See:
http://www.mysql.com/news/article-75.html
And you will understand. There probably are not enough changes to warrant a +1 increment in the release number, but this gives them a new version that does not support NuSphere's attempt to usurp MySQL's copyright and trademark rights.
-josh
Views: Good ridance. A maintenance nightmare.
You clearly have no knowledge whatsoever of databases. Maybe you don't use subselects in CS102: Intro to Databases, but there are many things that can ONLY be accomplished with subselects. The simplest subselects would be worked around using temporary tables (which unnecessarily complicates the application), and the more complex requirements cannot be worked around at all (go look up "nested subquery").
Views are one of the greatest things ever to happen to a real-world database system. Various applications like their data organized in different ways, and the creation of views allows a single dataset to be used for all. The workaround is to create and populate separate tables (now that's a "maintenance nightmare").
The bottom line: a "mission-critical" database needs to support these things, and the others listed above. People would much rather use a different system that supports these features than rewrite their existing applications around the limitations of MySQL.
until (succeed) try { again(); }
If you're listening MySQL -- who really cares about SSL and unicode. Granted I've had them in my RDBMS that I use but still you're missing the big picture.
... is great and all, but the resulting table is a PAIN to read. What I want to know is simple:
... DESC can now use keys."
:D
The people who post funny things like 'MySQL Mad libs' are on to something - Slashdot is full of 'arm chair' DBAs (and programmers and network engineers and etc. etc. etc.) who know just enough to think they know exactly what is wrong and how to fix it. It's kind of like the people who have used a computer for a while and start trying to troubleshoot their friend's computers - 'You may have run out of Megahertz' or 'You probably need more memory to download files faster'. Yes, subqueries, locking issues, etc. are very important. However, these are 'surface' level flaws in MySQL. There are some very, very large problems in the underlying architecture which need to be addressed. Since they're not as glamorous (or as understood) as subqueries and pretty much ignored by 90% of the users they never see the light of day - but they impact almost 100% of the users in one way or another.
Fix things like this:
Filesystem buffered writes. Transactional support is great - it allows me to roll-back aborted transactions. However, due to the inability to control whether or not my tables are write-buffered means that MySQL may *think* it has performed a write even though it is still in the write-cache. I can then turn off the system and voila -- corruption! Part of the fault lies in the OS who tells MySQL it was written even though it is in the cache, but I have a simple solution. Devise a way to selectively turn off buffered writes for certain tables / databases. This way if I know I have a critical table which has a lot of writes I can turn buffering off and be ASSURED that writes will be performed when asked. I suspect a lot of 1040 and other table corruptions are caused by something like this. Yes, performance will take a hit but I think it is a very acceptable trade-off for data corruption. Obviously all system tables should NOT be buffered.
Inability to use more than one index on a table in a query -- most enterprise RDBMS' can use more than one index on a table for a query. This can easily save a table scan or the use of a single, less-efficient index. Given an example query - 'SELECT bob FROM sometable WHERE somecol = 45 and somecol2 = 44' - if I have two indexes on sometable (somecol and somecol2) it can join the two indexes together and
Clustered indexes. These basically physically sort the table based on particular columns. This allows you to ORDER BY username ASC without using anything special since the rows are already sorted on username (if you have a users table and cluster the username col). This also greatly speeds up BETWEEN clauses. And yes, to people who know a little bit of SQL but don't know as much about clustered indexes -- you can create an index with a bobcol ASC but clustering the actual data is faster and more efficient if you are grabbing data which is not on the index. For example, SELECT * FROM table ORDER BY username ASC will not be as efficient as the same query clustered on the username. If you had a sorted index on username it will probably read the index sequentially and then visit the table. That extra operation = more disk seeks = more time / cpu to execute (and it really adds up as the table size increases). However, if you are doing something like 'select username, password from user order by username' it would be better to create a sorted index on username ASC, password. That way it will read the index only and not visit the table at all.
on-line backups. In today's internet world your site has to be 24/7. This means you cannot have significant performance problems (or even offline-ing your dB!) when you make a dump -- Sybase, etc. have done this from as far back as I can remember.
backups to something other than CSV files. MS SQL, Sybase, Oracle, they all dump to a compressed binary file. Saves a TON of space and is MUCH FASTER to dump and load. I can dump a 6GB Sybase DB in under 5 minutes. Loading it all (from scratch) and then bringing the DB online is about the same amount of time.
Ability to specify the number of files to dump to. What happens if you have a dump which is larger than 2GB? Most linux distros cannot handle a single file of 2GB or more. Give users a way to, within the dump statement, split the dump over two files. Sybase has the 'STRIPE ON' clause (originally to dump to two tape drives at once but works fine on filesystem files as well) to split the dump equally over an unlimited number of files.
cleaner way to view query plans of statements. EXPLAIN
Query is using XYZ, ABC tables. Table XYZ is using index 123 which is sorted so I do not need to create a temp table to sort ASC.
Since you have all the columns in your select statement in the index I do not have to visit the actual table - I can pull it all from the index. Because of this, I will read the index from start to finish.
ABC is using index 23dsf which is not sorted so I must create a temp table to sort that. Also, since it is a join, I do not need to perform an index scan but a positioned search (table scan is to a WHERE clause with no index AS index scan is to an index which is not selective enough or needs to read all columns.)
Simple, easy and pretty much even a NOVICE can see that their query is a good performer or a bad performer.
Along with more in-depth EXPLAIN, also provide me with a way to see what the optimizer is doing with the query. In MS SQL and Sybase you have 'trace flags' which you can turn on before your query to see EXACTLY what Sybase is doing - why does it think this index is better than this other one, why is it table scanning when you think it should index sort, etc. Give me an easy way to say 'verbose on; explain xxx;'.
Ability to delve deeply into performance of the system. If there is one job a DBA must know it's how to tell what the heck is going on when something is slow. Currently MySQL gives you meaningless info like 'slow queries'. Great, I see 200,000 of them. What queries are they? What good is it in a large application which may contain 3000 lines of SQL to tell me the raw number of queries which are slow? I want to know the EXACT SQL of the query(s) which are slow and I want to find the one taking up the most CPU time and blocking all the rest. I want to know how MySQL is managing it's data cache so I can see if I need more ram (e.g. it is swapping lots of data to/from the cache) or if I am I/O bound. Don't tell me to look at 'free' or 'top' - half the time it is wrong because you (MySQL) tell it misleading figures. I want *you* to tell me exactly what you are doing since you would know best! If you've ever seen a sp_sysmon output from Sybase ASE you'd know what I'm talking about.
Hire people who are accomplished relational algebra freaks. Pay them a lot of money - it is well worth it!!! If I see another changelog entry like this I'm going to scream:
Optimized queries of type: SELECT DISTINCT * from table_name ORDER by key_part1 LIMIT #
So does that mean these queries were NOT AT ALL optimized before? It doesn't read 'FURTHER optimized'.
"ORDER BY
Does that mean it was table scanning each time? Jebus! Get these wiz-bangs to overhaul your query optimizer. Hands down this is one of the most important things in the database -- knowing how to use the database statistics and knowing when to use a merge-join vs. a hash-join etc. are CRITIAL to database performance. Trust me when I say that this is a MAJOR priority - especially over SSH or Unicode since it impacts EACH AND EVERY statement which MySQL parses.
Small things which can really raise the respect of MySQL in the eyes of people who matter - the CTOs and CIOs of the world who might be considering something like Postgres or MySQL but opt for MS SQL, Sybase, or Oracle because of the more advanced (but less flashy) features.
Of course, integrated row (or in the least page) locking and full support of subqueries and the like are also VERY HIGH priorities.
I think addressing these issues will vastly improve MySQL -- they're not flames really, just gripes
Thanks,
--
Matt