So yesterday I introduced the newly committed HTTP JSON key-value interface in Drizzle. The next step of course is to create some simple application that would use this to store data, this serves both as an example use case as well as for myself to get the feeling for whether this makes sense as a programming paradigm.
Personally, I have been a fan of the schemaless key-value approach ever since I graduated university and started doing projects with dozens of tables and hundreds of columns in total. Especially in small projects I always found the array structures in languages like PHP and Perl and Python to be very flexible to develop with. As I was developing and realized I need a new variable or new data field somewhere, it was straightforward to just toss a new key-value into the array and continue with writing code. No need to go back and edit some class definition. If I ever needed to find out what is available in some struct, I could always do dump_var($obj) to find out. Even large projects like Drupal get along with this model very well.
There will be a book signing opportunity at the MySQL User Conference, more precisely at the Expo Hall Community Reception on Wednesday evening. You will be able to meet and talk to authors of great MySQL related books. ...and myself.
Oh boy, I'm starting to feel the stress of having to prepare a little bit of this and a little bit of that for the upcoming MySQL User Conference (Santa Clara, April 10 to 13). But I wanted to also jump on this meme and list a few sessions I definitively want to attend:
I'm speaking, so I suppose I need to attend:
- How to evaluate which MySQL High Availability solution best suits you. This 3 hour tutorial I'm co-presenting with Ben Mildren, a former Nokia collague who now works with Pythian.
Alex Yurchenko finally posted results on a benchmark he has planned to do for a long time: Galera vs NDB cloud shootout.
Their blog requires registration to comment, so I'll post my comment here instead:
Sysbench can do the loadbalancing itself, so there is no need for external loadbalancer. Just add a comma separated list of master MySQL nodes to --mysql-host. This is similar to what the JDBC and PHP drivers can do too, and it is my favorite architecture. Why introduce extra layers of stuff that you don't need and that doesn't bring any additional value?
Earlier today I posted a Drizzle white paper we've been working on: Drizzle and IPv6.
With apologies to Planet MySQL readers. This post is about MySQL, but it is not technical, and probably not at all interesting to many of my usual readers. But it didn't fit in a tweet...
The Open Invention Network announced that its members have agreed to broaden the scope of the "protection" that it offers its members against software patent attacks against "The Linux System". Simon Phipps, a former Sun collague whom I follow on Twitter, covered the OIN in a very informative InfoWorld piece:
Yep. I see this too at work. InnoDB is in my opinion really good at handling concurrent workloads. So good I was surprised when I eventually found a project that was having locking issues. SHOW ENGINE INNODB STATUS showed queries had been waiting for hours on some locks they would never get. Yeah, it's a large and busy database, but it took me by surprise nevertheless.
It turns out, while InnoDB handles concurrent UPDATEs very efficiently, a combination of transactions that DELETE and INSERT rows - even just in the same general area of a table - will make the transactions wait for each other. Hence a workload that does a lot of inserts and deletes may get you into trouble. The solution is to change to READ COMMITTED or even READ UNCOMMITTED mode.
A week ago I again had the pleasure to give a guest lecture at Tampere University of Technology. I've visited them the first time when I worked as MySQL pre-sales in Sun.
To be trendy, I of course had to talk about the cloud. It turns out every section has the subtitle "...and why it is more difficult for databases". I also rightfully claim to have invented the NoSQL key-value development model in 2005.