On 04/28/2016 08:44 AM, Edward Leafe wrote:
On Apr 24, 2016, at 3:28 PM, Robert Collins <robe...@robertcollins.net> wrote:
For instance, the things I think are essential for a distributed
database based datastore:
- good single-machine developer story. Must not need a physical
cluster to hack on OpenStack
- deal gracefully with single node/rack/site failures (when deployed
appropriately) - allow limiting failure domain impact
- straightforward programming model: wrong uses should be obvious to reviewers
- low latency performance with big datasets: e.g. nova list as an
admin should be able to get the Nth page as rapidly as the 2nd or 3rd.
nova list as an admin (or any user frankly) should be a proxy call to
Project Searchlight and elasticsearch.
elasticsearch is a great interface for this kind of operation. We should
use it.
The Cells architecture, which allows the operator to both scale the
message queue *and* limit the scope of failure domains, is a good one.
Having a database that stores only the local (to the cell) information
is perfectly fine given the top-level API database's index/mapping
tables. Where this design has short-comings, as Ed and others point out,
are things like doing list operations across dozens of separate cells.
So, let's not use the Nova database for that and instead use a solution
that works very well for it: Project Searchlight.
And for those that have small clouds and/or don't want/need to install
elasticsearch, OK, cool, stick with a single cell and a single RDBMS
instance.
Best,
-jay
__________________________________________________________________________
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
