On 03/02/14 16:22 +0000, Paul Montgomery wrote:
Solum community,
I notice that we are using String(36) UUID values in the database schema as
primary key for many new tables that we are creating. For example:
https://review.openstack.org/#/c/68328/10/solum/objects/sqlalchemy/application.py
Proposal: Add an int or bigint ID as the primary key, instead of UUID (the UUID
field remains if needed), to improve database efficiency.
In my experience (I briefly pinged a DBA to verify), using a relatively long
field as a primary key will increase resource utilization and reduce
throughput. This will become pronounced with the database will no longer fit
into memory which would likely characterize any medium-large Solum
installation. This proposal would relatively painlessly improve database
efficiency before a database schema change becomes difficult (many pull
requests are in flight right now for schema).
In order to prevent the auto-incrementing ID from leaking usage information
about the system, I would recommend using the integer-based ID field internally
within Solum for efficiency and do not expose this ID field to users. Users
would only see UUID or non-ID values to prevent Solum metadata from leaking.
Thoughts?
I am reworking my patch now to use autoinc. int for the index and
have a seperate uuid.
-Angus
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev