考虑到NoSQL用于分布式设置的优势以及用于快速访问的大量数据/水平可伸缩性，对于某些实现来说，像mongodb这样的nosql数据库是个好主意。
然而，似乎nosql数据库有其优点和缺点。 而且似乎关系数据库带来明显的优势，特别是对于当前构建在关系数据库上的应用程序。
在这种情况下，我想问一下，站在两个数据库中是否有优势，一个用于NoSQL类型的数据，另一个用于其他用例，这些用例由业务需求预测，需要关系数据库类型的约束和功能？ （表中的连接和事务）。这是一种实用而常见的做法吗？
作为一个例子，推特或Facebook是否有关于用户登录信息和用户帐户的关系模型，而不是存储NoSQL数据库的其他动态数据？
答案 0 :(得分：2)
是的，当然。许多成功的公司都是这样做的。
NoSQL数据库旨在优化特定查询负载的访问，这与设计非规范化关系数据库以帮助特定查询的方式非常相似。
规范化的关系数据库旨在防止数据的冗余或异常存储。
这两个目标在适当的背景下都很重要。所以关系和非关系都有一个地方（非规范化的RDBMS适合后一类）。
SQL或NoSQL数据库似乎不是最理想的地方是当它们被不恰当地用于另一个更好的任务时。
纯粹规范化的RDBMS是万能的，无人掌握，因为它们支持各种各样的查询。但是，如果您不需要支持针对某个数据集的各种查询，那么非规范化或NoSQL都可以提供帮助。
当您厌倦了设计架构并执行ALTER TABLE以不时添加列时，NoSQL很有吸引力。但是，如果为一个查询加载设计NoSQL数据库，则可以将自己描绘成一个角落，然后发现您还需要支持针对相同数据的完全不同的查询负载。您要么使用慢查询，要么克隆整个数据集，但存储在不同的结构中。
答案 1 :(得分：0)
首先，我要说@Bill Karwin的回答是非常周到的，我同意他写的大部分内容。
现在，我的应用程序在几年内发展了。当在SQL中创建第一代数据库时，NoSql并不是真的。数据库增长为包含大量表和更多的函数和存储过程。我们两个人最终只是为了维持它而全职工作。优化查询几乎占用了我所有的时间。
在第一个DBA继续前进之后，我独自一人，我重新设计了这个概念，以便使用＆＃34; NoSql＆＃34;概念，但在关系数据库表（当时，Mongo和类似的alpha / beta）。在这种方法中减少到大约10个不同的表。它取得了一定程度的成功，但在速度方面并没有给我们带来太大的帮助。它确实允许我们避免雇用另一个DBA。
第三次，我实现了混合关系/无SQL数据模型。 Relational用于分层数据，但保持相同的＆＃34;打开表＆＃34;概念并没有很多表格列。查询相当快，但仍然没有跟上我们的负载。
最后，我决定完全抛弃Sql数据库（大约一年前）。我放弃了能够动态编写查询的灵活性，但是Mongo和Couchbase有足够的能力来查询我现在很舒服。性能优势远远超过了我的NoSql应用程序中冗余数据的缺点。
我的观点是我的案例最适合SQL数据库，但由于我能够重新设计我的应用程序，它实际上在NoSql环境中表现更好，我可以在我的自己，兼职，没有任何帮助。因此，SQL关系数据库的好处虽然强大，但实现起来可能非常昂贵，您应该将其纳入决策和设计中。