云数据库选型也绕不开“CAP定理”？

与80年代初期相比，今天的数据库技术，可以说是取得了长足猛进的发展。不仅在硬件的选择上，不再视大型机为唯一，还可以根据具体的业务需求，选择更贴近业务场景需求的数据库产品。

如今，软、硬件技术在不断进步，使得数据库的种类发生了翻天覆地的变化。除了过去常用的关系型数据库，我们还可以选择时序数据库、图数据库、文本数据库等等。有的数据库只支持单一数据处理，有的数据库可支持多种数据共用同一个实例。一些专门用于在线事务处理的数据库，叫做 OLTP;一些专门用于分析型业务的数据库叫做 OLAP。而能够把两者结合起来的，叫做HTAP。

总之，你可以把数据库放在任意地方，可随时随地访问你的数据，或者随意迁移数据。比如：你可以把智能手机上的数据迁移到本地的数据中心服务器，还可以从本地服务器迁移到云数据库上。

那么，问题来啦，什么是云数据库?

这两年，不管是传统数据库厂商，还是云计算大厂，都在主推“云数据库”，对于云数据库概念，不同人有不同理解，可以说是众说纷纭。那么，到底什么是云数据库?数据库从本地迁移到云上，就是云数据库吗?

从定义来看，云数据库是指被优化或部署到一个虚拟计算环境中的数据库，最显著的优势是可以获得按需付费、按需扩展、高可用性以及存储整合等能力。所以，云数据库即可以在本地运行，也可以通过专有云的方式运行，同时与本地数据库兼容。另外，有些云计算大厂推崇的是云原生数据库，这意味着整个数据架构都需要使用公有云厂商提供的服务。

不管大家如何看待云数据库，有一点可以确定，那就是数据库不是一个简单的软件应用，而是涉及到应用程序的后端和存储层。即数据从前端传到后台，后台与数据库直接关联。同时，按照CAP定理，在一致性、可用性、分区容错性三者之间，不可能三者兼顾，而是最多同时兼顾两项。

也就是说，如何选择一个理想数据库，取决于应用程序需求。如果只用于显示应用程序的目录，那么数据库的读取速度和延迟时间很重要，这时文档数据库可能是理想型选择，当然很多关系型数据库和宽列数据库也能适用。如果是金融交易式应用程序处理，那么如何满足数据库的 ACID 属性(原子性、一致性、隔离性和持久性)就变得非常重要，这时关系型数据库显然是最佳选择。

随着数据库技术的不断成熟，数据库选型也在突破传统技术架构的局限。比如：在满足现代化业务需求的分布式数据库架构中，节点故障和分区容错性可以通过使用 Paxos 或 Raft 共识算法来解决。本质上，当一个节点退出集群时，只要它有仲裁，集群就能继续工作。此外，这种分区的思想在私有云内部网络中很少见，类似于云服务提供商提供的那种分布式架构服务，在本地数据中心是通过光纤冗余来实现，并且不通过公网传输占据内部流量。

所以，总的来看，虽然没有任何技术可以绕过CAP 定理，但好的云数据库具有超过五个九 (99.999%) 的可用性，从一定程度上大大提高了数据库的一致性和可用性水平。比如：针对多人游戏场景，读写能力和延迟性都很重要，这时分布式数据库架构，可以很好地解决这一问题。如果不是强一致性业务以及关系型业务，键值数据库可能是理想选择。如果是传感器之类的数据输入输出，可以快速大量写入的时序数据库，表现会更好。

另外，任何云数据库都可以处理少量以及大量数据。少的可以处理以千兆字节或更少单位的数据。而具有大数据处理能力的云数据库，可以处理 TB级数据(数千 GB)，包括少数数据库可以容纳 PB级(数百万 GB)。

需要重点强调的是，大多数云数据库会按月向您收取存储费用，SSD 存储的费用要高于磁盘存储。另外，过高的数据处理速度也会给其他指标带来影响，例如数据库写入速度和网络容量受到限制。 如果数据量突增，数据库或前端程序可能需要在写入永久存储时将其缓冲在 RAM 中，以避免数据丢失。

无论你选择什么样的数据库，都不要忘记在投入生产前进行大量测试。另外，也并不是所有的云数据库，都要需要你100%地把本地数据库迁移到云上。同时，一旦数据库上云，就要做好监控和防护措施，出现问题时要有预警机制，能够快速迁移到备份方案中。