nosql数据库有哪些 4种不适合用NoSQL数据库的场景

在最近的一篇文章中，我们讨论了NoSQL和新闻生活的基本区别。现在让我们通过观察开发人员真正关心的东西来分析差异:

我们可以用NoSQL解决什么问题？

同样重要的是，NoSQL在哪些方面不适合使用？

不同的方法(NoSQL和NewSQL)可以在哪些方面显示出它们的优势？

让我们回顾一下NoSQL和NewSQL之间的四个明显区别，并回顾一些使用NoSQL技术但可能不是最佳选择的用例。

NoSQL数据库的四个缺点

别误会，NoSQL数据库对于许多工作负载和应用程序非常有利，但它的缺点在四个方面很明显。

扩展性

当实施NoSQL产品以满足谷歌、脸书和推特等互联网公司的可扩展性要求时，它们开始吸引注意力。这些公司不得不处理来自无数来源的大量非结构化数据:网络搜索、移动设备、用户状态更新、评论流等等。

在这些用例中，最重要的考虑是可伸缩性:数据库必须大规模扩展。SQL数据库的僵化模式和交互性被视为桎梏，在传统RDBMS上扩展的成本也被认为是不可行的。

向外扩展廉价硬件产品的能力至关重要。如果您的用例需要扩展无限的数据源，NoSQL可能是正确的选择——除非您想要实时操作数据。

尽管传统的关系数据库系统提供了扩展选项，但成本非常高，许多NewSQL系统都是为了解决可伸缩性挑战而设计的，这些挑战首先通过使用NoSQL来解决，同时保留了传统关系数据库管理系统的事务性和交互性。

一个很好的替代方案是内存中的大规模并行SQL关系数据库，它在廉价的硬件产品上线性扩展。数据库应该是云友好的，并且可以扩展以满足云操作的需要。它应该设计为高性能、低延迟、无共享、本地集群和云友好的架构，以实现高可用性、冗余性和容错性。

可用

大多数NoSQL系统都是为可用性而设计的。

Apache Cassandra做出的这一著名设计决策是基于这样一种观点，即数据始终可访问比数据立即正确更重要。毕竟原因是，谁真的在乎一条Tweet是不是按照发布的顺序实时显示？最终，它会以正确的顺序显示，但不必立即显示。

在一些用例中，最终的一致性是可以接受的。但是在很多情况下，比如你需要马上做决定的时候…

让移动用户的访问通过。

分配有限和稀缺的资源。

处理财务。

……欧共体(和NoSQL)不是一个好的选择。

一些NewSQL系统允许用户降低一致性级别。例如，MemSQL支持弱隔离(ACID中的“I”)来提高查询延迟。为了可用性而牺牲正确答案对于分析型(OLAP)工作负载可能是有意义的，但是对于事务型(OLTP)工作负载就变得无关紧要了。

一致性(例如，与ACID兼容的事务、正确答案)

NoSQL系统是为可用性而设计的(见上文)。这个选择意味着他们不能提供CAP定理>:

因此，NoSQL系统选择应用程序——它们是可用性和分区容错。这使得NoSQL不适合要求高度一致性的应用程序或用例:

计费。

权限管理，运营支持(电信公司)。

最后一块钱(广告技术，游戏)。

SLA(译者注:Service Level Agreement)管理，即会话管理，是提供服务的企业与客户之间就服务的质量、标准和性能达成的协议或合同。

交易验证、欺诈检测、投标和报价管理。

传感器管理。

一个典型的CAP定义说:你不可能同时满足这三个特征。

一个更实际的思考CAP的方法:面对网络分区，你不可能一直拥有完美的一致性和100%的可用性。你要有相应的规划。

快速请求-响应应用程序

现代请求和响应式应用大量出现:

验证用户余额时允许手机连接。

以最好的价格交易。

向成千上万的潜在用户展示移动广告，而不影响广告商的广告预算。

为电信运营商管理严格的SLa。

交易审批前检测欺诈性刷卡。

这些事件每天在世界各地发生数百万次。电信、金融服务、网络游戏、广告技术等行业的供应商需要适应这些事件的变化和速度。他们需要一个可扩展的、事务一致的解决方案。

结束。

相关建议: