Use BINARY(16) for ID columns in SQL backends
UUIDs are 16 bytes in length [1], however keystone's SQL backends generally use VARCHAR(64) columns [2] to store 32-character hexidecimal representations of UUIDs. Beyond the obvious waste of space, this may result in poor JOIN performance [3] in particular.
Specifically:
- Keystone should continue to emit 32-character hexidecimal representations of UUIDs (other services should not be affected)
- Keystone should be migrated to persist UUIDs using their raw 16-byte representations
To illustrate, a hex string representation can be loaded by the uuid module and translated to a 16-byte representation:
$ python -c "import uuid; hex_str = uuid.uuid4().hex; print(len(
16
As this is primarily a performance optimization, this change should be benchmarked.
[1]: http://
[2]: https:/
[3]: http://
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Dolph Mathews
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Dolph Mathews
Related branches
Related bugs
Sprints
Whiteboard
would not change, right? (nor target_id, I'm not sure which one can correspond to the user)
-markwash
As an internal reference, L587 should be migrated to a BINARY(16) column. -Dolph
Today in the LDAP identity driver, the default user-id field is the CN, which is not generally a UUID. So it seems like a migration of existing user-ids would be required in order to change L587 to BINARY(16).
-markwash
Correct - this blueprint is effectively dependent on a solution to https:/
This may also conflict with https:/
