That’s right, I said InnoDB+, with a “plus” at the end. I didn’t know it existed until, while following some links from Monty’s appeal to save MySQL, I decided to read a Groklaw post that links to Eben Moglen’s letter to the EU Commission, which includes this text:
Innobase could therefore have provided an enhanced version of InnoDB, like Oracle’s current InnoDB+, under non-GPL license, …
I don’t know anything more. Do you?
Related posts:
[Read more]O’Reilly’s official website announces that they are planning a MySQL conference in 2010 (same time, same place). Unlike past years, it isn’t co-presented with Sun/MySQL; they are flying solo. The theme is Information Unleashed.
Related posts:
…
[Read more]The best overall method of performance optimization is optimization for response time. Users care about response time, not load average or cache hit ratios. The job of a system is to accept some request and do the required work, and deliver a result. The time elapsed between the request and the result is the response time.
Methods of Response Time Optimization
Not all optimization methods are created equal. Here are a few I see commonly.
The No-SQL tag really lumps together a lot of concepts that are in fact as distinct from eachother as they are from SQL/RDBMS.
An object store is not at all similar to Cassandra and Hypertable, which is not at all like an column store. And when looking at BigTable derivatives, it’s quite important to realise that Google actually does joins in middle layers or apps, so while BigTable does not have joins, the apps essentially do use them – I’ve heard it professed that denormalising everything might be a fab idea, but I don’t quite believe in that for all cases, just like I don’t believe in ditching the structured form of RDBMS being the solution.
SQL/RDBMS has had a few decades of dominance now, and has thus become the great “general purpose” tool. With the ascent of all the other tools, it’s definitely worthwhile to look at them, but also realise that each (inluding SQL based ones) have their place. Moving all your …
[Read more]If you haven’t seen it, Josh Berkus has a very concise way to look at the confusing mess that is database “clustering” from the point of view of three distinct types of users: transactional, analytic, and online. I think that using this kind of distinction could help keep discussions clear — I’ve seen a lot of conversations around clustering run off the rails due to disagreements about what clustering means. MySQL Cluster, for example, is a huge red herring for a lot of people, but it seems to be a difficult process to learn it well enough to decide. If we called it a clustering solution for transactional users, but not for analytic or online users, it might help a lot.
Related posts:
Ever been around a group of people discussing some technology and heard Cool-Whip phrases like this?
It’s not about MySQL versus PostgreSQL, it’s about using the right tool for the job.
Or how about this one?
You need to take the important factors into account before you decide whether [hot new fad] or [trusty old solution] is best suited for your application.
Both are signs that someone might be trying to sound important. In situations like this, I’ve noticed that the people I look up to usually don’t make weighty-sounding statements about other people’s systems. They talk about what they are qualified to talk about: either they say something about their own systems, or if it’s warranted and invited, they ask intelligent questions about other people’s systems.
People who only have vacuous generalities to contribute don’t talk about their own systems, because if they actually worked on …
[Read more]I was at OpenSQL Camp 2009 in Portland last weekend. I thought the event was very well done. On Friday we had a pizza party at Old Town Pizza, which was awesome. Saturday and Sunday were breakfast, sessions, lunch (yum), and sessions and hacking. These were held at souk, a co-working space. After 5PM, people got together for dinner, beer, etc.
I presented on mk-query-digest — a live demo of features requested by the audience. Sessions from others that I thought were particularly good included ones on CouchDB and MongoDB. I mixed up the time and missed the session from Tokutek on how fractal tree indexes work. I’ll try to watch the video if that one was taped.
During the hackathons, Daniel and I worked on Maatkit. We are laying groundwork for a more powerful mk-query-digest.
As you may know, I …
[Read more]You used to use mk-query-digest to aggregate and report on MySQL’s slow query log. Then it got the ability to grab query events from polling SHOW PROCESSLIST. Next we thought, really, how hard can it be to implement the libmysql wire protocol, so we can sniff TCP packets? … it’s hard, but not that hard as it turns out. But why stop there, why not implement memcached protocol too? I think you can see where this is headed.
So now mk-query-digest is a tool that can understand and “do stuff with” a variety of query/response types of information. The latest is HTTP. HTTP traffic is just a query-response flow of events, perfectly suitable for response-time analysis. Example:
baron@kanga:~$ mk-query-digest sample-http.txt --type http
# 1.6s user time, 100ms system time, 14.20M rss, 17.07M vsz
# Overall: 56 total, 30 unique, 1.27 QPS, 0.06x concurrency ______________
# …[Read more]
Last week I attended the Enterprise LAMP Summit and Camp in Nashville, Tennessee. I enjoyed the event and met or reconnected with a lot of great people. I was glad to be able to spend time with some folks from the Postgres community. My own sessions focused on MySQL.
During the Summit I tried to help people understand how to think about performance, and made the case that the Percona versions of the MySQL server are not only the highest-performance available, but uniquely provide the instrumentation necessary to follow a disciplined performance optimization process such as Method R or Goal-Driven Performance Optimization.
At the Camp the next day, there were several sessions on MySQL. My talk was later in the day, so I elected to skip …
[Read more]