[openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255
m at metacloud.com
Sun Mar 2 20:05:10 UTC 2014
Having done some work with MySQL (specifically around similar data sets)
and discussing the changes with some former coworkers (MySQL experts) I am
inclined to believe the move from varchar to binary absolutely would
increase performance like this.
However, I would like to get some real benchmarks around it and if it
really makes a difference we should get a smart "UUID" type into the common
SQLlibs (can pgsql see a similar benefit? Db2?) I think this conversation.
Should be split off from the keystone one at hand - I don't want valuable
information / discussions to get lost.
Sent via mobile
On Sunday, March 2, 2014, Sean Dague <sean at dague.net> wrote:
> On 03/01/2014 08:00 PM, Clint Byrum wrote:
> > Excerpts from Robert Collins's message of 2014-03-01 14:26:57 -0800:
> >>> +1. A Keystone record belongs to Keystone, and it should have a
> >>> ID. External records that are linked should be linked separately.
> >>> It may not be obvious to everyone, but MySQL uses B-trees for indexes.
> >>> B-trees cannot have variable-length keys.
> >> Hmm, B-Trees and B+-Trees both can have variable length keys. I'll
> >> accept an assertion that MySQL index B-trees cannot - but we should be
> >> precise here, because its not a global limitation.
> > Sorry, I misspoke, _InnoDB's_ b-tree's cannot have variable length keys.
> > :-P
> On a previous project we did a transition from varchar based UUID to
> binary based UUID in MySQL. The micro benchmarks on joins got faster by
> a factor of 10,000 (yes 10k). Granted, MySQL has evolved since then, and
> this was a micro benchmark, however this is definitely work considering.
> Sean Dague
> Samsung Research America
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev