一、NoSQL数据库
数据库使用排名: https://db-engines.com/en/ranking
1.1、什么是nosql数据库
- NoSQL(
NoSQL = Not Only SQL ),意即“不仅仅是SQL”,泛指非关系型的数据库。 - NoSQL 不依赖业务逻辑方式存储,而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。
- 不遵循SQL标准
不支持ACID - 远超于SQL的性能
1.2、NoSQL适用场景
- 对数据高并发的读写
- 海量数据的读写
- 对数据高可扩展性的
- 用不着sql的和用了sql也不行的情况,可以考虑用NoSql
1.3、NoSQL不适用场景
- 需要事务支持
- 基于sql的结构化查询存储,处理复杂的关系,需要即席查询
1.4、Redis和MongoDB
1.4.1、Redis
- 数据都在内存中,
支持持久化 ,主要用作备份恢复 - 除了支持简单的key-value模式,还支持多种数据结构的存储,比如
string、 list、set、hash、zset等 。 - 一般是作为缓存数据库辅助持久化的数据库
1.4.1、MongoDB
- 高性能、开源、模式自由(schema free)的
文档型数据库 - 数据都在内存中, 如果内存不足,把不常用的数据保存到硬盘
- 虽然是key-value模式,但是对value(尤其是json)提供了丰富的查询功能
支持二进制数据及大型对象 可以根据数据的特点替代RDBMS ,成为独立的数据库。或者配合RDBMS,存储特定的数据
1.5、行式数据库和列式数据库
1.5.1、Hbase
- HBase是Hadoop项目中的数据库
- 它用于需要对大量的数据进行随机、实时的读写操作的场景中。
HBase的目标就是处理数据量非常庞大的表 ,可以用普通的计算机处理超过10亿行 数据,还可处理有数百万列 元素的数据表。
1.5.2、Cassandra
- Apache Cassandra是一款免费的开源NoSQL数据库,其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(
数据量通常达到PB级别 ) - 在众多显著特性当中,
Cassandra最为卓越的长处是对写入及读取操作进行规模调整 ,而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程 。
1.5.3、计算机存储单位
计算机存储单位一般用B,KB,MB,GB,TB,EB,ZB,YB,BB
注:“兆”为百万级数量单位。
- 位 bit (比特)(Binary Digits):存放一位二进制数,即 0 或 1,最小的存储单位。
- 字节 byte:8个二进制位为一个字节(B),最常用的单位。
- 1KB (Kilobyte 千字节)=1024B
- 1MB (Megabyte 兆字节 简称“兆”)=1024KB
- 1GB (Gigabyte 吉字节 又称“千兆”)=1024MB
- 1TB (Trillionbyte 万亿字节 太字节)=1024GB,其中1024=2^10 ( 2 的10次方)
- 1PB(Petabyte 千万亿字节 拍字节)=1024TB
- 1EB(Exabyte 百亿亿字节 艾字节)=1024PB
- 1ZB (Zettabyte 十万亿亿字节 泽字节)= 1024 EB
- 1YB (Jottabyte 一亿亿亿字节 尧字节)= 1024 ZB
- 1BB (Brontobyte 一千亿亿亿字节)= 1024 YB
1.6、图关系型数据库 Neo4j
主要应用:社会关系,公共交通网络,地图及网络拓谱(n*(n-1)/2)
二、Redis 安装和配置文件
1.1、官网
Redis官方网站:http://redis.io
Redis中文官方网站:http://redis.cn/
下载地址:http://redis.io/download
1.2、安装
docker 安装rredis查看==>docker安装redis和数据挂载
安装C 语言的编译环境-centos7环境
yum install centos-release-scl scl-utils-build
yum install -y devtoolset-8-toolchain
scl enable devtoolset-8 bash
查看gcc版本
gcc --version
下载,软件放在opt目录
wget http://download.redis.io/releases/redis-6.2.6.tar.gz
tar -zxvf redis-6.2.6.tar.gz
进入源码目录编译安装
cd redis-6.2.6/src
编译
make
安装
make install
安装目录在:/usr/local/bin
- redis-benchmark:性能测试工具,查看服务器性能
- redis-check-aof:修复有问题的AOF文件
- redis-check-dump:修复有问题的dump.rdb文件
- redis-sentinel:Redis集群使用
- redis-server:Redis服务器启动命令
- redis-cli:客户端,操作入口
1.3、配置文件
进入源码目录src,先复制一份配置文件作为备份
cp redis.conf redis.conf.bak
vi redis.conf
1.1.1、常规设置
-
允许后台运行=>daemonize no改成yes -
访问限制: 注释掉bind 127.0.0.1 -::1 运行远程访问,生产环境写服务器ip,不写的情况下,无限制接受任何ip地址的访问 -
将本机访问保护模式设置no=>protected-mode yes改成no -
端口6379改成6300 -
设置密码
1.1.1.1、启动redis
启动:
redis-server
多个端口可以
redis-cli -p6300
进入客户端
redis-cli
关闭
redis-cli shutdown
多实例关闭,指定端口关闭:
redis-cli -p 6300 shutdown
查看进程
ps -ef |grep redis
杀死进程
kill -9 进程号
1.1.2、配置文件详解
1.1.2.1、INCLUDES包含模块
类似jsp中的include,多实例的情况可以把公用的配置文件提取出来
1.1.2.2、网络相关配置
- 默认情况bind=127.0.0.1只能接受本机的访问请求 不写的情况下,无限制接受任何ip地址的访问
- 如果开启了protected-mode,那么在
没有设定bind ip且没有设密码的情况下 ,Redis只允许接受本机的响应 - rotected-mode 将本机访问
保护模式设置no - port 端口号,默认 6379
- timeout 一个空闲的客户端维持多少秒会关闭,
0表示关闭该功能。即永不关闭 。 - tcp-keepalive 对访问客户端的一种
心跳检测 ,每个n秒检测一次。 单位为秒 ,如果设置为0,则不会进行Keepalive检测,建议设置成60 - tcp-backlog
a.设置tcp的backlog,backlog其实是一个连接队列 ,backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列 b.在高并发环境下你需要一个高backlog值来避免慢客户端连接问题 。 c.注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值(128) 所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog(128)两个值来达到想要的效果
1.1.2.3、通用
daemonize :是否为后台进程,设置为yespidfile :存放pid文件的位置,每个实例会产生一个不同的pid文件loglevel 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为noticelogfile 日志文件名称databases 16 设定库的数量 默认16,默认数据库为0
1.1.2.4、SECURITY安全模块
- requirepass 密码–永久有效
1.1.2.5、LIMITS限制模块
1.1.2.5.1 连接限制
- 设置redis同时可以与多少个客户端进行连接。
默认情况下为10000个客户端 - 如果达到了此限制,redis则会拒绝新的连接请求,并且向这些连接请求方发出“max number of clients reached”以作回应。
1.1.2.5.2 maxmemory
建议必须设置,否则,将内存占满,造成服务器宕机 设置redis可以使用的内存量 。一旦到达内存使用上限,redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定。- 如果redis无法根据移除规则来移除内存中的数据,或者设置了“不允许移除”,那么redis则会针对那些需要申请内存的指令返回错误信息,比如SET、LPUSH等。
- 但是对于无内存申请的指令,仍然会正常响应,比如GET等。如果你的redis是主redis(说明你的redis有从redis),那么在设置内存使用上限时,需要在系统中留出一些内存空间给同步队列缓存,只有在你设置的是“不移除”的情况下,才不用考虑这个因素。
1.1.2.5.3. maxmemory-policy
- volatile-lru:使用LRU算法移除key,只对设置了过期时间的键;(最近最少使用)
- allkeys-lru:在所有集合key中,使用LRU算法移除key
- volatile-random:在过期集合中移除随机的key,只对设置了过期时间的键
- allkeys-random:在所有集合key中,移除随机的key
- volatile-ttl:移除那些TTL值最小的key,即那些最近要过期的key
- noeviction:不进行移除。针对写操作,只是返回错误信息
1.1.2.5.4. 4.6.4.maxmemory-samples
- 设置样本数量,
LRU算法和最小TTL算法都并非是精确的算法 ,而是估算值 ,所以你可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个 - 一般设置3到7的数字,
数值越小样本越不准确,但性能消耗越小 。
三、数据持久化模式RDB和AOF
AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)
1.1、RDB模式(Redis DataBase)
官网介绍:http://www.redis.io
1、在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里 2、默认文件名dump.rdb
1.1.1、RDB持久化流程图
1.1.2、持久化流程说明
- Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。
- 整个过程中,
主进程是不进行任何IO操作的 ,这就确保了极高的性能 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。 RDB的缺点是最后一次持久化后的数据可能丢失 。
1.1.3、什么是Fork
Fork的作用是复制一个与当前进程一样的进程 。- 新进程的所有数据(变量、环境变量、程序计数器等)
数值都和原进程一致 ,但是是一个全新的进程 ,并作为原进程的子进程 - 在Linux程序中,
fork()会产生一个和父进程完全相同的子进程 ,但子进程在此后多会exec系统调用,出于效率考虑,Linux中引入了“写时复制技术” - 一般情况父进程和子进程
会共用同一段物理内存 ,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。
1.1.4、动态停止RDB复制
save后给空值,表示禁用保存策略
redis-cli config set save ""
1.1.5、redis.conf中的配置和触发策略
- 在redis.conf中配置文件名称,
默认为dump.rdb - rdb文件的保存路径,
默认为Redis启动时命令行所在的目录下 dir ./ - save 3600 1 表示 3600秒内一个key发现改变就触发写入(持久化)
推荐使用:bgsave a、save :save时只管保存,其它不管,全部**阻塞** 。手动保存。不建议 b、bgsave:Redis会在后台异步 进行快照操作, 快照同时还可以响应客户端请求。 c、可以通过lastsave 命令获取最后一次成功执行快照的时间 - stop-writes-on-bgsave-error:当Redis 无法写入磁盘 的话,直接关掉Redis的写操作。推荐yes.
- rdbcompression :压缩文件
a、对于存储到磁盘中的快照,可以设置是否进行压缩存储。 b、如果是的话,redis会采用LZF算法进行压缩。 c、如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。 c、推荐yes. - rdbchecksum 检查完整性
a、在存储快照后,还可以让redis使用CRC64算法来进行数据校验 b、但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能 c、推荐yes.
如图:
1.1.6 RDB模式的优势和劣势
1.1.6.1、优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高更适合使用
- 节省磁盘空间
- 恢复速度快
1.1.6.2、劣势
- fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
- 在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。
1.1.7.3、归纳图
1.2、AOF模式(Append Only File)
- AOF模式默认不开启
- `以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件
- redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
- 可以在redis.conf中配置文件名称,默认为 appendonly.aof
- AOF文件的保存路径,同RDB的路径一致。
1.1.1、 AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内;
- AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量
- Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的
1.1.2、 AOF启动和异常修复
启动:
修改配置文件,默认的appendonly no,改为yes
异常修复(AOF文件损坏)
通过/usr/local/bin/redis-check-aof--fix appendonly.aof 进行恢复
恢复:
重启redis然后自动重新加载
1.1.3、 AOF同步频率设置
- appendfsync always
始终同步 ,每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好 - appendfsync everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。 - appendfsync no
redis不主动进行同步,把同步时机交给操作系统。
1.1.4、Rewrite重写压缩
1.1.4.1、说明
- AOF
采用文件追加方式 ,文件会越来越大为避免出现此种情况,新增了重写机制 , - 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集.
- 可以使用命令bgrewriteaof
1.1.4.2、重写流程图
bgrewriteaof触发重写 ,判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。- 主进程fork出子进程执行重写操作,保证主进程不会阻塞。
- 子进程遍历redis内存中数据到临时文件
- 客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
- 子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息.
- 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
- 使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。
1.1.4.3、重写原理和触发重写条件
1、AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename) 2、redis4.0版本后 的重写,是指上就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。
- 重写虽然可以
节约大量磁盘空间,减少恢复时间 。 - 但是每次重写还是有一定的负担的
- 因此设定Redis
要满足一定条件才会进行重写
如下:
no-appendfsync-on-rewrite=yes (降低数据安全性,提高性能) 不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。
no-appendfsync-on-rewrite=no (数据安全,但是性能降低) 还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞。
auto-aof-rewrite-percentage: 设置重写的基准值,文件达到100%时开始重写(文件是原来重写后文件的2倍时触发)
auto-aof-rewrite-min-size: 设置重写的基准值,最小文件64MB。达到这个值开始重写。
示例说明:
例如:文件达到70MB开始重写,降到50MB,下次什么时候开始重写?
答案:100MB
- 系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size
- 如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
1.1.5、优势和劣势
1.1.5.1、优势
- 备份机制更稳健,丢失数据概率更低
- 可读的日志文本,通过操作AOF稳健,可以处理误操作
1.1.5.2、劣势
- ?比起RDB占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话,有一定的性能压力
- 存在个别Bug,造成恢复不能
1.1.5.1、归纳图
1.3、推荐一起使用
rdb模式冷备。aof模式热备
- 如果对数据不敏感,可以选单独用RDB。
- 不建议单独用 AOF,因为可能会出现Bug。
1.4、官网建议说明
1.4.1、RDB和AOF官网说明
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
1.4.2、同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件
- 那要不要只使用AOF呢?
- 建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份), 快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。
1.4.2、性能建议
- 因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留
save 900 1(表示900秒 有key变化 ) 这条规则。(也就是冷备) - 如果使用AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。
- 代价:一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
- 只要硬盘许可,
应该尽量减少AOF rewrite的频率 ,AOF重写的基础大小默认值64M太小了,可以设到5G以上。 - 默认超过原大小100%大小时重写可以改到适当的数值。
|