Open Stack

Li Ma,

This is interesting, In general I am in favor of expanding the scope of any
read/write separation capabilities that we have. I'm not clear what exactly
you are proposing, hopefully you can answer some of my questions inline.
The thing I had thought of immediately was detection of whether an
operation is read or write and integrating that into oslo.db or sqlalchemy.
Mike Bayer has some thoughts on that[1] and there are other approaches
around that can be copied/learned from. These sorts of things are clear to
me and while moving towards more transparency for the developer, still
require context. Please, share with us more details on your proposal.

-Mike

[1]
http://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html
[2]
http://techspot.zzzeek.org/2012/01/11/django-style-database-routers-in-sqlalchemy/


On Thu, Aug 7, 2014 at 10:03 PM, Li Ma <skywalker.nick at gmail.com> wrote:

> Getting a massive amount of information from data storage to be displayed
> is
> where most of the activity happens in OpenStack. The two activities of
> reading
> data and writing (creating, updating and deleting) data are fundamentally
> different.
>
> The optimization for these two opposite database activities can be done by
> physically separating the databases that service these two different
> activities. All the writes go to database servers, which then replicates
> the
> written data to the database server(s) dedicated to servicing the reads.


> Currently, AFAIK, many OpenStack deployment in production try to take
> advantage of MySQL (includes Percona or MariaDB) multi-master Galera
> cluster.
> It is possible to design and implement a read/write separation schema
> for such a DB cluster.
>

I just want to clarify here, are you suggesting that _all_ reads and _all_
writes would hit different databases? It would be interesting to see a
relational schema design that would allow that to work. That seems like
something that you wouldn't try in a relational database at all.


>
> Actually, OpenStack has a method for read scalability via defining
> master_connection and slave_connection in configuration, but this method
> lacks of flexibility due to deciding master or slave in the logical
> context(code). It's not transparent for application developer.
> As a result, it is not widely used in all the OpenStack projects.
>
> So, I'd like to propose a transparent read/write separation method
> for oslo.db that every project may happily takes advantage of it
> without any code modification.
>

The problem with making it transparent to the developer is that, well, you
can't unless your application is tolerant of old data in an asynchronous
replication world. If you are in a fully synchronous world you could fully
separate writes and reads, but what would be the point since your database
performance is now trash anyway. Please note that although Galera is a
considered a synchronous model it's not actually all the way there. You can
break the certification of course, but there are also things that are done
to keep the performance to an acceptable level. Take for example the
wswrep_causal_reads configuration parameter[2]. Without this sucker being
turned on you can't make read/write separation transparent to the
developer. Turning it on causes a significant performance degradation
unfortunately.

I feel like this is a problem fundamental to a consistent relational
dataset. If you are okay with eventual consistency it's okay, you can make
things transparent to the developer. But by it's very nature relational
datasets are well, relational, they need all the other pieces and those
pieces need to be consistent. I guess what I am saying is that your
proposal needs more details. Please respond with specifics and examples to
move the discussion forward.


>
> Moreover, I'd like to put it in the mailing list in advance to
> make sure it is acceptable for oslo.db.
>
> I'd appreciate any comments.
>
> br.
> Li Ma
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/4056a62e/attachment-0001.html>