Comments on: What is the scalable replacement for InnoDB? http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/ Stay curious! Thu, 09 Feb 2012 09:56:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Hindsight on a scalable replacement for InnoDB at Xaprb http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/#comment-16435 Hindsight on a scalable replacement for InnoDB at Xaprb Sat, 09 May 2009 20:40:39 +0000 http://www.xaprb.com/blog/?p=767#comment-16435 [...] while ago I posted about a comment a Sun performance engineer made about a scalable replacement for InnoDB. At the time, I did not believe it referred to Falcon. In hindsight, it seems even clearer that the [...] [...] while ago I posted about a comment a Sun performance engineer made about a scalable replacement for InnoDB. At the time, I did not believe it referred to Falcon. In hindsight, it seems even clearer that the [...]

]]> By: Log Buffer #131: a Carnival of the Vanities for DBAs http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/#comment-15684 Log Buffer #131: a Carnival of the Vanities for DBAs Fri, 16 Jan 2009 17:21:15 +0000 http://www.xaprb.com/blog/?p=767#comment-15684 [...] and a couple questions pertaining to InnoDB. The first comes from xaprb’s Baron Schwartz: What is the scalable replacement for InnoDB? — a question provoked by a statement by a Sun engineer that Sun is working on this [...] [...] and a couple questions pertaining to InnoDB. The first comes from xaprb’s Baron Schwartz: What is the scalable replacement for InnoDB? — a question provoked by a statement by a Sun engineer that Sun is working on this [...]

]]> By: Mark Callaghan http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/#comment-15671 Mark Callaghan Wed, 14 Jan 2009 18:40:42 +0000 http://www.xaprb.com/blog/?p=767#comment-15671 Yes, InnoDB has provided valuable feedback on the rw-mutex patch and not yet published changes that reduce mutex contention on the transaction log mutex and buffer cache mutex. Valuable == fixed a few bugs, improved code quality and portability. They also have published 5.1 as a plugin so that it is easy for anyone to publish updated versions of it separate from the MySql release cycle. Yes, InnoDB has provided valuable feedback on the rw-mutex patch and not yet published changes that reduce mutex contention on the transaction log mutex and buffer cache mutex. Valuable == fixed a few bugs, improved code quality and portability. They also have published 5.1 as a plugin so that it is easy for anyone to publish updated versions of it separate from the MySql release cycle.

]]> By: Ken Jacobs http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/#comment-15667 Ken Jacobs Wed, 14 Jan 2009 04:19:50 +0000 http://www.xaprb.com/blog/?p=767#comment-15667 Sorry, Vadim, we've already fixed the issues we found in the (Google, not Percona) patch. The people who know InnoDB best are the InnoDB group at Innobase. We respect what you guys do, but there is not much value (to us, admittedly) in showing you what those issues were at this point. This isn't about the "power of open source". It's about doing what's right for InnoDB users. That includes making sure any patches we do include in InnoDB are completely solid and reliable. The best way to do that is for the InnoDB team to be careful and thoroughly test and evaluate potential solutions to possible problems. Again, stay tuned. Sorry, Vadim, we’ve already fixed the issues we found in the (Google, not Percona) patch. The people who know InnoDB best are the InnoDB group at Innobase. We respect what you guys do, but there is not much value (to us, admittedly) in showing you what those issues were at this point.

This isn’t about the “power of open source”. It’s about doing what’s right for InnoDB users. That includes making sure any patches we do include in InnoDB are completely solid and reliable. The best way to do that is for the InnoDB team to be careful and thoroughly test and evaluate potential solutions to possible problems.

Again, stay tuned.

]]> By: Xaprb http://www.xaprb.com/blog/2009/01/13/what-is-the-scalable-replacement-for-innodb/#comment-15666 Xaprb Wed, 14 Jan 2009 03:59:40 +0000 http://www.xaprb.com/blog/?p=767#comment-15666 Sheeri, "What is scalable" is one of the primary questions I had in the blog post. Who defines scalable? Again I don't think MrBenchmark talks the same language the rest of us on this thread so far talk. But it's not just him. Look at the video on the front page of http://www.sun.com/systems/solutions/mysql/ and notice what Mikael Ronstrom says about Cluster: "MySQL has been focusing its efforts on dual-core systems for a long time, and it's only recently that we've seen this massive development of multi-core systems in the world. So customers care very much about scalability, I mean they, they buy systems with 16 cores and they expect to be able to use all those 16 cores." OK, so far so good, although I take exception to "only recently." But then, they cut the video and immediately show him saying "So we have actually achieved linear scalability of MySQL Cluster..." Those two have nothing to do with each other. And, right now Cluster is single-threaded, so it's *less* scalable -- you can use one core per instance, period. (I know that is supposed to change, but... I'll save my predictions about that for later). Any way you look at it, it's a bait and switch. So, my rhetorical question remains: by what criterion does this wait-and-see storage engine scale? Sheeri,

“What is scalable” is one of the primary questions I had in the blog post. Who defines scalable? Again I don’t think MrBenchmark talks the same language the rest of us on this thread so far talk. But it’s not just him. Look at the video on the front page of http://www.sun.com/systems/solutions/mysql/ and notice what Mikael Ronstrom says about Cluster:

“MySQL has been focusing its efforts on dual-core systems for a long time, and it’s only recently that we’ve seen this massive development of multi-core systems in the world. So customers care very much about scalability, I mean they, they buy systems with 16 cores and they expect to be able to use all those 16 cores.”

OK, so far so good, although I take exception to “only recently.” But then, they cut the video and immediately show him saying

“So we have actually achieved linear scalability of MySQL Cluster…”

Those two have nothing to do with each other. And, right now Cluster is single-threaded, so it’s *less* scalable — you can use one core per instance, period. (I know that is supposed to change, but… I’ll save my predictions about that for later). Any way you look at it, it’s a bait and switch.

So, my rhetorical question remains: by what criterion does this wait-and-see storage engine scale?

]]>