nosql数据库入门_NoSQL入门资料

nosql数据库入门

虽然您中的某些人可能是NoSQL专家，但通常缺乏对NoSQL的扎实知识，以及一些常见的神话。 具体地说，诸如NoSQL适用性/用例及其与关系数据库的比较（公平和不公平）之类的主题通常是由不完整的知识所驱动。 我并没有声称自己是NoSQL领域的专家，但是我想记下我对NoSQL所知甚少的信息（通常）可能会很有用。 从（相对）初学者的角度看NoSQL的人可以从这篇文章中受益（也许吗？）。 因此，让我们开始吧。

NoSQL…..

这并不意味着“没有SQL” （请参见空格如何弄乱东西）！。 这与事实相去甚远。 实际上，它的意思是“不仅仅是SQL” ！ 看到不同 ？ 甚至基于NoSQL的技术都使用某种（主要是专有的）语言来“查询”它们的本机存储-那时它与结构化查询语言并没有太大的不同！

好的，所以它是“不仅仅是SQL”。 但…。

它的主要特点是什么？

很难精确列出NoSQL解决方案的所有特定属性。 某些解决方案可能支持或可能不支持所有这些属性，但总的来说，这些是最常见的解决方案

没有架构

这也许是所有最基本的属性。 NoSQL解决方案没有模式的概念（它只是关于数据容器的一堆元数据-行和列）

自然分布

大多数NoSQL解决方案都支持分布式架构，该架构在多个实例之间对数据本身进行分区和负载平衡（完全不同！）。

基础

它是用于缩写“B asically 甲 vailable，S经常状态，E ventual一致性”。 好吧，我不想赘述[因为我不完全理解它！ ;-)]。 但是我所知道的事实是，BASE（对于NoSQL）与ACID（对于RDBMS）常常是争论的重点。

NoSQL解决方案的类型

这些是NoSQL解决方案的最常见类别/类型/变体

• 键值对 ：将数据存储为键值对，其中值没有固定的表示形式，例如Redis，Oracle NoSQL
• 文档存储 ：将文档（XML，JSON，BSON等）存储为值，例如MongoDB，Couchbase
• Graph ：将信息存储在类似结构的图形中，例如Neo4j，OrientDB
• 基于列 ：将数据存储在列中但不包含行，例如Apache Cassandra

…。 或上述一项或多项的组合！

好的，那为什么我应该在我的旧RDBMS之上选择NoSQL解决方案呢？

好了，现在是讨论一些区别的合适时机。 希望即使不是100％准确，我也能大致得到这些结果

可扩展性

很容易（至少在理论上）添加NoSQL数据存储的其他节点/实例来满足您的应用程序不断增长的需求。 NoSQL解决方案旨在以分布式方式很好地工作，这一事实使之成为可能。

灵活性

这与“无模式”特征有关。 从某种意义上说，NoSQL解决方案是灵活的，即它们根本没有架构，或者它们允许存储相对非结构化的数据而无需进行管理方面的修改（例如，在RDBMS的情况下演进架构）

高度可用

一开始听起来可能很愚蠢。 您可能会说，通过添加更多实例，任何东西（包括RDBMS）都可以变得多余（高度可用）。 确实如此。 使用NoSQL解决方案，这样做更加容易，因为它们（通常）是从头开始设计的（从头开始），并且考虑到了极端的扩展性，这会自动使它们高度可用-如果一个节点发生故障，您的应用程序不会停止。 数据在其余节点之间重新分配（重新分区），然后继续播放。

性能

分布式NoSQL解决方案的性能在涉及大型数据集的问题域中很有用，因为它可以水平扩展（通过添加更多节点）

更适合云端

在我看来，云计算（特别是与PaaS相关的服务）是关于弹性扩展（对资源进行成本有效的管理，在这种情况下，您的实例将根据基于负载，体积，时间等因素的策略进一步增加/减少），更轻松的设置和配置以及流畅的升级/修补过程。 NoSQL解决方案非常适合该法案（我可以肯定，至少从扩展的角度来看）

具有成本效益

再次，其全部关于水平缩放而不是垂直缩放。 水平缩放意味着旋转更多实例（便宜得多），而不是升级单台机器的硬件（在特定时间点可能会增加成本）

好吧..那么NoSQL的“没有警告”吗？

绝对不！ 与任何技术一样，尽管它的用法可能非常适合您的用例，但也有利弊

• 对于RDBMS纯粹主义者，NoSQL解决方案的最终一致性还不够好。 在特定的用例/域中，通常缺乏ACID属性是NoSQL存储的最大缺点。
• 异构产品和缺乏标准：NoSQL解决方案激增。 尽管许多基本概念和特征保持不变，但是从不同的供应商那里学习NoSQL解决方案可以使学习过程更加艰难！ 这是因为，关于这项技术还没有特定的标准/ API（至少我还没有看到）
• 相对较新：听起来不像是一个严重的警告，但是与RDBMS（数十年来一直有效！）相比，团队可能需要花费更多时间来开发该技术。

什么时候应该使用NoSQL解决方案？

我没有在生产中实现NoSQL解决方案的个人经验，但是从常识的角度来看，这就是我的想法。
众所周知，最好的答案是“取决于” ；-)好吧，也许不是吗？ 无论您是在考虑NoSQL与RDBMS还是在比较各种NoSQL产品，都应该查看用例，然后从那里进行学习。 如果需要ACID属性，请避免使用NoSQL。 如果您有大型数据集，并且数据类型本质上是非关系的，则最好利用NoSQL及其可伸缩性属性。 就从图形，键值，基于文档或基于列的NoSQL存储中进行选择而言，答案（或可能是问题）仍然保持不变-“您的用例需要什么？”

好奇？ 探索 ！

干杯!

翻译自: https://www.javacodegeeks.com/2015/09/introductory-nosql-stuff.html

nosql数据库入门