There are some big things coming on the horizon that, coupled with coding tendencies people are already displaying, could be real game changers.
We all know that no one really spends much time hand-writing SQL anymore. Whether you think it’s a good idea or not (and we might just get in to that, too) the majority of people out there who aren’t using PHP are writing applications using ORMs. Hibernate, JDO, JPA, SQLAlchemy, ActiveRecord. It’s what people are doing, and it allows them to focus on writing the objects their application needs.
But there is an efficiency problem, and many of the real performance nuts get hot and bothered when confronted with ORM’s generating SQL Queries. SQL isn’t exactly the best medium for serialization of data, and trying to generate optimal sequences isn’t always successful.
What happens when we take the abstraction of ORMs, and match it with databases exposing lower-level interfaces to send queries?
With the NDB API in MySQL Cluster, you get storage engine level calls like “fetch tuple” or “scan index”.
In Drizzle we’re talking about the possibility to pushing parsing to the client and sending serialized parse trees or maybe even query plans to the server directly.
Google is already doing something similar to this in Google App Engine. The DB layer looks like the Django ORM, but on the backend it’s talking to non-SQL-based Google Storage stuff.
Why should your ORM generate SQL strings so that it can send them to the server who will then just parse the SQL strings to generate storage operations. What if the ORM layer, with the extra amount of knowledge it has about Unit of Work and Context of the operations, just generated API calls or built parse structures directly?
Better efficiency! Less impedance! Maybe even a better ability to automatically generate smart transaction boundaries!
Monty Taylor is an Engineer for Sun. He’s the crazy guy who wrote the NDB/Bindings in the first place (why write one language when you can have six?) and is currently one of the crazy guys hacking on Drizzle full time. Up until a few days ago, he was also a Senior Consultant for MySQL, where he focused on MySQL Cluster, DRBD and other High Availability solutions.
Monty is a Python programmer by first choice (and yet he hears the obvious joke surprisingly infrequently) but seems to be spending all of his time recently in C, C++ and Java.
Comments on this page are now closed.
For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at email@example.com
Download the MySQL Sponsor/Exhibitor Prospectus
For media-related inquiries, contact Maureen Jennings at firstname.lastname@example.org
To stay abreast of conference news and to receive email notification when registration opens, please sign up for the MySQL Conference newsletter.
View a complete list of MySQL contacts.