Corda, SQL and NoSQL（翻译）

2024年1月31日 162次阅读来源: ppppp

原文地址

Corda在很多方面都与其他区块链平台有一些差异，其中最显著的是我们使用了关系数据库。有时候人们会问 – 我们是不是在反潮流，毕竟当前的技术趋势是不提倡SQL和传统数据库的。

答案是否定的，我将在下面的文章中阐述我们这么做的原因。

NoSQL 还是 NewSQL

在介绍SQL，NoSQL和NewSQL数据库之间的区别之前，我想简要提一下我的背景。我是Corda项目的首席开发工程师，负责大部分架构设计。我曾经为谷歌工作，在谷歌我的第一份工作是作为谷歌地图和地球项目的“网站可靠性工程师”。SRE团队将具有各种背景的人员结合在一起 – 系统管理员和系统级程序员在会在一起配合完成一项服务的各个方面的日常操作。这项工作涉及系统负载，故障排除，设计和架构评审，基础设施运营等。我的角色之一是操作BigTable集群，因为卫星图像基础架构严重依赖于Google的第一代可扩展数据库。在开始这个工作之后，我还写了很多使用BigTable和MapReduce的软件。所以我对于这些技术栈非常的熟悉。

在Google发布了关于这两种技术的论文之后，它们被称为“NoSQL”和“大数据”被人们所熟知。通过放弃关系数据模型及其相关查询语言的限制，使得大规模的“web scale”数据集合变得容易。关系数据库引擎的许多功能限制导致它不是很容易作为集群扩展，于是通过web服务的方式寻找替变的有意义。这一趋势导致开源界重复造了很多的轮子，如Hadoop，HBase，Cassandra和Accumulo（来自NSA！）。对于使用BigTable的任何Google工程师来说，Cassandra文档看起来都非常的熟悉，比如有关sstables，合并压缩等内容。

NoSQL的趋势也衍生了一组与BigTable及其派生类似的数据库，但实际上它们完全不同。我把MongoDB和CouchDB放在了这个类别里。最典型的区别是它们不是基于列的，而是存储任意的JSON树，缺乏透明的自动重新分割，并且根本不提供查询语言（每个查询都必须作为MapReduce运行）。

除了偶尔发表学术论文之外，Google对于数据库并没有提供太多的外部意见或建议。因此，软件行业开始陷入严重的误解：认为缺乏SQL和其他核心关系数据库特性是一个优势而不是缺点。

“NoSQL”这个名称也反映了这种趋势。但事实并非如此，在谷歌内部失去SQL，连接，临时查询和复杂交易被视为重大问题。这些特征只有极度不情愿才会放弃。实际上，在Google业务的最核心部分 – 存储广告数据的部分 – 他们从不愿意切换到自己的内部数据库，因为缺少的功能太过关键。直到最近我才知道在我在谷歌任职的这段期间，核心AdWords数据库都在一个分片的MySQL集群上运行。对于不能或不会采用这种架构的应用程序，需要大量的工程成本来解决NoSQL功能缺失的弱点。

因此，目标始终是建立一种新的关系数据库引擎，这种引擎可以扩展到Google所需的惊人尺寸。为实现这一目标创建了大量项目，这些目标导致了像Dremel，MegaStore，Spanner这样的系统，并最终取得了冠军，F1是一款数据库引擎，具有与MySQL相竞争的特性。 F1论文有一些引用来说明这20年的旅程：

近年来，工程界一直认为，如果您需要高度可扩展的高吞吐量数据存储，唯一可行的选择是使用NoSQL密钥/值存储，并在缺少ACID事务保证和缺少像二级索引，SQL等便利性的条件下工作。当我们为AdWords产品寻求谷歌MySQL数据存储的替代品时，这样的选项根本无法实现：在我们的业务逻辑的每个部分处理非ACID数据存储的复杂性将非常高，而且我们的业务必须用SQL查询查询描述和运行。

我们没有进入NoSQL，而是建立了F1，这是一个分布式关系数据库系统，结合了高可用性，NoSQL系统的吞吐量和可扩展性，以及传统关系数据库（包括ACID事务和SQL查询）的功能性，可用性和一致性。

这种新一代的数据库技术可以被称为NewSQL 通过新引擎处理大数据的特性。

谷歌并不是唯一认识到传统数据库引擎的功能对于任何真实业务都不可或缺的公司。布隆伯格几十年来一直在设计自己的数据库引擎，直到最近我还没有意识到这一点，但这并没有让人感到意外。他们的ComDB2数据库现在不仅在一篇优秀的论文中进行了描述，而且彭博社甚至已经开源了它。 ComDB2可以使用很多机器来提供大量的读取吞吐量，尽管它不能像F1那样扩展到相同的范围，但即使是金融行业中要求最严格的场景，它也显然是足够的。

好了，历史课结束……来解释一下这些是如何作用在Corda上的？

Corda and SQL

Corda节点由关系数据库支持。开源版本使用H2嵌入式SQL引擎，但该设计允许使用具有JDBC驱动的任何数据库。预计将来会看到对其他数据库引擎的支持（有帮助的是，Bloomberg的ComDB2自带了这种适配器）。

