共计 4941 个字符，预计需要花费 13 分钟才能阅读完成。
对于作者
John Ryan 是经验丰富的数据仓库架构师、开发人员和数据库管理员。他专门从事多太字节 Oracle 零碎上的 Kimball 维度设计，在移动电话和投资银行等多个不同的行业积攒了超过 30 年的 IT 教训。
本文首次发表是作为无关数据库和大数据的系列文章中的一篇。
01 世界曾经变了
在过来的 20 年，世界产生了天翻地覆的变动。在 2000 年的时候，上网的人不过寥寥数百万，还是用台式机连 56k 的猫来上网，那时候亚马逊还只卖书。明天，数十亿人用智能电话或平板电脑每周 7 天、每天 24 小时上 网，简直什么都在网上买，另外还应用 Facebook、Twitter 和 Instagram 这些社交利用与人互动。势不可挡。
人们的心理预期也变了。如果网页几秒钟未法实现刷新，咱们当即失去急躁，换个别的网站。如果某个网站无法访问，咱们放心那就是咱们所知文化的终结。如果某个大型网站无法访问，它会成为全球性的大新闻。
** 即刻满足都还不够！
(Instant gratification takes too long!)
— Ladawn Clare-Panton**
注：如果您不是经验丰富的数据库架构师，则您可能须要先浏览我以前对于可扩展性和数据库架构的文章。
02 哪些变了？
由上可得出下列几个论断：
- 可扩展性 — 流量可能呈现爆炸性的增长，IT 零碎须要迅速扩充规模，以解决指数化增长的事务
- 高可用性 — IT 零碎必须每周 7 天、每天 24 小时运行，并且必须具备故障容错性。（美国银行 2011 年产生一次故障，对 2900 万客户造成继续六天的影响）。
- 高性能 —随着可扩展性的一直加强，性能也必须跟上，保持稳定和疾速。据亚马逊估算，在极其状况下，页面加载工夫每减少一秒，该公司每年要损失 16 亿美元。
- 速度 — 设施自带的联网传感器越来越多（远的不说，智能电话就自带联网传感器），每秒可能会有数以百万计的事务须要解决。
- 实时剖析 —夜间进行批处理和业务智能化曾经过期。剖析与操作解决之间的界线变得含糊，对实时决策的需要越来越多。
** 物联网 (Internet of Things) 让速度急剧放慢！
— Stonebraker 博士 (MIT) .**
上述需要催生极为精彩的营销术语 Translytical 数据库，意思是采纳混合解决方案，即同一个解决方案既可解决海量事务，也可实现实时剖析。
03 问题是什么？
在降低成本的同时提供高性能（可能还要应用便宜服务器），是所有数据库厂商都面对的挑战。然而，需要之间互相抵触：
- 性能—最大限度地缩短提早，在毫秒级工夫内实现事务处理。
- 可用性—即便零碎的一个或多个节点产生故障或与网络断开，也能放弃运行的能力。
- 可扩展性—可能一直地扩充规模，以满足海量数据和事务速度的要求。
- 一致性—提供统一、精确的后果 — 特地是在产生网络故障时。
- 耐久性—确保批改一旦施行后不会失落。
- 灵活性—提供通用的数据库解决方案，以撑持事务及剖析方面的工作负荷。
要具备海量渐进扩大能力，惟一事实的方法就是部署横向扩大的分布式系统。通常状况下，为最大地限度进步可用性，对某个节点施行的批改会被立刻复制至两个或更多个其余节点。然而，一旦将数据调配给多个服务 器，则面临利弊衡量。
例如：
**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 博士（斯坦福大学）
04 ACID 与最终一致性
数据库解决方案的扩大方面，次要挑战之一就是维持 ACID 一致性。亚马逊采纳 DynamoDB 数据库，放松一致性束缚，以换取速度，从而解决了性能问题，由此催生了大量 NoSQL 数据库。
另外，最胜利的数据库（包含 Oracle）也无奈提供真正的 ACID 隔离性。本文钻研了 18 个数据库，默认反对 SerializabilITy（可串行性）的数据库只有三个（VoltDB、Ingres 和 Berkeley DB）。次要起因是难以在放弃性能的同时反对可串行性。
最终一致性是特地弱的一种模式。
** 零碎可返回任何数据，仍然能够做到最终统一。
— Peter Bailis 博士（斯坦福）**
另一方面，最终一致性简直不提供一致性保障。下图阐明了最终一致性所存在的问题。一个用户从银行账户上扣款 100 万美元，然而在账户批改失去复制之前，又有一个别的用户查看这个账户的余额。惟一的保障是，只有没有进一步的写入操作，零碎最终会提供统一的后果。这又有什么用途呢？让人承受就更谈不上了。
▲ Cassandra — 最终一致性
05 从新构想 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 个。
06 世上无难事！
Stonebraker 博士的成就令人侧目。此前的 TCP- C 世界纪录为每个 CPU 外围大概 1,000 个事务，但 H -Store 采纳双核 2.8GHz 台式机，速度是原世界纪录的 35 倍。他在 2008 年的文章《细探 OLTP》(OLTP through the Looking Glass)中解释了为什么商业数据库（包含 Oracle）的性能为什么如此差劲。
▲ 关系数据库的解决资源耗费
上图显示，有 93% 的零碎开销是用于传统（历史遗留）的数据库系统，包含锁定、锁存和缓存治理。共计只有 7% 的机器资源是专门用于手头的工作。
H-Store 只是通过打消上述瓶颈，应用基于内存的解决来代替基于磁盘的解决，就得以实现看似不可能的工作，即全面的 ACID 事务一致性，使速度晋升了几个数量级。
07 NewSQL 数据库技术
VoltDB 最早公布于 2010 年，是 H -Store 原型的商业化产品，属于专用的 OLTP 平台，用于 Web 级的事务处理和实时剖析。如这张信息图所示，目前有 250 种商业化数据库解决方案，其中只有 13 种被纳入 NewSQL 技术的行列。
08 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% 的写入。
09 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 类数据库。
如果您对 VoltDB 的工业物联网大数据低提早计划、全生命周期的实时数据平台治理等感兴趣，欢送私信，进入到咱们的官网交换群。
