关系型数据库还是NoSQL：
- 选用关系型数据库RDBMS :
- The data is well structured, and lends itself to a tabular arrangement (rows and columns) in a relational database. Typical examples: bank account info, customer order info, customer info, employee info, department info etc etc.
- Another aspect of the above point is : schema oriented data model. When you design a data model (tables, relationships etc) for a potential use of RDBMS, you need to come up with a well defined schema: there will be these many tables, each table having a known set of columns that store data in known typed format (CHAR, NUMBER, BLOB etc).
- Very Important: Consider whether the data is transactional in nature. In other words, whether the data will be stored, accessed and updated in the context of transactions providing the ACID semantics or is it okay to compromise some/all of these properties.
- Correctness is also important and any compromise is _unacceptable_. This stems from the fact that in most NoSQL databases, consistency is traded off in favor of performance and scalability (points on NoSQL databases are elaborated below).
- There is no strong/compelling need for a scale out architecture ; a database that linearly scales out (horizontal scaling) to multiple nodes in a cluster.
- The use case is not for “high speed data ingestion”.
- If the client applications are expecting to quickly stream large amounts of data in/out of the database then relational database may not be a good choice since they are not really designed for scaling write heavy workloads.
- In order to achieve ACID properties, lots of additional background work is done especially in writer (INSERT, UPDATE, DELETE) code paths. This definitely affects performance.
- The use case is not for “storing enormous amounts of data in the range of petabytes”.
- 选用NoSQL数据库:
- There is no fixed (and predetermined) schema that data fits in:
- Scalability, Performance (high throughput and low operation latency), Continuous Availability are very important requirements to be met by the underlying architecture of database.
- Good choice for “High Speed Data Ingestion”. Such applications (for example IoT style) which generate millions of data points in a second and need a database capable of providing extreme write scalability.
- The inherent ability to horizontally scale allows to store large amounts of data across commodity servers in the cluster. They usually use low cost resources, and are able to linearly add compute and storage power as the demand grows.
不算题外话：
关系型数据库（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
然而唯一令人遗憾的是他们切换方式和以前相反，这点请注意。事实上你的团队总是喜欢使用相同的数据库有很多的原因，即使是这些数据库团队开发许可很贵，在很多案例里更贵：
- 从事额外的许可和/或合同需要新数据库供应商提供技术支持.
- 为了新技术寻找技能熟练的数据库管理员（DBA）(能够胜任新数据库).
- 维护两个数据仓库，并能维持数据同步的成本。
最终，有一个临界值：
@gareth @xeraa 一般情况下，都有一个临界值，没到临界点，可以坚持使用关系型数据库（RDBMS），在某种程度上就要开始考虑同时使用两种数据库或者完全迁移到另一个上。
— 卢卡斯埃德尔 (@lukaseder) 2016年9月21日
在数据库中使用JSON，这很简单：
偶尔使用JSON存储：坚持使用关系型数据库（RDBMS）。
一切以JSON为主：可以考虑不用关系型数据库(RDBMS）。
这个同样适用于图形问题。SQL完全能够处理图形和递归遍历。递归的计算子集之和，这是一个时髦的声明：
如果你只有一点树形/图形遍历需要计算（例如，一个简单的菜单结构），就无需涉及关系型数据库。如果图形存储是您的主要业务，那么关系型数据库可能不是一个好的选择。
结论
无论你要解决什么问题，请记住：如果你有一把锤子，而每一个问题开始的时候都可以当作钉子。但不要把关系型数据库当作是把愚蠢的锤子。不要小看它，在2016年它在处理非关系型小众的事情上做的非常的好。
关系型数据库仍然是处理各种数据问题的最好的选择。 只有当你存储超过一定阀值（或者你可以预见到要这么做），那是你应该去寻找替代品来替代它。因为当你去寻找一个新的(JSON，图形等）来改变的时候，要浪费你很多的时间回到你“正常”的关系业务里去。
