写点什么

架构师必备:业务扩展模式选型

  • 2025-07-08
    福建
  • 本文字数:1931 字

    阅读完需:约 6 分钟

业务发展过程中,增加字段是很常见、频繁的,因此怎么存储新增的字段是要重点考虑的因素。下面结合笔者的经验,总结一下各种业务扩展模式选型的优缺点、适用场景,如何让系统保持良好的业务扩展性。


方案选项


1. 最朴素方案:MySQL 表直接加字段


实现:在表中新增字段(ALTER TABLE ... ADD COLUMN ...)。


优点:

  • 简单直接,快速迭代


缺点:

  • 需要频繁修改表结构

    字段膨胀导致表臃肿,索引效率下降(mysql 单行记录有大小上限,65535 字节;特别地,TEXT、BLOB 另外分开存储,占 9 到 12 字节)


适用场景:

  • 业务初期频繁加字段

    或该字段为通用字段,适用于所有记录


2. 按业务领域聚合字段(增量更新)


实现:将新增字段按业务域划分,比如业务一的信息都放到 field_1,业务二的信息都放到 field_2,每个字段是 json 格式、方便后续扩展。


优点:

  • 业务聚合:相同业务领域信息存在一个字段内,无需每次 DDL 新增字段


缺点:

  • 每次更新都要先查 DB 的值,merge 本次变更后再写入 DB

    需做好并发控制,否则可能丢失变更内容(可通过乐观锁、或悲观锁控制,取决于并发程度)

    仍然存在 mysql 单行大小限制


适用场景:

  • 小型项目,不做推荐


3. 按业务领域垂直拆表


  • 实现:相近业务领域的字段,做垂直分表(如拆为订单信息表 order_info、订单支付表 order_payment、订单物流表 order_logistics)。

优点:

  • 彻底解耦业务域,各表独立演进

    按需查表,提升查询性能


缺点:

  • 每个垂直分表仍是在表内新增字段

    业务扩展的难易程度,取决于垂直拆分得是否合理


适用场景:

  • 业务模式已经稳定

    或业务边界清晰的项目


4. 主表 + 动态扩展表(通过业务 ID 关联)


实现:

  • 主表:存储核心字段(如业务 ID、其它通用关键字段)

  • 动态扩展表:存储动态扩展字段,与主表通过业务 id 关联。包括扩展 key、扩展 value(可以是 json 格式,方便后续扩展)

  • 每次新增字段:(1)新增一个扩展 key,在扩展 value 里存储内容;(2)或在已有扩展 key 的 value 中新增字段。



之所以通过动态扩展表来实现,是因为很多字段并非通用的,而仅针对部分记录。

以电子产品为例:可以有扩展字段 1(认证证书:3C),则扩展 key 为"certification",value 是["3C"]也可以有扩展字段 2(保修信息:保修期 12 个月、可延保、最长可延保 24 个月),则扩展 key 为"warranty",value 是{"warrantyMonths": 12, "canExtend": true, "maxWarrantyMonths": 24}以食品为例:可以有扩展字段 1(保质期截止时间:2026-07-07),则扩展 key 为"bestBefore",value 是对应时间戳也可以有扩展字段 2(生产地:中国上海),则扩展 key 为"productionPlace",value 是{"country": "CN", "province": "Shanghai"}

表结构设计:


-- 主表CREATE TABLE biz_info (  id BIGINT AUTO_INCREMENT PRIMARY KEY,  biz_id BIGINT UNIQUE KEY,  -- 业务ID  ...  -- 其它通用关键字段);
-- 通用扩展表CREATE TABLE biz_extension ( id BIGINT AUTO_INCREMENT PRIMARY KEY, biz_id BIGINT, -- 关联主表的业务ID extension_key VARCHAR(64), -- 扩展key名 extension_value TEXT, -- 扩展value值 UNIQUE KEY (biz_id, extension_key) -- 唯一键);
复制代码


优点:

  • 动态扩展字段,无需 DDL 变更

    按需查扩展 key 对应的记录,提升查询性能


缺点:

  • 扩展数据为字符串存储,需要按业务自定义格式解析,无法直接按条件筛选查询


适用场景:

  • 应当优先考虑的长期方案


5. MySQL 主表 + HBase 业务扩展表


  • 实现:

  • MySQL:存储核心结构化数据(强事务需求、可指定条件筛选查询)

  • HBase:存储动态扩展字段(稀疏、多列),可以按业务领域垂直拆表,因为在 HBase 表中新增字段的成本很低

  • 关联方式:用 mysql 主表业务 ID,作为 HBase rowKey 的一部分,通过业务 id 即可查到 HBase 中的其它扩展信息。

  • 如果想按条件查询扩展信息,需要把数据导入到 ES 里,通过 ES 查询。



HBase 表设计:如果业务 id 是 123456789,则 rowKey 可设计成:{业务 id 后缀}_{业务 id},如 789_123456789;方便将 hbase 数据打散到不同的 region,提高存储和查询性能。


HBase 业务扩展表 1



HBase 业务扩展表 2



优点:

  • 支持大量列字段,稀疏存储高效

    是“主表 + 扩展表”的进阶版


缺点:

  • 扩展信息不能方便地按条件查询,导出至 ES 后才行

    事务支持弱(跨 MySQL/HBase 无法保证事务性,只能做到最终一致性)

    复杂度变高:开发成本、运维成本都变高了


适用场景:

  • 数据量较大,需拆分一部分扩展信息至 HBase

    或动态扩展字段变多,达到千级/万级时


结论


  • 适用于所有记录的字段,在 MySQL 表中直接新增

  • 初期优先选择“主表 + 动态扩展表”模式,平衡灵活性与复杂度

  • 当扩展信息数据量较大,或动态扩展字段达到千级/万级时,考虑升级到“MySQL 主表 + HBase 业务扩展表”模式

  • 若需复杂查询,可补充 Elasticsearch 构建二级索引


文章转载自:Java烘焙师

原文链接:https://www.cnblogs.com/toplist/p/18955480

体验地址:http://www.jnpfsoft.com/?from=001YH

用户头像

还未添加个人签名 2025-04-01 加入

还未添加个人简介

评论

发布
暂无评论
架构师必备:业务扩展模式选型_架构_量贩潮汐·WholesaleTide_InfoQ写作社区