谷歌4亿英镑收购人工智能公司DeepMind,百度目前正推进“百度大脑”项目,腾讯、阿里等各大巨头布局深度学习。随着社会化数据大量产生,硬件速度上升、成本降低,大数据技术的落地实现,让冷冰冰的数据具有智慧逐渐成为新的热点。要从数据中发现有用的信息就要用到数据挖掘技术,不过买来的数据挖掘书籍一打开全是大量的数学公式,而课本知识早已还给老师了,难以下手、非常头大!

我们可以跳过数学公式,先看看我们了解数据挖掘的目的:发现数据中价值。这个才是关键,如何发现数据中的价值。那什么是数据呢?比如大家要上网首先需要输入网址,打开网页后会自动判断哪些是图片、哪些是新闻、哪些是用户名称、游戏图标等。人大脑可以存储大量的信息,包括文字、声音、视频、图片等,每一个都可以转换数据存储在电脑。人的大脑可以根据输入自动进行判断,电脑可以通过输入判断吗?答案是肯定的! 不过需要我们编写程序来判断每一种信息,就拿文字识别来说吧,怎么从一个人在社交网络的言论判断他今天的心情是高兴还是愤怒!比如:“你假如上午没给我吃冰淇淋,我绝对会不happy的。” 信息发布时间为下午2点。对于我们人类一看这个句子就知道他是吃过冰淇淋了,心情肯定不会是愤怒。那计算机怎么知道呢?

这就是今天的主题,要让计算机理解句子的语义,必须要有个程序,上面的句子和发布时间是输入,输出就是 “高兴”。要得到“高兴”就要建立 “高兴”的规则,可以建一个感情色彩词库,比如 高兴(识别词是高兴、happy),愤怒(识别词是愤怒、生气)。这里的识别词就是输入中出现的词语,比如上面的句子中的“happy”就识别出了“高兴”这个感情色彩词。但是光识别出“happy”肯定是不行的,前面的“假如。。。没。。。,我。。。不。。。”等关键词都需要识别出来,才能完整判断一个句子的意思。为了达到这个效果,就必须要用分词技术了。

我们先人工对上面的句子来进行一下切词,使用斜线分割:“你/假如/上午/没/给/我/吃/冰淇淋/,/我/绝对/会/不/happy/的/。/”。但是程序如何做到自动切分?这个其实中国的前辈们已经做了很多中文分词的研究,常见的分词算法有:

1、基于词典的分词,需要先预设一个分词词典,比如上面句子切分出来的“假如、上午”这些词先存放在词典,然后把句子切分成单字组合成词语去词典里查找,匹配上了就挑选出来一个词。没有匹配上的就切分成单字。

2、基于统计的分词,需要先获取大量的文本语料库(比如新闻、微博等),然后统计文本里相邻的字同时出现的次数,次数越多就越可能构成一个词。当达到一定次数时就构成了一个词即可形成语料概率库。再对上面句子进行单字切分,把字与字结合后在语料概率库里查找对应的概率,如果概率大于一定值就挑选出来形成一个词。这个是大概描述,实际生产环境中还需要对句子的上下文进行结合才能更准确的分词。

3、基于语义的分词,简而言之就是模拟人类对句子的理解来进行分词。需要先整理出中文语句的句法、语义信息作为知识库,然后结合句子的上下文,对句子进行单字切分后组合成词逐个带入知识库进行识别,识别出来就挑选出一个词。目前还没有特别成熟的基于语义的分词系统。

为了让大家快速的了解分词技术,我们采用第一个方式来做测试:基于词典的分词,这种方式简单暴力可以解决百分之七八十的问题。基于词典的分词大概分为以下几种方式:

1、正向最大匹配,沿着我们看到的句子逐字拆分后组合成词语到词典里去匹配,直到匹配不到词语为止。举个实际的例子:“人民大会堂真雄伟”,我们先拆分为单字“人”去词典里去查找,发现有“人”这个词,继续组合句子里的单字组合“人民”去词典里查找,发现有“人民”这个词,以此类推发现到“人民大会堂”,然后会结合“人民大会堂真”去词典里查找没有找到这个词,第一个词“人民大会堂”查找结束。最终分词的结果为:“人民大会堂/真/雄伟”。

segment

2、逆向最大匹配,这个和上面相反,就是倒着推理。比如“沿海南方向”,我们按正向最大匹配来做就会切分成 “沿海/南方/向”,这样就明显不对。采用逆向最大匹配法则来解决这个问题,从句子的最后取得“方向”这两个字查找词典找到“方向”这个词。再加上“南方向”组成三字组合查找词典没有这个词,查找结束,找到“方向”这个词。以此类推,最终分出“沿/海南/方向”。

