Redis与Mongodb、Hbase笔记总结

redis mongodb hbase

//--------------------------------------------------------------------------

//----------------------Redis-----------------------------------------------

//--------------------------------------------------------------------------

安装

解压源码并进入目录

3/ make

4/ 可选  make test (可能出现need tcl>8.4,yum install tcl

/usr/local/redis

make PREFIX=/usr/local/redis install

运行

bin/redis-server

默认前端运行模式。后台进程模式: 修改conf   daemonize yes)

连接

bin/redis-cli

的主从复制

下面的列表清楚的解释了Redis Replication的特点和优势。

    1). 同一个Master可以同步多个Slaves

    2). Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力。因此我们可以将RedisReplication架构视为图结构。

    3). Master Server同步期间,客户端仍然可以提交查询或修改请求。

    4). Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据。

    5). 为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成。即便如此,系统的伸缩性还是得到了很大的提高。

    6). Master可以将数据保存操作交给Slaves完成,从而避免了在Master中要有独立的进程来完成此操作。    

的工作原理:

  

见如下步骤:

    1). 同时启动两个Redis服务器,可以考虑在同一台机器上启动两个Redis服务器,分别监听不同的端口,如63796380

    2). Slave服务器上执行一下命令:

    /> redis-cli -p 6380   #这里我们假设Slave的端口号是6380

    redis 127.0.0.1:6380> slaveof 127.0.0.1 6379 #我们假设MasterSlave在同一台主机,Master的端口为6379

    OK

重新启动之后,他们之间的复制关系将终止。

的配置文件中做如下修改:

    /> cd /etc/redis  #切换Redis服务器配置文件所在的目录。

    /> ls

    6379.conf  6380.conf

    /> vi 6380.conf

    # slaveof

改为

slaveof 127.0.0.1 6379

保存退出。

   

四、应用示例:

已经建立。

服务器。

    [root@Stephen-PC redis]# redis-cli -p 6379

    redis 127.0.0.1:6379>

    redis 127.0.0.1:6379> flushdb

    OK

作为测试数据。

    redis 127.0.0.1:6379> set mykey hello

    OK

    redis 127.0.0.1:6379> set mykey2 world

    OK

    redis 127.0.0.1:6379> keys *

    1) "mykey"

    2) "mykey2"

    

服务器。

    [root@Stephen-PC redis]# redis-cli -p 6380

中一致,从结果看,他们是相等的。

    redis 127.0.0.1:6380> keys *

    1) "mykey"

    2) "mykey2"

    

,并查看删除后的结果。

    redis 127.0.0.1:6379> del mykey2

    (integer) 1

    redis 127.0.0.1:6379> keys *

    1) "mykey"

    

中被删除。

    redis 127.0.0.1:6380> keys *

的持久化

提供了哪些持久化机制:

1). RDB持久化:该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。    

2). AOF持久化:该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。

3). 无持久化:我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了。

4). 同时应用AOFRDB。    

机制的优势和劣势:

存在哪些优势呢?

1). 一旦采用该方式,那么你的整个天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。

2). 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。

又存在哪些劣势呢?

1). 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

机制的优势和劣势:

的优势有哪些呢?

1). 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大,Redis可以自动启用切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。

的劣势有哪些呢?

1). 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。

2). 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

四、其它:

1. Snapshotting:缺省情况下,Redis会将数据集的快照dumpdump.rdb文件中。此外,我们也可以通过配置文件来修改Redis服务器dump快照的频率,在打开6379.conf文件之后,我们搜索save,可以看到下面的配置信息:

save 900 1           #900(15分钟)之后,如果至少有1key发生变化,则dump内存快照。

save 300 10          #300(5分钟)之后,如果至少有10key发生变化,则dump内存快照。

save 60 10000        #60(1分钟)之后,如果至少有10000key发生变化,则dump内存快照。

2. Dump快照的机制:

1). Redis子进程。

2). 子进程将快照数据写入到临时RDB文件中。

3). 当子进程完成数据写入操作后,再用临时文件替换老的文件。

3. AOF文件:上面已经多次讲过,RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点,我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言,其缺省的机制是RDB,如果需要使用AOF,则需要修改配置文件中的以下条目:

将appendonly no改为appendonly yes

从现在起,Redis在每一次接收到数据修改的命令之后,都会将其追加到AOF文件中。在Redis下一次重新启动时,需要加载AOF文件中的信息来构建最新的数据到内存中。

4. AOF的配置:

在Redis的配置文件中存在三种同步方式,它们分别是:

appendfsync always     #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec  #每秒钟同步一次,该策略为AOF的缺省策略。

appendfsync no          #从不同步。高效但是数据不会被持久化。

5. 如何修复坏损的AOF文件:

1). 将现有已经坏损的AOF文件额外拷贝出来一份。

2). 执行"redis-check-aof --fix "命令来修复坏损的AOF文件。

