(okmajdye)
(okmajdye)
(mongodb大神)
(风的孤独)
(KnightLiao)
第三方登录：登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 十二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
如何高效地将SQL数据映射到NoSQL存储系统中
如何高效地将SQL数据映射到NoSQL存储系统中
Sytze Harkema
0&他的粉丝
3&他的粉丝
日. 估计阅读时间:
：开启与Netflix、微软、ThoughtWorks等公司的技术创新之路！
亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的。
相关厂商内容
相关赞助商
在本文中，我将为读者介绍，并解释是怎样将SQL数据映射到后台系统中的。
NoSQL数据库 &&FoundationDB的键-值存储系统
FoundationDB是一个分布式的键-值存储系统，支持全局ACID事务操作，并且性能出众。在安装系统时，可以指定。数据分发为容错性提供了支持：当某个服务器或网络的某部分产生故障时，数据库仍然可以正常操作，你的应用也不会受到影响。
键-值与SQL架构
我们开发的这套架构能够在键-值存储系统上支持多个层，每个层都能够在FoundationDB的基础上提供一套不同的数据模型，例如SQL数据库、文档数据库或图形数据库。许多使用者也自行创建了自定义的层。
下图中列出架构中的了关键部分。处于最底层的是FoundationDB集群，无论集群的实际大小如何，对它的操作与一个单独的逻辑数据库并没有分别。SQL层则以一种无状态的中间层方式运行在键-值存储系统之上。这一层通过SQL与应用程序进行通信，并使用FoundationDB的客户端API与键-值存储系统进行通信。由于SQL层是无状态的，因此可以并行地运行任意数据的SQL层。
SQL层为键-值存储系统带来了如Google的F1般的能力
SQL层是对SQL与键-值存储API进行转换的一套逻辑严密的层。首先，SQL层会从一条SQL语句开始，将其转换为最高效地键-值操作。这种方式类似于编译器将代码转换为低级别的执行格式。并且，这种转换是完全符合ANSI SQL 92标准的。开发者可以将该功能与ORM、REST API进行接合，或者直接使用SQL层的命令行界面进行调用。从代码的角度来说，SQL层与键-值存储是完全分离的，它是通过FoundationDB的Java绑定方式与键-值存储进行通信的。感兴趣的读者可以查看，其代码是完全开源的。眼下唯一能够和这套系统进行比较的是，后者是一套基于该公司的Spanner技术所创建的SQL引擎。
如以下的简单图例所示，SQL层是由一系列组件所组成的。应用程序通过某种受支持的SQL客户端向SQL层发送查询语句，在解析之后转换为一棵计划节点树。优化器（Optimizer）会计算最佳的执行计划，并以一棵操作符树的方式表现出来，随后由执行框架（Execution Framework）运行。在执行阶段，对数据的请求将被发送到存储虚拟（Storage Abstraction）层，这一层通过使用Java的键-值API在数据与FoundationDB集群之间进行传输。数据库模型将存放在Information Schema层中，这一层将被其它多个组件所调用。
将SQL数据映射到键-值存储系统
SQL层需要管理两种类型的数据，首先是信息Schema的元数据，它负责描述所创建的表与可用的索引。其次，它还需要存储实际的数据，包括表内容、索引及序列。我们首先来描述一下这些数据是如何保存在键-值存储系统中的。
本质上讲，每个键都是对应了某张表中的特定行的指针，而值则包含了该行的数据。键的分配是由Table-Group所决定的，它是包含了一个或多个表的组。稍后会对这个概念的细节进行更深入的讲解。SQL层会通过使用键-值存储目录层为每个Table-Group创建一个目录，存储目录层是为用户管理键空间的一个工具，它为每个独立的目录分配一个简短的字节数组，作为该目录的唯一键。同时，它也维护着其它元数据，以实现通过名称进行查找的功能。
下面这个例子演示了如何创建目录的映射，通过以下语句分配键。
CREATE TABLE schema_a.table1(id INT PRIMARY KEY, c CHAR(10));
CREATE TABLE schema_a.table2(id INT PRIMARY KEY);
在键-值存储系统中有一些预定义的目录：
sql/data/table/
sql/data/table/schema_a/table1/
sql/data/table/schema_a/table2/
在存储数据时，可以选择使用以下三种格式中的一种：&元组（Tuple）&、&原始数据（Row_Data）&或者是&Protobuf&。如果使用默认的Tuple存储格式，那么每一行内容都将保存为一个单独的键-值对，键是通过连接以下字符串所生成的元组：目录前缀、该表在Table-Group中的位置，以及主键。而值的内容则是由该行中的所有列所组成的一个元组。
举例来说，以下代码对之前创建的表进行操作，产生对应的键与值。
INSERT INTO schema_a.table1 VALUES (1, 'hello'), (2, 'world');
INSERT INTO schema_a.table2 VALUES (5);
Tuple Value
\x15\xD7\x15\x01\x15\x01
(215, 1, 1)
\x15\x01\x02hello\x00
(1, 'hello')
\x15\xD7\x15\x01\x15\x02
(215, 1, 2)
\x15\x02\x02world\x00
(2, 'world')
\x15\xF7\x15\x01\x15\x05
(247, 1, 5)
了解了键-值存储系统中键的结构之后，你就能够从存储系统中直接读取数据了。我们将使用FoundationDB的Python API来演示这一功能。在SQL层中，键与值是通过&.pack()&方法进行编码，并通过&.unpack()&方法进行解码的。下面的示例为你演示如何获取并解码数据。
import fdb& fdb.api_version(200)
db = fdb.open()
directory = fdb.directory.open(db,('sql','data','table','schema_a','table1'))
for key, value in db[directory.range()]:&&&&&&&& print fdb.tuple.unpack(key), ' --& ', fdb.tuple.unpack(value)
以上代码会输出类似下面的结果：
(215, 1, 1) --& (1, u'hello')
(215, 1, 2) --& (2, u'world')
现在让我们再来近距离观察一下Table-Group。每个独立的表都属于一个单独的组，如果某张额外的表能够创建一个对第一张表的&组外键&引用，那么它也能够加入到同一个组中。当我们为某张表创建组外键时，字表将与父表所在的目录进行交互。字表将成为Table-Group的一部分，在源表之后进行命名。这两张表的数据在将同一个目录中进行交互，这保证了范围扫描的高速，并且在Table-Group之内访问对象及表连接的开销极小。为了演示这一特性，我们将继续之前的示例，这一次的SQL语句如下：
CREATE TABLE schema_a.table3(id INT PRIMARY KEY, id_1 INT, GROUPING FOREIGN KEY (id_1) REFERENCES schema_a.table1(id));
INSERT INTO schema_a.table3 VALUES (100, 2), (200, 2), (300, 1);
该语句将返回以下结果：
directory = fdb.directory.open(db,('sql','data','table','schema_a','table1'))
for key, value in db[directory.range()]:&&&& print fdb.tuple.unpack(key), ' --& ', fdb.tuple.unpack(value)
(215, 1, 1)&&&&&&&&& --&& (1, u'hello')
(215, 1, 1, 2, 300)& --&& (300, 1)
(215, 1, 2)&&&&&&&&& --&& (2, u'world')
(215, 1, 2, 2, 100)& --&& (100, 2)
(215, 1, 2, 2, 200)& --&& (200, 2)
由于第三张表的键都处于第一张表中各行的命名空间范围内，因此第三张表中所有插入的行都能够与第一张表的行相关联。键中的两个额外的值分别对应了Table-Group中的位置以及第三张表中的主键。对表1与表3通过引用键进行连接也无需通过标准的连接操作实现，直接通过线性扫描就语句了。这种排序方式比起传统的关系型数据库系统有着极大的优势。
由于键都已经经过排序，因此索引可以直接利用这一点所带来的便利性。所有的表索引只包含一个键值，其中包括两部分内容。每个索引都创建于该表所属的目录之下，一个名为index的子目录中，这是该键元组的第一部分内容。第二个部分是一个组合，首先是该索引所对应的各个列的值，之后则是指定这一行所必须的列的值。
举例来说，我们可以为这张表的c列创建一个索引。
CREATE INDEX index_on_c ON schema_a.table1(c) STORAGE_FORMAT
接下来使用Python读取这个索引的内容，我们需要在Python解释器中加入以下内容：
directory = fdb.directory.open(db, ('sql', 'data', 'table', 'schema_a', 'table1', 'index_on_c'))
for key, value in db[directory.range()]:&&&& print fdb.tuple.unpack(key), ' --& ', fdb.tuple.unpack(value)
这段代码会输入类似于下图中的内容，显示了键的两个组成部分：即该索引所在的目录的字节值，以及创建索引的c列的值加上主键的值。最后一个部分将被索引的值链接到某个特定的行，而该索引键所对应的值为空。
(20127, u'hello', 1) --& ()
(20127, u'world', 2) --& ()
如果要对SQL层的行为进行更多的控制调整，可以使用以下三种存储格式：一是之前描述过的元组格式，一是列键格式，以及protobuf格式。列健格式会为某一行的每个列值创建一个独立的键-值对。而protobuf存储格式为会每一行创建一个protobuf消息。
接下来还需要对元数据进行存储与组织。SQL层使用protobuf消息与基于SQL的数据的结构进行通信。这个结构是由schema、组、表、列、索引与外键等对象共同组成的。
SQL与NoSQL的混合模式
如果在应用程序级别使用只读的键-值API，那么SQL层就能够在客户端进行直接访问。可以通过键-值API直接访问数据，但如果增加或改写了SQL层所用的关键数据，那就很可能破坏系统的运行。这里例举一些可能会产生的问题：缺乏对索引的维护、缺乏应有的限定，以及忽略了对数据及元数据的版本维护。而这种方式的好处，哪怕是在进行数据读取时也并不明显，因为SQL层本身的额外开销就非常小。因此总的来说，性能的开销主要取决于网络延迟。
SQL与NoSQL的结合使用能够相互利用两者的优点。FoundationDB的键-值存储系统为SQL层带来的好处包括可伸缩性、容错性及全局ACID的事务属性。你的应用程序同样也能从中受益，因此赶紧尝试一下吧！对应那些要执行大量的小批数据读取及写入的应用程序来说，FoundationDB提供了一个高伸缩并且安全的解决方案，并且可以任意使用SQL或NoSQL。
Sytze Harkema从2014年3月起担任的软件工程师，他专注于SQL层的开发，致力于使其成为高伸缩SQL应用的最佳解决方案。Sytzey曾经就读于荷兰的Delft科技大学及美国的哈佛大学。
查看英文原文：
Author Contacted
语言 & 开发
192 他的粉丝
架构 & 设计
517 他的粉丝
0 他的粉丝
35 他的粉丝
0 他的粉丝
关系型数据库
0 他的粉丝
21 他的粉丝
0 他的粉丝
10 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
InfoQ.com及所有内容，版权所有 ©
C4Media Inc. InfoQ.com 服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。SQL与NoSQL（MongoDB）数据库的对应关系图表-MongoDB-@大数据资讯
你好，游客
SQL与NoSQL（MongoDB）数据库的对应关系图表
来源：程序师&
关系数据库有一套标准的SQL语句来操作数据库，MongoDB是NoSQL文档型数据库，概念与操作方式与SQL都不相同，下面的几张表全面的表达了SQL与MongoDB的对应关系，便于快速熟悉MongoDB的操作思路
概念名称的对应
SQL语句 与 NoSQL MongoDB操作 对比
假设SQL数据库中有一个 users表，MongoDB中有一个 users 集合，包含了 user 文档，例如
_id: ObjectId("509a8fb2f3fa0"),
user_id: "abc123",
status: 'A'
Create/Alter 创建和修改表
Insert 插入数据
Select 查询数据
EXPLAIN 语句分析
Update 更新数据
Delete 删除数据
相关新闻 & & &
& (01月03日)
& (12/21/:50)
& (01月17日)
& (12/21/:57)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款有SQL数据库为什么还要有NoSQL？
　作者: 景保玉　编辑:
　　【IT168资讯】我们都知道，SQl在数据库方面非常有用，而且至今已经用了几十年，为何有了NoSQl?我们经常会处理大量的文档，其中文档的图表都是要查找的信息，彼此之间需要互相连接，SQL的复杂度会很高，因此就有了NoSQL。▲　　为什么用NOSQL?　　SQl在做有些任务的时候非常容易，比如一些文档，可以运行很多数据，这时SQl非常有用，会非常的快，如果命令行太长如何能够使他快速呢?这时会用到分布式的数据库，是否可以用Joins代替数据库呢?　　举个例子，在分布式系统中使用Java软件。如果需要在北京和伦敦之间传输1G数据，需要多少时间呢?一般来说需要12秒。如果用Java的系统会有问题。　　非常复杂的数据用关系型数据库是无法解决的　　如何在非常大的数据库中解决数据的存储等问题呢?我们会使用NoSQL，有些架构是需要SQL架构的。举一个数据量非常大的例子，银行业不管是在北京还是在上海，如果用某种价格买卖产品，每秒钟有5-10万，数据量非常大。还有一些更加复杂的情况，比如股票中的上万种投资组合，都需要有摸一个价格报出，需要有上百万的数据报出，复杂的计算规模相当的大，这些采用的都是毫秒计算，价格变化之后，全世界所有的银行都要进行相关的处理买卖。　　伦敦的一家银行的功能组合，非常的大，非常的复杂，这些功能组要发挥很重要的作用，从价格到风险计算，然后到清算等等，每笔交易都有10万个数据计算。所有的银行数据都要进行连接，而且非常复杂，在做交易和处理的时候，每秒有数十万的交易计算，因此这就需要新技术的推进。　　在西方有些人愿意面对风险，有些人不愿意接受失败，用户把钱交给银行，一旦出了错误，就需要进行相应的赔付，因此需要了解风险，并采用技术进行解决，用虚拟机把交易挪出来，进而降低风险带来的损失。　　随着银行业务规模的增加，计算机越来越多，处理能力越来越强，多数的机器使用的是，8-12个核心，但是我们现在不是把电脑变得越来越大，而是需要通过编程进行调整，因此面对这些庞大的数据我们要做分布式的模型。在本地完成的话通常无法扩大规模，如果我们通过编程的话，可以再任何地方的任何机器都能使用服务，不管位置在哪里。我们不能假设所以的数据和处理都在自己本地的RAM上，可能有1T byte的数据需要分步在很多机器上，这就要采用改变编程模式的方式。如果是用的小型，而且还要扩大规模的话，就需要采用分布式的架构来做。　　关于网格计算现在采用的是，对于银行来说可能会有2万的电脑，然后用一个机器进行管理，将本地的电脑进行连接，做成一个私有云，然后通过编程的方式实现。当然我们还可以建立公共云，issue非常易用，也非常的便宜，你的编程和测试都非常的方便。　　Terracotta 做虚拟机的复制非常好，有开源的版本。其他的相关技术：Gigaspaces，Coherence　　New4J。银行业用的最多的是MongoDB，当然还有很多其他优秀的技术，比如：HBase，Risk。　　现在6-10家银行其中的某一家都采用了这些数据库的技术，他们的人员投入很大的人力研究这些技术。数据库技术的每一个操作都有可能导致结果的不同，这些技术都有各自的优势，都有自己发挥的领域。　　NoSQl是一个每天都要使用到的技术，处理的速度非常的快，每秒几十亿的信息，可以用Java进行编程，对于企业来说非常容易使用，大企业处理的数据量非常大，社交网站和银行业也同样，因此NoSQL在这些领域都有很大的使用空间。
IT168企业级为什么说SQL正在击败NoSQL，这对数据的未来意味着什么？
作者｜Ajay Kulkarni
翻译｜谢然
冬去春又回，新一轮的数据库开发风潮展现出了向 SQL 回归的趋势，为什么要回归？对数据社区有什么影响？
随着计算机的日益普及，各种应用每天产生的数据量呈指数级增长。如何存储这些数据，有效处理分析这些数据, 并从中提取有价值的信息, 是当下迫切需要解决的问题。在过去的十年里，NoSQL 在软件工程师阵营里越来越受欢迎，其中最重要的实现是 MapReduce，Bigtable，Cassandra，MongoDB, 等产品。 它主要用于解决 SQL 的可扩展性问题。
然而今天 SQL 开始回归。几乎所有的云计算服务提供商都在提供备受青睐的关系型数据库管理服务：例如 Amazon RDS，Google Cloud SQL，Azure 的 PostgreSQL 数据库（ Azure 今年推出）。在亚马逊看来，其 PostgreSQL 和 MySQL 兼容的数据库产品 Aurora 一直是 AWS 历史上增长最快的服务。Hadoop 和 Spark 之上的 SQL 接口继续迅猛发展。就在上个月，Kafka 推出了 SQL 支持。
在这篇文章中，我们将研究 SQL 备受青睐的原因以及这对未来的数据社区工程和分析意味着什么。
第一部分：新希望的崛起
想要了解 SQL 为什么回归，让我们先了解他最初的设计初衷。
故事始于 20 世纪 70 年代初的 IBM 研究院，其中关系型数据库诞生了。那时候，查询语言依赖于复杂的数学逻辑和符号。Donald Chamberlin 和 Raymond Boyce 两位博士对关系型数据模型造诣颇深，看到查询语言将成为其主要瓶颈。他们开始设计一种新的查询语言（以他们自己的话来说）：“ 用户使用更容易，不需要再参加数学或计算机程序设计方面的正规培训 ”。
回想在互联网之前，在 PC 出现以前，当程序设计语言 C 首次被引入世界时，两名年轻的计算机科学家意识到，“计算机行业的成功很大程度上依赖于培养一种除了训练有素的计算机专家以外的用户。“他们渴望一种与英文一样容易阅读的查询语言，包括数据库管理和操作。
结果是 SQL 在 1974 年首次被引入世界，成了关系型数据库的最主要语言。在接下来的几十年里，SQL 被证明也是很受欢迎的。作为关系型数据库，如 System R，Ingres，DB2，Oracle，SQL Server，PostgreSQL，MySQL（等等）在软件行业里的发展壮大，SQL 也成为了与数据库进行交互的首选语言，成为了一个日益拥挤、竞争激烈的生态系统的通用语言。。
（不幸的是，Raymond Boyce 从来没有机会见证 SQL 的成功，他只做了一个早期的 SQL 演讲，1 个月后他便死于脑动脉瘤，当时他只有 26 岁，留下了一个妻子和一个年轻的女儿。）
有一段时间，似乎 SQL 已经成功地履行了它的使命。接着互联网出现了。
第二部分：NoSQL 反击
虽然 Chamberlin 和 Boyce 正在开发 SQL，但他们没有意识到的是，加利福尼亚州的 另一批工程师正在开展另一个新兴项目，该项目逐渐成熟后，明显威胁到 SQL 的存在。该项目就是 ARPANET，诞生于 1969 年 10 月 29 日。
但是此前 SQL 发展一直很好，直到 1989 年，另一位工程师的出现并发明了万维网。
互联网和 Web 的蓬勃发展正在改变着我们的世界，但是对于数据社区来说，也是很让人头痛的：数据以大的量级和更快的速度爆炸式增长。
随着互联网的不断发展和壮大，软件社区发现当时的关系数据库无法应对新的负载压力，就好像一百万个数据库突然过载让人抓狂一般。
然后两家新的互联网巨头取得突破，并开发了自己的非关系型分布式系统来应对这种新的数据冲击：Google 的 MapReduce（2004 年发布）和 Bigtable（2006 年发布）以及亚马逊的 Dynamo（2007 年发布）。这些开创性论文导致出现了更多的非关系型数据库，包括 Hadoop（基于 MapReduce 论文，2006），Cassandra（Bigtable 和 Dynamo 的深度解析，2008 ）和 MongoDB（2009））。因为这些都是从零开始大量编写的新系统，避开了 SQL，导致了 NoSQL 运动的兴起。
开发者社区的软件工程师们逐渐地也接受了 NoSQL，相较于 SQL 当时的出现，被越来越多的工程师所接受。这个原因非常容易理解：NoSQL 是现在流行的；它承诺了规模和权力；这似乎是项目通往成功的捷径。但后来问题出现了。
开发人员很快发现，不用 SQL 的局限性。每个 NoSQL 数据库都提供了自己独特的查询语言，这意味着：要学习更多的语言（并向同事教授）; 将这些数据库连接到应用程序的难度增加，导致大量胶水代码的出现（代码之间有很强的耦合性）; 缺乏第三方生态系统，要求企业必须开发自己的操作和可视化工具。
这些 NoSQL 语言是新的，也没有完全开发。例如，关系型数据库已经运行很多年了，为 SQL 添加必要的功能（例如 JOIN）也早都已经完成了，NoSQL 语言的不成熟意味着在应用程序级别就会有更多的复杂性。缺乏 JOIN 也导致了非规范化，导致数据膨胀和僵化。
一些 NoSQL 数据库添加了自己的“类 SQL”的查询语言，如 Cassandra 的 CQL。但这往往使问题更糟。使用几乎相同的界面，却让内心更纠结：工程师不知道什么是支持的，什么不是。
社区中的一些人在早期就看到了 NoSQL 的问题（例如，DeWitt 和 Stonebraker 在 2008 年就看到了）。经过时间的实战检验，以及使用过程中的经验积累，越来越多的软件开发人员也看到了这一点。
第三部分：SQL 回归
经历了黎明前的黑暗，软件社区看到了曙光，那就是回归 SQL。
首先是 Hadoop（之后的 Spark）之上的 SQL 接口，引导业界兴起了 NoSQL , NoSQL “不仅仅是 SQL ”。
然后，NewSQL 的兴起：新的可扩展性数据库，完全支持 SQL。来自于麻省理工学院 ( MIT ) 和布朗大学 ( Brown ) 研究人员的 H-Store （2008 年发布）是第一个可扩展 OLTP 数据库之一。Google 在发布的第一份 Spanner 论文（2012 年发布）（其作者包括最初的 MapReduce 作者）中揭示这是基于 SQL 的查询语言，可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性，从而开创了可地理复制的 SQL 界面的数据库，接着是 CockroachDB（2014）这样的先驱者。
与此同时，PostgreSQL 社区开始复苏，增加了 JSON 数据类型（2012），以及 PostgreSQL 10 的新特性：对分区和复制更好的本地支持，JSON 的全文搜索支持等（今年晚些时候发布）。其他像 CitusDB（2016）和其他的公司 (今年发布的 TimescaleDB ) 发现了新的方法从而针对特定数据工作负载的扩展 PostgreSQL。
事实上，我们开发 TimescaleDB 的过程与业界的发展轨迹密切相关。早期的 TimescaleDB 内部版本使用了我们自己的类 sql 查询语言“ ioQL ”。是的，我们正是被困难驱动着：构建我们自己的查询语言才能更强大。但是，虽然看似简单，但我们很快意识到，我们必须做更多的工作：例如，决定语法，构建各种连接器，培训用户等。我们还发现自己需要不断地去查找合适的语法，去查询那些已经可以用 SQL 进行查询的内容。
有一天，我们意识到建立自己的查询语言是没有意义的。关键还是要拥抱 SQL。这是我们做出的最好的决策之一。同时也开启了一个全新的世界。今天，即使我们的数据库才问世 5 个月，但我们的用户完全可以使用我们的产品，并获得各种各样支持：可视化工具（ Tableau ），通用 ORM 连接器，各种工具和备份选项，大量的在线教程和语法说明等。
不要把我们的话放在心上，看看谷歌
Google 已经十多年来一直处于数据工程和基础设施的领先地位。我们应该密切关注他们正在做什么。
看看谷歌的第二大 Spanner 论文，仅在四个月前发布（Spanner：成为一个 SQL 系统，2017 年 5 月），你会发现它支持我们的发现成果。
例如，Google 开始在 Bigtable 之上开发，但是后来发现缺少 SQL 产生了一系列问题（在下面的所有引号中有强调）：
“虽然这些系统提供了数据库系统的一些优势，但它们缺乏应用程序开发人员常常依赖的许多传统数据库功能。一个关键的例子是强大的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合应用程序中的数据。因此，我们决定将 Spanner 变成一个功能齐全的 SQL 系统，其查询执行与 Spanner 的其他架构功能（如强一致性和全局复制）紧密集成。
在本文的后面，他们进一步了解从 NoSQL 转换到 SQL 的理由：Spanner 的原始 API 提供了为单个和交叉表的点查找和范围扫描的 NoSQL 方法。虽然 NoSQL 方法提供了启动 Spanner 的简单路径，并且在简单的检索方案中继续有用， 但 SQL 在表达更复杂的数据访问模式并将计算推送到数据方面提供了重要的附加价值。
本文还介绍了如何在 Spanner 上使用 SQL 并不会停止，哪怕某一个数据中心停止运转, 仍然可用。但实际上扩展到 Google 的其余部分，其中多个系统共享一个通用的 SQL 语言：
Spanner 的 SQL 引擎与 Google 的其他几个系统共享一个称为“标准 SQL ”的常见 SQL 语言，包括内部系统，如 F1 和 Dremel（以及其他）以及外部系统，如 BigQuery 。
对于 Google 用户，这会降低跨系统的工作障碍。对 Spanner 数据库编写 SQL 的开发人员或数据分析师可以将他们对语言的理解转移到 Dremel，而不用担心语法，NULL 处理等方面的微妙差异。
这就是这种方法的成功奥秘。当“潜在云客户对 SQL 有浓厚兴趣”时，Spanner 已经成为 Google 主要系统的根基（包括 AdWords 和 Google Play ） 。
考虑到 Google 最先启动了 NoSQL 的运动，这是非常显著的，它今天正在回归 SQL。（引起一些人反思：“ Google 10 年前挺进大数据市场就是个大忽悠吗”？）
这对数据的未来意味着什么：SQL 将变成窄腰
在计算机网络中，有一个叫做“窄腰”的概念。
这个概念的出现解决了一个关键问题：在任何给定的网络设备上，想象一个堆栈，底层硬件层和顶层软件层。中间可能会存在各种网络硬件 ; 类似地，也存在各种软件和应用程序。需要一种方法来确保无论硬件如何，软件仍然可以连接到网络 ; 无论软件如何，网络硬件都知道如何处理网络请求。
在网络中，窄腰的角色由互联网协议 ( IP ) 扮演，它是为局域网设计的底层联网协议和更高级别的应用程序和传输协议的公共接口。(这是一个很好的解释。) 而且（在一个广泛的过度简化）中，这个公共接口成为了计算机的通用语言，使网络互连，设备进行通信，而这个“网络网络”可以发展成为今天丰富多样的互联网。
我们认为，这等同于 SQL 已成为数据分析的“窄腰。
我们生活在一个数据正在成为“世界上最宝贵资源”的时代（”“经济学人”，2017 年 5 月）。我们看到了 Cambrian 的专业数据库（ OLAP，时间序列，文档，图表等），数据处理工具（ Hadoop，Spark，Flink ），数据总线（ Kafka，RabbitMQ ）等的红海。还有更多的应用程序需要依赖这种数据基础设施，无论是第三方数据可视化工具（ Tableau，Grafana，PowerBI，Superset ），Web 框架（ Rails，Django ）还是定制的数据驱动应用程序。
像网络一样，我们有一个复杂的堆栈，底层的基础设施和顶部的应用程序。通常，我们最终编写了大量的胶水代码，使此堆栈工作。但是胶水代码可能很脆弱：需要维护和贴合。
我们需要的是一个公共接口，允许这个堆栈的各个部分相互通信。这个行业已经标准化了。它能让不同层级之间的通信阻碍降到最小。
这就是 SQL 的力量。和 IP 一样，SQL 也是一个公共接口。
但事实上，SQL 比 IP 复杂的多。因为数据还需要被人类分析。而且 SQL 创建者最初给它设定的目标就是可读性要高。
SQL 完美吗？不，但这是社区中的大多数人都已经了解的语言。虽然已经有工程师在开发更和谐的语言界面，但这些系统最终会连接到哪里? 还是 SQL 。
所以在堆栈的顶部还有一层。那一层就是我们。
SQL 已经回来了。不仅仅是因为使用 NoSQL 工具编写胶水代码是恼人的。不仅仅是因为培训大家学习无数新的语言成本是巨大的，不只是因为统一标准的重要性。
而且也因为世界充满了数据。它围绕着我们，束缚着我们。首先，我们依靠我们的人类感官和感觉神经系统来处理它。现在我们的软件和硬件系统也越来越智能，可以帮助我们。随着我们收集的数据越来越多，可以更好的让我们了解这个世界，系统的复杂性，存储，处理，分析和可视化的需求只会继续增长。
我们生活在一个脆弱的世界和一百万个不同界面的世界。或许我们可以继续拥抱 SQL 。一切都将遵循能量守恒定律。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点}