3、双向最大匹配,顾名思义就是结合正向最大匹配和逆向最大匹配,最终取其中合理的结果。最早由哈工大王晓龙博士理论化的取最小切分词数,比如“我在中华人民共和国家的院子里看书”,正向最大匹配切分出来为“我/在/中华人民共和国/家/的/院子/里/看书”工8个词语,逆向最大匹配切分出来为“我/在/中华/人民/共/和/国家/的/院子/里/看书”共11个词语。取正向最大匹配切出来的结果就是正确的。但是如果把上面那个例子“沿海南方向”双向切分,都是3个词语,改如何选择?看第4个《最佳匹配法则》。

4、最佳匹配法则,先准备一堆文本语料库、一个词库,统计词库里的每一个词在语料库里出现的次数记录下来。最后按照词频高的优先选出,比如“沿海南方向”,正向切分为:“沿海/南方/向”,逆向切分为:“沿/海南/方向”。其中“海南”的频度最高,优先取出来。剩下“沿”、“方向”也就正常切分了。是不是这就是基于词典分词的最佳方案?比如数学之美中提到的:“把手抬起来” 和 “这扇门的把手”,可以分为“把”、“手”、“把手”,不管怎么分总有一句话的意思不对。后续再介绍如何通过统计的分词处理这些问题。

说了这么多,我们来实战一下如何基于词典的分词:

public class TestPositiveMatch {
    public static void main(String[] args) {
        String str = "我爱这个中华人民共和国大家庭";
        List<String> normalDict = new ArrayList<String>();

        normalDict.add("");
        normalDict.add("爱");
        normalDict.add("中华");   //测试词库里有中华和中华人民共和国,按照最大匹配应该匹配出中华人民共和国
        normalDict.add("中华人民共和国");

        int strLen = str.length();  //传入字符串的长度
        int j = 0;
        String matchWord = ""; //根据词库里识别出来的词
        int matchPos = 0; //根据词库里识别出来词后当前句子中的位置
        while (j < strLen) {      //从0字符匹配到字符串结束
            int matchPosTmp = 0;   //截取字符串的位置
            int i = 1;
            while (matchPosTmp < strLen) {   //从当前位置直到整句结束,匹配最大长度
                matchPosTmp = i + j;
                String keyTmp = str.substring(j, matchPosTmp);//切出最大字符串
                if (normalDict.contains(keyTmp)) { //判断当前字符串是否在词典中
                    matchWord = keyTmp;  //如果在词典中匹配上了就赋值
                    matchPos = matchPosTmp; //同时保存好匹配位置
                }
                i++;
            }
            if (!matchWord.isEmpty()) {
                //有匹配结果就输出最大长度匹配字符串
                j = matchPos;
                //保存位置,下次从当前位置继续往后截取
                System.out.print(matchWord + " ");
            } else {
                //从当前词开始往后都没有能够匹配上的词,则按照单字切分的原则切分
                System.out.print(str.substring(j, ++j) + " ");
            }
            matchWord = "";
        }
    }
}

输出结果为: 我 爱 这 个 中华人民共和国 大 家 庭

按照这样我们一个基本的分词程序开发完成。

对于文章一开始提到的问题还没解决,如何让程序识别文本中的感情色彩。现在我们先要构建一个感情色彩词库“高兴”,修饰词库“没”、”不”。再完善一下我们的程序:

public class TestSentimentPositiveMatch {
    public static void main(String[] args) {
        String str = "你假如上午没给我吃冰淇淋,我绝对会不happy的。";

        //语义映射
        Map<String, String> sentimentMap = new HashMap<String, String>();
        sentimentMap.put("happy", "高兴");

        //情感词库
        List<String> sentimentDict = new ArrayList<String>();
        sentimentDict.add("happy");

        //修饰词
        List<String> decorativeDict = new ArrayList<String>();
        decorativeDict.add("不");
        decorativeDict.add("没");

        //修饰词衡量分数
        Map<String, Double> decorativeScoreMap = new HashMap<String, Double>();
        decorativeScoreMap.put("不", -0.5);
        decorativeScoreMap.put("没", -0.5);

        List<String> decorativeWordList = new ArrayList<String>();  //修饰词
        String sentimentResult = ""; //情感结果

        int strLen = str.length();  //传入字符串的长度
        int j = 0;
        String matchSentimentWord = ""; //根据词库里识别出来的情感词
        String matchDecorativeWord = ""; //根据词库里识别出来的修饰词
        int matchPos = 0; //根据词库里识别出来词后当前句子中的位置
        while (j < strLen) {      //从0字符匹配到字符串结束
            int matchPosTmp = 0;   //截取字符串的位置
            int i = 1;
            while (matchPosTmp < strLen) {   //从当前位置直到整句结束,匹配最大长度
                matchPosTmp = i + j;
                String keyTmp = str.substring(j, matchPosTmp);//切出最大字符串
                if (sentimentDict.contains(keyTmp)) { //判断当前字符串是否在词典中
                    matchSentimentWord = keyTmp;  //如果在词典中匹配上了就赋值
                    matchPos = matchPosTmp; //同时保存好匹配位置
                }
                if (decorativeDict.contains(keyTmp)) { //判断当前字符串是否在词典中
                    matchDecorativeWord = keyTmp;  //如果在词典中匹配上了就赋值
                    matchPos = matchPosTmp; //同时保存好匹配位置
                }
                i++;
            }
            if (!matchSentimentWord.isEmpty()) {
                //有匹配结果就输出最大长度匹配字符串
                j = matchPos;
                //保存位置,下次从当前位置继续往后截取
                System.out.print(matchSentimentWord + " ");
                sentimentResult = sentimentMap.get(matchSentimentWord);
            }
            if (!matchDecorativeWord.isEmpty()) {
                //有匹配结果就输出最大长度匹配字符串
                j = matchPos;
                //保存位置,下次从当前位置继续往后截取
                System.out.print(matchDecorativeWord + " ");
                decorativeWordList.add(matchDecorativeWord);
            } else {
                //从当前词开始往后都没有能够匹配上的词,则按照单字切分的原则切分
                System.out.print(str.substring(j, ++j) + " ");
            }
            matchSentimentWord = "";
            matchDecorativeWord = "";
        }

        double totalScore = 1;
        for (String decorativeWord : decorativeWordList) {
            Double scoreTmp = decorativeScoreMap.get(decorativeWord);
            totalScore *= scoreTmp;
        }

        System.out.print("\r\n");
        if (totalScore > 0) {
            System.out.println("当前心情是:" + sentimentResult);
        } else {
            System.out.println("当前心情是:不" + sentimentResult);
        }
    }
}

