缩放自动增量

时间:2017-12-14 16:10:23

标签: mysql database postgresql

我仍然在权衡数字自动增量主键与UUID的好处。我使用Postgis和Postgis作为我的后端,因为我将进行基于地理定位的查询 性能是一个重点,因为它打算成为一个基于地理位置的实时应用程序,否则我可能会更少关注它。

对我个人来说,差不多已做出决定。自动增量最适用于高性能外键和连接操作,快速查找以及与数据库空间相关的较低成本。我想在我的后端使用salted hashids来模糊我的自动增量主键到客户端,所以我不需要在我的表上使用辅助唯一键。

但是,我总是在分布式数据库系统中警告不要使用自动递增的主键 我需要分布式系统吗?最诚实的答案是:我现在不知道,我怎么能这样?如果应用程序不成功,答案可能不是。如果是,那么可能就是这样 然而,当我发现我需要它并且我没有使用通用密钥时,为时已晚。许多文章警告与重复键有关的问题。

所以我的问题是;使用自动增量密钥来运行风险有多大的好处是为了提高性能和减少空间,并随着时间的推移使用自动增量扩展到分布式系统?

我目前工作的导师警告我,过早的优化是邪恶的,但同时你不应该天真。我在这里细线,所以我该怎么办?

编辑:我标记了MySQL以及我猜这同样适用。

1 个答案:

答案 0 :(得分:0)

如果您对使用UUID感觉更舒服,并预见将来会出现自动增量问题,那么您应该使用它。性能影响可以忽略不计。由于其他一些数据库设计问题,您将失去更多性能,绝对不是因为您使用的是UUID

对于快速查找,您只需要对大表进行分区,或者对它们进行聚类。