何时该用SQL，何时该用NoSQL ?

翻译小吕

本文转自可译网，转载需授权

有些人做架构决策的时候纯粹是基于谁的声音大：

@xeraa @lukaseder 不，我们最重要的架构决策是基于 #tweets. 这是一个面向Twitter的体系结构。
— 加里斯维斯特恩 (@gareth) 2016年9月21日

然而对其他大多数人而言，决策并不是这么简单。例如：什么时候我们应该启用NoSQL存储系统来代替关系型数据库管理系统（RDBMS）？

关系型数据库（RDBMS）能够适应所有情况

这个问题很明显，假设你开始就使用关系型数据库（RDBMS)，这种传统的数据库系统能够解决任何问题且不容易被取代。这意味着什么？简单的举例：

关系型数据库（RDBMS）一直被使用，所以他们和”新来者“相比在市场上有巨大的优势， “新来者”缺少优秀的工具，如社区、支持也不够成熟。
埃德加·弗兰克·科德的工作对我们整个行业产生的最大影响可能就是，自那以后，几乎没有像关系模型那样具有革命性的东西了。对一个替代型数据库来说，它很难被普遍使用。意即它们通常被用来解决小问题。

有人会这么说，有时候你确实碰到一个小问题。例如，一个图形数据库的问题。然而事实上，图表和你在关系模型中所标识的东西没有什么根本性的不同。它很容易用多到多的关系表来模拟一个图。

这些同样使用于数据库中的XML/JSON(别忘记， JSON就是XML，但比XML少一些语法和属性，所以它更棒)。有时候，您需要在数据库中的层次结构中存储文档的结构（层次结构数据）而不是规范他们。当然你也可以先规范文档，但可能会做很大的无用功。

大多数现代关系型数据库提供XML/JSON数据结构来存储（以及更重要的查询）数据，包括PostgreSQL、Oracle、DB2、SQL Server等。

那么，我们什么时候决定切换？

作为开发人员，我们倾向于能够快速的切换。例如，当我们处理图形时，我们喜欢用Neo4j，因为它具有不起的数字查询语言。当我们使用JSON时，我们喜欢用Couchbase，因为它实现了有趣的N1QL查询语言。这两种语言都深受SQL查询语言影响，在我看来我们的供应商会给我们提供明智的选择（不会像MongoDB基于JSON查询语言），终究原因，SQL语言乃是由最强大和最流行的4GL 曾经创造的。

但是作为开发人员，我们不应该轻率的做出决定。首先，虽然这些专业的数据库看起来像是更好的选择，但是运营团队需要增加额外的维护成本、监控、补丁以及生产系统的额外调整。这在关系型数据库中真实的存在，最近的一个突出的例子是Uber从PostgreSQL 切换回MySQL：

https://eng.uber.com/mysql-migration