通过传入“你假如上午没给我吃冰淇淋,我绝对会不happy的。”,结果输出为:“当前心情是:高兴”。当然你也可以改变其中的修饰词,比如改为:“你假如上午没给我吃冰淇淋,我绝对会happy的。”,结果输出为:“当前心情是:不高兴”。

机器再也不是冷冰冰的,看起来他能读懂你的意思了。不过这只是一个开始,抛出几个问题:

1、如何让程序识别句子中的时间?比如“上午”、“下午2点”。
2、如何处理“把手抬起来” 和 “这扇门的把手”中的“把”与“手”的问题?
3、如何构建海量的知识库,让程序从“婴儿”变成“成年人”?
4、如何使用有限的存储空间海量的知识库?
5、如何提高程序在海量知识库中查找定位信息的效率?
6、如何识别新词、人名、新鲜事物等未知领域?

univers_brain

这是《纽约时报》刊登的2张照片,一张是老鼠的脑细胞(左),一张是宇宙(右)。早期宇宙中星系互连关系,和大脑神经元相互连接,几乎无法分辨两张图之间的不同,大脑细胞与整个宇宙拥有一样的结构。

宇宙芸芸众生都是相通的,大脑也许就是一个小宇宙,在这个小宇宙又有很多星球、住着很多生物。而电脑也是宇宙中地球上的一个产物,只要存储计算速度发展到足够强大一定可以构建成一个强大的大脑。

你看这个单词 “testaword” 认识吗?可能不认识,因为我们五官先获取到的信息,然后根据大脑以往学习的经验做出判断。但是你看这个短语 ” test a word” 认识吗?再看看开始那个单词“testaword”是不是就亲切多了?

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 数据挖掘-分词入门

按照上一节中《搭建高可用mongodb集群(三)—— 深入副本集》搭建后还有两个问题没有解决:

  • 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大?
  • 数据压力大到机器支撑不了的时候能否做到自动扩展?

在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的。而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题。

传统数据库怎么做海量数据读写?其实一句话概括:分而治之。上图看看就清楚了,如下 taobao岳旭强在infoq中提到的 架构图:

fenpian1

上图中有个TDDL,是taobao的一个数据访问层组件,他主要的作用是SQL解析、路由处理。根据应用的请求的功能解析当前访问的sql判断是在哪个业务数据库、哪个表访问查询并返回数据结果。具体如图:

fenpian2

说了这么多传统数据库的架构,那Nosql怎么去做到了这些呢?mysql要做到自动扩展需要加一个数据访问层用程序去扩展,数据库的增加、删除、备份还需要程序去控制。一但数据库的节点一多,要维护起来也是非常头疼的。不过mongodb所有的这一切通过他自己的内部机制就可以搞定!顿时石化了,这么牛X!还是上图看看mongodb通过哪些机制实现路由、分片:

fenpian3

从图中可以看到有四个组件:mongos、config server、shard、replica set。

mongos,数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口,防止其中一个挂掉所有的mongodb请求都没有办法操作。

config server,顾名思义为配置服务器,存储所有数据库元信息(路由、分片)的配置。mongos本身没有物理存储分片服务器和数据路由信息,只是缓存在内存里,配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息,以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态,这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器,因为它存储了分片路由的元数据,这个可不能丢失!就算挂掉其中一台,只要还有存货, mongodb集群就不会挂掉。

