Open Stack

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.

Cheers,
Morgan.

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:
> >> On 1 March 2014 13:28, Clint Byrum <clint at fewbar.com <javascript:;>>
> wrote:
> >>
> >>> +1. A Keystone record belongs to Keystone, and it should have a
> Keystone
> >>> 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
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net <javascript:;> / sean.dague at samsung.com <javascript:;>
> http://dague.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140302/215d2056/attachment.html>