掌握不同数据库架构开发方法是大多数软件开发程序员都需要具备的一个编程能力，而本文我们就通过案例分析来简单了解一下，传统数据库都有哪些特性。
特性1：高可用问题。
MySQL本身是不具备高可用能力的，它的高可用能力通过外部工具协助达成(MySQL高可用方案随着复制的改进有漫长的演化历史)。众所周知，高可用工具往往只能大限度解决数据一致性的问题，而不能解决HA切换后应用访问的问题，通常一个完整的高可用系统是要HA工具+Proxy联动+ClientDriver连接池合理配置共同实现的。遗憾的是，时至今日不少中小公司并没有丝滑解决HA切换的问题，主要原因是HA工具+Proxy深度定制能力欠缺，篇幅原因不做展开。
特性2：数据一致性问题。
数据复制是存在时差的，造成读一致性问题，但这通常不是太大的问题，通过Proxybindmaster操作都能解决，不过，master压力可能会同样面临性能瓶颈。
特性3：容量、性能扩展、结构变更。
这是传统单机数据库的三宗罪。存储的扩展在一定程度内可以通过堆硬件(垂直扩容)的方式来解决，但堆硬件也是有限度的，出于可运维、易运维的角度，通常DBA都不会让单实例或者单表太大。可能对于一个冷的日志表存储超过1TBDBA可能就会比较紧张了，毕竟DDL一次可能要以天计算，而对于一个读写高频的订单表超过GB，估计DBA维护就会如履薄冰瑟瑟发抖了!这时棘手的问题就来了：给够你硬件你都不敢用。
通过堆硬件能在一定程度上缓解存储容量上限的问题，但性能问题是无法靠堆硬件完全解决的。还以订单表为例，如果是日订单百万甚至千万级别，无论怎么折腾单表都会出现严重的读写性能问题，此时通过扩容硬件的方式不能解决问题。一方面是因为数据库本身会由于热点表的高频读写造成严重的锁放大问题，另一方面数据库本身并不能充分使用硬件资源，尤其MySQL5.6之前的版本由于诸多子线程未从Master主程上拆分，造成CPU使用不充分，这在MySQL5.7版本后有了很大的改观。尽管如此，还是会受到网卡、磁盘IOPS上限因素的影响，注定单机构成的数据库集群存在性能上限。因此不幸的是：给你足够的资源你都用不到。
不敢用、用不到都很痛苦!为此就诞生了“拆”的想法，根据不同的“拆”法诞生了不同形态的分布式数据库。值得一提的是今天做数据库拆分的初衷并不是为了解决性能瓶颈而是数据存储达到单机上限，更直白一点地说，拆的关键是解决大表运维困境。
特性4：HTAP。
新时代赋予数据处理新的诉求，目前解决方案还是通过数据流(ETL)的方式将数据写到其他分析型数据库中。不管是链路维护复杂性还是应用健壮性(低延迟、高稳定性)都有不小的麻烦。因此，希望能通过一套数据库搞定所有问题。
特性5：容灾能力。
近几年企业对容灾的要求越来越高，作为DBA也应当确保极端情况下(机房限电、被炸等)数据库具备逃逸能力。单机数据库通过主从(异地部署)方式也能实现，虽然维护较为复杂但也能用。