Oracle、NoSQL和NewSQL 数据库技术对比

2022-04-13 00:00:00 数据 数据库 事务 实时 可用性
关于作者

John Ryan是经验丰富的数据仓库架构师、开发人员和数据库管理员。他专门从事多太字节Oracle系统上的Kimball维度设计，在移动电话和投资银行等多个不同的行业积累了超过30年的IT经验。

本文发表是作为有关数据库和大数据的系列文章中的一篇。



1
世界已经变了




在过去的20年，世界发生了翻天覆地的变化。在2000年的时候，上网的人不过寥寥数百万，还是用台式机连56k的猫来上网，那时候亚马逊还只卖书。今天，数十亿人用智能电话或平板电脑每周7天、每天24小时上 网，几乎什么都在网上买，另外还使用 Facebook、Twitter和Instagram 这些社交应用与人互动。势不可挡。
人们的心理预期也变了。如果网页几秒钟未法完成刷新，我们当即失去耐心，换个别的网站。如果某个网站无法访问，我们担心那就是我们所知文明的终结。如果某个大型网站无法访问，它会成为全球性的大新闻。
即刻满足都还不够！
(Instant gratification takes too long!)
— Ladawn Clare-Panton
注：如果您不是经验丰富的数据库架构师，则您可能需要先阅读我以前关于可扩展性和数据库架构的文章。

2
哪些变了？



由上可得出下列几个结论：

  • 可扩展性 — 流量可能出现爆炸性的增长，IT系统需要迅速扩大规模， 以处理指数化增长的事务

  • 高可用性 — IT系统必须每周7天、每天24小时运行，并且必须具有故障容错性。（美国银行2011年发生一次故障，对2900万客户造成持续六天的影响）。

  • 高性能 — 随着可扩展性的不断增强，性能也必须跟上，保持稳定和快速。据亚马逊估算，在极端情况下，页面加载时间每增加一秒，该公司每年要损失16亿美元。

  • 速度 — 设备自带的联网传感器越来越多（远的不说，智能电话就自带联网传感器），每秒可能会有数以百万计的事务需要处理。

  • 实时分析 — 夜间进行批处理和业务智能化已经过时。分析与操作处理之间的界限变得模糊，对实时决策的需求越来越多。

物联网(Internet of Things)让速度急剧加快！
— Stonebraker博士(MIT) .
上述需求催生极为精彩的营销术语Translytical数据库，意思是采用混合解决方案，即同一个解决方案既可处理海量事务，也可完成实时分析。

3
问题是什么？



在降低成本的同时提供高性能（可能还要使用廉价服务器），是所有数据库厂商都面对的挑战。但是，需求之间相互冲突：

  • 性能—大限度地缩短延迟，在毫秒级时间内完成事务处理。

  • 可用性—即使系统的一个或多个节点发生故障或与网络断开，也能保持运行的能力。

  • 可扩展性—能够不断地扩大规模，以满足海量数据和事务速度的要求。

  • 一致性—提供一致、准确的结果 — 特别是在发生网络故障时。

  • 耐久性—确保修改一旦实施后不会丢失。

  • 灵活性—提供通用的数据库解决方案，以支撑事务及分析方面的工作负荷。

要具备海量渐进扩展能力，现实的办法就是部署横向扩展的分布式系统。通常情况下，为大地限度提高可用性，对某个节点实施的修改会被立即复制至两个或更多个其他节点。但是，一旦将数据分配给多个服务 器，则面临利弊权衡。
例如：
3.1
性能与可用性和耐久性

许多NoSQL数据库将数据复制至集群内的其他节点，以提高可用性。如果  数据库节点在在写入操作后立即崩溃，则数据在其他机器上有备份，因此修改是持久的。但是，也可放松这个要求，不备份就立即返回。这可实现性能的大化，但有丢失修改的风险。修改可能根本无法持久。
▲ 地理分散式系统

3.2
一致性与可用性

NoSQL数据库支持终一致性。例如，在上图中，如果与纽约之间的网络  连接临时断掉，则有两个选择：

  • 停止处理 — 但是纽约的可用性就受到了影响

  • 接受读取/写入操作 — 在恢复网络连接后消除差异。但是这么做的风险是提供过期或错误的结果，可能需要解决写入操作的冲突

显然，NoSQL数据库是用一致性来换取可用性方面的能力。
3.3
灵活性与可扩展性
与Oracle和DB2等通用型关系数据库相比，NoSQL数据库的灵活性相对较  差，（例如）不支持Join（连接）操作。除了许多不支持SQL语言的数据库，有些数据库（例如Neo4J和MongoDB）是专为支持特定问题而设计的—图处理和JSON数据结构。
即使像HBase、Cassandra和Redis这样的数据库，也放弃关系连接操作， 但许多还限制访问单一主键，并且不支持辅助索引。
许多数据库都声称支持ACID事务，
实际上提供正式ACID保证者寥寥无几。
— Peter Bailis 博士（斯坦福大学）

4
ACID与终一致性



数据库解决方案的扩展方面，主要挑战之一就是维持ACID一致性。亚马逊采用DynamoDB数据库，放松一致性约束，以换取速度，从而解决了性能问题，由此催生了大量NoSQL数据库。
另外，成功的数据库（包括Oracle）也无法提供真正的ACID隔离性。本文研究了18个数据库，默认支持SerializabilITy（可串行性）的数据库只有三个（VoltDB、Ingres和Berkeley DB）。主要原因是难以在保持性能的同时支持可串行性。

终一致性是特别弱的一种模式。 

