浅谈关系型数据库主键设置策略

几乎大多数的应用都会使用关系型数据库进行数据存储,而主键一定是标配。那么,在您的应用中,通常使用什么方案来满足业务扩张呢?下面简单介绍普遍做法以及改进之道。

第一层:业务布局之初。众所周知,企业业务刚开始,需要进行快速试错,而彼时的数据量不会太多,而且暂时不会存在瓶颈,主要是快速打开市场,提供可运行的软件系统,此时不会太多的去关注存储。(言外之意:创业之初会有技术欠债,随着企业发展壮大,会比较痛)。

这时,数据一般采用自增型主键,比如mysql或者sqlserver、postgresql的自增型主键,oracle的序列等都可以很好的满足初期技术架构。当然,如果想用UUID等唯一值做主键也是可以的。不过需要注意的是,使用uuid的可读性会比较差,同时使用字符串做主键,其索引比较大,检索效率稍差。推荐用long类型主键。第一层数据库存储如下图所示:

图片

第二层:快速扩张期。业务经过几轮迭代,数据量也在极度飞升,单机较难满足业务增长,数据库连接常常第一时间产生瓶颈。因此为了提升数据的存储速度,还有快速扩张,技术会选择分库分表。彼时第一阶段会根据业务内容进行垂直分库,比如电商中常见的按照用户、订单、交易、评论等进行拆分。这时的架构也还是当个数据库,只是按照具体业务内容拆分,其主键依然可以采用第一层次的方案。

图片

而随着交易、订单的进一步增长,单库也无法满足性能要求。只能从水平方向上拆分,简单的评估方案是,未来数据存储需要按一亿来计算,单表支撑1千万条数据,最起码需要10张表进行存储。此时会将单库扩张成多张表。此时未考虑到数据库之间的主键不能同步,并同时兼容数据查询高效性。其主键通常会采用分布式ID生成策略,经典有的雪花算法等。此时,单库的自动生成已不再满足业务要求,而uuid等字符型主键因为性能瓶颈也不适合。此时的数据存储架构如下:

图片

第三层:未来扩展期。通过良好的分库分表可以友好的解决存储问题,但是使用这种方案对于数据库的前移工作量比较大。如果是比较新的应用,可以采用newsql的方式解决这种方式,业界比较常见的有TiDB,这种数据存储模式避免了分库分表的一些坑,对于上层应用来说就是单体的存储。业务进行到这个地步,主键推荐采用long类型的主键生成器,避免采用字符型主键。

综上所述,文章简单说明了应用迭代中,主键的一些选型推荐及选择依据。朋友们目前处于什么阶段,当前阶段你们的主键采用什么方式进行生成,欢迎交流。

图片

相关推荐
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页