[openstack-dev] [Keystone] Best way to do something MySQL-specific?

Monty Taylor mordred at inaugust.com
Tue Jul 9 16:27:50 UTC 2013

On 07/09/2013 11:21 AM, Clint Byrum wrote:

>>> You may want to update your snark! MySQL has its warts which are pretty
>>> easy to take shots at, but it has been a "real" ACID compliant database
>>> for well over a decade.
>> My snark is more recently generated than that.  There are plenty of 
>> places where MySQL has fallen down.
>> InnoDB support was not mandatory, and without it, MySQL was not really 
>> ACID compliant.  Using InnoDB was troublesome enough that the RHEL 6 
>> version of MySQL defaults to MyISAM.
> Its not so much that it was troublesome to use InnoDB as it was that
> people were used to MyISAM's few mis-features (fulltext and delayed
> inserts mostly) and needed a long warning (run up to 5.5) that the
> default was changing. Before 5.5 was released, Drizzle _completely
> removed_ MyISAM because it causes way more problems than it solves.

Let's try to avoid snarky database flame wars. There are enough of us in
this community with massive experience in each database that they are
useless to have.

MySQL and PostGres are both lovely databases that are both completely
valid choices for production. If anyone out there wants to have a beer
and attempt to convince me otherwise, you are welcome to. You will not
succeed. All snark aside, the current body of evidence for the current
state of both databases will vastly outweigh any snark. The_historical_
body of evidence for both databases has ridiculous warts, but is pointless.

That said, we, as a project, seem to have made the decision that we find
it important to support any biases you may have as a deployer by
supporting multiple database backends via SQLalchemy. However, OpenStack
is intended to be something that can be used for real large-scale
production workloads. Most large scale database apps are NOT written in
a database agnostic manner, because every database out there has
performance quirks that have to be considered, and has a different set
of tools for making things work.

How do we deal with that dichotomy? I think it might behoove us to
figure out a _sensible_ way to allow for engine-specific overrides of
sqlalchemy behavior where appropriate. The sqlaclchemy code should be
totally functional and correct, but there are clearly times when a
single well-crafted query, or taking advantage of a database-specific
extension could make a massive difference for a large deploy.

I don't think we should start peppering our code with a bunch of ifs. If
we want this, we need an understandable, sensible and repeatable
mechanism for engine-specific optimizations. Something tells me this
will not be the last time the question comes up.


More information about the OpenStack-dev mailing list