HBase是一个基于Hadoop的分布式的、面向列的开源数据库，它以Google的BigTable为原型。

　　高可用性、高性能、列存储、可伸缩、实时读写。

　　完全分布式安装HBase是在完全分布式安装好Hadoop的基础上进行的。

　　HBase的版本和Hadoop的版本需要匹配得上，尽量不要选择最新的版本，应该选稳定版本的。

　　我这里用的是Hadoop-0.20.2和HBase-0.90.5。

　　以下操作在hadoop的namenode主节点上进行，在主节点上配置好之后，再复制到各个从节点。

1、下载并安装HBase

　　1）我这里把hbase-0.90.5.tar.gz放到/home/coder/目录下。

　　2）解压hbase-0.90.5.tar.gz到/home/coder/hbase-0.90.5/

2、配置hbase-env.sh文件

　　该文件在hbase-0.90.5/conf/目录下。

　　1）配置JDK安装目录

　　2）配置Hadoop安装目录

　　3）配置由HBase负责启动和关闭zookeeper

3、配置hbase-site.xml文件

　　该文件在hbase-0.90.5/conf/目录下，文件内容配置如下：

4、配置regionservers文件

　　该文件在hadoop-0.90.5/conf/目录下，我这里配置了两个从节点h2和h3作为Re

     日常开发中，总会接触到一些好玩的东西，比如这篇的redis，一说到redis，可能就有人跟memcache做比较了，是呀，

memcache只能说是简单的kv内存数据结构,而redis支持的数据类型就丰富多了，当然最能让人看上眼的就是SortedSet。

有了它，我们就可以玩一些“贪心”的问题，比如适合“贪心”的优先队列，说到优先队列，我们以前实现了仅仅是内存形式的，

哎，内存毕竟是内存，当有海量数据的时候，最好能有一个序列化到硬盘的操作。。。恰恰这个场景redis就可以办到。。。

一：快速搭建

    好了，我们知道redis比较适合做的事情了，现在我们可以进行快速搭建。

第一步：下载redis-2.0.2.zip (32 bit)。然后改名为redis放在D盘中。

最重要的也就是下面两个：

redis-server.exe：        这个就是redis的服务端程序。

redis-cli.exe：             服务端开启后，我们的客户端就可以输入各种命令测试了。

从图中我们可以看到两点：

①：没有指定config file。

     原来redis建议我们做一个配置文件，那我就搞段配置。

daemonize:  是否以“守护进程”的方式开启，当是守护进程的时候就不受控制台的影响了。

logfile:         log文件位置。

database:    开启数据库的个数。

dbfilename:  数据快照文件名。

save * *:     保存快照的频率，第一个为时间，第二个为写操作。

将这些配置好后，我们再看看：

②：我们看到redis默认的开放端口为6379。

二：安装驱动

好了，redis已经搭建完毕了，现在我们就要用C#去操作redis，这也是我最渴望的功能，优先队列~，先下载C#驱动，

就可以看到如下3个dll。

