4 种不适合使用 NoSQL 数据库的场景

• 我们可以用NoSQL来解决哪些问题?
  
• 同样重要的是，NoSQL在哪些方面不适合使用？
  
• 不同的方法 （NoSQL 和 NewSQL） 在哪些方面才能显示它们的优势?
  
  

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

NoSQL数据库的四个缺点

不要让我们产生误解，NoSQL数据库对于许多工作负载和应用程序是非常有优势的，但在四个方面，NoSQL的缺点是很明显的。

可扩展性

当NoSQL产品用来实现以满足诸如Google，Facebook和Twitter等与生俱来的网络公司的可扩展性需求时，它们开始引起注意。 这些公司要处理大量来自无数来源的非结构化数据：网络搜索，移动设备，用户状态更新，评论流等。

在这些用例中，最重要的考虑是可扩展性：数据库必须大规模扩展。 SQL数据库的僵硬模式和交互性被视为枷锁，并且在传统RDBMS上扩展的成本也被认为是不可行的。

在廉价的硬件商品上向外扩展的能力是很关键的。 如果你的用例需要横向扩展无限数据源，NoSQL可能是正确的选择 --- 除非你要对数据进行实时操作。

虽然传统的关系数据库系统提供了扩展选项 ---- 以非常显著的成本 ---- 许多NewSQL系统被设计为解决可扩展性挑战，首先使用NoSQL来解决，同时保留传统RDBMS的事务性和交互性。

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

可用性

大多数NoSQL系统是为可用性设计的，CAP-定理>

这个由Apache Cassandra做出的著名的设计决策是基于这样一个观点，即数据总是可以访问比数据立即正确更重要。 毕竟，理由是，谁真的关心一个Tweet是否真的按照发布的顺序实时显示？ 最终，它将以正确的顺序显示，但不一定非得立即正确显示。

在某些用例中，最终的一致性是可以接受的。 但是在许多情况下，例如当您需要立即作出决定时...

• 让移动用户的访问通过。
  
• 分配有限的，稀缺的资源。
  
• 处理财务。
  
  

... EC（和NoSQL）就不是一个好的选择。

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

一致性（例如，兼容ACID事务，正确答案）

NoSQL系统被设计为可用性（见上文）。 这个选择意味着他们无法提供CAP定理>

因此，NoSQL系统选择AP - 它们是可用性和分区容错性。 这使得NoSQL对于需要强一致性的应用程序或用例来说是一个糟糕的选择：

• 计费。
  
• 权限管理，运营支持（电信公司）。
  
• 最后一美元（广告科技，游戏）。
  
• SLA（译者注：Service Level Agreement 服务级别协议，提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约）管理，会话管理。
  
• 交易验证，欺诈检测，投标和报价管理。
  
• 传感器管理。
  
  

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

一个更实际的方式来考虑CAP：面对网络分区，您不能总是具有完美的一致性和100％的可用性。 您应该相应地做出规划。

快速请求-响应应用程序

现代请求-响应式风格的应用程序大量发生：

• 验证用户的余额时允许移动电话进行连接。
  
• 以最优惠的价格交易。
  
• 向潜在的成千上万的用户展示移动广告，而不会影响广告客户的广告预算。
  
• 为电信运营商管理严格的SLA。
  
• 在交易批准之前检测欺诈刷卡。
  
  

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

来自：http://blog.csdn.net/qq_33046143/article/details/72360834