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 <mord...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
