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（说明）

（编辑：湖南网）

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