[openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.
Jay Pipes
jaypipes at gmail.com
Mon Aug 19 07:14:49 UTC 2013
On 08/18/2013 10:33 PM, Joe Gordon wrote:
> An alternative I think would be better would be to scrap the use of
> the SQLAlchemy ORM; keep using the DB engine abstraction support.
>
> +1, I am hoping this will provide noticeable performance benefits while
> being agnostic of what DB back-end is being used. With the way we use
> SQLALchemy being 25x slower then MySQL we have lots of room for
> improvement (see http://paste.openstack.org/show/44143/ from
> https://bugs.launchpad.net/nova/+bug/1212418).
@require_admin_context
def compute_node_get_all(context):
return model_query(context, models.ComputeNode).\
options(joinedload('service')).\
options(joinedload('stats')).\
all()
Well, yeah... I suppose if you are attempting to create 115K objects in
memory in Python (Need to collate each ComputeNode model object and each
of its relation objects for Service and Stats) you are going to run into
some performance problems. :)
Would be interesting to see what the performance difference would be if
you instead had dicts instead of model objects and did something like
this instead (code not tested, just off top of head...):
# Assume a method to_dict() that takes a Model
# and returns a dict with appropriate empty dicts for
# relationship fields.
qr = session.query(ComputeNode).join(Service).join(Stats)
results = {}
for record in qr:
node_id = record.ComputeNode.id
service_id = record.Service.id
stat_id = record.ComputeNodeStat.id
if node_id not in results.keys():
results[node_id] = to_dict(record.ComputeNode)
if service_id not in results[node_id]['services'].keys():
results[node_id]['services'][service_id] = to_dict(record.Service)
if stat_id not in results[node_id]['stats'].keys():
results[node_id]['stats'][stat_id] = to_dict(record.ComputeNodeStat)
return results
Whether it would be any faster than SQLAlchemy's joinedload...
Besides that, though, probably is a good idea to look at even the
existence of DB calls that potentially do that kind of massive query
returning as A Bad Thing...
Best,
-jay
More information about the OpenStack-dev
mailing list