On May 2, 2016, at 10:51 AM, Mike Bayer <mba...@redhat.com> wrote: >> Concretely, we think that there are three possible approaches: >> 1) We can use the SQLAlchemy API as the common denominator between a >> relational and non-relational implementation of the db.api component. These >> two implementation could continue to converge by sharing a large amount of >> code. >> 2) We create a new non-relational implementation (from scratch) of the >> db.api component. It would require probably more work. >> 3) We are also studying a last alternative: writing a SQLAlchemy engine >> that targets NewSQL databases (scalability + ACID): >> - https://github.com/cockroachdb/cockroach >> - https://github.com/pingcap/tidb > > Going with a NewSQL backend is by far the best approach here. That way, > very little needs to be reinvented and the application's approach to data > doesn't need to dramatically change.
I’m glad that Matthieu responded, but I did want to emphasize one thing: of *course* this isn’t an ideal approach, but it *is* a practical one. The biggest problem in any change like this isn’t getting it to work, or to perform better, or anything else except being able to make the change while disrupting as little of the existing code as possible. Taking an approach that would be more efficient would be a non-starter since it wouldn’t provide a clean upgrade path for existing deployments. By getting this working without ripping out all of the data models that currently exist is an amazing feat. And if by doing so it shows that a distributed database is indeed possible, it’s done more than anything else that has ever been discussed in the past few years. -- Ed Leafe __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
