【源文】https://www.datanami.com/2017/09/25/sql-databases-integrating-nosql-like-features
【译文】
过去的几十年间，关系型数据库（SQL）在全世界几乎应用到所有类型的业务。其技术可靠，标准稳定，整体成熟已超过20多年。
非关系型数据库（NoSQL）的概念实际早于关系型数据库，但他们只是在10年前变成切实可行。然而，在他们开始做后，主要在两类业务中快速被推广应用。第一类是大型数字经济公司，他们需要前所未有的扩展，第二类是技术初创公司，他们寻找廉价易用的数据库解决方案，以满足其扩展要求。
鉴于NoSQL功能流行度的提升，SQL数据库厂商开始注意，并在其数据库架构中实现类NoSQL类的功能。
在我们深入讨论之前，有必要先更好的理解为什么NoSQL会取得现在的地位。
NoSQL的诱惑力
NoSQL数据库主要的亮点体现在两个方面：扩展性和弹性。
在基础设施和扩展性方面，几十年间随着业务的增长，数据量也同步增长，传统的手段是垂直扩展，即升级至更强的数据库服务器。然而，基于云计算、商业服务器，企业现在可以实现水平扩展解决性能和高可用需求，即分布式部署NoSQL数据库，跨数据中心复制数据（如果必要，跨全球也可实现）。
管理关系型数据库是一项有技巧、成本高的运维工作，既是是使用开源产品，这就阻碍了其在初创企业的应用。使用NoSQL数据库将大幅削减对DBA角色对需求，尤其是当使用云服务时，该角色甚至消失。
在数据架构中，弹性已成为关键。传统做法是，遵循范式规则创建数据模型，该方法成型的年代，存储设备非常昂贵，人们尽力避免数据冗余。但范式规则对改进产生了巨大对束缚。对于数据库模式做的任何变更都意味着繁重的操作和高成本的协调，既是是为了改进应用，这限制了企业的灵活性。除了上面提到的基础设施的革新，NoSQL的真正革命性的方面是其弹性，可以快速适应业务改变的需求。NoSQL数据库这方面被错误的称之为“无模式”。
这个词一方面有效的抓住了人们的注意力，但也传递了错误但印象，即开发者不需要思考待存数据但结构。事实上，在使用NoSQL数据库时，数据建模甚至比之前更家重要。为了表达持续的弹性，更好的术语可能是“动态模式”。
NoSQL降低了总体拥有成本
感谢上面的两个特性，应用的总体拥有成本（TCO）得到了大幅降低，因为企业开发变得更加灵活，IT部门可以更加快速的响应竞争环境的变化。
NoSQL易入门、扩展性好、可靠性高、弹性好，且灵活，这些因素导致只需更少成本的程序就能满足业务需求。这可能不足以证明翻写已有的应用，但对于任何新项目，采用NoSQL就有意义了，它可以阻止技术债的增长和创造高成本的资产。
选择关系型数据库的常见论点是，它们的一致性、引用完整性以及能基于两阶段提交来处理事务。的确如此，当今这些功能技术对于大型、本地复杂应用依然有用。然而，在以异步、无状态WEB服务组成的相互连接的世界中，这种优势正在快速消失，这这种应用环境中要求应用能容忍事务处理的失败。基于NoSQL数据库，大部分业务可以接受和实现最终一致性，尤其是这能让网站用户保持耐心。
JSON的影响
对于特定的应用有许多不同的方式来设计关系型数据库，范式规则和引用完整性提供来一种防护措施来应对各种设计问题。对于NoSQL文档数据库，JSON的特点是灵活性和功能强大，它给新用户一种错误的安全感。相比关系型数据库，对于NoSQL数据库而言，数据建模变得更加重要，它使用户创建不同的What-if脚本。
NoSQL数据库开始成为主流后，SQL数据库厂商感受到一些影响。对于传统数据库厂商最简单的事情是增加对JSON文档对支持。这种方式对应了NoSQL文档数据库对灵活性的优点。需要小心的是，每个厂商本地检索复杂对象的能力是否与这种新能力匹配。同时，每个厂商扩展策略仍然没有太多改变。这就意味着你不能自然的使用NoSQL技术来真正的实现水平扩展。
尽管如此，也很少发现在SQL数据库中实际存储JSON数据的用户。厂商们或许不知道这个比例，但依然好不犹豫的采取防御措施，尝试将NoSQL数据库排除在企业IT部门之外。无论如何，在SQL数据库中增加JSON存储似乎只是一种附加物，而NoSQL文档数据库则明显是有意内置的。同时，我们也观察到一些大的SQL数据库厂商收购了一些NoSQL数据库，这也反应了NoSQL市场的增长。有人会认为这是产品经理忙于将不同的产品打包至一个解决方案中。
几乎每个月都有一款新NoSQL产品发布，但这难以持续下去。面对快速发展的每个细分市场，我们可能更关注改组、强化、合并。已确立的运动员会防卫他们的场地，以捍卫现有的得分，另一面挑战者会出创新牌。一些挑战者会壮大，而另一些挑战者会被收购、兼并。让我们期待最好的技术能胜出，而不是最好的市场推广能力。
NoSQL数据库厂商的回应
当然，NoSQL厂商并不会坐而待毙。首先，他们从单一功能，转变为多模型方法。而且，在宣称NoSQL数据库为“非关系型”后，人们意识到关系存在于数据语义学中，无论数据库是否支持外键约束。结果，用户要求NoSQL数据库厂商增加关系特征，例如，MongoDB引入了跨多集合的lookup功能和只读视图，以应对执行用户的请求，还有增加ACID能力来应对缺乏事务支持对非议。另外，一些增加了类似SQL对查询句法来帮助开发者过渡。
最后一个需要考虑的是，如果你从没有强制规范化过，那么使用JSON来进行数据建模会很自然，但是习惯的力量是顽固的，尤其你是SQL老手。结果，如果你从事过关系数据库，使用JSON建模则需要换思路，不论是在传统数据库中内置JSON组件，还是NoSQL文档数据库。你需要取挑战那些不可改变的原则，那些范式和事务原子性。
为了合理的利用NoSQL的优势，你需要强迫自己忘记第三范式，而从如何访问数据的角度来思考。你想要写数据库是连接数据，所以你要做的是当你读取时将其存储在一起。这种思想转变很难，尤其是在同样的数据库里，你可能暂时需要能以传统规范的方式存储数据。
NoSQL玩家持续增加特性以帮助该技术的成熟，NoSQL数据库会占据一席之地，最终会成为主流，走入企业IT的视线。同时，SQL厂商可能会说服已安装的数据库保持现状。标准化一份老的技术也许会很安全，IT部门也不会使自己丧失新技术带来的益处。他们会实验和判断，以选择合适的的工具来完成各自的业务需求。
关于作者 Pascal Desmarets
Pascal Desmarets为Hackolade创始人、CEO，他带领团队打造来一系列可视化工具，以帮助NoSQL技术在IT架构中应用推广。Hackolade软件让NoSQL文档数据库的数据建模更加舒适和易用。[email protected].