数据库40年发展史：NoSQL和NewSQL谁将登上“铁王座”？
起初有文件，后来有基于结构化文件的导航数据库，然后出现了ims和codasyl。大概40年前，出现了首批关系数据库。在20世纪八、九十年代的大部分时间，“数据库”严格意义上指“关系数据库”——sql（标准查询语言）占主导地位。
后来随着面向对象编程语言日益流行，一些人认为，解决面向对象语言和关系数据库“阻抗不匹配”的办法是在数据库中映射对象。因此，我们最后迎来了“面向对象的数据库”。对象数据库方面有意思的地方是，在许多情况下，它们基本上是内置对象映射器的普通数据库。这种数据库后来渐渐失宠，下一个真正的主流尝试是2010年代的“nosql”。
1. 攻击sql
nosql以同样的方式攻击关系数据库和sql。这回的主要问题是，互联网颠覆了具有40年历史关系数据库管理系统（rdbms）架构的基本前提。这种数据库旨在节省宝贵的磁盘空间，并可纵向扩展。然而现在有太多的用户和太多的任务，一台胖服务器处理不了。nosql数据库则宣称，如果数据库没有连接（join），没有标准查询语言（因为实现sql需要花费时间），也没有数据完整性，那么就可以横向扩展以处理众多用户。这解决了纵向扩展的问题，但也带来了新问题。
与这些联机交易处理系统（oltp）并行开发的是另一种关系数据库，名为联机分析处理系统（olap）。这种数据库支持关系结构，但在执行查询时就知道它们将返回大量数据。上世纪八、九十年代的公司企业仍主要由批处理驱动。此外，olap系统为开发和分析人员提供了将数据想象成n维数据集并加以存储的能力。如果你设想二维数组和基于两个索引的查询，以便基本上与恒定时间一样高效，但是随后在此基础上添加另一个维度，以便可以执行实质上是3个或更多因素（比如供应、需求和竞争对手数量）的查询，你就可以更高效地分析和预测。然而，构建这些元素是一项费力又高度面向批处理的工作。
图形数据库几乎与横向扩展型nosql同一时间面市。许多事物本身不是“关系型”，或者不是基于集合论和关系代数，而是基于父子关系或朋友的朋友关系。一个典例是模型中的产品系列-产品品牌-款型-部件。如果你想知道“我的笔记本电脑搭载什么主板？”，会发现制造商的采购来源很复杂，光有品牌或型号可能不够。如果你想知道某产品系列中使用的所有主板，在经典（非cte即通用表表达式）sql中，你必须遍历表，并且分多个步骤进行查询。最初，大多数图形数据库根本就不分片。实际上，无需将数据实际存储为图形，就能完成许多类型的图形分析。
2. 兑现和未兑现的nosql承诺
nosql数据库的扩展性确实比oracle数据库、db2或sql server（它们都基于40年前的一种设计）好得多。然而，每种nosql数据库都存在新的限制：
（1） 键值存储 ·
没有比db.get（键）更简单的查询了。然而，世界上许多数据和使用场景无法以这种方式来设计结构。此外，我们其实在谈论缓存策略。在任何数据库中，主键查询速度很快。重要的只是内存中的数据。在理想情况下，它们像哈希图一样扩展。然而，如果要跑30趟数据库才能将数据放回去或进行任何类型的复杂查询，这行不通。这些系统现在更常作为缓存实施在其他数据库的前面。（例子：redis。）
（2） 文档数据库 ·
这种数据库之所以流行起来，是由于它们使用json，对象又易于序列化成json。这种数据库的第一个版本没有连接，将整个“实体”放到一个庞大的文档中有其自身的缺点。没有事务保证，你还会遇到数据完整性问题。今天，一些文档数据库支持一种不太可靠的事务，但它不是大多数人习惯的同一种保护级别。而且，即使对简单查询而言，这种数据库在延迟方面常常速度很慢，尽管它们就吞吐量而言扩展性更好。（例子：mongodb和amazon documentdb。）
（3） 列存储 ·
这种数据库的查询速度与键值存储一样快，它们可以存储更复杂的数据结构。然而，如果执行像跨3个表（rdbms术语）或3个集合（mongodb术语）连接这样的操作，会让人痛苦不堪。这种数据库确实适合时间序列数据（请给我在下午1点至2点出现的所有事务）。
还有其他更深奥的nosql数据库。然而，所有这些数据库的共同点是不支持通用数据库惯用语，而且往往专注于“特殊用途”。一些流行的nosql数据库（比如mongodb）编写了出色的数据库前端和生态系统工具，因而开发人员很容易采用它们，但存储引擎存在严重的限制，更不用说弹性和可扩展性方面的限制了。
3. 数据库标准仍然很重要
关系数据库占主导地位的原因之一是，它们有一个通用的工具生态系统。首先有sql。虽然数据库方言可能不一样——如果你是开发或分析人员，想从sql server 6.5升级到oracle 7，可能不得不修复查询，并使用“（+）”用于外部连接，但是简单的切实可行，复杂的很容易转换。
其次，你有odbc以及后来的jdbc等。几乎任何可以连接到一个rdbms的工具（除非为了管理该rdbms而专门设计）都可以连接到其他任何rdbms。有许多人每天连接到rdbms，并将数据倒入到excel以便分析。我不是指tableau或其他数百种工具，而是指“鼻祖”excel。
nosql摈弃了标准。mongodb不使用sql作为主要语言。mongodb的劲敌couchbase寻找一种查询语言来取代基于java的mapreduce框架时，更是创建了一套自己的sql方言。
标准很重要，无论是为了支持工具生态系统，还是由于许多查询数据库的人不是开发人员——他们都知道sql。
4. graphql和状态管理的兴起
你知道谁总是翘着两个大拇指想搭车，就想让他的应用进入到数据库里，但却不关心如何实现吗？事实证明，整整一代的开发人员都想这么做。而graphql（与图形数据库无关）可将对象图形存储在底层数据存储系统中。这样一来，开发人员就不必担心这个问题了。
这方面的早期尝试是对象关系映射（orm）工具，比如hibernate。它们拿来一个对象后，基于对象到表的映射设置，基本上将对象变成了sql。这种工具的许多前几代产品很难配置。此外，我们面临学习过程。
大多数graphql实现方法与sequelize或typeorm之类的对象关系映射工具兼容。结构良好的graphql实现方法和api不会在你的全部代码中泄露状态管理问题，而是在对象图形发生变化时写入并返回相关数据。谁会在应用层面真正关心数据是如何存储的？
面向对象数据库和nosql数据库的基础之一是，应用开发人员要意识到数据在数据库中如何存储方面的复杂情况。当然，这对于开发人员来说很难用较新颖的技术来驾驭，但现在不再困难了，因为graphql完全消除了这个问题
5. newsql或分布式sql闪亮登场
谷歌遇到了数据库问题，写了一篇论文，然后编写了一种名为“spanner”的实现方法，描述了全局分布式关系数据库如何行得通。spanner引发关系数据库技术领域迎来了新一波创新。你实际上可以有一个关系数据库，不仅让它能扩展，还能在需要时进行全球范围扩展。我们所谈论的是现代意义上的大规模，而不是经常令人失望且日趋复杂的rac/streams/goldengate方法。
所以，关系系统中“存储对象”的前提是错误的。如果关系数据库的主要问题是后端而不是前端，将会怎么样？这就是所谓的“newsql”或名称更恰当的“分布式sql”数据库背后的想法。其想法就是将nosql存储知识和谷歌的spanner概念与一种成熟的开源rdbms前端（比如postgresql或mysql/mariadb）结合起来。
这意味着什么？这意味着鱼和熊掌可以兼得。这意味着你可以有多个节点，并横向扩展——包括跨云可用区扩展。这意味着你可以有多个数据中心或云地理区域——仅用一个数据库。这意味着作为用户，你可以拥有真正的可靠性和永远不会崩溃的数据库集群。
与此同时，整个sql生态系统仍有用！你无需重新构建整个it基础架构就能做到这点。虽然你可能不敢“丢弃并更换”传统的rdbms，但大多数企业并不打算使用更多的oracle。最棒的是，你仍可以使用在云端和全球各地的sql及所有工具。
责编ajx
光幕光栅是什么，如何使用及注意事项
618蓝牙耳机便宜吗？学生党高性价比TWS真无线蓝牙耳机推荐！
生物传感器的分类有哪些
中国北斗芯片已实现规模化应用，工艺已由0.35微米提升至28纳米，最低单片价格不到人民币6元
详解TD-SCDMA建设情况
数据库40年发展史：NoSQL和NewSQL谁将登上“铁王座”？
舞厅用音乐同步声控开关电路
HMC624A是一款6位数字衰减器
LT3587单芯片的小型高效解决方案
变频器安装现场应满足哪些条件
3D打印技术将为机器人增添新材料 改变机器人技术
曝华为将与印度Indus OS合作 将加强在印度市场的影响力
微软将眼球追踪技应用于AR设备中
英国脱欧后将暂停8.1万个.eu域名
谷歌推Android 11正式版，将带来什么变化？
电子行业需求增加 工业机器人每年以平均14%的速度增长发展
什么是伽玛(γ)匹配
人工智能名片+在线教育，开启智能营销新模式
冰箱过滤器工作原理、作用、结构特点、发凉、发热
大疆否认“将退出中国市场”传言：大疆无人机没有退出计划
后来随着面向对象编程语言日益流行，一些人认为，解决面向对象语言和关系数据库“阻抗不匹配”的办法是在数据库中映射对象。因此，我们最后迎来了“面向对象的数据库”。对象数据库方面有意思的地方是，在许多情况下，它们基本上是内置对象映射器的普通数据库。这种数据库后来渐渐失宠，下一个真正的主流尝试是2010年代的“nosql”。
1. 攻击sql
nosql以同样的方式攻击关系数据库和sql。这回的主要问题是，互联网颠覆了具有40年历史关系数据库管理系统（rdbms）架构的基本前提。这种数据库旨在节省宝贵的磁盘空间，并可纵向扩展。然而现在有太多的用户和太多的任务，一台胖服务器处理不了。nosql数据库则宣称，如果数据库没有连接（join），没有标准查询语言（因为实现sql需要花费时间），也没有数据完整性，那么就可以横向扩展以处理众多用户。这解决了纵向扩展的问题，但也带来了新问题。
与这些联机交易处理系统（oltp）并行开发的是另一种关系数据库，名为联机分析处理系统（olap）。这种数据库支持关系结构，但在执行查询时就知道它们将返回大量数据。上世纪八、九十年代的公司企业仍主要由批处理驱动。此外，olap系统为开发和分析人员提供了将数据想象成n维数据集并加以存储的能力。如果你设想二维数组和基于两个索引的查询，以便基本上与恒定时间一样高效，但是随后在此基础上添加另一个维度，以便可以执行实质上是3个或更多因素（比如供应、需求和竞争对手数量）的查询，你就可以更高效地分析和预测。然而，构建这些元素是一项费力又高度面向批处理的工作。
图形数据库几乎与横向扩展型nosql同一时间面市。许多事物本身不是“关系型”，或者不是基于集合论和关系代数，而是基于父子关系或朋友的朋友关系。一个典例是模型中的产品系列-产品品牌-款型-部件。如果你想知道“我的笔记本电脑搭载什么主板？”，会发现制造商的采购来源很复杂，光有品牌或型号可能不够。如果你想知道某产品系列中使用的所有主板，在经典（非cte即通用表表达式）sql中，你必须遍历表，并且分多个步骤进行查询。最初，大多数图形数据库根本就不分片。实际上，无需将数据实际存储为图形，就能完成许多类型的图形分析。
2. 兑现和未兑现的nosql承诺
nosql数据库的扩展性确实比oracle数据库、db2或sql server（它们都基于40年前的一种设计）好得多。然而，每种nosql数据库都存在新的限制：
（1） 键值存储 ·
没有比db.get（键）更简单的查询了。然而，世界上许多数据和使用场景无法以这种方式来设计结构。此外，我们其实在谈论缓存策略。在任何数据库中，主键查询速度很快。重要的只是内存中的数据。在理想情况下，它们像哈希图一样扩展。然而，如果要跑30趟数据库才能将数据放回去或进行任何类型的复杂查询，这行不通。这些系统现在更常作为缓存实施在其他数据库的前面。（例子：redis。）
（2） 文档数据库 ·
这种数据库之所以流行起来，是由于它们使用json，对象又易于序列化成json。这种数据库的第一个版本没有连接，将整个“实体”放到一个庞大的文档中有其自身的缺点。没有事务保证，你还会遇到数据完整性问题。今天，一些文档数据库支持一种不太可靠的事务，但它不是大多数人习惯的同一种保护级别。而且，即使对简单查询而言，这种数据库在延迟方面常常速度很慢，尽管它们就吞吐量而言扩展性更好。（例子：mongodb和amazon documentdb。）
（3） 列存储 ·
这种数据库的查询速度与键值存储一样快，它们可以存储更复杂的数据结构。然而，如果执行像跨3个表（rdbms术语）或3个集合（mongodb术语）连接这样的操作，会让人痛苦不堪。这种数据库确实适合时间序列数据（请给我在下午1点至2点出现的所有事务）。
还有其他更深奥的nosql数据库。然而，所有这些数据库的共同点是不支持通用数据库惯用语，而且往往专注于“特殊用途”。一些流行的nosql数据库（比如mongodb）编写了出色的数据库前端和生态系统工具，因而开发人员很容易采用它们，但存储引擎存在严重的限制，更不用说弹性和可扩展性方面的限制了。
3. 数据库标准仍然很重要
关系数据库占主导地位的原因之一是，它们有一个通用的工具生态系统。首先有sql。虽然数据库方言可能不一样——如果你是开发或分析人员，想从sql server 6.5升级到oracle 7，可能不得不修复查询，并使用“（+）”用于外部连接，但是简单的切实可行，复杂的很容易转换。
其次，你有odbc以及后来的jdbc等。几乎任何可以连接到一个rdbms的工具（除非为了管理该rdbms而专门设计）都可以连接到其他任何rdbms。有许多人每天连接到rdbms，并将数据倒入到excel以便分析。我不是指tableau或其他数百种工具，而是指“鼻祖”excel。
nosql摈弃了标准。mongodb不使用sql作为主要语言。mongodb的劲敌couchbase寻找一种查询语言来取代基于java的mapreduce框架时，更是创建了一套自己的sql方言。
标准很重要，无论是为了支持工具生态系统，还是由于许多查询数据库的人不是开发人员——他们都知道sql。
4. graphql和状态管理的兴起
你知道谁总是翘着两个大拇指想搭车，就想让他的应用进入到数据库里，但却不关心如何实现吗？事实证明，整整一代的开发人员都想这么做。而graphql（与图形数据库无关）可将对象图形存储在底层数据存储系统中。这样一来，开发人员就不必担心这个问题了。
这方面的早期尝试是对象关系映射（orm）工具，比如hibernate。它们拿来一个对象后，基于对象到表的映射设置，基本上将对象变成了sql。这种工具的许多前几代产品很难配置。此外，我们面临学习过程。
大多数graphql实现方法与sequelize或typeorm之类的对象关系映射工具兼容。结构良好的graphql实现方法和api不会在你的全部代码中泄露状态管理问题，而是在对象图形发生变化时写入并返回相关数据。谁会在应用层面真正关心数据是如何存储的？
面向对象数据库和nosql数据库的基础之一是，应用开发人员要意识到数据在数据库中如何存储方面的复杂情况。当然，这对于开发人员来说很难用较新颖的技术来驾驭，但现在不再困难了，因为graphql完全消除了这个问题
5. newsql或分布式sql闪亮登场
谷歌遇到了数据库问题，写了一篇论文，然后编写了一种名为“spanner”的实现方法，描述了全局分布式关系数据库如何行得通。spanner引发关系数据库技术领域迎来了新一波创新。你实际上可以有一个关系数据库，不仅让它能扩展，还能在需要时进行全球范围扩展。我们所谈论的是现代意义上的大规模，而不是经常令人失望且日趋复杂的rac/streams/goldengate方法。
所以，关系系统中“存储对象”的前提是错误的。如果关系数据库的主要问题是后端而不是前端，将会怎么样？这就是所谓的“newsql”或名称更恰当的“分布式sql”数据库背后的想法。其想法就是将nosql存储知识和谷歌的spanner概念与一种成熟的开源rdbms前端（比如postgresql或mysql/mariadb）结合起来。
这意味着什么？这意味着鱼和熊掌可以兼得。这意味着你可以有多个节点，并横向扩展——包括跨云可用区扩展。这意味着你可以有多个数据中心或云地理区域——仅用一个数据库。这意味着作为用户，你可以拥有真正的可靠性和永远不会崩溃的数据库集群。
与此同时，整个sql生态系统仍有用！你无需重新构建整个it基础架构就能做到这点。虽然你可能不敢“丢弃并更换”传统的rdbms，但大多数企业并不打算使用更多的oracle。最棒的是，你仍可以使用在云端和全球各地的sql及所有工具。
责编ajx
光幕光栅是什么，如何使用及注意事项
618蓝牙耳机便宜吗？学生党高性价比TWS真无线蓝牙耳机推荐！
生物传感器的分类有哪些
中国北斗芯片已实现规模化应用，工艺已由0.35微米提升至28纳米，最低单片价格不到人民币6元
详解TD-SCDMA建设情况
数据库40年发展史：NoSQL和NewSQL谁将登上“铁王座”？
舞厅用音乐同步声控开关电路
HMC624A是一款6位数字衰减器
LT3587单芯片的小型高效解决方案
变频器安装现场应满足哪些条件
3D打印技术将为机器人增添新材料 改变机器人技术
曝华为将与印度Indus OS合作 将加强在印度市场的影响力
微软将眼球追踪技应用于AR设备中
英国脱欧后将暂停8.1万个.eu域名
谷歌推Android 11正式版，将带来什么变化？
电子行业需求增加 工业机器人每年以平均14%的速度增长发展
什么是伽玛(γ)匹配
人工智能名片+在线教育，开启智能营销新模式
冰箱过滤器工作原理、作用、结构特点、发凉、发热
大疆否认“将退出中国市场”传言：大疆无人机没有退出计划