业务发展的初期，数据库采用单点或者简单的读写分离的方式进行部署维护，业务的快速发展，流量的增长，复杂的业务场景可能导致整个数据库的性能逐渐下降，这样的情况之下，数据库系统架构如何升级、扩展满足现有以及未来一段时间的的业务需要，以下内容为工作中遇到的问题和总结。

数据库上面临的问题

业务问题

1、报表类业务，业务上快速发展离不开业务指标的各种数据维度的分析，定期的分析过去一段时间内的业务数据情况，转化为报表输出。这些指标数据是对某些业务上的聚合、归并、统计等分析。

2、客户查询历史订单信息，数据库数据已经被物理删除，没有办法查询。

技术问题

1、大批量的写入或者读取数据库，影响到整体拖垮数据库。

2、数据库查询性能越来越慢。

3、定时任务实时处理数据。

4、技术维度设计的表按照业务维度分析数据。

分析和解决思路

以上问题简单举例，还有可能很多业务场景出现，主要从两个方面的问题，数据量的快速增长带来的各种性能问题，这样的情况下如何在MySQL中存储业务的全部数据，并满足业务上的各种查询需要，主要从以下几个方面考虑。

操作特性上可以分为读、写操作，也就是将数据库进行读写分离，这样的操作一般用于读流量较高，写操作较少的场景，同时也可以做多个从库用于承接读的流量。这种情况下同时也会带来一定的业务问题，比如经常倒大批量的数据等，性能上也会存在一定的问题，如何解决呢？

操作特性上分析，抽象归为两类操作，对应的特点：

针对高频操作的服务，在周期内提高单次处理的响应时间，对应的资源要求相对苛刻，低频操作的服务，对延迟性要求没有那么严格，资源上可以相对少分配一些，为了满足两组场景的需要，需要将资源上分别部署，可以将数据库拆分为以下几个应用场景：主库：可以支持快速的插入数据操作，库结构上可以不支持查询类操作，不建立索引等，这样写入的性能很高。

* 从库：可以建立供业务上的查询操作，为了提高查询性能，可以建立索引，提高查询效率，聚合类的操作类型尽可能少，如果有，可以做多从业务上拆分开.

* 离线库：主要应用于大批量实时倒数据的应用场景，离线分线数据使用，性能相对一般。

* 备份库：用于冗灾恢复的情况，不承接流量使用，业务上不对外开放使用。

* Hive：用户搭建数据仓库，大量分析数据指标的业务处理，同时也可以作为数据归档处理。

通过将数据库的职责进行划分，将不同的业务场景调用不同的数据库，从而性能满足各种业务上需要。

数据特性上分析，可以将数据分为业务数据和基础属性数据，某些基础属性为另外一部分业务数据服务，相对于整体上而言，两部分的数据操作特性相差还是比较大，可以将业务相关和不相关的业务进行垂直和水平拆分。

垂直拆分就是要把表按模块划分到不同数据库表中，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，这样既可以保证业务上的数据快速增长，又可以保障基础核心服务数据的稳定性。

水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里，简单理解就是水平拆分行，将不同的数据按照某种规则拆分到不同表中。

垂直与水平结合使用，横向和纵向分析业务数据。垂直拆分主要解决数据表读取的资源竞争关系，水平拆分主要解决单个数据表的读写的压力。

从查询场景上分析，可以将业务上分为复杂查询和简单查询。

复杂查询场景，常用的方式我们可以添加索引方式，再就是搭建搜索系统解决，也是目前常用的方式解决问题，类似常用的搜索系统的数据量级别，查询场景相当的复杂，就是基于搜索系统维护(开源的框架有Elasticsearch、Lucene，感兴趣的可以了解一下)。

简单查询场景，为了降低磁盘IO的性能问题，可以将数据内存化管理，也就是我们常说的NoSQL，将数据K-V化存储到内存中，这样的性能会质的变化。

总结

经过以上几部分的优化，数据库上已经有质的飞跃的改进和优化。针对性能上优化的思路，单个资源的处理能力是有限的，可以将数据横向、纵向分布到多资源处理，也就是分布式系统。同时也会带来CAP的问题，可以从业务上分析一下，优先解决的问题是哪个。

数据库技术上的优化可以很大程度上解决性能上的问题，提升业务上用户体验，但有时候静下心来想一想是不是业务上或者架构设计上的不合理导致的，可以从架构、业务的角度多方位思考一下问题，多方向攻击性能，效果又有可能是另外一种质的飞跃。