系统可返回任何数据，依然可以做到终一致。
— Peter Bailis 博士（斯坦福）
另一方面，终一致性几乎不提供一致性保证。下图说明了终一致性所存在的问题。一个用户从银行账户上扣款100万美元，但是在账户修改得到复制之前，又有一个别的用户检查这个账户的余额。的保证是，只要没有进一步的写入操作，系统终会提供一致的结果。这又有什么用处呢？让人接受就更谈不上了。
▲ Cassandra — 终一致性 

5

重新设想OLTP数据库




十年前，Michael Stonebraker博士撰写了《架构时代的终结》(The End of an ArchITectural Era)这篇文章，认为Oracle、微软和IBM提出的1970年代的数据库架构已经过时。
他提出OLTP数据库应具备下列特点：

  • 专门用于解决某一个问题 — 快速执行短暂的预定义（非即席的）事务，查询计划相对简单。简而言之，就是专用的OLTP平台。

  • 符合ACID规范 — 所有事务均为单线程运行，默认提供全部可串行性。

  • 总是可用 — 利用数据复制（而非热备）来提供高可用性，几乎不增加成本。

  • 地理分散 — 在由分散多处的机器组成的网格上无缝运行（进一步提高韧性，并局部地提高性能）

  • 无共享架构 — 多台机器通过对等网格联网，分担负荷。添加机器是不会造成停机的无缝操作，并且失去一个节点仅会造成性能略微下降，而不是全系统停止运行。

  • 基于内存 — 全部在内存中运行，以提高速度，通过向其他节点进行内存中数据复制来保证耐久度。

  • 消除瓶颈 — 彻底重新设计数据库的内部构件，实现单线程运行，同时消除重做(Redo)日志以及锁定和锁存的必要性—这些都是数据库性能为重大的制约。

为证明上述各项的可能性，他建了一个原型，即H-Store数据库，并证明使用相同的硬件， TPC-C基准性能是某商业竞争对手的82倍。H-Store原型成绩优异，实现了每秒处理70,000个事务，而尽管数据库管理员付出了大量努力进行调优，某商业竞争对手每秒仅850个。

6

世上无难事！




Stonebraker博士的成就令人侧目。此前的TCP-C世界纪录为每个 CPU 核心大约1,000个事务，但H-Store采用双核2.8GHz台式机，速度是原世界纪录的35倍。他在2008年的文章《细探 OLTP 》(OLTP through the Looking Glass)中解释了为什么商业数据库（包括Oracle）的性能为什么如此差劲。
▲ 关系数据库的处理资源消耗
上图显示，有93%的系统开销是用于传统（历史遗留）的数据库系统，包括锁定、锁存和缓存管理。合计只有7%的机器资源是专门用于手头的任务。
H-Store只是通过消除上述瓶颈，使用基于内存的处理来代替基于磁盘的处理，就得以实现看似不可能的任务，即全面的ACID事务一致性，使速度提升了几个数量级。

7

NewSQL数据库技术




VoltDB早发布于2010年，是H-Store原型的商业化产品，属于专用的OLTP平台，用于Web级的事务处理和实时分析。如这张信息图所示，目前有250种商业化数据库解决方案，其中只有13种被归入NewSQL技术的行列。

8

VoltDB




与其他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%的写入。

9

MemSQL




与VoltDB相同的是，MemSQL是横向扩展的内存型分布式数据库，专为快速获取数据和实时分析而设计。另外，既可在本地运行，也可在云上运行，并可在不同节点之间自动分片，在每个CPU核心上并行执行查询。
▲ 关系数据库的处理资源消耗
尽管与VoltDB有许多相似点，但上图表明了一个重要的差异。MemSQL 试图在实时事务与数据仓库式历史数据处理这两种相互冲突的需求之间寻求平衡。为此，MemSQL以行存储(row store)的方式在内存中存储数据， 并用面向列的磁盘存储作为备份，从而将实时（近）数据与历史结果结合在一起。
这使其在OLTP和数据仓库(Data Warehouse)领域获得了稳固的位置，尽管这两种解决方案都是瞄准实时数据获取和分析市场。

10

哪些应用需要NewSQL技术？




要求采集速度和响应速度非常快（平均1-2毫秒），同时要求ACID保证所提供的事务准确性的任何应用—例如客户计费。
典型的应用包括：

  • 实时授权 — 例如，为了分析和计费而验证、记录和授权移动电话呼叫。通常，99 .999%的数据库操作都必须在50毫秒内完成。

  • 实时欺诈侦测 — 用于完成复杂的分析查询，以在交易授权之前，准确地确定欺诈的可能性。

  • 游戏分析 — 用于根据玩家的能力和玩家的典型行为，实时动态修改游戏难度。目标是留住现有玩家，以及将免费客户转化为付费玩家。在速度、可用性和准确性要求很高的情况下，某客户通过运用这些手段，将玩家的游戏支出提高了40%。

  • 个性化Web广告 — 实时动态地选择基于 Web 的个性化广告，记录广告呈现事件以用于计费，同时记录广告结果以用于后续分析。

与绝大多数OLTP应用相比，这些起初看来都不起眼，但是在每周7天、每天24小时联网的世界，这些为实时分析提供了新的疆域，并且随着物联网的兴起，也带来了巨大的机会。

11

结论




虽然Hadoop与大数据的关联更为密切，并且近来获得巨大的关注，但数据库技术是任何IT系统的基石。
类似地，NoSQL数据库为替代关系数据库提供了一个快速、可扩展的选 择，但是尽管有免许可开源数据库的诱惑，事实上还是一分钱一分货。另外，正如VoltDB所显示的那样，实际上长期来看，可能比NoSQL类的选择更为便宜。
总的说来，如果有Web规模、OLTP和（或）实时分析的要求，则需要认真考虑NewSQL类数据库。
来源 https://www.modb.pro/db/170794

相关文章