NoSQL究竟是什么？了解为什么NoSQL数据库不是传统数据库的对手

通过阅读这篇文章，你会发现本章扩展的不仅仅是优势之一。这不是阻止使用NoSQL的方法。本章将对NoSQL技术的所有限制进行公正的描述，并且只是想让您了解使用它们时可能遇到的每个问题。许多要点可能会因实施而有所不同（即，当我说支持的工具很少时，大多数工具都适合，但并非所有工具都适用），因此请将它们视为一个概述，提醒您可能存在的风险找。我期望的是，在您选择使用NoSQL产品之后，您可以使用本章作为核对表来了解您的特定数据库中是否存在此问题以及它是否与应用程序相关。

安全

安全是每个人都想要的，但很难达到。从理论上讲，每种技术都可能存在安全问题。SQL系统上也存在安全问题，也许存在安全问题。那么为什么我将此标记为NoSQL的可能问题？

关于安全性的NoSQL“概念”没有真正的问题，但我们可能会遇到与我们采用的产品的成熟度相关的安全问题。产品增长时出现安全问题，然后修复。直观地说，年轻的产品可能有许多未知的安全问题。此外，一个年轻的产品在市场上销售的时间较短，因此顾问没有时间获得它们的经验，许多安全限制可以忽略不计。所以，问题是大多数NoSQL平台的新特性。对于商业用途，我建议只使用成熟的解决方案，背后有供应商。

数据一致性

当我们开始学习RDBMS时，他们告诉我们ACID事务是使整个数据库保持一致的操作的最佳选择。好吧，大多数NoSQL技术都没有实现这种交易。NoSQL系统基于最终一致性原则。在实践中，拥抱一点风险（一个节点可能与其他节点不同步），它们会获得一些性能提升。是的，这是妥协，但我们不能拥有一切。

我必须提到一些NoSQL实现，比如FoundationDB，允许类似ACID的事务保持NoSQL性能高。顺便说一下，当我们继续使用NoSQL时，数据一致性仍然是一个关键部分：基于您正在开发的应用程序，这可能是一个问题。

JOIN的

当您与试图将您转换为NoSQL技术的人交谈时，您可以从中听到的第一个好处之一是由于删除关系而带来的性能优势。我们都同意一种关系可能会降低性能，但我们会失去什么呢？

想象一下，你在徒步旅行时背着沉重的背包。当然，放弃它你会更快。这样做很方便吗？取决于这个包装包含什么，这取决于背包内容的价值是什么。如果它包含一个夜晚的帐篷，也许最好在一小时后到达目的地，但要保持温暖而不是走得更快。如果你带来有用的一次性用品，也许你可以做相反的事情。

遵循这种并行性，我们是否可以接受松散的一致性以获得性能？方便值得吗？

退后一步，我将从连接的起源开始。RDBMS使用该关系将数据从一个表链接到另一个表，以将数据保存在一个位置而不复制它们。构造连接以允许我们在查询中重新连接它们。当然，在表之间进行连接需要额外的计算成本，而不是直接在要查询的表中查找数据。但是这个成本对于保持关系（没有复制，一致性）是必要的。

很明显，虽然这个功能有可接受的开销，但这没关系，可能是最好的选择。但什么时候它减慢了一切或需要太多的硬件？这个问题允许NoSQL开发人员声称缺少JOIN到一个功能，但NoSQL始终是解决方案吗？

不总是。有时我们只需要重新设计数据库结构，可能会删除一些关系或重组数据。是的，我们将失去一些关系，或者我们将复制日期的某些部分，但它可以接受（在NoSQL中我们将失去所有的关系）。

另一个问题是一致性。考虑类别和产品。我们可能有一个嵌套的类别树，许多产品作为树的叶子。在传统的RDMS中，更改类别树只是对类别表上的外键（自我关系）的更新。这些更改会自动反映所有子类别和产品。在NoSQL中，我们可以在所有类别/产品上拥有冗余数据，并且需要对子元素进行大量更新。

棘手的交易

让我假设我们的应用程序可以放弃JOIN以获得速度，在我们的例子中，这是一个可接受的权衡。我们说过，在许多NoSQL实现中，很难保持各种条目的一致性。当您在没有事务的情况下工作时，您可以按顺序执行许多操作，但过了一段时间后会出现不一致 这对于NoSQL的第一次实现是正确的，并且一些新技术试图给出事务。您还可以考虑在应用程序级别管理事务，尝试回滚脏数据，但在许多情况下可能很难管理。

缺少供应商技术的标准

SQL是一种标准语言。可能会有许多变化带来特定的方言，但这很复杂并不禁止抽象数据访问。想想Hibernate，NHibernate，Doctrine，Entity Framework或其他ORM。它们证明了SQL方言之间的区别并不重要。我们可以得出结论，即使许多供应商实现了不同的数据库技术，SQL也是一种标准语言。此外，如果您不是基于ORM层，如果您为DB生成查询，则大多数代码可以在其他代码中重用。这使迁移更容易，开发人员可以快速适应不同的DB解决方案。

另一方面，在NoSQL世界中，存在更多混乱。每个供应商实现其特定语法，而不涉及任何共享标准。这意味着在不同的NoSQL实现之间迁移应用程序更加困难。这意味着找到一个熟悉许多NoSQL技术的程序员更难。

架构灵活性可能是一个麻烦

NoSQL系统的一个特点是它们不需要架构。在实践中，程序员在保存数据时决定数据结构。因此，没有任何地方可以写出数据的结构以及数据的含义。即使您可以使用某种自动化工具轻松地从数据关系重新创建数据库模型，这可能是传统应用程序中缺少的。

而且，如果发生错误怎么办？我们知道可能存在代码出错的情况。传统的RDMS是脚手架，因此如果您切换某些字段或者您的字段格式错误，它们可以保护您免受不一致。在NoSQL的情况下，DB没有任何帮助，因为没有定义任何模式，没有任何关于数据的信息应该保存：没有人可以说数据是否错误。最糟糕的副作用是，该过程为开发人员带来了很多权力和很多责任，通常不了解所有流程或完整结构。

而且，即使你现在知道什么是保存的，你认为你会记得下个月的所有内容？和第二年？并非所有项目都需要持续开发，在我们需要进行一些更改之前，可能会有一个业务应用程序保持原样多年。

在IT部门，公司通常会将项目委托给某个供应商，因此必须考虑这一部分，以确保在项目结束时轻松移交，可能要求准确记录有关数据的结构以及每个字段/集合的含义。与模式灵活性相关的最后一个问题是团队中的每个成员都无法在项目中工作，因此，对于小团队来说，流量是至关重要的并非所有成员都对数据结构有完整的了解，或者没有足够的文档。

Analytics（分析）

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!