自研数据库画像工具支持“去O”评估

。拆分的原则就是尽量控制单库规模。一般可遵循如下拆分优先原则：

1）业务层垂直拆分

在应用层面，将数据按照不同的业务条线进行拆分。例如电商平台中按照订单、用户、商品、库存等拆分。各自拆分的部分，业务内聚，无强数据依赖关系。

2）业务层水平拆分

在同一业务内部，对数据建立生命周期管理，进行数据冷热分层。针对不同层的数据访问特点不同，可做进一步拆分。例如电商平台中，针对订单可分为活跃订单(二周内，可退换货)、非活跃订单(二周至半年期，客服可受理)、历史订单（半年以上）。

3）应用层分库分表

若经过上述拆分单个库的规模仍然较大，可考虑使用分库分表技术。通常的做法是引入数据库中间层，逻辑上虚拟出一个数据库，但物理上划分为多个数据库。这是一种不太“优雅”的方案，因为很难做到应用透明。也就是说，必须在研发方面有所妥协，牺牲一部分数据库能力。常见技术方案上可分为：Client、Proxy、SideCar三类，现多推荐使用Proxy模式（容器部署可考虑SideCar模式）。

4）基础层分布式数据库

较“分库分表”方式更为彻底的是直接使用分布式数据库。它提供了一种可承载更大规模（容量、吞吐量）的解决方案。近些年来，分布式数据库已逐渐成熟，推广落地；并开始在关键场景中尝试使用。量过多，直接影响数据字典大小，进而影响数据库整体效率。从MySQL来看，还需考虑文件句柄等问题。这一指标没有一定之规，需根据情况酌情考虑。这里更多是数据架构层面考虑，避免单库数据表过多。曾经历过单库10万张表，性能低下；优化后整合成2万张的优化案例。如选择MySQL，建议单库不超过5000张表；库*表的总数不超过20000。

2）表(大表)

控制单表的规模，是设计的要点之一，直接影响到访问性能。表过大，应考虑采用上面的原则进行拆分。表大小没有通用原则，这里可通过参数进行配置。可按照物理大小或记录数两个维度设置。这里的关键点在于表的访问方式，如均为简单的kv型访问，规模大些还好；如访问比较复杂，则建议阈值设置更低些。如选择MySQL，大表复杂查询或多表关联等均不是其擅长场景，可考虑使用ES、solr+hbase等方式异步处理复杂查询。

3）表(分区表)

从9i、10g以来，Oracle的分区功能日趋完善、功能增强。可以说已成为Oracle应对海量数据的利器。但对于MySQL来说，仍然不太建议使用分区功能。一方面，随着硬件能力的增强，单表可承载力变大；另一方面，MySQL使用分区还需面对“DDL放大”、“锁变化”等问题。如果团队可以很好地驾驭数据库中间层，还是建议使用复杂度更低的分表技术。这也许会稍许增加研发量，但对运维来说，好处多多。

4）字段(大对象)

在任何数据库中，都不建议使用大对象。如果你用了，趁着改造工作，赶紧去掉吧。大对象功能对数据库来说，就是鸡肋。数据库自身的AC

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!