shard,这就是传说中的分片了。上面提到一个机器就算能力再大也有天花板,就像军队打仗一样,一个人再厉害喝血瓶也拼不过对方的一个师。俗话说三个臭皮匠顶个诸葛亮,这个时候团队的力量就凸显出来了。在互联网也是这样,一台普通的机器做不了的多台机器来做,如下图:

fenpian4

一台机器的一个数据表 Collection1 存储了 1T 数据,压力太大了!在分给4个机器后,每个机器都是256G,则分摊了集中在一台机器的压力。也许有人问一台机器硬盘加大一点不就可以了,为什么要分给四台机器呢?不要光想到存储空间,实际运行的数据库还有硬盘的读写、网络的IO、CPU和内存的瓶颈。在mongodb集群只要设置好了分片规则,通过mongos操作数据库就能自动把对应的数据操作请求转发到对应的分片机器上。在生产环境中分片的片键可要好好设置,这个影响到了怎么把数据均匀分到多个分片机器上,不要出现其中一台机器分了1T,其他机器没有分到的情况,这样还不如不分片!

replica set,上两节已经详细讲过了这个东东,怎么这里又来凑热闹!其实上图4个分片如果没有 replica set 是个不完整架构,假设其中的一个分片挂掉那四分之一的数据就丢失了,所以在高可用性的分片架构还需要对于每一个分片构建 replica set 副本集保证分片的可靠性。生产环境通常是 2个副本 + 1个仲裁。

说了这么多,还是来实战一下如何搭建高可用的mongodb集群:

首先确定各个组件的数量,mongos 3个, config server 3个,数据分3片 shard server 3个,每个shard 有一个副本一个仲裁也就是 3 * 2 = 6 个,总共需要部署15个实例。这些实例可以部署在独立机器也可以部署在一台机器,我们这里测试资源有限,只准备了 3台机器,在同一台机器只要端口不同就可以,看一下物理部署图:

fenpian5

