3 ms·

The arguments against UUID just don't seem strong enough to me. Even with huge datasets queries against UUID keys/indices have never been any kind of bottle ne

The arguments against UUID just don't seem strong enough to me. Even with huge datasets queries against UUID keys/indices have never been any kind of bottle neck or major performance hit compared with other more complex queries within the application. Add that to the fact db's like Postgres have native support for UUID types and stable extensions for UUID1-4 generation, I just could not see myself wanting to sacrifice such a well known solution for one that offers such slight gains.

makmanalp 13y ago
Thanks for commenting! I think DB support is great. I'm especially jealous of postgres, which like you mention, has native UUID types. UUID-OSSP is especially great: http://www.postgresql.org/docs/devel/static/uuid-ossp.html http://www.postgresql.org/docs/devel/static/uuid-ossp.html Postgres handles all the gunk for you in terms of efficient storage and display, AND you can cluster by a different field than the UUID one. For those of us not unfortunate enough to be using a DB that has such niceties, things are different :) As for performance I think this will always depend on your what your queries look like. For random reads or for reads when your dataset is not larger than RAM, you won't see any degradation because of caching. But if you need to make tons of range queries on a dataset that doesn't fit in RAM (or even worse, the index doesn't fit in RAM), things can get a bit crazy. I wish I had time to also do a benchmark supporting this, but I've hit this issue before. Other people also seem to have hit it here: http://stackoverflow.com/questions/2365132/uuid-performance-in-mysql http://stackoverflow.com/questions/2365132/uuid-performance-... (comments and answers) or here: https://news.ycombinator.com/item?id=5310662 https://news.ycombinator.com/item?id=5310662 or here: http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/ http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-no... So, it really depends on your use case, I guess. Hope this helps!

makmanalp 13y ago

Thanks for commenting! I think DB support is great. I'm especially jealous of postgres, which like you mention, has native UUID types. UUID-OSSP is especially great: http://www.postgresql.org/docs/devel/static/uuid-ossp.html http://www.postgresql.org/docs/devel/static/uuid-ossp.html Postgres handles all the gunk for you in terms of efficient storage and display, AND you can cluster by a different field than the UUID one. For those of us not unfortunate enough to be using a DB that has such niceties, things are different :) As for performance I think this will always depend on your what your queries look like. For random reads or for reads when your dataset is not larger than RAM, you won't see any degradation because of caching. But if you need to make tons of range queries on a dataset that doesn't fit in RAM (or even worse, the index doesn't fit in RAM), things can get a bit crazy. I wish I had time to also do a benchmark supporting this, but I've hit this issue before. Other people also seem to have hit it here: http://stackoverflow.com/questions/2365132/uuid-performance-in-mysql http://stackoverflow.com/questions/2365132/uuid-performance-... (comments and answers) or here: https://news.ycombinator.com/item?id=5310662 https://news.ycombinator.com/item?id=5310662 or here: http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/ http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-no... So, it really depends on your use case, I guess. Hope this helps!