讲给普通人听的分布式数据存储讲给普通人听的分布式数据存储
摘要:简单易懂,十分靠谱.AWS有这么多数据存储选项,针对你正确的工作负载选最适合你的那一个!
Neo,这就是让我们心烦的问题
为什么AWS有这么多的数据存储选项?我应该用哪个?这些是客户常见的问题。在这分成三部分的博客系列中,我将试图做
一些澄清。在第一部分,我会论述高可用性的基础,以及为什么冗余是实现高可用性的常用方法。我也简要地提到在数据层加
入冗余会带来新的问题。在本博客系列的第二部分,我会讨论这其中的一些问题,以及在克服这些问题时你需要考虑的取舍。
本博客系列的第三部分在这些信息的基础上,论述AWS特定的数据存储选项,以及每个存储选项的优化所针对的是哪些工作
负载。在你读完本博客系列的全部三部分之后,你就会赞同AWS提供了丰富的数据存储产品,并学会针对正确的工作负载选
择正确的选择。
关系型数据库到底有什么问题?
正如你们中的很多人可能已经知道的,关系型数据库(RDB)技术自从1970年代就已经存在,直到1990年代末一直是结构化
存储的事实标准。RDB几十年来很出色地支持了高度一致性事务的工作负载,并依然保持强劲。随着时间的推移,该项古老
的技术为应对客户的需求获得了新的能力,比如BLOB存储、XML/文档存储、全文检索、在数据库中执行代码、使用星形数据
结构的数据仓库、以及地理空间扩展。只要一切都能挤进关系型数据结构的定义中,并且适合于单机,就可以在关系型数据库
中实现。
然后,互联网的商业化发生了,并且彻底改变了一切,使得关系型数据库不再能够满足所有的存储需求。相比于一致性,可用
性、性能和扩展正在变得同样重要--有时甚至更重要。
性能一直很重要,但是随着互联网商业化的出现,改变的是规模。事实证明,要达到规模化的性能,要求的技巧和技术是前互
联网时代无法接受的。关系型数据库围绕着ACID(原子性Atomicity、一致性Consistency、隔离性Isolation和持久性
Durability)的概念而建立,实现ACID最简单的方法就是把一切保持在单机上。因此,传统的RDB规模化的方法是垂直扩展
(scale up),用白话说,就是使用更大的机器。
哦-哦,我想我需要一台更大的机器
使用一台更大的机器的解决方案一直很好,直到互联网带来的负载大到单机无法处理。这迫使工程师们想出巧妙的技术来克服
单机的限制。有许多不同的方法,各有其优缺点:主—副、集群、表联合与分区(table federation and partitioning)、水平
分区(sharding,可以认为是分区的特例)。