Welcome to the 62nd edition of Log Buffer, the weekly review of database blogs. You know, I haven’t actually written one of these since LB#46, way back in May, so I hope I haven’t lost my touch. I guess we’ll see, eh?
An item in last week’s Database Column by Mike Stonebraker, a guru figure in the world of DBMS development, got around this week, was covered on Slashdot, and so it has drawn quite a lot of response.
In One size fits all, Stonebraker asserts that, while hardware capacity has greatly changed since he helped to create the RDBMS 25-odd years ago, the fundamental characteristics of the DBMS largely have not, and that the systems are therefore outmoded for at least some applications. He goes on to say that, by better orienting itself to today’s hardware, his current technology venture represents the way forward, specifically for the data warehouse.
Mark Rittman provided a quick explanation of the technological background: columnar data storage.
On DBMS2, Curt Monash responded to what he saw as three bold assertions in the article, in particular, the claims Stonebraker makes for the speed of his technology, and that the columnar approach is right for all classes of data storage.
Kevin Closson’s reaction to the putative death of row-oriented RDBMS technology is amongst many of the “well, he would say that, wouldn’t he” kind. In Kevin’s opinion, Stonebrakers speed claims, “…(look) cut and pasted from a Vertica data sheet-but I don’t know. One thing I do know is that it seems unwise to say things like ‘all’ and ‘typically by a factor of’ in the same sentence. And this bit about ‘set-up and loaded’ taking ‘weeks’ for the ‘major vendors’ is just plain goofy.” (Nuno Souto’s first comment puts it in a pithier fashion, but I’ll leave that for your visit to Kevin’s page.)
Anant Jhingran likewise deems the article, “…a blatant ad for Vertica,” and he disputes the practical significance of, “(providing) an equivalent bit replacement…”.
Sheeri Kritzer, the MySQL She-BA, said what needed to be said: “I think that MySQL comes the closest to a DBMS that is NOT ‘one size fits all’, given the multiple storage engines available.”
Chris Eaton from An Expert’s Guide to DB2 Technology finds fault with the Stonebraker argument for reasons of pragmatism. Using the ever-popular car metaphor, he wrote: “Where I come from you don’t see many Porshe Boxsters on the road. Why not? … Because I don’t think they would handle Canadian winters very well and there isn’t enough room to put my son and daughters hockey bags in the trunk and take then to the ice rink in the snow. I can’t afford to have a car sit in my garage all winter so I choose cars that can do more than just go fast and look great.”
Tim DiChiara on Eye on Oracle: “(Are) column-oriented databases inherently faster, or is bad Oracle database design the root cause of the apparent difference?”
Okay, enough of that. Let’s move on to some blogs on one of Mr. Stonebraker’s children, PostgreSQL. On Merlin’s Stuff, Merlin Moncure, writes about managing trees with arrays. “I’ve made it my quest to debunk the prevailing myth that recursive structures are not ‘relational’ and thus should be handled in application code or some alternative format. … What follows is a demonstration of how one might use the arrays of integers in PostgreSQL in a variation of the classic ‘materialized path’ method of organizing data in trees…”
</depesz> writes about some PostgreSQL gotchas you might not have considered. “…don’t expect any postgresql-bashing. if you want some, indicate so in comments, I’ll find some things to bash postgresql for. … but in here I’d rather bash us – people – for making mistakes. the ones that are not really easy to see as mistakes for database.”
On the Revolution Systems Blog, Frank Wiles conveys a simple tip for discovering which PostgreSQL backend a particular client is connected to.
Some Oracle stuff now, starting with something of a challenge from Tom Kyte, something that seems simple enough, but has a hidden wrinkle.
Tom also announces the second part of his 11g podcast, and also writes about the dangers to life that programming creates. If you’ve ever wished you could “grep” for something in your kitchen, you’ll understand.
With more conferences on the way, the blogging has begun. Pythian’s Alex Gorbachev has a short one about the upcoming Miracle Oracle Open World.
A late addition: I would be remiss if I failed to mention Jay Pipes’s announcement of the 2008 MySQL Conference’s call for participation.
Firebird News introduces the seminars and conferences page of the Firebird website. (Guess what? There are some, including the Fifth International Firebird Conference taking place in Hamburg in October.)
If you’re keen on getting an OCA, die Seilerwerks’s Don Seiler shows how he prepared for the Oracle 10g OCA Exam.
On One size doesn’t fit all, Chris Muir asks, what features would you like to see in PL/SQL?. (Of course, as he complains, Steven Feuerstein got there first.)
Eddie Awad issues a warning: Do Not Use This New Oracle Database 11g Feature — PL/Scope. Then it says something about corrupt databases. I guess you should probably read this.
Alex Kornbrust about Oracle security published his presentation PDF on hacking hardened and patched Oracle databases, showing how SQL*Plus scripts may be vulnerable to SQL injection.
Tyler Muth writes about RMAN encrypted backups: “A number of recent high profile data thefts have resulted from lost or stolen backups that were not encrypted. Offsite backups are a good first-step in a Disaster Recovery plan, but they also create a huge risk for data theft. Even if the backup is not offsite, a backup sitting around your office represents nicely packaged target for someone to steal.” He has prepared a demonstration screencast.
In the MySQL quarter, Zach Urlocker has an update about two of that DBMS’s up-and-coming storage engines, MyBS and Falcon.
On Optim MySQL, Parvesh Garg elucidates a fine point of InnoDB row-level locking: “…InnoDB row level locking works in a somewhat different manner when using indexes. In this case, InnoDB locks index records in shared or exclusive mode when searching or scanning an index. Therefore, as mentioned in MySQL Documentation, the row level locks are actually index record locks.” Of course, there are workarounds, and he has them.
The MySQL Performance Blog likewise offers some tips on bypassing caches at various system levels.
Okay, that’s all for now, although there’s always more of course. Next week, the incomparable Craig Mullins does his second edition of LB. Please get in touch with me, the Log Buffer coordinator, to edit and publish an edition of your own.
2 Comments. Leave new
I was a fan of Michael Stonebraker when I first read his “The Ingres Papers” some 20 years ago when I started with RDBMS products (that’s a long time ago). I read the white papers several months ago on Vertica but after being contacted by them I never pursued any level of testing. It will be interesting to observe what transpires with this idea.
Dave,
regarding one size fits all DB. I’ll wait for someone to create a bunch of tables with one column each in oracle and then let them go head to head.
Raj