这两天，似乎关于核心业务系统切换至国产数据库的话题甚嚣尘上，在数据库圈的很多从业者眼中，对应案例中的业务系统根本算不是我们心中的核心业务系统，那么作为一个DBA，在我眼中什么是核心业务系统或者什么是核心业务系统的数据库呢。
首先，在我的从业生涯中，接触过电商核心订单系统使用MySQL是16C64G的硬件资源，数据量大概200GB左右；然后接触过4C8G数据量大概40GB的教育行业核心系统MySQL数据库；现在维护的运营商O域核心系统则基本上都是10TB起步运行在Exadata上…那么前面说的每个系统在对应的企业内都是负责支撑核心业务的系统，但是其数据库的硬件配置则千差万别；如果再深究其负载，差别也很大；如果再把具体运行时的SQL拎出来，差距可能就更大了。
再举个栗子，之前在某会上看到一数据库宣传在某核心业务场景下数据库支撑了几W的TPS，但是深究其事务SQL，除了简单插入以外，大多数是基于单表点查的更新操作，且几W的TPS也不是持续发生；还是拿我这里的省级资源管理业务来看，TPS刚刚过万，但是这个TPS几乎是7×24的状态，同时把SQL挑出来查看的话几乎就没有简单插入，大多数事务语句都是基于多表关联的，且核心模块对应的单表数据量至少都是千万级的。那么前面说的两种哪个算是核心系统呢？
再说说我们一般所说的金融和运营商的核心系统，也就是计费、记账等跟钱强相关的业务系统，这种业务往往运行的SQL却相对简单，就是基于点查的增删改；但是其数据量是异常庞大，并发非常大，且对数据库的响应要求非常高，几乎是实时的。这样的业务系统对硬件和数据库的要求是异常苛刻的，这些系统的数据库往往运行在小机、大机或者数据库一体机上，亦或是应用设计研发非常好的基础上使用大规模分布式数据库。
而我们一般说的一些次核心系统，比如一些即时决策分析报表、故障管理、实时工单、反诈等系统，往往热数据量和并发并没有那么大，但是需要关联的内容非常多，也就是我们一般所说的SQL十分复杂，同时这类系统的响应虽然没有前面所说的核心系统要求那么高，但是对应业务依然有很高的时效性要求。那么这些业务对底层数据库的依赖依然很重，硬件也是非常好的。
那么一定有人要说了，也有很多地方，数据量、并发量都非常大，响应要求也很高，但是似乎在架构中数据库只占了很小一部分，这种常常出现在互联网公司的应用场景确实会使用大量的数据中间层（比如缓存、列存、全局搜索等）来加速处理数据的速度，而数据库仅仅是最终记录数据的地方。但是反过来想一下，这需要有非常强大的技术实力，不仅是研发实力、架构能力，还有新技术探索实力与维护能力。整个IT架构会非常复杂，这不是一般企业能承受的。而且经济下行中，以前“牛逼轰轰”的互联网公司也会逐渐简化自身IT架构，数据库需要承载的压力也会逐步上升。
那么回到题目，什么是核心业务系统，或者什么是核心业务系统的数据库，不同的行业甚至相同行业不同规模都会有不同的定义，但我认为“理想情况下”至少是要同时满足下面的要求中的3个：
数据量够大：整个数据库是TB甚至是PB级别，核心单表也会很大且数量较多
并发量够大：几乎所有调用都涉及到它
SQL足够复杂：多模块（多表）关联是常态
响应要求高：实时或近实时响应
还有就是可用性要求高：数据库不能中断服务，一旦中断影响面极大。那么这样的系统转换成硬件资源的要求就是：海量存储的同时支持巨大的IO压力；还需要从海量数据中以“花样”的方式快速获得或操作数据，计算压力也会非常巨大；N个9的高可用性也意味着巨大的软硬件投资。