3). 用修复后的AOF文件重新启动Redis服务器。

6. Redis的数据备份:

在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中,之后在利用cron job的方式定时备份Redis的数据文件,并将备份文件copy到安全的磁盘介质中。  

的虚拟内存   

一、简介:

和大多NoSQL数据库一样,Redis同样遵循了Key/Value数据存储模型。在有些情况下,Redis会将Keys/Values保存在内存中以提高数据查询和数据修改的效率,然而这样的做法并非总是很好的选择。鉴于此,我们可以将之进一步优化,即尽量在内存中只保留Keys的数据,这样可以保证数据检索的效率,而Values数据在很少使用的时候则可以被换出到磁盘。在实际的应用中,大约只有10%Keys属于相对比较常用的键,这样Redis就可以通过虚存将其余不常用的KeysValues换出到磁盘上,而一旦这些被换出的KeysValues需要被读取时,Redis则将其再次读回到主内存中。

二、应用场景:

对于大多数数据库而言,最为理想的运行方式就是将所有的数据都加载到内存中,而之后的查询操作则可以完全基于内存数据完成。然而在现实中这样的场景却并不普遍,更多的情况则是只有部分数据可以被加载到内存中。在Redis中,有一个非常重要的概念,即keys一般不会被交换,所以如果你的数据库中有大量的keys,其中每个key仅仅关联很小的value,那么这种场景就不是非常适合使用虚拟内存。如果恰恰相反,数据库中只是包含少量的keys,而每一个key所关联的value却非常大,那么这种场景对于使用虚存就再合适不过了。在实际的应用中,为了能让虚存更为充分的发挥作用以帮助我们提高系统的运行效率,我们可以将带有很多较小值的Keys合并为带有少量较大值的Keys。其中最主要的方法就是将原有的Key/Value模式改为基于Hash的模式,这样可以让很多原来的Keys成为Hash中的属性。

三、配置:

1). 在配置文件中添加以下配置项,以使当前Redis服务器在启动时打开虚存功能。

vm-enabled yes

2). 在配置文件中设定Redis最大可用的虚存字节数。如果内存中的数据大于该值,则有部分对象被换出到磁盘中,其中被换出对象所占用内存将被释放,直到已用内存小于该值时才停止换出。

vm-max-memory (bytes)

使用,以避免频繁的换入换出。

3). 在配置文件中设定页的数量及每一页所占用的字节数。为了将内存中的数据传送到磁盘上,我们需要使用交换文件。这些文件与数据持久性无关,Redis会在退出前会将它们全部删除。由于对交换文件的访问方式大多为随机访问,因此建议将交换文件存储在固态磁盘上,这样可以大大提高系统的运行效率。

vm-pages 134217728

vm-page-size 32    

在上面的配置中,Redis将交换文件划分为vm-pages个页,其中每个页所占用的字节为vm-page-size,那么Redis最终可用的交换文件大小为:vm-pages * vm-page-size。由于一个value可以存放在一个或多个页上,但是一个页不能持有多个value,鉴于此,我们在设置vm-page-size时需要充分考虑Redis的该特征。

4). Redis的配置文件中有一个非常重要的配置参数,即:

vm-max-threads 4

该参数表示Redis在对交换文件执行IO操作时所应用的最大线程数量。通常而言,我们推荐该值等于主机的CPU cores。如果将该值设置为0,那么Redis在与交换文件进行IO交互时,将以同步的方式执行此操作。对于Redis而言,如果操作交换文件是以同步的方式进行,那么当某一客户端正在访问交换文件中的数据时,其它客户端如果再试图访问交换文件中的数据,该客户端的请求就将被挂起,直到之前的操作结束为止。特别是在相对较慢或较忙的磁盘上读取较大的数据值时,这种阻塞所带来的影响就更为突兀了。然而同步操作也并非一无是处,事实上,从全局执行效率视角来看,同步方式要好于异步方式,毕竟同步方式节省了线程切换、线程间同步,以及线程拉起等操作产生的额外开销。特别是当大部分频繁使用的数据都可以直接从主内存中读取时,同步方式的表现将更为优异。如果你的现实应用恰恰相反,即有大量的换入换出操作,同时你的系统又有很多的cores,有鉴于此,你又不希望客户端在访问交换文件之前不得不阻塞一小段时间,如果确实是这样,我想异步方式可能更适合于你的系统。至于最终选用哪种配置方式,最好的答案将来自于不断的实验和调优。    

的服务器管理

一、概述:

CONFIG SET/GET command

二、相关命令列表:

命令原型 时间复杂度 命令描述 返回值

CONFIG GET parameter 主要用于读取服务器的运行时参数,但是并不是所有的配置参数都可以通过该命令进行读取。其中该命令的参数接受glob风格的模式匹配规则,因此如果参数中包含模式元字符,那么所有匹配的参数都将以key/value方式被列出。如果参数是*,那么该命令支持的所有参数都将被列出。最后需要指出的是,和redis.conf中不同的是,在命令中不能使用数量缩写格式,如GBKB等,只能使用表示字节数量的整数值。  

