Oracle and Sun: Cui Bono?

Well, here’s a hint: it’s not Oracle, “Sun,” Java, or MySQL in the long run.

I’m thinking the Ruby, Python, and PostgreSQL worlds just got a shot in the arm, as this is minor calamity (at least) for Java, and a major one for MySQL. Ironic, since Java maturing like a fine wine and recovering from early-decade blunders; MySQL was already in trouble thanks to Sun.

As for benefits, it’s also not Google, who relies heavily on Java but could eventually find itself in an adversarial relationship with Oracle as enterprise computing moves to the cloud. Google does have enough sheer wo/manpower to exploit the OSS licensing on Java to take it in its own direction if necessary … but is that really a desirable way to go? or one the investors can live with?

I don’t think Microsoft minds this one bit either … since there was nothing that that Java, Oracle, and their communities (and users) couldn’t do before that they can now, while a number of scenarios (Java and open source databases/appservers in the enterprise) suddenly become just a bit murkier.

mod_ndb: Wicked REST for My[Giant]SQL Cluster

I caught a great presentation at CommunityOne a couple of weeks ago, and haven't had a chance to write about it until now.

In a nutshell, mod_ndb is an Apache module which allow a limited set of parametrizable MySQL queries to be automagically exposed as REST services via Apache. There are three things I left out of that sentence for clarity, that make this uber-cool:

1. The operations actually run against MySQL Cluster, a high-performance, shared-nothing (code for you don't need to manage a SAN and shared filesystem) scale-out system.
2. In exchange for not having full SQL capability, these services interact with MySQL Cluster using the cluster's native NDB API for maximum performance.
3. The latest version of MySQL Cluster, 5.1, has significant technical advantages over the earlier but still impressive 4.1 and 5.0. These include the ability to store more data on disk instead of dedicated RAM, and this collection of improvements. (In that doc, where you see references to 'carrier grade edition' note also that, according to the CommunityOne talk, future versions of MySQL Cluster will be on a unified codebase from that carrier grade version.)

I've liked MySQL Cluster since it's debut, and I'm thrilled to see this evolution.

As far as "let's download this right now and set it up," it is true that in the four years or so since that debut, the niche for scale-out clustering has narrowed:

On one hand, machines and storage have continued to get cheaper and faster, with the result that a data set and transaction load that might have a cluster of 2-4 dual-proc servers, and associated hassle, can now be handled by a single server with a couple of fat quad-core Xeons. The single OS and single filesystem simplify things vastly, to the benefit of databases like SQL Server, which have not invested in a scale-out strategy.

On the other hand, applications with a need for super-massive data that can live with some latency and a lightly structured, don't-call-me-relational data model can pay as they go for that scale-out capability with Amazon SimpleDB, Microsoft SSDS, etc.

Still, there is a well-defined middle section for a product like MySQL Cluster (and its arch-nemesis, Oracle RAC):

• big data sets and/or large-scale OLTP,
• plus a highly-structured relational data model. (Microsoft has asserted that SSDS will move toward full relational capabilities in the longer-term roadmap, but inasmuch as the initial service is still in beta, I don't count that.)
• legal or business requirements to keep the data in-house (not in the cloud)

Or you can flip it around the other way: if your app doesn't need a cluster like this (or something similar), what are you really doing, anyway?

In Which I Try to Save Someone from a Rails/MySQL BLOB Debugging Hassle

I was recently debugging an app and spent a bunch of time on a MySQL error symptom. I'd like to save the next developer from the same searches, since there are lots of documented MySQL connection issues with Rails, and few (any?) posts mentioning the following particular gotcha:

If you're getting the Lost connection to MySQL error, or its cousin, MySQL server has gone away (depending on whether you're using the Ruby driver or the Ruby-C driver), and you happen to be working with BLOBs (images, file uploads, streaming docs from a DB, etc.), there is a reasonable chance that the problem is you're sending too large a "packet" to MySQL. The "server has gone away" doc mentions this and refers to more detail at the "packet too large" error detail page.

In the current MySQL version, the default max packet size is 1 MB and by packet, they don't mean the TCP packet you might be using under your connection, they mean "a single SQL statement sent to the MySQL server, a single row that is sent to the client, or a binary log event sent from a master replication server to a slave." So it's actually quite easy to hit the default limit if you're working with BLOBs.

The limit can be raised in various ways (command-line, service config, etc.) and the doc points out that raising the limit should not in itself incur a performance penalty, as the additional memory is allocated only when needed.

Before cranking the max_allowed_packet setting up and calling it a night, though, it's also worth a quick sanity check as to whether you really mean to be reading and writing BLOBs this big. If you're storing videos or RAW data from a DSLR, then maybe yes.

In my case, I was using a heuristic for converting and compressing smallish photos and logos. I didn't intend to create a larger image than what the user was uploading (the largest test item was around 250kb), so the 1 MB default limit should have been fine. On closer inspection, a bug in my logic flow was incorrectly deciding to convert some 250K JPEGs into 4MB PNGs. Doh!