值得快速回顾一下其他区块链/分布式账本平台在此领域中选择的方式：

• 以太坊：每个实例化的智能合约都获得一个关键/价值存储。据我所知，没有查询语言。

• IBM Fabric：您可以在LevelDB（一个基于键/值存储的数据库，采用了部分BigTable的方式设计）或CouchDB（JSON文档存储）之间进行选择。没有查询语言，而是必须在JavaScript中编写小MapReductions，然后每次处理整个数据集。由于CouchDB和LevelDB都是无结构的，因此没有办法在数据层约束账本上的数据格式。

• 比特币：不提供通用数据库或查询系统，因为它仅用于处理单一资产。

• Quorum：基于以太坊并提供相同的查询功能。

正如你所看到的，我们是唯一一个使用关系数据模型服务的。以下原因导致我们产生了这个决定：

1. SQL是必要的。正如谷歌所说的那样，“SQL查询是必须要有的功能，它们对我们的业务至关重要”。如果他们对Google的业务至关重要，那么他们对于Corda所涉及的业务更为重要 – 金融公司能够快速查询，分析和电子表格数据是每日需求。 SQL是个通用技术并广为人知，可以在几秒钟内解决复杂的业务问题。

“仅仅让开发人员写来编写MapReduce”并不是一个可以接受的替代品，我们预计在不支持关系映射的平台上构建的概念验证会在他们真正作为产品环境时遇到困难。

2. SQL是未来。软件行业有一个成熟的模式，即追随少数几个大型企业，他们正在大量投资SQL。当然不仅是Google，而且是金融界最大的玩家。我们的赌注已经得到回报，这要感谢彭博社决定开放源码ComDB2 – 我希望我们将在未来的某个时候尝试增加对Corda的支持。

3.许多数据集不需要NewSQL数据库。 BigTable于2004年为该时代的硬件而设计。论文描述了当时在Google Analytics中使用的两个表格 – 一个200 TB的原始点击表格和一个20 TB的总结表格。

但即使在2005年，也可以在Oracle上运行100TB的数据库。从那时起，SSD，CPU核心数量，RAM都已经出现了。像PostgreSQL这样的开源数据库已经有了很大的改进，一台机器上的数十兆字节不再被认为是不合理的。

考虑到大约10,000美元，你可以购买1TB的RAM。如果您的应用程序拥有十亿用户，那么每个用户都可以获得大约一千字节的RAM ……这将产生真正令人敬畏的IO吞吐量。然而，没有什么银行一开始有那么多的用户！特别是在金融领域，数据集通常有一个热门的“尖端”，例如，目前的交易正在被记录下来，数据迅速冷却并且很少被访问。

如果您只需购买一台大型机器即可使用传统的关系数据库，那么这样做是一个非常好的主意 – 您将节省运行分布式系统带来的大量维护难题（我依然记得我用来调试大型BigTable群集的那些夜晚和周末！）实际上，对于分布式账本的许多使用案例，它们可以很容易地放入单个精心设计的服务器中。

Corda对SQL的支持非常深入：

•节点本身将其工作数据存储在数据库中。从而：

备份或复制数据库也会备份或复制节点。
数据中心之间的节点数据复制在很大程度上是配置数据库引擎的问题，这是金融机构具有丰富专业知识的任务。

•与Google的尖端F1数据库一样，Corda分布式账本可以存储任意数据树状态。 JPA注解被用来启用映射到关系模型。你并不局限于柱面方法。这很有用 – Google在他们的F1论文中一再强调他们发现其等价能力的重要性和实用性（protobuf嵌入）。

•使用该功能，节点会自动为您授权查看的全局账本部分创建只读关系镜像。它会自动发生，应用程序开发人员不需要采用额外的步骤来标注其模式。

•您可以为CorDapp中的每个状态定义多个模式，这意味着应用程序可以按照不同的计划进行升级以更改基础模式更改。这很适合许多银行使用的模式变更流程。

•您可以从Corda shell发出SQL查询。

•将开放源代码节点与嵌入式H2数据库一起使用时，可以从DemoBench工具打开Web控制台，以交互式浏览和使用数据库层。

•通过在节点使用的同一个数据库中创建自己的表，您可以加入私人数据集（如客户记录和账本数据） – SQL JOIN是一种非常强大的工具，可以使账本中的私人数据变得简单直接。这是我们故事的一个关键部分，可以确保数据只存在于需要去的地方。

•节点通过RPC（针对某些类型的查询）向连接的客户端发送更改通知和增量，以启用即时响应账本中的更改的应用程序。这是其他平台通常缺乏的功能。

我们相信这种方法非常有吸引力，其他分布式账本平台会及时生成SQL适配器层，我们会欢迎这种开发。如果不同区块链平台上的多个节点可以共享相同的基础数据库引擎，则可以通过在不同分布式账本之间执行SQL JOIN来解决一些互操作问题。

    原文作者：ppppp
    原文地址: https://zhuanlan.zhihu.com/p/33981057
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。