Another round of discussion on in-memory OLTP data management
Oracle Exadata was pre-teased as “Extreme performance.” Some incorrect speculation shortly before the announcement focused on the possibility of OLTP without disk, which clearly would speed things up a lot. I interpret that in part as being wishful thinking. 🙂
The most compelling approach I’ve seen to that problem yet is H-Store, which however makes some radical architectural assumptions. One point I didn’t stress in my earlier posts, but which turned out to be a deal-breaker for one early tire-kicker, is that to use H-Store you have to be able to shoehorn each transaction into its own stored procedure. Depending on how intricate your logic is, that might make it hard to port an existing app to H-Store.
Even for new apps, it could get in the way of some things you might want to do, such as rule-based processing. And that could be a problem. A significant fraction of the highest-performance OLTP apps are customer-facing, and customer-facing apps are one of the biggest areas where rule-based processing comes into play.
Comments
3 Responses to “Another round of discussion on in-memory OLTP data management”
Leave a Reply
The whole stored procedure in C++ thing scares the living daylights out of me. I have never been a huge stored procedure fan, but then to have to downgrade to C++ in a proprietary fashion – that just seems like a strange way to go.
I understand the logic, but it would have to be an otherwise compelling solution for me to contemplate it.
I’m not going to check my notes as to what the latest language plan is for the most advanced H-Store commercialization project for H-Store is, since it was under NDA otherwise. (But please contact me privately about same if you care.) All I recall is that the Ruby idea was dropped due to performance.
I’d expect good language flexibility to be in early, whether or not it actually is there Day 1.
I have just been reading the various white papers sent to me by Vertica. C++ is feartured front and center.
IMHO the language needs to be slightly higher level – you don’t want to be in a place where a pinhole sized memory leak brings down the whole database.
I can un understand why Ruby would be eliminated, there really aren’t (yet?) any rocking fast VMs that I know about. It would be interesting to see the Model code of Rails’s MVC etructure execute “down there” though.
That leaves us with java. As long as they stay away from EJB, and do something lightweight, I suppose that will be OK. Since Oracle owns it (or will soon), every DBMS vendor that embeds java will at least look twice.
Whatever the method, there has to be a whole lot better IDE, debug and development support than the version 1.0 kinds of stored procedures that we see today.
I would expect:
Realtime debuggers
Unit test frameworks
Refactoring capabilities
Version management
Team development capabilities
all to be present before the thing can be considered ready for prime time.