CONFIG SET parameter value CONFIG GET * 命令的执行结果。如果想在一个命令中设置多个同类型参数,如redis.conf配置文件中的save参数:save 900 1/save 300 10。在该命令中我们可以将多个key/value用双引号括起,并用空格符隔开,如:config set save "900 1 300 10" 表示设置成功,否则返回相关的错误信息。

CONFIG RESETSTAT O(1) Reset INFO命令给出的统计数字。 始终返回OK

DBSIZE   返回当前打开的数据库中Keys的数量。 的数量。

FLUSHALL ,不仅限于当前打开的数据库。  

FLUSHDB

相关推荐

  • OC基础学习笔记总结 关于OC方面的基础笔记总结:#importintmain(intargc,constchar*argv[]){@autoreleasepool{//定义一个block类型的变量,打印N条线void(^myBlock)(int)=^(intn
  • 学习delphi笔记总结 一关于access1.使用ADO连接access的方法C:=ExtractFilePath(Application.ExeName);//exe文件路径DBS:='Provider=Microsoft.Jet.OLEDB.4.0;DataS
  • Ajax课堂笔记总结 一、jQuery概述主要提供如下功能 -访问页面框架的局部 -修改页面的表现 -更改页面的内容 -响应事件 -为页面添加动画 -与服务器异步交互 -简化常用的JavaScript操作二、基本选择器$(‘a’);//这个选择器匹配所有超链接元
  • Android学习笔记总结 http://download.chinaprj.cn/detail/rirrbBbE
  • 小汽车驾驶技术笔记总结(完美版 起步、停车要领、口诀:一、起步要领:1、上车,调整座椅,系安全带;2、打左转向灯,鸣喇叭,看周围情况(两侧倒车镜);3、快速踩离合器至底,挂1档,松手刹;4、快抬离合器于半联动位置稍停顿,然后慢抬离合器,同时配合慢加油门,车平稳起步。起步口
  • Shell笔记总结 ------------------------------------------------------------------------*/---------------------------------------------*
  • MongoDB学习笔记(五) MongoDB文件存取操作 MongoDB学习笔记(五)MongoDB文件存取操作  由于MongoDB的文档结构为BJSON格式(BJSON全称:BinaryJSON),而BJSON格式本身就支持保存二进制格式的数据,因此可以把文件的二进制格式的数据直接保存到Mon
  • HBase初步学习总结 HBase是啥?HBase是一个分布式的基于列存储的非关系型数据库。HBase的查询效率很高,主要由于查询和展示结果。利用HDFS作为文件存储系统,利用MR为其处理海量数据。利用zookeeper作为协调工具。简而言之,HBase就是had
  • [转载]MACD背离学习笔记与总结 原文地址:MACD背离学习笔记与总结作者:熊市猎手MACD背离学习笔记与总结背离的定义:所谓背离,最基本的要素就是,价格创新高/低,而指标却未在这个时候创出新高/低。价格的走势和指标的走势出现了一定的背驰(相反)现象。有时候甚至出现价格不断
  • 2016年心理学考研总结|相关研究优缺点,凯利的三维归因,知觉线索等心理学考研笔记 2016年心理学考研总结|相关研究优缺点,凯利的三维归因,知觉线索等心理学考研笔记最近在梳理普心中存在的阶段划分,大家来补充!梦5:4+1思维4:分析与综合、比较与归类、抽象与概括、具体化和系统化创造性思维4:准备、酝酿、豁朗、验证表征:图
  • 分享总结的几点网站快照不更新的因素_笔记seo 分享总结的几点网站快照不更新的因素_笔记seo  网站快照更新问题一直都是让广大站长特别头疼的一件事,为此,我们大量监控来访数据,判断快照更新规则及时间。我们知道,在优化关键字的过程中,很多优先更新快照的页面要比更新快照缓慢的页面占有优势。
  • 比苹果Mac薄的小米笔记本 笔记本天猫店 比苹果Mac薄的小米笔记本比苹果Mac薄的小米笔记本笔记本天猫店苹果笔记本,笔记本,ThinkPad,精做强,仿真近日,手机厂商小米在新品发布会上带来了进军笔记本市场的处女作——小米笔记本。从发布会上公布的产品参数来看,轻便或许成为了此款产

你的评论

就没有什么想说的吗?

©2017传客网    琼ICP备15003173号-2    

本站部分文章来源于互联网,版权归属于原作者。
本站所有转载文章言论不代表本站观点,如是侵犯了原作者的权利请发邮件联系站长(weishubao@126.com),我们收到后立即删除。
站内所有资源仅供学习与参考,请勿用于商业用途,否则产生的一切后果将由您自己承担!

X