英文原文：SQL Makes a Comeback through NewSQL
新一轮的数据库开发风潮展现出了向 SQL 回归的趋势，只不过这种趋势并非是在更大、更好的硬件上（甚至不是在分片的架构上）运行传统的关系型存储，而是通过 NewSQL 解决方案来实现。
在市场被 NoSQL（一开始叫做“No more SQL”，后来改为“Not only SQL”）逐步蚕食后，近一段时间以来传统的 SQL 开始回归。其中广为传颂的一个解决方案就是分片，不过对于某些情况来说这还远远不够。因此，人们推出了新的方式，有些方式结合了 SQL 与 NoSQL 这两种技术，还有些方式是通过改进关系型存储的性能与可伸缩性来实现，人们将这些方式称作 NewSQL。Google（NoSQL 最初的支持者之一）构建了 F1，这是一个分布式的关系型数据库，将 BigTable 的高可用性与可伸缩性与 SQL 的“一致性和可用性”结合起来。Google 在白皮书 F1: A Distributed SQL Database That Scales（PDF）中是这样介绍 F1 的：
这是由 Google 构建的一个容错、分布式的 OLTP 与 OLAP 数据库，作为新的存储系统用在 Google 的 AdWords 系统上。设计它的目标旨在替换掉分片的 MySQL 实现，因为后者已经无法满足日益增长的可伸缩性与可靠性的需求了。
MemSQL 就是众多的 NewSQL 解决方案中的一个，这是个完全的内存解决方案，用于对结构化与半结构化（JSON）数据进行实时分析。它并没有使用列式存储，而是使用了“无锁的 skip 列表与无锁的 hash tables”以实现更快的数据访问，并且对非分片架构使用了并行处理，不会出现单点失败的情况。
另一个 NewSQL 解决方案是 ClustrixDB，这是个点对点的非分片的分布式数据库，用于事务处理与实时分析。根据 Clustrix CEO Robin Purohit 所述，他们的数据库在 Twoo.com 每天能够处理 4.4B 个事务，21 个节点（每个节点的配置是 8 核，48GB 内存）的平均延迟为 5 到 10 毫秒，其构建方式是这样的：
从头开始构建的点对点分布式 SQL 数据库，没有单独的协调者（因此就不会出现单个的失败点）。ClustrixDB 使用了分布式事务，事务使用了 Paxos 的一致性协议。ClustrixDB 针对写使用了 2 阶段锁，还使用了分布式的多版本并发控制，用于确保读与写不会互相干扰。这可以保证分布式环境下单个节点数据库严格的 ACID 属性。ClustrixDB 并没有使用分片架构，这种方式也是唯一一种可以实现线性伸缩的架构。ClustrixDB 将原来只有cangku.html" target="_blank">数据仓库中才拥有的用于实时分析的 Massively Parallel Processing （MPP）带到了主流数据库上。
我们也向 Twoo.com 的 CEO Toon Coppens 提出了这样一个问题：为何最初的 MySQL 分片解决方案无法满足他们的要求，转而去选择一个 NewSQL 呢：
我们花了一些时间了解 Netlog.com 的架构，他们拥有成百个 MySQL 分片，重新平衡与管理这些分片的代价是非常高昂的，更不必说即时修改查询或是在所有分片上创建新查询时的不灵活性了，这种方式并不可取。我们希望一个查询就能将数据查出来。虽然 NoSQL 提供了不错的可伸缩性，但我们并不想将自己绑定在底层的数据表示上。我们希望在修改产品与特性需求时拥有完全的灵活性，同时又不必修改每天都在变化的网站的数据层（clustrix 提供了快速的变化，同时又能在高负载下运行良好，当然了，它还有其他很多优秀的特性）。
虽然 NoSQL 因其性能、可伸缩性与可用性而广受赞誉，但其开发与数据重构的工作量要大于 SQL 存储。因此，有些人开始转向了 NewSQL，它将 NoSQL 的优势与 SQL 的能力结合了起来。最为重要的是使用能够满足需要的解决方案。
相关文章