架构搭好了,安装软件!

  • 1、准备机器,IP分别设置为: 192.168.0.136、192.168.0.137、192.168.0.138。
  • 2、分别在每台机器上建立mongodb分片对应测试文件夹。
    #存放mongodb数据文件
    mkdir -p /data/mongodbtest
    
    #进入mongodb文件夹
    cd  /data/mongodbtest
    
  • 3、下载mongodb的安装程序包
    wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.4.8.tgz
    
    
    #解压下载的压缩包
    tar xvzf mongodb-linux-x86_64-2.4.8.tgz
    
  • 4、分别在每台机器建立mongos 、config 、 shard1 、shard2、shard3 五个目录。
    因为mongos不存储数据,只需要建立日志文件目录即可。

               #建立mongos目录
               mkdir -p /data/mongodbtest/mongos/log
    
               #建立config server 数据文件存放目录
               mkdir -p /data/mongodbtest/config/data
    
               #建立config server 日志文件存放目录
               mkdir -p /data/mongodbtest/config/log
    
               #建立config server 日志文件存放目录
               mkdir -p /data/mongodbtest/mongos/log
    
               #建立shard1 数据文件存放目录
               mkdir -p /data/mongodbtest/shard1/data
    
               #建立shard1 日志文件存放目录
               mkdir -p /data/mongodbtest/shard1/log
    
               #建立shard2 数据文件存放目录
               mkdir -p /data/mongodbtest/shard2/data
    
    #建立shard2 日志文件存放目录
    mkdir -p /data/mongodbtest/shard2/log
    
    #建立shard3 数据文件存放目录
    mkdir -p /data/mongodbtest/shard3/data
    
    #建立shard3 日志文件存放目录
    mkdir -p /data/mongodbtest/shard3/log
    
  • 5、规划5个组件对应的端口号,由于一个机器需要同时部署 mongos、config server 、shard1、shard2、shard3,所以需要用端口进行区分。
    这个端口可以自由定义,在本文 mongos为 20000, config server 为 21000, shard1为 22001 , shard2为22002, shard3为22003.
  • 6、在每一台服务器分别启动配置服务器。
                 /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --configsvr --dbpath /data/mongodbtest/config/data --port 21000 --logpath /data/mongodbtest/config/log/config.log --fork
    
  • 7、在每一台服务器分别启动mongos服务器。
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongos  --configdb 192.168.0.136:21000,192.168.0.137:21000,192.168.0.138:21000  --port 20000   --logpath  /data/mongodbtest/mongos/log/mongos.log --fork
    
  • 8、配置各个分片的副本集。
    #在每个机器里分别设置分片1服务器及副本集shard1
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard1 --port 22001 --dbpath /data/mongodbtest/shard1/data  --logpath /data/mongodbtest/shard1/log/shard1.log --fork --nojournal  --oplogSize 10
    

    为了快速启动并节约测试环境存储空间,这里加上 nojournal 是为了关闭日志信息,在我们的测试环境不需要初始化这么大的redo日志。同样设置 oplogsize是为了降低 local 文件的大小,oplog是一个固定长度的 capped collection,它存在于”local”数据库中,用于记录Replica Sets操作日志。注意,这里的设置是为了测试!

    #在每个机器里分别设置分片2服务器及副本集shard2
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard2 --port 22002 --dbpath /data/mongodbtest/shard2/data  --logpath /data/mongodbtest/shard2/log/shard2.log --fork --nojournal  --oplogSize 10
    
     
    #在每个机器里分别设置分片3服务器及副本集shard3 
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard3 --port 22003 --dbpath /data/mongodbtest/shard3/data  --logpath /data/mongodbtest/shard3/log/shard3.log --fork --nojournal  --oplogSize 10
    

    分别对每个分片配置副本集,深入了解副本集参考本系列前几篇文章。

    任意登陆一个机器,比如登陆192.168.0.136,连接mongodb

               
    #设置第一个分片副本集
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo  127.0.0.1:22001
    
                        
    #使用admin数据库
    use admin
    
    #定义副本集配置
    config = { _id:"shard1", members:[
                         {_id:0,host:"192.168.0.136:22001"},
                         {_id:1,host:"192.168.0.137:22001"},
                         {_id:2,host:"192.168.0.138:22001",arbiterOnly:true}
                    ]
             }
    
    #初始化副本集配置
    rs.initiate(config);
    
     
    #设置第二个分片副本集
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo  127.0.0.1:22002
    
                         
    #使用admin数据库
    use admin
    
     
    #定义副本集配置
    config = { _id:"shard2", members:[
                         {_id:0,host:"192.168.0.136:22002"},
                         {_id:1,host:"192.168.0.137:22002"},
                         {_id:2,host:"192.168.0.138:22002",arbiterOnly:true}
                    ]
             }
    
     
    #初始化副本集配置
    rs.initiate(config);
    
    #设置第三个分片副本集
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo    127.0.0.1:22003
    
                         
    #使用admin数据库
    use admin
    
     
    #定义副本集配置
    config = { _id:"shard3", members:[
                         {_id:0,host:"192.168.0.136:22003"},
                         {_id:1,host:"192.168.0.137:22003"},
                         {_id:2,host:"192.168.0.138:22003",arbiterOnly:true}
                    ]
             }
    
    #初始化副本集配置
    rs.initiate(config);
    
  • 9、目前搭建了mongodb配置服务器、路由服务器,各个分片服务器,不过应用程序连接到 mongos 路由服务器并不能使用分片机制,还需要在程序里设置分片配置,让分片生效。
    #连接到mongos
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo  127.0.0.1:20000
    
    #使用admin数据库
    user  admin
    
     
    #串联路由服务器与分配副本集1
    db.runCommand( { addshard : "shard1/192.168.0.136:22001,192.168.0.137:22001,192.168.0.138:22001"});
    

    如里shard是单台服务器,用 db.runCommand( { addshard : “[: ]” } )这样的命令加入,如果shard是副本集,用db.runCommand( { addshard : “replicaSetName/[:port][,serverhostname2[:port],…]” });这样的格式表示 。

    #串联路由服务器与分配副本集2
    db.runCommand( { addshard : "shard2/192.168.0.136:22002,192.168.0.137:22002,192.168.0.138:22002"});
    
    #串联路由服务器与分配副本集3
    db.runCommand( { addshard : "shard3/192.168.0.136:22003,192.168.0.137:22003,192.168.0.138:22003"});
    
    #查看分片服务器的配置
    db.runCommand( { listshards : 1 } );
    

    #内容输出

            {
                     "shards" : [
                            {
                                    "_id" : "shard1",
                                    "host" : "shard1/192.168.0.136:22001,192.168.0.137:22001"
                            },
                            {
                                    "_id" : "shard2",
                                    "host" : "shard2/192.168.0.136:22002,192.168.0.137:22002"
                            },
                            {
                                    "_id" : "shard3",
                                    "host" : "shard3/192.168.0.136:22003,192.168.0.137:22003"
                            }
                    ],
                    "ok" : 1
            }

    因为192.168.0.138是每个分片副本集的仲裁节点,所以在上面结果没有列出来。

  • 10、目前配置服务、路由服务、分片服务、副本集服务都已经串联起来了,但我们的目的是希望插入数据,数据能够自动分片,就差那么一点点,一点点。。。

    连接在mongos上,准备让指定的数据库、指定的集合分片生效。

    #指定testdb分片生效
    db.runCommand( { enablesharding :"testdb"});
    #指定数据库里需要分片的集合和片键
    db.runCommand( { shardcollection : "testdb.table1",key : {id: 1} } )

    我们设置testdb的 table1 表需要分片,根据 id 自动分片到 shard1 ,shard2,shard3 上面去。要这样设置是因为不是所有mongodb 的数据库和表 都需要分片!

  • 11、测试分片配置结果。
    #连接mongos服务器
    /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo  127.0.0.1:20000
    #使用testdb
    use  testdb;
     
    #插入测试数据
    for (var i = 1; i <= 100000; i++) 
    db.table1.save({id:i,"test1":"testval1"});
     
    #查看分片情况如下,部分无关信息省掉了
    db.table1.stats();
                  {
                          "sharded" : true,
                          "ns" : "testdb.table1",
                          "count" : 100000,
                          "numExtents" : 13,
                          "size" : 5600000,
                          "storageSize" : 22372352,
                          "totalIndexSize" : 6213760,
                          "indexSizes" : {
                                  "_id_" : 3335808,
                                  "id_1" : 2877952
                          },
                          "avgObjSize" : 56,
                          "nindexes" : 2,
                          "nchunks" : 3,
                          "shards" : {
                                  "shard1" : {
                                          "ns" : "testdb.table1",
                                          "count" : 42183,
                                          "size" : 0,
                                          ...
                                          "ok" : 1
                                  },
                                  "shard2" : {
                                          "ns" : "testdb.table1",
                                          "count" : 38937,
                                          "size" : 2180472,
                                          ...
                                          "ok" : 1
                                  },
                                  "shard3" : {
                                          "ns" : "testdb.table1",
                                          "count" :18880,
                                          "size" : 3419528,
                                          ...
                                          "ok" : 1
                                  }
                          },
                          "ok" : 1
                  }
    

    可以看到数据分到3个分片,各自分片数量为: shard1 “count” : 42183,shard2 “count” : 38937,shard3 “count” : 18880。已经成功了!不过分的好像不是很均匀,所以这个分片还是很有讲究的,后续再深入讨论。

  • 12、java程序调用分片集群,因为我们配置了三个mongos作为入口,就算其中哪个入口挂掉了都没关系,使用集群客户端程序如下:
    public class TestMongoDBShards {
    
           public static void main(String[] args) {
    
                 try {
                      List<ServerAddress> addresses = new ArrayList<ServerAddress>();
                      ServerAddress address1 = new ServerAddress("192.168.0.136" , 20000);
                      ServerAddress address2 = new ServerAddress("192.168.0.137" , 20000);
                      ServerAddress address3 = new ServerAddress("192.168.0.138" , 20000);
                      addresses.add(address1);
                      addresses.add(address2);
                      addresses.add(address3);
    
                      MongoClient client = new MongoClient(addresses);
                      DB db = client.getDB( "testdb" );
                      DBCollection coll = db.getCollection( "table1" );
    
                      BasicDBObject object = new BasicDBObject();
                      object.append( "id" , 1);
    
                      DBObject dbObject = coll.findOne(object);
    
                      System. out .println(dbObject);
    
                } catch (Exception e) {
                      e.printStackTrace();
                }
          }
    }
    
    

