Sheeri and others are organizing another incarnation of OpenSQL Camp in October in Boston. You ought to go! It’s relevant to MySQL, PostgreSQL, SQLite, and lots of the newer generation of databases — MongoDB, Cassandra, and so on.
Related posts:
OpenSQL Camp Boston 2010 will be held at the Stata Center in Cambridge, Massachusetts, October 15-17, 2010.
The Stata Center was designed by Frank Gehry and was completed in 2005. The Stata Center houses CSAIL (The MIT Computer Science and Artifical Intelligence Laboratory) and LIDS (The MIT Laboratory for Information and Decision Systems). Some of my favorite pictures of the Stata Center were taken during construction. (I’m a member of CSAIL)
The OpenSQL Camp will be held on the first floor of the Stata Center where we’ve reserved four classrooms (with capacities 318, 90, 60, and 60 respectively). We expect to have access also to the social areas along the interior “student street”.
The OpenSQL Camp has been running since 2008 in an “unconference format” with a blend of spontaneity and planning, no registration fees, and is open for all essentially on a first-to-sign-up basis (the sign up sheet isn’t up yet, however). The unconference typically includes seminars, hackathons, freeform discussions, and socializing with discussion topics including MySQL, PostgresQL, NoSQL, Maria, Drizzle, Storage Engines, the implications of new hardware and data structures technologies, and “soft” topics such as the formation of the Open Database Alliance, as well as anything else people want to talk about.
Mid October is near the peak of the fall foliage season. We are trying to get the conference organized early so that people will be able to find reasonable accomodation and travel arrangements.
It looks like Sheeri and I will be doing a lot of the legwork to organize this event, but this event can succeed only if many people pitch in to make it work.
I hope to see you there!
I just spotted the youtube video of my OpenSQL Camp (Portland 2009) talk on An Open Storage Engine API. I talked about some of technical issues for implementing storage engines across many SQL front ends, not just MySQL.
You can find this talk and other mostly technical material at http://tokutek.com/technology/.
I recently discovered that there’s a youtube video of the talk I gave at OpenSQL Camp in Portland in 2009.
This is a whiteboard presentation and is less well developed than the talk I gave a the MySQL conference (I posted those slides two days ago. But since it includes audio it may be easier to understand.
This talk presents the data structure underlying the TokuDB storage engine for MySQL.
I got a couple of questions and comments about OpenSQL Camp in the past week, and I thought it would be worth noting down the history, because I think there is some difference in perception and memory about this series of events. The following is only my point of view.
I can say what I had in mind when I created the original event, but this is bigger than me, so I don’t get to dictate anything. I wanted a free technical event created entirely by and for a community of open-source databases, in an inclusive sense. Not created or heavily influenced by someone employed by a corporation whose job title includes the word “Community,” but really by a community themselves. There’s nothing wrong with Community So-And-So employed at a corporation, but they are by nature a liaison with that company, and it’s not the same thing. My original blog post about this topic is probably the clearest explanation of what I had in mind.
Nobody. That’s right — I deliberately abdicated control over things. I wanted it to be decentralized. Centralization is a problem; decentralization prevents problems. As just one example, Sheeri Cabral owns opensqlcamp.org the last I saw, and Technocation tends to be the default conduit for all things financial.
If someone wants to take things in a new direction, then they can do so. I don’t know if anyone would show up for an event that didn’t really match the spirit that I think is lodged in people’s minds now, but there is no stick you can brandish, other than threat of negative publicity.
Nothing whatsoever. MySQL Camp was a series of mini-conferences about MySQL, a particular open-source database. There the resemblance ends. OpenSQL Camp is not “the same thing under a different name,” and it’s not even “the continuation of MySQL Camp.” It’s not even a MySQL event. If you want to look at a particular MySQL event and see where a seed was planted, look to the commercial MySQL conference, not the free MySQL Camp; but you’d be much better off looking at beCamp as a root than anything to do with MySQL.
I created OpenSQL Camp to set off in a new direction. However, the idea was not fully my own. A brief timeline begins in the Spring of 2008, after I’d been to a few MySQL Camp events and could see that something was lacking:
I heard a rumor this past week that planning for at least one event is in progress, but isn’t public yet. I had not heard this news until then myself, which again I think is awesome. This is exactly the point: nobody needs to get approval from any “authority” to run these things.
This entire conference was born out of an “I see a lot of talk but no action” kind of situation. I generally don’t believe in surprise when a community is involved, but sometimes there is a lot of chatter, and talk is actually preventing action — to get things to happen, you actually have to stop talking. These events were born out of my realization that two things were true:
Sometimes, it’s simply time to shut up and do stuff.
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
As pointed out by Schlomi Noah on my last blog, MySAR was already taken by a project related to Squid reports with MySQL. I decided then to look for a new name, and as I posted initially, I want to keep the sar prefix to describe the script’s purpose by association with the OS utility of the same name. I brainstormed many names. I liked Dave Edwards’s suggestion: SARkila, but it sounds too close to tequila, so I settled with Sheeri Cabral’s suggestion: sar-sql.
The title of the Launchpad page already reflects the change. What remains to be done is: a) change the name of the Perl script and documentation; and b) change the Launchpad URL. It is likely that I will change the name of the script when I release version 1.x (see below). I’m not sure of all the implications in Bazaar regarding the URL change, so that task will have to wait for now.
Now a little more info on the status of the project.
In the latest trunk there are two patches. One corresponds to Bug #455870, which should be fixed. I’m excited since this bug was posted by a user. (Yay!)
The 2nd patch refers to a bug that came up during an implementation in a client, in a master-slave configuration (in hindsight, I should have thought about it earlier). The snapshots from the master were being replicated to the slave, so when the script ran on the slave, the autoincrement values were in conflict and stopped replication. In the latest patch (build 16), I have added a column that records the server id, as in SHOW GLOBAL VARIABLES LIKE 'server_id' to distinguish the master and slave data. I like the fact that it is possible to query the master and slave snapshots side by side to diagnose slave lag. This change makes the last version in the trunk incompatible with the newer ones, which triggered the creation of the first README file.
I will be posting a new tarball soon.
Believe or not, there are enough ideas in the queue to justify a road map. Here’s a summary list and you’re welcome to comment on it. I promise to review all the suggestions.
As I mentioned above, the script currently works, but it’s far from optimal. So I’ll be changing the code base with two objectives. 1) Increase overall efficiency; and 2) facilitate future improvements. The more profound code changes will be implemented in version 0.x (current version). I believe that messy code leads to bugs, so the cleaner it is, the less likely I’ll break existing functionality while adding new one.
Adding new functionality implies that the script will perform more tasks which in turn will add overhead to each one of them. To minimize this overhead, I am working on a different command line syntax and the corresponding underlying code. This change will happen in version 1.x (the next version) since the code has to be cleaned up to be effective and works as it is. The command line syntax change will imply rewriting any wrapper script that might be in place to invoke in the crontab, so this will be the opportunity to rename the script as well.
The script is so simple that distributing a tarball is enough for now, but I’d like to have an installer and possibly a package that will take care of the Perl modules dependencies, schema initialization and user credentials verification / creation. I have no target version for this. I’ll shoot for 1.x, but it’s likely to go into 2.x.
I’m still working on plenty of use cases, best practices, and companion scripts examples. In time, the example scripts and documentation will be part of the complete package and installed along side with the main utility. In the meantime, just follow the blogs and the links to them in the Launchpad announcements page.
Having a user file a bug, Schlomi’s bringing up the name issue, and Sheeri contributing with her sanity checks are a great help, but I invite all of you out there to participate through comments to my blogs, bug reports, questions in the Launchpad page, and replying to my tweets.
I will be participating in OpenSQL Camp in Portland, OR next month. I’m sure I will have an opportunity to review my ideas with the old friends I’ll be meeting there. Stay tuned.
