NoSQL数据库从入门到实战 nosql数据库总结

转载

IT独行侠 2023-09-28 10:40:28

文章标签 NoSQL数据库从入门到实战 nosql 数据 Redis 数据库 文章分类 NoSQL 数据库

NoSQL历史：

随着用户内容的增长，所生成、处理、分析和归档的数据的规模快速增大，类型也快速增多。此外，一些新数据源也在生成大量数据，比如传感器、全球定位系统（GPS）、自动追踪器和监控系统。这些大数据集通常被称为大数据。数据不仅仅快速增长，而且半结构化和稀疏的趋势也很明显。这样一来，预定义好数据库的组织和结构，和利用关系型引用的传统数据管理技术就受到了挑战。在探索海量数据和半结构化数据相关问题的过程中，诞生了一系列新型数据库产品，其中包括列族数据库（column-oriented data store）、键/值数据库和文档数据库，这些数据库统称NoSQL。

今天NoSQL泛指这样一类数据库和数据存储，它们不遵循经典RDBMS原理，且常与Web规模的大型数据集有关。换句话说，NoSQL并不单指一个产品或一种技术，它代表一族产品，以及一系列不同的、有时相互关联的、有关数据存储及处理的概念。

NoSQL数据库是非常高效、强大的海量数据存储与处理工具。大部分NoSQL数据库都能很好地适应数据增长，并且能灵活适应半结构化数据和稀疏数据集。

NoSQL最早起源于1998年，但是从2009年开始，NOSQL真正开始逐渐兴起和发展。起初Google建造了大规模可扩展的基础设施，用于支撑Google的搜索引擎和其他应用。其策略是在应用程序栈的每个层面上分别解决问题，旨在建立一套可伸缩的基础设施来并行处理海量数据。为此Google创建了一整套完备的机制，包括分布式文件系统、面向列族的数据存储、分布式协调系统和基于MapReduce的并行算法执行环境。

Google公布设计理念引起了开源开发者的广泛关注和浓厚兴趣。很快，第一个模仿Google基础设施部分特性的开源软件就开发出来了，它的创建者正是开源搜索引擎Lucene的发明人。紧接着，Lucene的核心开发者们加入了Yahoo!，在那里，依靠众多开源贡献者的支持，参照Google的分布式计算架构，开发者们创建出了一个能够替代Google基础设施所有部分的开源产品，这就是Hadoop及其子项目和相关项目。然后随着大数据时代的蓬勃发展，到现在已经出现了很多种Nosql。

K-V存储的数据库： Redis、Membase、Oracle BDB等。
列存储数据库： HBase、Hypertable、Cloudata等。
文档数据库： MongoDB、CouchDB等。
图形数据库： Neo4j、FlockDB等。

NoSQL现状：

国内的互联网蓬勃发展，不仅涌现出BAT（百度，阿里巴巴，腾讯）之类的巨头，也带动了整个互联网行业的发展，大量的创业型公司如春笋般的涌出，在国家层面也提出了“互联网+”和“万众创业”的口号。更多传统的行业也开始拥抱互联网。但是无论是做所谓的生态平台还是传统业务的转型，涉及到的业务是多种多样的。这个时候企业架构师对于应用系统的核心——数据库管理不仅有传统的SQL选项也有了NoSQL这种适合特定场景需求的选项。

NoSQL近来年越来越受到互联网公司的重视，在业务量（通常是用户量）的规模在一定范围内，传统关系数据库完全可以满足要求，没必要最开始去采用NoSQL，由于SQL数据库发展几十年，相关技术是非常稳定的，项目的前期最重要的是完成核心产品功能的交付而不是“一步到位”去追求未来不确定的架构况且大部分采用NoSQL的公司很多也是采用了SQL与NoSQL结合的方式应用。把大量变化频率比较小或者对性能要求不太高的数据存放在SQL，把大量访问频繁或者对性能要求高的数据存放在NoSQL里。因此再次证明了NoSQL的目的并不是要替代SQL而是要更好地服务于业务。

当前的NoSQL主要应用在性能上和功能上，从性能上来说，同样的需求貌似传统的关系数据库也可以解决，只是在采用了分表、分库、集群各种优化手段之后依然很难去提升需求的更替或者是对长期来说是很大的挑战，或者是解决方案所投入的成本已经超出部署NoSQL可能面临的风险之上，企业会采用NoSQL来支撑业务的发展。从功能上来说，现在各行业的大数据革命必然对海量数据存储和处理有着十分高的要求，这个情况下传统的关系数据库很难达到类似Hadoop这样的数据存储处理能力，因此这样选择NoSQL是必要的。