整个分片集群搭建完了,思考一下我们这个架构是不是足够好呢?其实还有很多地方需要优化,比如我们把所有的仲裁节点放在一台机器,其余两台机器承担了全部读写操作,但是作为仲裁的192.168.0.138相当空闲。让机器3 192.168.0.138多分担点责任吧!架构可以这样调整,把机器的负载分的更加均衡一点,每个机器既可以作为主节点、副本节点、仲裁节点,这样压力就会均衡很多了,如图:

fenpian6

当然生产环境的数据远远大于当前的测试数据,大规模数据应用情况下我们不可能把全部的节点像这样部署,硬件瓶颈是硬伤,只能扩展机器。要用好mongodb还有很多机制需要调整,不过通过这个东东我们可以快速实现高可用性、高扩展性,所以它还是一个非常不错的Nosql组件。

再看看我们使用的mongodb java 驱动客户端 MongoClient(addresses),这个可以传入多个mongos 的地址作为mongodb集群的入口,并且可以实现自动故障转移,但是负载均衡做的好不好呢?打开源代码查看:

fenpian7

它的机制是选择一个ping 最快的机器来作为所有请求的入口,如果这台机器挂掉会使用下一台机器。那这样。。。。肯定是不行的!万一出现双十一这样的情况所有请求集中发送到这一台机器,这台机器很有可能挂掉。一但挂掉了,按照它的机制会转移请求到下台机器,但是这个压力总量还是没有减少啊!下一台还是可能崩溃,所以这个架构还有漏洞!不过这个文章已经太长了,后续解决吧。

参考:
http://docs.mongodb.org/manual/core/sharding-introduction/

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 搭建高可用mongodb集群(四)—— 分片

在上一篇文章《搭建高可用mongodb集群(二)—— 副本集》 介绍了副本集的配置,这篇文章深入研究一下副本集的内部机制。还是带着副本集的问题来看吧!

  • 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点。
  • 官方说副本集数量最好是奇数,为什么?
  • mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性?
  • mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重?

