关于作者
John Ryan是经验丰富的数据仓库架构师、开发人员和数据库管理员。他专门从事多太字节Oracle系统上的Kimball维度设计,在移动电话和投资银行等多个不同的行业积累了超过30年的IT经验。
本文首次发表是作为有关数据库和大数据的系列文章中的一篇。
在过去的20年,世界发生了翻天覆地的变化。在2000年的时候,上网的人不过寥寥数百万,还是用台式机连56k的猫来上网,那时候亚马逊还只卖书。今天,数十亿人用智能电话或平板电脑每周7天、每天24小时上 网,几乎什么都在网上买,另外还使用 Facebook、Twitter和Instagram 这些社交应用与人互动。势不可挡。
人们的心理预期也变了。如果网页几秒钟未法完成刷新,我们当即失去耐心,换个别的网站。如果某个网站无法访问,我们担心那就是我们所知文明的终结。如果某个大型网站无法访问,它会成为全球性的大新闻。
即刻满足都还不够!
(Instant gratification takes too long!)
— Ladawn Clare-Panton
注:如果您不是经验丰富的数据库架构师,则您可能需要先阅读我以前关于可扩展性和数据库架构的文章。
由上可得出下列几个结论:
物联网(Internet of Things)让速度急剧加快!
— Stonebraker博士(MIT) .
上述需求催生极为精彩的营销术语Translytical数据库,意思是采用混合解决方案,即同一个解决方案既可处理海量事务,也可完成实时分析。
在降低成本的同时提供高性能(可能还要使用廉价服务器),是所有数据库厂商都面对的挑战。但是,需求之间相互冲突:
要具备海量渐进扩展能力,唯一现实的办法就是部署横向扩展的分布式系统。通常情况下,为最大地限度提高可用性,对某个节点实施的修改会被立即复制至两个或更多个其他节点。但是,一旦将数据分配给多个服务 器,则面临利弊权衡。
例如:
3.1
性能与可用性和耐久性
许多NoSQL数据库将数据复制至集群内的其他节点,以提高可用性。如果 数据库节点在在写入操作后立即崩溃,则数据在其他机器上有备份,因此修改是持久的。但是,也可放松这个要求,不备份就立即返回。这可实现性能的最大化,但有丢失修改的风险。修改可能根本无法持久。
▲ 地理分散式系统
3.2
一致性与可用性
NoSQL数据库支持最终一致性。例如,在上图中,如果与纽约之间的网络 连接临时断掉,则有两个选择:
显然,NoSQL数据库是用一致性来换取可用性方面的能力。
3.3
灵活性与可扩展性
与Oracle和DB2等通用型关系数据库相比,NoSQL数据库的灵活性相对较 差,(例如)不支持Join(连接)操作。除了许多不支持SQL语言的数据库,有些数据库(例如Neo4J和MongoDB)是专为支持特定问题而设计的—图处理和JSON数据结构。
即使像HBase、Cassandra和Redis这样的数据库,也放弃关系连接操作, 但许多还限制访问单一主键,并且不支持辅助索引。
许多数据库都声称100%支持ACID事务,
实际上提供正式ACID保证者寥寥无几。
— Peter Bailis 博士(斯坦福大学)
数据库解决方案的扩展方面,主要挑战之一就是维持ACID一致性。亚马逊采用DynamoDB数据库,放松一致性约束,以换取速度,从而解决了性能问题,由此催生了大量NoSQL数据库。
另外,最成功的数据库(包括Oracle)也无法提供真正的ACID隔离性。本文研究了18个数据库,默认支持SerializabilITy(可串行性)的数据库只有三个(VoltDB、Ingres和Berkeley DB)。主要原因是难以在保持性能的同时支持可串行性。
最终一致性是特别弱的一种模式。
系统可返回任何数据,依然可以做到最终一致。
— Peter Bailis 博士(斯坦福)
另一方面,最终一致性几乎不提供一致性保证。下图说明了最终一致性所存在的问题。一个用户从银行账户上扣款100万美元,但是在账户修改得到复制之前,又有一个别的用户检查这个账户的余额。唯一的保证是,只要没有进一步的写入操作,系统最终会提供一致的结果。这又有什么用处呢?让人接受就更谈不上了。
▲ Cassandra — 最终一致性
十年前,Michael Stonebraker博士撰写了《架构时代的终结》(The End of an ArchITectural Era)这篇文章,认为Oracle、微软和IBM提出的1970年代的数据库架构已经过时。
他提出OLTP数据库应具备下列特点:
为证明上述各项的可能性,他建了一个原型,即H-Store数据库,并证明使用相同的硬件, TPC-C基准性能是某商业竞争对手的82倍。H-Store原型成绩优异,实现了每秒处理70,000个事务,而尽管数据库管理员付出了大量努力进行调优,某商业竞争对手每秒仅850个。
Stonebraker博士的成就令人侧目。此前的TCP-C世界纪录为每个 CPU 核心大约1,000个事务,但H-Store采用双核2.8GHz台式机,速度是原世界纪录的35倍。他在2008年的文章《细探 OLTP 》(OLTP through the Looking Glass)中解释了为什么商业数据库(包括Oracle)的性能为什么如此差劲。
▲ 关系数据库的处理资源消耗
上图显示,有93%的系统开销是用于传统(历史遗留)的数据库系统,包括锁定、锁存和缓存管理。合计只有7%的机器资源是专门用于手头的任务。
H-Store只是通过消除上述瓶颈,使用基于内存的处理来代替基于磁盘的处理,就得以实现看似不可能的任务,即全面的ACID事务一致性,使速度提升了几个数量级。
VoltDB最早发布于2010年,是H-Store原型的商业化产品,属于专用的OLTP平台,用于Web级的事务处理和实时分析。如这张信息图所示,目前有250种商业化数据库解决方案,其中只有13种被归入NewSQL技术的行列。
与其他NewSQL数据库一样,VoltDB旨在完全在内存中运行,提供定期拍摄磁盘快照的选择。它可在本地运行于64位Linux,也可使用AWS、谷歌和Azure的云服务来运行,采用横向可扩展的架构。
传统的关系数据库将数据写入基于磁盘的日志文件。VoltDB则不然,是同时对内存内的多台机器进行修改。例如,即使两台机器发生故障,
K-Safety系数为2时即可保证不会造成数据损失,因为数据至少存入三个内存节点。
事务作为Java存储过程(stored procedure)提交,可在数据库中异步执行,并且数据自动分区(分片),分配至系统内的节点,尽管可复制基准数据以最大限度地提高连接性能。VoltDB有一点不同寻常,就是还以JSON数据结构的形式,支持半结构化数据。
就性能而言,2015年进行的一次基准测试显示,VoltDB的处理速度至少是NoSQL数据库Cassandra的两倍,但成本只有AWS云处理成本的六分之 一。
最后,VoltDB 6 .4版通过了极为苛刻的 Jepsen分布式安全性测试。
相比之下,此前对NoSQL数据库Riak进行的测试表明,即使采用最强的一 致性设置,写入也会下降30-70%。与此同时,采用轻量级事务时,Cas- sandra 最多损失5%的写入。
与VoltDB相同的是,MemSQL是横向扩展的内存型分布式数据库,专为快速获取数据和实时分析而设计。另外,既可在本地运行,也可在云上运行,并可在不同节点之间自动分片,在每个CPU核心上并行执行查询。
▲ 关系数据库的处理资源消耗
尽管与VoltDB有许多相似点,但上图表明了一个重要的差异。MemSQL 试图在实时事务与数据仓库式历史数据处理这两种相互冲突的需求之间寻求平衡。为此,MemSQL以行存储(row store)的方式在内存中存储数据, 并用面向列的磁盘存储作为备份,从而将实时(最近)数据与历史结果结合在一起。
这使其在OLTP和数据仓库(Data Warehouse)领域获得了稳固的位置,尽管这两种解决方案都是瞄准实时数据获取和分析市场。
要求采集速度和响应速度非常快(平均1-2毫秒),同时要求ACID保证所提供的事务准确性的任何应用—例如客户计费。
典型的应用包括:
与绝大多数OLTP应用相比,这些起初看来都不起眼,但是在每周7天、每天24小时联网的世界,这些为实时分析提供了新的疆域,并且随着物联网的兴起,也带来了巨大的机会。
虽然Hadoop与大数据的关联更为密切,并且近来获得巨大的关注,但数据库技术是任何IT系统的基石。
类似地,NoSQL数据库为替代关系数据库提供了一个快速、可扩展的选 择,但是尽管有免许可开源数据库的诱惑,事实上还是一分钱一分货。另外,正如VoltDB所显示的那样,实际上长期来看,可能比NoSQL类的选择更为便宜。
总的说来,如果有Web规模、OLTP和(或)实时分析的要求,则需要认真考虑NewSQL类数据库。
如果您对VoltDB的工业物联网大数据低延迟方案、全生命周期的实时数据平台管理等感兴趣,欢迎私信,进入到我们的官方交流群。
原文:https://www.cnblogs.com/VoltDB/p/13958245.html