JSON (JavaScript Object Notation) 是一种轻量级的数据交换格式。它容易被人们阅读和编写，也容易被软件所读取和生成。如下是用JSON描述的一份客户数据。它能很好的用在交换和集成商。
目前使用还不错。 如果只把JSON用在应用程序中不同层级间的数据交换上，那还好。而当人们开始要将其作为一种数据库存储格式来使用时，就不好了。当我第一次遇到将JSON作为一种数据库中的数据格式时，感到非常惊奇，因为数据库要花费不少代价，每一条记录里面键和值都要存，而且每次查询都要进行处理。在我的演讲和文章里面，已经有许多人提过这个问题了。 以下是经常会遇到的异议:
我们一项一项地讨论一下这些异议。 1.JSON是文本的，它的效率不高 就像我们知道的那样，即使是Web2.0时代的到来，RDBMS提供的在线业务依然是生命的关键。RDBMS运行在所有站点的后台。从人类登上月球到Jim Gray最后一次航行，业务的成本已经从$5降低到了$0.02。这是由于九十年代，在 RDBMS上的巨大努力和硬件供应商为了赢得TPC基准战争所做的持续改进 。Oracle将在SUN硬件上发布，Sybase将在数量上击败HP。Informix将打败SGI，IBM 将打败IBM，然后，Oracle将会回来，每家公司都会花费$25.000在WSJ的整版广告上吹嘘自己——九十年代的时候人们在报纸上阅读新闻。 为了这一努力，数据库优化物理设计，访问路径，I/O，数据加载，事务等等。这导致了许多在硬件上的创新，如微处理器指令集应用到SMP系统设计，InfiniBand。数据库压榨每一个锁周期，每一次IO，每一个锁获取，日志优势。 在每一个瓶颈上奋力搏斗。每一个硬件供应商都试着拥有最好的TPC数。 RDBMS十分高效。 RDBMS有一种成本意识 -—— 空间，时间，时空，甚至一切 与RDBMS存储格式相比，JSON效率低下。
在数据库中使用JSON意味着:
有这么多低效率的缺陷，为什么还有数据库使用JSON作为数据模型呢？或者说实现JSON数据类型呢？ 的确。 JSON作为数据交换格式被发明，现在是公共API——数据集成场景的首选格式。大多数设备，大多数软件层可以以JSON的形式消费和产品数据。以JSON存储和发布数据意味着，除了下面的优点之外，API和应用程序还可以在他们熟悉的介质中与数据库交互。你必须考虑n层应用程序效率，而不是将其与元组插入和更新进行比较。大多数RDBMS现在已经将JSON添加为数据类型。随着JSON使用量的增长，存储和处理效率将会提高。我们一项一项地讨论一下这些异议。 1.JSON是文本的，它的效率不高 就像我们知道的那样，即使是Web2.0时代的到来，RDBMS提供的在线业务依然是生命的关键。RDBMS运行在所有站点的后台。从人类登上月球到Jim Gray最后一次航行，业务的成本已经从$5降低到了$0.02。这是由于九十年代，在 RDBMS上的巨大努力和硬件供应商为了赢得TPC基准战争所做的持续改进 。Oracle将在SUN硬件上发布，Sybase将在数量上击败HP。Informix将打败SGI，IBM 将打败IBM，然后，Oracle将会回来，每家公司都会花费$25.000在WSJ的整版广告上吹嘘自己——九十年代的时候人们在报纸上阅读新闻。 为了这一努力，数据库优化物理设计，访问路径，I/O，数据加载，事务等等。这导致了许多在硬件上的创新，如微处理器指令集应用到SMP系统设计，InfiniBand。数据库压榨每一个锁周期，每一次IO，每一个锁获取，日志优势。 在每一个瓶颈上奋力搏斗。每一个硬件供应商都试着拥有最好的TPC数。 RDBMS十分高效。 RDBMS有一种成本意识 -—— 空间，时间，时空，甚至一切 与RDBMS存储格式相比，JSON效率低下。
在数据库中使用JSON意味着:
有这么多低效率的缺陷，为什么还有数据库使用JSON作为数据模型呢？或者说实现JSON数据类型呢？ 的确。 JSON作为数据交换格式被发明，现在是公共API——数据集成场景的首选格式。大多数设备，大多数软件层可以以JSON的形式消费和产品数据。以JSON存储和发布数据意味着，除了下面的优点之外，API和应用程序还可以在他们熟悉的介质中与数据库交互。你必须考虑n层应用程序效率，而不是将其与元组插入和更新进行比较。大多数RDBMS现在已经将JSON添加为数据类型。随着JSON使用量的增长，存储和处理效率将会提高。 2.JSON在数据库中不要求数据结构。因此数据质量差 自从JSON数据库不要求任何结构。不管是有意，还是无意，应用程序都可以插入任何格式的数据了，只要这些数据是有效的JSON。 基于JSON的数据库倾向于“读取模式“。也就是说，读者有责任去理解和翻译每一个文档或查询结果的模式。查询语言，如N1QL ，就有很多文档本身的自解读功能。 已经提到过的一些工具，如Ottoman 和 Mongoose可以帮你去验证一个给定的JSON是否违反了已定义的结构。尽管对将数据加载进JSON数据库来说，这不是一个好的安全装置，但是在应用层对数据的正确控制可以帮助你提高数据的一致性。 另一方面，灵活性，JSON的内嵌结构可以帮助你在一个单独的JSON文档中匹配对象数据。 使用JSON也可以避免对象关系映射的开销。应用程序的规范和修改对象。为了在关系模式中存储这些数据，你需要在多个关系中规范这些数据，把它们存储在离散的表中。当你需要重建对象时，你需要在这些表中连接数据，构建返回对象。而对象关系映射层（如Hibernate自动完成这个过程），你仍然会消耗性能，因为你为每步执行了多个查询。 通过对象在JSON的分层内嵌结构中的表示，避免了很多对象关系映射的消耗。
2.JSON在数据库中不要求数据结构。因此数据质量差 自从JSON数据库不要求任何结构。不管是有意，还是无意，应用程序都可以插入任何格式的数据了，只要这些数据是有效的JSON。 基于JSON的数据库倾向于“读取模式“。也就是说，读者有责任去理解和翻译每一个文档或查询结果的模式。查询语言，如N1QL ，就有很多文档本身的自解读功能。 已经提到过的一些工具，如Ottoman 和 Mongoose可以帮你去验证一个给定的JSON是否违反了已定义的结构。尽管对将数据加载进JSON数据库来说，这不是一个好的安全装置，但是在应用层对数据的正确控制可以帮助你提高数据的一致性。 另一方面，灵活性，JSON的内嵌结构可以帮助你在一个单独的JSON文档中匹配对象数据。 使用JSON也可以避免对象关系映射的开销。应用程序的规范和修改对象。为了在关系模式中存储这些数据，你需要在多个关系中规范这些数据，把它们存储在离散的表中。当你需要重建对象时，你需要在这些表中连接数据，构建返回对象。而对象关系映射层（如Hibernate自动完成这个过程），你仍然会消耗性能，因为你为每步执行了多个查询。 通过对象在JSON的分层内嵌结构中的表示，避免了很多对象关系映射的消耗。
3. 每一个文档都是键值对? 那你就疯了! 不过现在的结果是瓶颈已经被转移啦。瓶颈已经从数据库核心性能移向了数据库灵活性和应用程序开发的迭代变更管理。 80，90年代RDBMS被用于许多的应用和用例中，最重要的是RDBMS能跟上发展脚步还有硬件的更新。它能适用于高时速，新指令，多内核，大内存的硬件更新。随着业务的增长，对应用程序的自动化多进程要求越来越高。而且一些应用程序越来越受欢迎和有价值，企业当然就希望它能做得更多。业务应用程序开始从后台自动化到真正的业务变更驱动程序。 RDBMS虽然擅长于做许多事情，但是从未改变过自己。所面临的问题都是组织和技术方面的问题。 RDBMS使用“写入模式”方法。模式决定了创建表的时间，在每个插入，更新，合并处检查。更改表结构通常涉及多个相关字段，多个应用程序，需要测试所有相关模块。 使用ALTER在表中添加列，更改数据类型需要对表的数据进行校验是否都符合要更改的数据类型，若有不符合的会导致应用程序和业务计划停机。如果你需要一个列来存储不同类型的数据或结构，那你就太不走运了。针对这种情况，系统已经尝试通过允许用户在线添加列来缓解小子集的问题。 所有这些都需要时间，会减缓了开发和交付的步伐。你可以看看到JSON上的模式变更中会做出的突破：在这个演示文稿[起始幻灯片17]中。 如果使用JSON格式通过键值来存储数据，您可以避免在写入时强制执行模式。当文档被查询处理引擎或应用程序读取时，它们必须阅读和解释文档。应用程序通常会对文档进行版本化管理以便他们知道在文档本身的模式发展过程中会发生什么。查询语言（如N1QL，SQL ++）将扩展到文件内部处理更灵活的模式！ 总结这是模拟数据在关系模型和JSON中的比较
没错，.JSON是文本的，它让模式执行充满挑战性，并占用了更多的空间。但是，它使得你的应用开发，模式演化，和对象关系映射变得更容易。 文献
|