Bully算法 mongodb副本集故障转移功能得益于它的选举机制。选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点。一个分布式集群架构中一般都有一个所谓的主节点,可以有很多用途,比如缓存机器节点元数据,作为集群的访问入口等等。主节点有就有吧,我们干嘛要什么Bully算法?要明白这个我们先看看这两种架构:

  1. 指定主节点的架构,这种架构一般都会申明一个节点为主节点,其他节点都是从节点,如我们常用的mysql就是这样。但是这样架构我们在第一节说了整个集群如果主节点挂掉了就得手工操作,上架一个新的主节点或者从从节点恢复数据,不太灵活。

    mongodb4

  2. 不指定主节点,集群中的任意节点都可以成为主节点。mongodb也就是采用这种架构,一但主节点挂了其他从节点自动接替变成主节点。如下图:

    mongodb故障转移

好了,问题就在这个地方,既然所有节点都是一样,一但主节点挂了,怎么选择出来下一个节点是谁来做为主节点呢?这就是Bully算法解决的问题。

那什么是Bully算法,Bully算法是一种协调者(主节点)竞选算法,主要思想是集群的每个成员都可以声明它是主节点并通知其他节点。别的节点可以选择接受这个声称或是拒绝并进入主节点竞争。被其他所有节点接受的节点才能成为主节点。节点按照一些属性来判断谁应该胜出。这个属性可以是一个静态ID,也可以是更新的度量像最近一次事务ID(最新的节点会胜出)。详情请参考NoSQL数据库分布式算法的协调者竞选还有维基百科的解释

选举 那mongodb是怎进行选举的呢?官方这么描述:

We use a consensus protocol to pick a primary. Exact details will be spared here but that basic process is:

  1. get maxLocalOpOrdinal from each server.
  2. if a majority of servers are not up (from this server’s POV), remain in Secondary mode and stop.
  3. if the last op time seems very old, stop and await human intervention.
  4. else, using a consensus protocol, pick the server with the highest maxLocalOpOrdinal as the Primary.

大致翻译过来为使用一致协议选择主节点。基本步骤为:

  1. 得到每个服务器节点的最后操作时间戳。每个mongodb都有oplog机制会记录本机的操作,方便和主服务器进行对比数据是否同步还可以用于错误恢复。
  2. 如果集群中大部分服务器down机了,保留活着的节点都为 secondary状态并停止,不选举了。
  3. 如果集群中选举出来的主节点或者所有从节点最后一次同步时间看起来很旧了,停止选举等待人来操作。
  4. 如果上面都没有问题就选择最后操作时间戳最新(保证数据是最新的)的服务器节点作为主节点。

这里提到了一个一致协议(其实就是bully算法),这个和数据库的一致性协议还是有些区别,一致协议主要强调的是通过一些机制保证大家达成共识;而一致性协议强调的是操作的顺序一致性,比如同时读写一个数据会不会出现脏数据。一致协议在分布式里有一个经典的算法叫“Paxos算法”,后续再介绍。

上面有个问题,就是所有从节点的最后操作时间都是一样怎么办?就是谁先成为主节点的时间最快就选谁。

选举触发条件 选举不是什么时刻都会被触发的,有以下情况可以触发。

  1. 初始化一个副本集时。
  2. 副本集和主节点断开连接,可能是网络问题。
  3. 主节点挂掉。

选举还有个前提条件,参与选举的节点数量必须大于副本集总节点数量的一半,如果已经小于一半了所有节点保持只读状态。
日志将会出现:

can't see a majority of the set, relinquishing primary

主节点挂掉能否人为干预?答案是肯定的。

  1. 可以通过replSetStepDown命令下架主节点。这个命令可以登录主节点使用
    db.adminCommand({replSetStepDown : 1})

    如果杀不掉可以使用强制开关

    db.adminCommand({replSetStepDown : 1, force : true})

    或者使用 rs.stepDown(120)也可以达到同样的效果,中间的数字指不能在停止服务这段时间成为主节点,单位为秒。

  2. 设置一个从节点有比主节点有更高的优先级。
    先查看当前集群中优先级,通过rs.conf()命令,默认优先级为1是不显示的,这里标示出来。

    rs.conf();
    {
            "_id" : "rs0",
            "version" : 9,
            "members" : [
                    {
                            "_id" : 0,
                            "host" : "192.168.1.136:27017"                },
                    {
                            "_id" : 1,
                            "host" : "192.168.1.137:27017"                },
                    {
                            "_id" : 2,
                            "host" : "192.168.1.138:27017"                }
            ]
            }

    我们来设置,让id为1的主机可以优先成为主节点。

    cfg = rs.conf()
    cfg.members[0].priority = 1
    cfg.members[1].priority = 2
    cfg.members[2].priority = 1
    rs.reconfig(cfg)

    然后再执行rs.conf()命令查看优先级已经设置成功,主节点选举也会触发。

    {
            "_id" : "rs0",
            "version" : 9,
            "members" : [
                    {
                            "_id" : 0,
                            "host" : "192.168.1.136:27017"                },
                    {
                            "_id" : 1,
                            "host" : "192.168.1.137:27017",
                            "priority" : 2
                    },
                    {
                            "_id" : 2,
                            "host" : "192.168.1.138:27017"                }
              ]
             }

    如果不想让一个从节点成为主节点可以怎么操作?
    a、使用rs.freeze(120)冻结指定的秒数不能选举成为主节点。
    b、按照上一篇设置节点为Non-Voting类型。

  3. 当主节点不能和大部分从节点通讯。把主机节点网线拔掉,嘿嘿:)

    优先级还可以这么用,如果我们不想设置什么hidden节点,就用secondary类型作为备份节点也不想让他成为主节点怎么办?看下图,共三个节点分布在两个数据中心,数据中心2的节点设置优先级为0不能成为主节点,但是可以参与选举、数据复制。架构还是很灵活吧!

    deeprepset1

