保持冷静，节制使用 JSON

Posted 2021-04-30 程序猿

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了保持冷静，节制使用 JSON相关的知识，希望对你有一定的参考价值。

来自：开源中国翻译频道

链接：https://www.oschina.net/translate/keep-calm-and-json（点击尾部阅读原文前往）

由 Robbie_Zhu, agile, leoxu, 混元归一, Tony 协作翻译完成

原文：https://dzone.com/articles/keep-calm-and-json

JSON (javascript Object Notation) 是一种轻量级的数据交换格式。它容易被人们阅读和编写，也容易被软件所读取和生成。如下是用JSON描述的一份客户数据。它能很好的用在交换和集成商。

目前使用还不错。

如果只把JSON用在应用程序中不同层级间的数据交换上，那还好。而当人们开始要将其作为一种数据库存储格式来使用时，就不好了。当我第一次遇到将JSON作为一种数据库中的数据格式时，感到非常惊奇，因为数据库要花费不少代价，每一条记录里面键和值都要存，而且每次查询都要进行处理。在我的演讲和文章里面，已经有许多人提过这个问题了。

以下是经常会遇到的异议:

1 、JSON 是文本，它效率不高。

2、JSON 没有没有可执行结构，毫无数据质量可言。

3、每一个文档（行）都得是键值对? 你肯定是疯了才会这样做。

让我们一个一个讨论这些异议。

JSON 是文本，它效率不高。

如我们所知RDBMS在电子商务中起到至关重要的作用，甚至是即将到来的Web2.0时代,RDBMS也将在网站后台运行。当人类登月以后，交易花费从 $5下降到 $0.02，于此同时Jim Gray进行了最后一次航海旅行。这是因为在90年代，经过在RDBMS的巨大的努力和相关硬件供应商持续的改进下，赢得了TPC基准测试之战。Oracle发布了支持SUN的硬件的版本。Sybase打破了HP的记录。Informix击败SGI。IBM进行了内部变革。之后，Oracle将卷土重来。在这个过程,每个公司都愿意花费 $25,000来占据一整页华尔街日报来吹嘘自己，是的，在90年代，人们以纸质的形式阅读报纸。

通过这些供应商的努力，数据库优化了物理设计，访问路径，I/O,数据读取，事务等等。这促进了许多硬件创新，例如：从微处理器指令系统到SMP系统设计，无线宽带技术等。数据库压缩每个时钟周期,每个IO,每个锁,记录的优势,每一个瓶颈都被强有力的改进。每个硬件供应商都尝试获得更高的TPC测评数。

RDBMS十分高效。

RDBMS有一种成本意识 -—— 空间，时间，时空，甚至一切。

与RDBMS存储格式相比，JSON效率低下。

● 所有的数据都是字符形式的JSON需要转换处理。

● 即使数值数据也存储在文本中。

● 每个值在每个文档中都带有其键名称（键值）。需要更多的存储和处理。

● 允许表示复杂的结构，导致运行时开销。

● 官方支持小集数据类型。无小数，无时间戳记等。

在数据库中使用JSON意味着:

● 数据库引擎必须理解每个文档的模式并处理它们，而不是处理常规元组和属性（行和列）。

● 必须解析和处理JSON中每个键值的数据类型

● JSON可能是XML的一个精减的版本，但它仍然很庞大。

有这么多低效率的缺陷，为什么还有数据库使用JSON作为数据模型呢？或者说实现JSON数据类型呢？

的确。 JSON作为数据交换格式被发明，现在是公共API——数据集成场景的首选格式。大多数设备，大多数软件层可以以JSON的形式消费和产品数据。以JSON存储和发布数据意味着，除了下面的优点之外，API和应用程序还可以在他们熟悉的介质中与数据库交互。你必须考虑n层应用程序效率，而不是将其与元组插入和更新进行比较。大多数RDBMS现在已经将JSON添加为数据类型。随着JSON使用量的增长，存储和处理效率将会提高。

JSON在数据库中不要求数据结构。因此数据质量差。

自从JSON数据库不要求任何结构。不管是有意，还是无意，应用程序都可以插入任何格式的数据了，只要这些数据是有效的JSON。

基于JSON的数据库倾向于“读取模式“。也就是说，读者有责任去理解和翻译每一个文档或查询结果的模式。查询语言，如N1QL ，就有很多文档本身的自解读功能。

已经提到过的一些工具，如Ottoman 和 Mongoose可以帮你去验证一个给定的JSON是否违反了已定义的结构。尽管对将数据加载进JSON数据库来说，这不是一个好的安全装置，但是在应用层对数据的正确控制可以帮助你提高数据的一致性。

另一方面，灵活性，JSON的内嵌结构可以帮助你在一个单独的JSON文档中匹配对象数据。

使用JSON也可以避免对象关系映射的开销。应用程序的规范和修改对象。为了在关系模式中存储这些数据，你需要在多个关系中规范这些数据，把它们存储在离散的表中。当你需要重建对象时，你需要在这些表中连接数据，构建返回对象。而对象关系映射层（如Hibernate自动完成这个过程），你仍然会消耗性能，因为你为每步执行了多个查询。

通过对象在JSON的分层内嵌结构中的表示，避免了很多对象关系映射的消耗。

保持冷静，节制使用 JSON

每一个文档都是键值对? 那你就疯了!

不过现在的结果是瓶颈已经被转移啦。瓶颈已经从数据库核心性能移向了数据库灵活性和应用程序开发的迭代变更管理。

80，90年代RDBMS被用于许多的应用和用例中，最重要的是RDBMS能跟上发展脚步还有硬件的更新。它能适用于高时速，新指令，多内核，大内存的硬件更新。随着业务的增长，对应用程序的自动化多进程要求越来越高。而且一些应用程序越来越受欢迎和有价值，企业当然就希望它能做得更多。业务应用程序开始从后台自动化到真正的业务变更驱动程序。

RDBMS虽然擅长于做许多事情，但是从未改变过自己。所面临的问题都是组织和技术方面的问题。

RDBMS使用“写入模式”方法。模式决定了创建表的时间，在每个插入，更新，合并处检查。更改表结构通常涉及多个相关字段，多个应用程序，需要测试所有相关模块。

使用ALTER在表中添加列，更改数据类型需要对表的数据进行校验是否都符合要更改的数据类型，若有不符合的会导致应用程序和业务计划停机。如果你需要一个列来存储不同类型的数据或结构，那你就太不走运了。针对这种情况，系统已经尝试通过允许用户在线添加列来缓解小子集的问题。

所有这些都需要时间，会减缓了开发和交付的步伐。你可以看看到JSON上的模式变更中会做出的突破：在这个演示文稿[起始幻灯片17]中。

如果使用JSON格式通过键值来存储数据，您可以避免在写入时强制执行模式。当文档被查询处理引擎或应用程序读取时，它们必须阅读和解释文档。应用程序通常会对文档进行版本化管理以便他们知道在文档本身的模式发展过程中会发生什么。查询语言（如N1QL，SQL ++）将扩展到文件内部处理更灵活的模式！

总结

这是模拟数据在关系模型和JSON中的比较

保持冷静，节制使用 JSON