NoSQL发展趋势：

目前来说，大部分需要的功能已经有主流的NoSQL实现完毕了，但是对于很多大公司来说，他们存在一些特别的需求，一直在NoSQL上面做更新维护。

NoSQL体系结构：

一些常见NoSQL的体系结构：

HBase：

Hbase底层是基于HDFS，那么最下就是HDFS，处理数据的职责又是DataNode负责，所以图示的最下面就是这部分内容。
Hbase本身就是一个主从架构，可以分为两部分，主节点HMaster（和HDFS中的NameNode的类似，也不是负责处理数据，只是进行接收请求客户端的请求，管理和维护Hbase整个集群的状态），从节点就是RegionServer（数据存放和处理的地方）。
列族就是Region，需要注意的一个列族应该对应多个Region，这个表数据的插入有关系，因为所有的数据都在一个大表上面，随着数据的加入一个列族的数据越来愈多，只用一个Region就没有办法进行存放和处理了，因此就需要多个。为了保证数据的安全，可以设置Region的冗余，也就是把数据进行备份。
Region也是一个逻辑单位，把其放大也是占用了一块内存，当存储的文件内容变大了就会形成文件（Store Files），为了提供性能的目的，这个文件并不是直接传递到DataNode进行处理，而是在达到128M时候形成HFile后再转送到DataNode。
既然是主从架构，就会出现单点故障的问题，因此就需要ZooKeeper，进行备份主节点，当然只有一个是启动运行，当主节点损坏后，备份的才启动。
集群状态的节点信息都存放在ZooKeeper上，需要注意的是存储的是主机名称（并不是ip地址），需要通过主机名来解析ip地址。

Redis：

底层使用C语言实现。
是一个有硬盘存储支持的内存数据库，效率很高。
支持事务和多种数据结构。
Master-slave复制。
Pub/Sub允许用户实现消息机制

Redis内部会使用很多高可用机制：主从同步，哨兵模式等。

在主从复制功能中，psyn 在不断的优化，不仅在 slave 闪断重连后可以进行增量复制，而且在 slave 通过主从切换成为 master 后，其他 slave 仍然可以与新晋升的 master 进行增量复制，另外，其他一些场景，如 slave 重启后，也可以进行增量复制，大大提升了主从复制的可用性。使用者可以更方便的使用主从复制，进行业务数据的读写分离，大幅提升 Redis 系统的稳定读写能力。

Redis 的内存数据都存在 redisDB 中。Redis 支持多 DB，每个 DB 都对应一个 redisDB 结构。Redis 的 8 种数据类型，每种数据类型都采用一种或多种内部数据结构进行存储。同时这些内部数据结构及数据相关的辅助信息，都以 kye/value 的格式存在 redisDB 中的各个 dict 字典中。

数据在写入 redisDB 后，这些执行的写指令还会及时追加到 AOF 中，追加的方式是先实时写入AOF 缓冲，然后按策略刷缓冲数据到文件。由于 AOF 记录每个写操作，所以一个 key 的大量中间状态也会呈现在 AOF 中，导致 AOF 冗余信息过多，因此 Redis 还设计了一个 RDB 快照操作，可以通过定期将内存里所有的数据快照落地到 RDB 文件，来以最简洁的方式记录 Redis 的所有内存数据。

Redis 进行数据读写的核心处理线程是单线程模型，为了保持整个系统的高性能，必须避免任何kennel 导致阻塞的操作。为此，Redis 增加了 BIO 线程，来处理容易导致阻塞的文件 close、fsync 等操作，确保系统处理的性能和稳定性。

NoSQL数据库从入门到实战 nosql数据库总结_Redis

NoSQL设计原则：

有排序需求的属性在设计document的时候要定义一个属性，不能放到contents里面去，否则后期无法实现排序的需求。
有频繁检索需求就要为其定义一个属性用来存放其值。不能只存放到contents里面去。或者两个地方都存放。
如果有全文检索的需求实体的设计方案：如果不用第三方的检索工具那就只能是尽量多的将属性存放到conents里面去，外面的用or查询来实现，此时外面不应当有太多属性。