Open Stack

On 04/05/2017 09:39 AM, Akihiro Motoki wrote:
> 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.

Yes! Very well said. UUID is the excellent choice for API - auto-inc is 
the excellent choice for the database.

> 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
>
> __________________________________________________________________________
> 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
>