关于数据库资源的评估

        在IT系统建设的过程中，不可避免的需要对数据库资源进行评估。作为运营商行业近18年的老兵，参与了至少50多个系统的扩容建设，对数据库资源的评估有一番心得，书写出来分享一下。

        数据库作为关基软件，是整个系统的重要组成部分，其资源的评估离不开整个系统的规划，如果不谈整个系统的规划，只谈数据库的规划那是在耍流氓。至少要提供整个系统对于数据库的存储要求、性能要求、特殊要求等，结合提供的硬件配置和网络资源来进行评估。

        数据库的表现跟硬件配置、网络带宽、应用程序等有很直接的关联关系。因此，对于数据库资源的评估，是根据对产品在以上影响因素的经验值预估，肯定存在一定的偏移量，这点是需要提前说明的。

        如果需要对数据库的资源进行评估，需要了解数据的逻辑结构以及处理的流程，否则评估起来会出现较大的偏差。以公司的产品为例：

产品是分布式数据库，主要分为管理节点和数据节点，管理节点主要支撑路由管理，保存数据表的分片规则、主备数据节点的映射信息等，不保存业务数据；数据节点主要是提供数据的存储和管理功能。主数据节点和备数据节点之间通过公司自由的复制机制进行数据同步，确保数据副本的安全性，为数据节点的高可用奠定基础。 

        同时，产品支撑业务系统分两种主要的方式：集中式驱动和分布式驱动，所谓集中式驱动即应用程序首先向路由节点发送请求建立连接，所有客户端请求发向路由管理节点，数据节点只与路由管理节点建立连接，不与客户端进行交互；客户端分片原理：应用程序首先向路由管理节点发送请求建立连接，获取分片规则信息，客户端程序针对此信息与数据节点建立连接，发送请求。

针对集中式驱动和分布式驱动的机制不同，对数据库的资源要求也是不同的：

1. 集中式驱动：管理节点是每次交互必须具备的环节，所以管理节点的配置与整个集群的性能要求都是匹配起来的，即全部数据节点整体性能的总和。由于在数据库正常运转时，不可能全部都达到每一个数据节点的极致性能，所以在集中式驱动时，将管理节点资源按照应用系统对数据库集群的整体性能要求匹配起来即可。数据节点资源的评估按照应用系统对数据库集群的整体性能要求和存储的容量要求进行匹配。
   1. 关于数据节点的性能和容量评估，通常按照均值来评估即可；即数据节点的性能=节点性能正常数值的80%进行评估，所需要的节点数=UPPER(数据库集群性能/数据节点的性能)。关于数据库的容量，可以按照表结构和数据量进行评估，例如：1000万条该表记录所占用的存储空间进行合理评估，通常都是可以存放下来的，尤其是磁盘空间。如果是内存库，就需要慎重评估，毕竟内存通常配置的相对而言还是比较小的。
   2. 如果已经明确分片键，有特别的不均衡，那就按照分片键算法区分化进行评估。例如：为了控制系统异常的影响范围，按照区域进行区分，这样某个数据节点异常最悲观的场景就是影响该节点对应的区域，其他区域不受到影响。如此不均衡的话，就按照区域进行个性化评估。
2. 分布式驱动：
   1. 在应用程序和数据节点建立TCP连接之前都是需要跟管理节点交互，但是一旦TCP连接建立完毕，管理节点就压力小很多，所以管理节点的资源评估就是在应用瞬时全部集中访问时提供的压力，避免配置较少时，导致应用集中启动，等同于攻击管理节点导致管理节点出现异常，引起业务中断。同样的，这个是需要跟应用的初始化的请求配置保持一致，因为应用的请求容量配置也是随着请求的变化而比较弹性的，按照应用的初始化配置并发数占用管理节点CPU总线程数的80%即可，这样预留的CPU线程也可以应对多出来的请求量。
   2. 对于分布式驱动的数据节点评估跟集中式驱动的数据节点的评估基本相同的，
3. 在数据库中是否存在瓶颈点，这个也是需要特别注意的，举个例子：数据库支撑的增删改的性能为50万/秒，但是主库和备库之间的复制性能为：25万/秒，那我们计算数据库的性能时，就应该按照25万/秒来进行评估，如果按照50万/秒来进行评估，数据库集群的数据副本的安全性和数据库的高可用就会存在极大的风险。因此，在数据库运行过程中的瓶颈点儿特别注意。
   如果是新建系统，对于数据库集群的评估要依赖前期现网应用与数据库集群的适配测试结果。如果是现有系统的扩容，务必依赖现有生产环境的状况进行评估，这样更准确。

关于服务器主要是关注于CPU、内存、硬盘空间、网卡等，CPU主要影响数据库的计算能力，一般的物理核虚拟2个线程，有个别的服务器一个物理内核虚拟4个线程。内存和磁盘空间主要影响数据库的存储容量，网卡主要影响数据库的性能和整体时长等等，目前网卡主要是万兆网卡。

资源评估是一个系统的工程，务必要心细谨慎。