Open Stack

On 04/05/2017 11:00 AM, Monty Taylor wrote:
> 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.

+1

with primary key datatype, you also imply the datatype of columns 
constrained by foreign key as well, which itself usually gets indexed too.




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