如题,我的使用场景是随机读写,需要保证尽可能高的性能。
一般来说 oracle 使用中都是使用序列代替 mysql 的自增主键功能。但是由于不了解 oracle 储存原理,不知道这个策略对于需求来说是不是最优的(考虑到分库分表的情况后)。因为今天看隔壁 mysql 主键的帖子想到比如 innodb 底层就不太适合用 uuid 做主键,会导致一些问题比如所有索引包含主键压缩率增加很多,还有 IO 方面的问题。想问一下有没有了解的朋友对于 oracle 来说使用 uuid 是否不存在类似问题,使用序列是否有什么坑,谢谢。
1
gt15207 2022-03-21 21:16:26 +08:00
纯维护 DBA ,所以不知道 Oracle 里应用使用 uuid 是否存在什么问题;可能之前碰到过问题,但不知道应用使用的是 uuid 。不过有一个万金油的方案,就是搭建一个 POC 测试,尽量模拟应用行为,并做压力测试,看看 Oracle 能不能 hold 住。
至于使用序列: 1. 在 Real Application Cluster 下使用序列会出现多个实例里拿的序列号不是严格递增的情况。因为序列一般在每个 RAC 节点上有 cache ,比如节点一 cache 了序列号 1 到 20, 然后节点二 cache 了 21 到 40 。节点二上的应用初始拿到的序列号就会是 21 ;而此时序列号 20 大概率还没分给应用使用呢(也就是序列号 21 先于 20 被分配了) 2. 在序列号被默认 cache 的情况下,如果 DB crash ,则内存中 cache 住的序列号会丢失。也就是丢掉的序列号不会被分配给应用了。 3. 如果关闭序列号的 cache 功能,则分配序列号的动作会变慢( Real Application Cluster/RAC 下此时需要节点间同步,所以分配序列号动作会变得更慢) 一般如果应用需要严格递增,而且不能缺号的序列号,是不应该使用 Oracle 自带的 sequence 技术的。 |
2
gt15207 2022-03-21 21:26:03 +08:00 1
抱歉,审题审错了,原来要用序列号做主键呀。Oracle 的主键默认会建成一个索引,所以它和 MySQL innodb 应该是类似的情况。但根据我个人的经验,在 Oracle 里用 sequence 做主键比用 uuid 做主键更容易造成热块争用;这和那个 MySQL 帖子里讲的恰恰相反 - 囧。
|
3
LeeReamond OP @gt15207 感谢分享,很有用的经验,性能方面比较在意的是热块争用以及储存上的碎片问题,这在 mysql 里存在但不太清楚 oracle 的情况,如果不存在 mysql 的种种问题的话似乎 uuid 是很不错的选择。我们目前没有严格递增的需求,不过考虑到这个需求的话,简单想了一下好像也不感觉业务处理会有啥更快的方法,就算搞一个业务锁处理节点同步也很费时间啊
|