在区块链的TPS后加多少个零才能看齐亚马逊?

几乎所有现实世界中的商用,包括但不限于支付,电子商务,远程遥测,业务流程工作流,供应链和运输物流,都需要很大的带宽来处理其当前的业务数据需求,更不用说未来的科技对处理速度的需求。

在区块链的TPS后加多少个零才能看齐亚马逊?

无论你对区块链的未来饱含多大的热情,对区块链的技术抱有多高的希冀,TPS都是一个硬指标,横亘在那里,不高不低。TPS不偏不倚的展现着区块链世界相较于互联网世界的差距。

几乎所有现实世界中的商用,包括但不限于支付,电子商务,远程遥测,业务流程工作流,供应链和运输物流,都需要很大的带宽来处理其当前的业务数据需求,更不用说未来的科技对处理速度的需求。

那么,到底目前成熟的商业应用需要多大的TPS?

通过查看Amazon的2019 Prime Day统计数据,笔者发现在Prime Day的48小时内, DynamoDB 的API进行了7.11万亿次调用,峰值为每秒4540万次请求。也就是说亚马逊DynamoDB的TPS 达到了4540万/秒。

每秒4500万次请求。这个处理能力比特币或以太坊还多六个零。这仅仅是亚马逊一家公司的流量,是全球流量的一部分。DynamoDB在高峰期实际执行的TPS甚至比上述数字还要高。

在区块链的TPS后加多少个零才能看齐亚马逊?

理想与目标之间的差距……并不仅限于此。如果您想在现实世界中的电子商务环境中使用区块链,并希望它以多线程的方式支持多家公司,希望它替代旧的数据库系统——一个稍微靠谱的目标要达到每秒1.4亿笔交易。

距离现今的TPS还有七个数量级。

对于如此魔鬼级别的TPS到底是何方神圣呢?我们先来梳理一下亚马逊DynamoDB的前世今生——

在区块链的TPS后加多少个零才能看齐亚马逊?

事情最初可以追溯到2004年。亚马逊那时候还在使用着 Oracle 带有集群与备份的企业级数据库。开发团队一直在努力构建在当时占据领先地位的商业数据库,但却无法满足亚马逊业务持续增长带来的可用性、可扩展性以及性能需求。

彼时,基于 Oracle 运行的数据库已是不堪重负,于是亚马逊团队开始评估是否可以开发一款定制的数据库来满足长期商业需求。于是他们优先专注于那些能够支持亚马逊购物车等大规模、任务关键型服务的要求。同时,团队也大胆提出传统关系型数据库可替代的假设,如强一致性的要求。他们的目标是开发有着无限扩展性、一致性能以及高可用性的数据库,从而促进业务的快速发展。

在区块链的TPS后加多少个零才能看齐亚马逊?

亚马逊对当时数据库的使用方式进行了深入研究,发现其对数据库的关系型能力需求并不频繁。大约70%的操作都是键-值类操作——仅使用一个主键,返回一个单行数据。大约20%的操作会返回一组行数据,但是也仍然位于单个表上。

基于这些要求以及对当前现状的质疑,一个规模并不大的分布式系统领域专家团队合作设计了一款可以同时支持读写扩展的横向扩展型分布式数据库,来满足长期业务需求。这就是亚马逊 Dynamo 数据库的起源。

基于 Dynamo 数据库前期取得的成功,亚马逊发表了Dynamo白皮书,并在2007年 ACM 操作系统原理会议(SOSP)上发表,希望可以让业界同行从中获益。这篇白皮书得到了业界的广泛认可,并催生了当今众所周知的 NoSQL 分布式数据库技术。

在区块链的TPS后加多少个零才能看齐亚马逊?

《Dynamo: Amazon's Highly Available Key-value Store》文章节选

当然,没有哪项技术变革是在封闭的环境中发生的,与此同时,在 NoSQL 演进的过程中,云计算技术也在向前发展。随着 AWS 的发展,亚马逊开始着手基于原有的 Dynamo 设计架构打造一项全面托管型 AWS 数据库服务。并于2012年1月正式发布了 Amazon DynamoDB。这项基于云端的 NoSQL 数据库服务可在满足安全性、可用性、高性能以及可管理性的同时,支持运行超大规模的关键性作业任务。

在区块链的TPS后加多少个零才能看齐亚马逊?

今天,DynamoDB 正在驱动那些让传统数据库难以承载的新一代高性能、互联网规模应用。Lyft、Tinder 和 Redfin 等互联网巨头以及 Comcast、Under Armor、宝马、 Nordstrom 和丰田等大型企业都在依靠 DynamoDB 的可扩展性和高性能来为自身的关键作业任务保驾护航。

Lyft 使用 DynamoDB 储存所有车辆的位置信息;

Tinder 使用它来存储百万用户信息以及完成数十亿次的搜索匹配;

Redfin 使用它来存储百万用户信息,并管理数以亿计的房产数据;

Comcast 使用它来驱动运行于2000多万台设备上的 XIFINITY X1 视频服务;

宝马使用它来打造了“车传感(CARASSO)”服务,可在24小时内实现两个数量级的服务规模变化;

Nordstrom 在推荐系统中使用 DynamoDB,使得处理时间从20分钟降至短短几秒;

Under Armour 使用它支持拥有2亿用户的互联健身社区;

丰田赛车部门基于 DynamoDB 制定有关进站、轮胎更换、比赛策略的实时决策;

此外还有超过10万的 AWS 客户在各种这样的大规模、高性能应用中使用 DynamoDB。

基于大量的客户实践,DynamoDB 已经实现了它的设计初衷。

现在让我们看一下技术。

在我们考虑下一代区块链架构时,是否可以从成功扩展的分布式系统(例如DynamoDB)中收集设计灵感和经验呢?

应用程序层分片

与NoSQL数据库的API相比,在区块链中采取的合约可以更强的以合约为中心,但是让应用程序确定哪些交易需要全部执行还是部分执行还是不需要执行,这一点至关重要。

路由很重要

单靠网络路由无法将区块链速度提高7个数量级。

基本硬件的重要性

绝大多数区块链节点都在云中运行,但区块链开发人员几乎忽略云的存在,忽视了对云服务器的优化。这让区块链在性能上与互联网有了很大的差距。在像DynamoDB这样的系统中,每一行代码都已经过优化,可以在云中良好运行。但如果没有针对云服务进行专门优化,区块链将在每笔交易中都浪费性能和成本。

通过将区块链与当今商业世界中最高频使用、最重要意义的分布式算法进行比较,我们可以学到很多东西。只有愿意从相关领域和应用程序中学习和改变想法,区块链和加密货币才能成长成为当初被设定的代表人类崇高理想的样子。

本文来自,仅作分享,存在异议请联系平台删除。本文观点不代表刺猬财经 - 刺猬区块链资讯站立场。

(0)
上一篇 2019年10月14日 上午9:00
下一篇 2019年10月14日 上午10:10

相关推荐