5 ms·
(We're getting way off topic) but I think the problem with auto increment is that it can't be sharded easily since multiple shards can increment to the same val
by zawerf 7y ago
(We're getting way off topic) but I think the problem with auto increment is that it can't be sharded easily since multiple shards can increment to the same value. If you then try to go back to random ids you're now stuck with 8 bytes which will conflict once every billion items or so. I guess it's pretty extreme premature optimization but I think UUID is nicer for future-proofing at the cost of some performance. (I would love to see benchmarks to know exactly how much performance I am giving up though)
By the way uuidv1 is already prefixed by a timestamp! But unfortunately it doesn't use a sortable version of the time so it doesn't work for clustering the ids into the same page. I think it was really designed for distributed systems where you would want evenly distributed ids anyway.
- pas 7y agoIn MySQL/MariaDB/Percona InnoDB Galera every writeable replica has an auto increment offset.
- takeda 7y agoSame in postgres[1], and I'm willing to guess every relational database has a way to do it. [1] https://www.postgresql.org/docs/current/sql-createsequence.html https://www.postgresql.org/docs/current/sql-createsequence.h...
- takeda 7y ago> I would love to see benchmarks to know exactly how much performance I am giving up though https://www.youtube.com/watch?v=xrMbzHdPLKM https://www.youtube.com/watch?v=xrMbzHdPLKM It ends up being a pitch for Aurora at the end (as with any presentation from AWS folks), but it has tons of useful information for standard Postgres.