编译 | 小吕 来源 | 可译网 有些人做架构决策的时候纯粹是基于谁的声音大：
然而对其他大多数人而言，决策并不是这么简单。例如：什么时候我们应该启用NoSQL存储系统来代替关系型数据库管理系统（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 然而唯一令人遗憾的是他们切换方式和以前相反，这点请注意。事实上你的团队总是喜欢使用相同的数据库有很多的原因，即使是这些数据库团队开发许可很贵，在很多案例里更贵：
最终，有一个临界值：
在数据库中使用JSON，这很简单： 偶尔使用JSON存储：坚持使用关系型数据库（RDBMS）。 一切以JSON为主：可以考虑不用关系型数据库(RDBMS）。 这个同样适用于图形问题。SQL完全能够处理图形和递归遍历。递归的计算子集之和，这是一个时髦的声明： 如果你只有一点树形/图形遍历需要计算（例如，一个简单的菜单结构），就无需涉及关系型数据库。如果图形存储是您的主要业务，那么关系型数据库可能不是一个好的选择。 结论无论你要解决什么问题，请记住：如果你有一把锤子，而每一个问题开始的时候都可以当作钉子。但不要把关系型数据库当作是把愚蠢的锤子。不要小看它，在2016年它在处理非关系型小众的事情上做的非常的好。 关系型数据库仍然是处理各种数据问题的最好的选择。 只有当你存储超过一定阀值（或者你可以预见到要这么做），那是你应该去寻找替代品来替代它。因为当你去寻找一个新的(JSON，图形等）来改变的时候，要浪费你很多的时间回到你“正常”的关系业务里去。 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
