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

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

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

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

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

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

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

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

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

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

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

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

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

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

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。