Investigate E-S document routing

Registered by Steve McLellan

This is not essential, but will be a performance boost, especially for large indices (thinking swift).

Elasticsearch by default assigns a document to a shard (lucene instance) based on the document id, as defined in https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-routing-field.html. This means a search has to hit all shards. An easy performance gain in certain situations is to define the routing oneself; in our case, tenant_id provides a natural routing hint because the majority of non-admin queries restrict on tenant-id.

Some further thought is required, including, i think, a short spec proposal, because there are some edge cases around things like glance membership where this routing would not be reliable, but i think we could apply it in many cases.

Blueprint information

Status:
Complete
Approver:
None
Priority:
High
Drafter:
Steve McLellan
Direction:
Needs approval
Assignee:
Lakshmi N Sampath
Definition:
Approved
Series goal:
Accepted for mitaka
Implementation:
Implemented
Milestone target:
milestone icon mitaka-rc1
Started by
Lakshmi N Sampath
Completed by
Travis Tripp

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/document-routing,n,z

Addressed by: https://review.openstack.org/289798
    Routing was optional until now, but with swift plugin it has become mandatory as swift has multiple hierarchies of parent and child relationships in document, wherein grand child and grandparent have to be located in the same shard for the queries to work

Gerrit topic: https://review.openstack.org/#q,topic:bp/swift-plugin,n,z

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.