NoSQL技术的示例分析
这篇文章主要介绍了NoSQL技术的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
关系型数据库几乎是许多开发者和DBA对于传统三层架构应用的唯一选择。使用这一场景有很多原因，数据建模方法，查询语言与数据交互，保证数据的一致性部署，并能够为复杂的应用服务。
然而，这不是解决所有数据存储问题的唯一方案，也是NoSQL 产生的原因。NoSQL 提供了新的方法而不是采用面向标准SQL的范式。
NoSQL 技术与高伸缩性无缝融合，很多技术同时具备了高分布性和高性能,是大数据分析的存储基石。大多数时间里，它们使 现有RDBMS 技术所实现的架构更加完整，例如 作为缓存服务器，搜索引擎，非结构化存储，易变信息存储等。主要分为4类：
Key/value
列存储
面向文档的存储
图存储
现在深入到各种技术，选择最适用于使用场景的技术。
Key/Value
第一个也是最早的 NoSQL 数据存储就是key/value. 这些数据就像字典一样根据key来匹配value，通常使用在需要高性能的基本信息存储，例如需要快速读写的session信息，这些存储在这样的情景非常高效，也通常具有高伸缩性。
Key/value也经常被用于上下文的队列化来保证数据不丢失，例如日志架构或搜索引擎的索引架构。Redis 和Riak KV 是非常有名的key/value数据存储； Redis 使用的更加广泛，因为它有着一个内存型 K/V 存储，并且持久化是可选的。Redis 经常用于web应用中来存储session相关的数据，例如node或者-
PHP的 web应用 ; 每秒钟可以提取成千上万的session信息而没有性能损失。另一个典型场景是后面要讲到的序列化：Redis位于 Logstash 和 ElasticSearch 之间来存储t ElasticSearch 查询中的索引。
Column
由于要存储超大量的记录信息 到达了key/value存储限制的时候就需要用到列存储。列存储技术对于RDBMS世界的工程师可能不太容易理解，但事实上非常简单。RDBMS 中数据是按行存储的，而列存储中是按列的。使用列数据库的主要好处是能高速访问海量数据。 RDBMS的一行在硬盘上是一个连续的存储，多行可能存储在硬盘不同的位置，使访问稍显复杂，在列数据库中的一列数据是连续存储的。
举个例子，考虑在RDBMS中查询索引博客的标题，尤其是有数百万数据的时候，需要大量的IO操作，而在列数据库中，这样的查询只是一次访问。这样的数据库在从特定簇提取海量数据中非常顺手，但此消彼长的是缺乏灵活性。使用最多的列存储数据库是
Google Cloud Bigtable, 但开源的列存储数据库是Apache HBase 和Cassandra.
列存储数据库的另一个好处是容易伸缩，这些列在海量存储时具有高伸缩性。这就是为什么它们主要用于保存非易变且长久保留信息的原因。
Document
列存储数据库对于含有比较深嵌套结构的结构化数据的存储不是最好的，这种场景需要使用面向文档的数据存储。数据实际上以key/value 存储,但是所有压缩的数据叫做文档。 文档依赖于一个结构或者编码例如XML, 但更多时候是 JSON (JavaScript Object Notation).
尽管文档型数据库对于数据的结构化存储和表达都非常有用，但也有其脆弱的一面，特别是与数据的交互性操作。它们基本上要遍历整个文档，例如当读取某个特定字段的时候，遍历可能会影响性能。
当需要存储嵌套信息的时候，可以采用文档型数据库。例如，考虑怎样表达应用中的一个账户，大概有以下信息：
基础信息:姓名，生日，照片 ，URL, 创建日期等等
复杂信息: 地址，认证方法(password, Facebook, 等第三方认证),兴趣等等。
这也是NoSQL 文档型数据库经常用到web应用的原因: 表达嵌套对象非常容易，由于都使用JSON，还可以与前端的JavaScript技术无缝集成。
使用最多的文档型数据库是MongoDB, Couchbase, 和 Apache CouchDB，都非常容易安装和启动，有很好的文档说明，而且都是可伸缩的，除此之外，它们也是开放现代web应用的明确选择。
Graph
Graph 数据库与其它数据库有着本质的区别。它使用了不同的范式来表达数据--树结构，节点和边连接起来叫做关系。这些数据库是随着社交网络而诞生的，例如表达用户的好友网络，他们的好友关系等等。对于其它类型的数据存储，可能把一个用户的好友关系存储在一个文档中，但是，存储好友关系还依然非常复杂；使用图数据库就非常简单，为每个好友创建节点，通过关系连接他们，依赖查询的需要和范围浏览图。
最著名的图数据库是Neo4j, 象前面所说的，主要使用场景是处理复杂的关系信息，例如实体间的连接，也可以用于分类的场景。
Figure 2-1 展示了在图数据库中3个实体是如何连接的。
图中的两天账户节点Jane 和 John, 它们之间的每一条边定义了他们的关系，在某天相互认识，另一组节点连接的两个账户展示了Jane 和 Joh在某天后都成为了足球组的成员。
使用场景中的NoSQL
根据使用场景，首先需要一个文档型的 NoSQL数据库，将存储在关系型数据库中的数据结构化的一个 JSON 文档. 如前所述，传统的RDBMSs 将数据存储到多个有关系的表，当得到一个完整对象时变得比较复杂和低效。在Figure 2-2. 中可以看到一个账户被分割成多个表的例子。
如果要获得所有的账户信息，基本上需要join两到三个表。现在考虑这样的情形: 需要处理所有用户在应用中的每一次连接，这些连接有着不同的商业逻辑。 最后,想要账户自身的视图。通过传递一个账户标识通过API从全部用户视图中得到一个怎样的文档呢？
{ "id": "account_identifier", "email": "account@email.com", "firstname": "account_firstname", "lastname": "account_lastname", "birthdate": "account_birthdate", "authentication": [{ "token": "authentication_token_1", "source": "authenticaton_source_1", "created": "16-12-12" }, { "token": "authentication_token_2", "source": "authenticaton_source_2", "created": "16-12-12" }], "address": [{ "street": "address_street_1", "city": "address_city_1" "zip": "address_zip_1" "country": "address_country_1" "created": "16-12-12" }]} 好处显而易见: 通过保持一个实体的 JSON 表达,可以更快更好的访问数据。进一步，将这一方法通用化，从NoSQL数据库读取所有的读操作，而让所有的写操作 (create, update,delete) 还在RDBMS上 .但必须实现一个逻辑来维持 RDBMS到NoSQL 的数据同步，如果没在缓存中的话还要创建一个关系型数据库的对象。
在NoSQL高效可伸缩地创建文档时为什么还要保持 RDBMS呢？因为这不是应用的真正目的。我不想产生一个Big Bang 的影响. 假设RDBMS已经准备好了，但因为RDBMS缺乏灵活性而集成了一个NoSQL存储。希望充分利用两个最好的技术 -- 特别是RDBMS的数据一致性和NoSQL的伸缩性 。
感谢你能够认真阅读完这篇文章，希望小编分享的"NoSQL技术的示例分析"这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!
