VectorWise has emerged from stealth mode. Even more interesting is that Ingres is collaborating with them on Ingres VectorWise. And most interesting is the video made to promote the work. In the interest of disclosure, I have friends who work on this at Ingres and VectorWise.
I have read many of the papers on X100 and MonetDB and believe the performance claims they make. Within the MySQL community, this is most similar to Kickfire in terms of the query workloads it can support. The difference is that VectorWise writes their software to run at full speed on a modern CPU and maintain a high IPC rate while Kickfire uses custom hardware (and a lot of really good software that they probably cannot describe without an NDA). Anyone attempting to build a VectorWise storage engine would have to do all of the fun things that KickFire has done to circumvent much of the MySQL optimizer and execution code, so I doubt that will be repeated.
-
I have been curious about Monty Program AB as their mailing list has been relatively quiet. They have been too busy to write much as they are setting up the company, talking to customers and doing real work including debugging the problems with MRR/BKA/ICP and InnoDB (thanks Igor and Sergey).
I will let them reveal their plans for growing the MariaDB community but I hope it includes my agenda of improving MySQL replication. Drizzle has a very clean interface for providing different replication implementations. I think the same is possible with MariaDB. It won't be as clean as the API in Drizzle because it has not diverged from MySQL source, but it should allow us to provide interesting alternatives (sync replication, conflict resolution with multi-master) in a reasonable amount of time. With such an interface and with row-based replication we can make it much easier and less expensive to manage a large MySQL deployment.0Add a comment
-
Do you know SQL or do you NoSQL? MySQL has been very popular for internet-scale deployments. But times have changed and there are alternatives. The alternatives either out-scale or out-avail MySQL and this is more important than providing the features of an RDBMS for many applications. My prediction is that there will be much less usage of MySQL for internet-scale applications in the future if we do not make big changes.
What are the problems and what can we do to fix them? From my perspective there are two problems:
- MySQL is not efficient on modern hardware (multicore, many disk IOPs)
- Replication is very expensive to manage
Replication requires much more work. I want more automation and more flexibility.
The lack of automation is apparent when you consider the replication related errors that require manual intervention. These errors are frequent or constant when you run a large number of MySQL servers. It is very expensive to support MySQL in this environment. Actions that must be automated include:
- the promotion of a slave to a master after the failure of the master
- failover of slaves to the new master
I have more ideas to improve replication but it isn't clear to me that I can afford the cost to modify the replication code in official MySQL. But then I looked at the code for Drizzle. Wow! The code is clean, easy to read and easy to modify. So I still have hope for MySQL-related technology in the datacenter, but in the form of Drizzle.7View comments
-
I use http://dev.mysql.com every day. But not today as the site is down. There is a mirror of the docs at http://docs.sun.com/source/mysql-refman-5.0/index.html. Although the docs license is one of my favorite topics, I am not a lawyer. Does the license not allow others to serve a copy of the docs?4
View comments
-
What does it mean to release a server with no known crashing bugs? I don't know. A lot of this depends on your perspective. Perhaps old releases of MySQL were done with no known crashing bugs, but this means that testing for current releases is much more rigorous. If you don't believe me then read some of the bug updates from Shane and others to understand how good they are at testing it.
I judge quality by whether I can depend on the code in production. Both 4.0 and 5.0 have been stable in production for me and both have had crashing bugs. I am sure that MySQL 5.0 releases have had more known bugs than 4.0 releases as 5.0 has more features, a larger community testing it and is run on much larger hardware (more RAM, more disks, multicore, more load). Note that my perception of 5.0 is based on using it with many features disabled including query cache, subqueries, stored procedures, triggers and views.
The quality metric that I am interested in is the number of major releases for a feature to become stable in production and feature complete. I don't mind when this number if more than 1 as long as I can disable the feature. But this number should never exceed 2.2View comments
-
I don't always agree with Monty but this time he is right. Now is the time to provide feedback on the merger. I wish there were more commentary on plans for MySQL after the merger.
My concern is the documentation license. If we want to improve MySQL at a faster rate than the docs copyright holder, then we must create separate documentation as we cannot publish a modified version of the official documentation. Several people have written about this before including me, Baron, Sheeri, Arjen and Justin.
Despite comments on stage between Karen and Kaj at the User Conference, there have been no changes to the docs license. The lead for the MySQL docs team explained to us that there will be no change and he deserves kudos for his bravery. I am very disappointed that neither Karen nor Kaj have said anything on this topic since then.
What else can you do? Find a different community. Check out the activity on the Drizzle mailing lists. I don't participate in Drizzle but I lurk there and am extremely impressed by the activity on the mailing lists and the changes they make to the code. MariaDB has yet to become active for external developers but it is quickly gaining momentum.6View comments
View comments