最后我们做下小测试：

 1     class Program 2     { 3         static void Main(string[] args) 4         { 5             var client = new RedisClient("127.0.0.1", 6379); 6  7             //最后一个参数为我们排序的依据 8             var s = client.AddItemToSortedSet("12", "百度", 400); 9 10             client.AddItemToSortedSet("12", "谷歌", 300);11             client.AddItemToSortedSet("12", "阿里", 200);12             client.AddItemToSortedSet("12", "新浪", 100);13             client.AddItemToSortedSet("12", "人人", 500);14 15             //升序获取最一个值:"新浪"16             var list = client.GetRangeFromSortedSet("12", 0, 0);17 18             foreach (var item in list)19             {20                 Console.WriteLine(item);21             }22 23             //降序获取最一个值:"人人"24             list = client.GetRangeFromSortedSetDesc("12", 0, 0);25 26             foreach (var item in list)27             {28                 Console.WriteLine(item);29             }30 31             Console.Read();32         }33     }

AddItemToSortedSet： 第三个参数也就是我们要排序的依据，这也非常适合我们做topK的问题，非常爽~

本文链接

    Tair是淘宝自主开发的一个分布式 key/value 存储系统。Tair 分为持久化和非持久化两种使用方式. 非持久化的 Tair 可以看成是一个分布式缓存. 持久化的 Tair 将数据存放于磁盘中. 为了解决磁盘损坏导致数据丢失, Tair 可以配置数据的备份数目, Tair 自动将一份数据的不同备份放到不同的主机上, 当有主机发生异常, 无法正常提供服务的时候, 其于的备份会继续提供服务.项目主页参见：淘宝Tair.

    受NoSQLFan上的一遍文章Redis监控技巧   一文的启发，本文系统的总结下我们在生产环境使用Tair时进行的各类监控和统计，希望对开源社区有所回馈。

    Tair最直接的监控和获取统计信息的方法是采用其提供的工具tairclient，按照如下方式使用，可以获取很多状态信息：

./sbin/tairclient -g group_1 -c tair_configserver_ip:port -l stat

• 配额信息
• dataserver存活信息
• 每个area(类似于namespace的信息)的dataSize，evictCount，getCount（per second），hitCount（per second），itemCount，putCount（per second），removeCount（per second），useSize信息
• 是否正在迁移（isMigrating false）
• group状态，代表是否有桶丢失（group_name status OK）

     对于上述信息有如下说明：

     1.dataSize和itemCount可能并不精确，参见“统计的itemcount问题”;

     2.dataSize、evictCount等，也可以通过tair_client_api.hpp的get_data_stat接口获取，可以进行更灵活的统计和计算；

     3.由于tair bucket的桶迁移并不常见，所以监控迁移状态作为一种预警非常有必要；

     4.监控group状态，如果不为OK，证明有bucket的所有副本均丢失，此时tair的configserver不会rebuild分配表，需要人工介入处理；

     服务状态监控

     使用客户端模拟客户请求，如果连续5次均失败，证明访问出现问题，需要报警。此处需要注意的是，构造的key必须是随机的。（因为根据tair的hash算法，同样的key会一直落到同一个bucket）；

     配置监控

     group.conf是由tair configserver使用，并自动在master slave间同步的配置文件。该文件有许多重要的信息，比如副本数、dataserver地址、area capacity等信息，可能经常需要手工进行修改。因此，为了保证严格一致，我们使用inotify结合rsync对group.conf的一致性进行监控，如果在任何状况下，发现master和slave的group.conf不一致，则报警。

     ldb level 0文件数目监控

     tair的ldb存储引擎使用的是google开源的leveldb，其level0的文件数会影响到读取性能（超过一定值，会减慢请求，甚至是挂起请求）。在tair出现大量bucket迁移时，有可能会出现level 0文件数骤增，因此需要对level 0文件数做监控，超过阈值报警。

     获取level 0文件数的方法非常简单，只需如下一行语句：

tac $log_file | grep -m 1 "compacted to:" | awk '{print $6}'

     $log_file是ldb目录下的LOG文件。

     内存级kv使用空间监控

     tair的内存级存储引擎类似于memcache，由于我们的业务方有部分是将内存级当作准存储在使用，所以有必要对内存级area的area使用的内存空间做监控，如果达到阈值（如设定capacity的80%）则给业务方报警，避免不必要的数据evict。

     thrift层面的监控

    为了方便多种语言的访问，同时为了进行管控，我们提供了thrift形式的访问接口，在thrift层面做了大量的工作。针对thrift，我们统计了不同db的访问量、占用空间、QPS、访问时延等数据，用来在访问质量出现下降时报警，同时每天发出统计报表。这个层面的报警统计可以和tair的统计配合使用。   

     bucket分布表和迁移状态

     Tair的桶分布表记录在configserver/data/目录下，使用cst_monitor工具，可以查看最新的桶分布表，同时在存在数据迁移时，可以查看最终生成的表，以及实时迁移表，使用这份数据，结合tairclient可以预估迁移进度。使用方式如下：

./cst_monitor ../configserverdir/data/group_1_server_table

     注：以上监控项，涉及到趋势的，均使用ganglia做前端，可以使用gmetric或自行编写插件，方便的将数据导入ganglia。ganglia还顺便用于分析cpu\memory\disk等的使用情况。

     除以上所述监控外，为了提高服务质量，便于迅速的定位问题，我们还在对ldb存储引擎内部进行剖析和监控，具体参见下图：

本文链接