我们在最近的一篇文章中探讨了 NoSQL 和 NewSQL之间的基本区别。 现在让我们通过观察开发人员真正关心的问题来剖析其差异：
- 我们可以用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。
- 在交易批准之前检测欺诈刷卡。
这些事件在世界各地每天发生数百万次。 电信，金融服务，在线游戏，广告技术等行业的供应商需要适应这些事件的变化和速度。 他们需要一个可扩展的，事务性一致的解决方案。