奇数 官方推荐副本集的成员数量为奇数,最多12个副本集节点,最多7个节点参与选举。最多12个副本集节点是因为没必要一份数据复制那么多份,备份太多反而增加了网络负载和拖慢了集群性能;而最多7个节点参与选举是因为内部选举机制节点数量太多就会导致1分钟内还选不出主节点,凡事只要适当就好。这个“12”、“7”数字还好,通过他们官方经过性能测试定义出来可以理解。具体还有哪些限制参考官方文档《 MongoDB Limits and Thresholds 》。 但是这里一直没搞懂整个集群为什么要奇数,通过测试集群的数量为偶数也是可以运行的,参考这个文章http://www.itpub.net/thread-1740982-1-1.html。后来突然看了一篇stackoverflow的文章终于顿悟了,mongodb本身设计的就是一个可以跨IDC的分布式数据库,所以我们应该把它放到大的环境来看。

假设四个节点被分成两个IDC,每个IDC各两台机器,如下图。但这样就出现了个问题,如果两个IDC网络断掉,这在广域网上很容易出现的问题,在上面选举中提到只要主节点和集群中大部分节点断开链接就会开始一轮新的选举操作,不过mongodb副本集两边都只有两个节点,但是选举要求参与的节点数量必须大于一半,这样所有集群节点都没办法参与选举,只会处于只读状态。但是如果是奇数节点就不会出现这个问题,假设3个节点,只要有2个节点活着就可以选举,5个中的3个,7个中的4个。。。

deeprepset2

心跳 综上所述,整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每两秒就会发送一次pings包,如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表,表明当前每个节点是什么角色、日志时间戳等关键信息。如果是主节点,除了维护映射表外还需要检查自己能否和集群中内大部分节点通讯,如果不能则把自己降级为secondary只读节点。

同步,副本集同步分为初始化同步和keep复制。初始化同步指全量从主节点同步数据,如果主节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后,节点之间的实时同步一般是增量同步。初始化同步不只是在第一次才会被处罚,有以下两种情况会触发:

  1. secondary第一次加入,这个是肯定的。
  2. secondary落后的数据量超过了oplog的大小,这样也会被全量复制。

那什么是oplog的大小?前面说过oplog保存了数据的操作记录,secondary复制oplog并把里面的操作在secondary执行一遍。但是oplog也是mongodb的一个集合,保存在local.oplog.rs里,但是这个oplog是一个capped collection也就是固定大小的集合,新数据加入超过集合的大小会覆盖。所以这里需要注意,跨IDC的复制要设置合适的oplogSize,避免在生产环境经常产生全量复制。oplogSize 可以通过–oplogSize设置大小,对于linux 和windows 64位,oplog size默认为剩余磁盘空间的5%。

同步也并非只能从主节点同步,假设集群中3个节点,节点1是主节点在IDC1,节点2、节点3在IDC2,初始化节点2、节点3会从节点1同步数据。后面节点2、节点3会使用就近原则从当前IDC的副本集中进行复制,只要有一个节点从IDC1的节点1复制数据。

设置同步还要注意以下几点:

  1. secondary不会从delayed和hidden成员上复制数据。
  2. 只要是需要同步,两个成员的buildindexes必须要相同无论是否是true和false。buildindexes主要用来设置是否这个节点的数据用于查询,默认为true。
  3. 如果同步操作30秒都没有反应,则会重新选择一个节点进行同步。

到此,本章前面提到的问题全部解决了,不得不说mongodb的设计还真是强大!

后续继续解决上一节这几个问题:

  • 主节点挂了能否自动切换连接?目前需要手工切换。
  • 主节点的读写压力过大如何解决?

还有这两个问题后续解决:

  • 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大?
  • 数据压力大到机器支撑不了的时候能否做到自动扩展?

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 搭建高可用mongodb集群(三)—— 深入副本集内部机制