[openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

Akihiro Motoki amotoki at gmail.com
Wed Apr 5 14:39:08 UTC 2017


I noticed this thread by Monty's reply. Sorry for my late :(

I think we need to think 'id' separately for API modeling and DB modeling.

In the API perspective, one of the important things is that 'id' is
not predictable
and it rarely conflict. From this perspective, UUID works.

In the DB perspective, the context will be different.
Efficiency is another important point.
auto-incremental way brings us a good efficiency.

In most OpenStack projects, we use 'id' in a database as 'id' in an API layer.
I am okay with using incremental integer as 'id' in DB, but I don't think
it is not a good idea to use predictable 'id' in the API layer.

I don't know how 'id' in API and DB layer are related in Zun implementation
but I believe this is one of the important point.

Akihiro


2017-04-05 22:00 GMT+09:00 Monty Taylor <mordred at inaugust.com>:
> On 02/21/2017 07:28 AM, gordon chung wrote:
>>
>>
>>
>> On 21/02/17 01:28 AM, Qiming Teng wrote:
>>>>
>>>> in mysql[2].
>>>
>>> Can someone remind me the benefits we get from Integer over UUID as
>>> primary key? UUID, as its name implies, is meant to be an identifier for
>>> a resource. Why are we generating integer key values?
>>
>>
>> this ^. use UUID please. you can google why auto increment is a probably
>> not a good idea.
>>
>> from a selfish pov, as gnocchi captures data on all resources in
>> openstack, we store everything as a uuid anyways. even if your id
>> doesn't clash in zun, it has a higher chance of clashing when you
>> consider all the other resources from other services.
>>
>> cheers,
>>
>
> sorry - I just caught this.
>
> Please do NOT use uuid as a primary key in MySQL:
>
> * UUID has 36 characters which makes it bulky.
> * InnoDB stores data in the PRIMARY KEY order and all the secondary keys
> also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index
> bigger which can not be fit into the memory
> * Inserts are random and the data is scattered.
>
> In cases where data has a large natural key (like a uuid) It is considered a
> best practice to use an auto-increment integer as the primary key and to put
> a second column in the table to store the uuid, potentially with a unique
> index applied to it for consistency.
>
> That way the external identifier for things like gnocchi can still be the
> UUID, but the internal id for the database can be an efficient
> auto-increment primary key.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list