分词

中文分词算法： 　　基于词典 　　　　优点：简单、意实现 　　　　缺点：慢、歧义切分问题、不同词典对结果的印象较大、缺乏自学习的智能性 　　　　包含： 　　　　　　正向最大匹配(MM，Maximum matching) 　　　　　　邻近算法 　　　　　　逆向最大匹配(RMM) 　　　　　　双向最大匹配 　　　　　　最短路径匹配 　　基于统计 　　　　包含： 　　　　　　N-gram模型 　　　　　　隐马尔科夫模型（HMM，Hidden Markov Model） 　　基于规则 　　　　包含： 　　　　　　扩充转移网络法 　　　　　　矩阵约束法 　　基于字标注 　　基于人工智能技术（基于理解） 　　　　包含： 　　　　　　神经网络分词算法 　　　　　　专家系统分词算法 　　　　　　神经网络专家系统集成算法 来源： https://www.cnblogs.com/zsxm/p/11675520.html

看了好几本大冰的书，感觉对自己的思维有不少的影响。想看看其他读者的评论。便想从当当下手抓取他们评论做个词云。 想着网页版说不定有麻烦的反爬，干脆从手机客户端下手好了。 果其不然，找到一个书评的api。发送请求就有详情的json返回，简直不要太方便... 要是对手机客户端做信息爬取，建议安装一个手机模拟器。 思路： 在安装好的手机模拟器设置好用来抓包的代理，我用的charles。记得安装证书，不然抓不了https的数据包。 然后安装当当客户端，打开进到书评页面。 然后成功在charles找到了这个接口。发送get请求就会返回书评... 然后这个接口只有page参数需要注意下，代表请求的第几页。然后其他参数我照抄过来了。 当当边好像没有对这些参数做检验，用很久之前抓的的链接的参数还是能请求到数据... 之后就是请求链接在脚本里解析返回的json就好了，我只需要评论，十几行代码就行。 如果要抓其他书的书评应该修改参数product_id就好。 爬虫代码： import requests import json import random import time url='http://api.dangdang.com/community/mobile/get_product_comment_list?access-token=&product_id=25288851&time_code

Lucene是什么 Lucene是一个开源的全文检索引擎工具包, 但它不是一个完整的全文检索引擎, 而是一个全文检索引擎的架构, 提供了完整的查询引擎和搜索引擎以及部分文本分析引擎。可以把它理解成一个信息检索程序库, 而不是应用产品, 具体的功能需要使用者自己去以代码实现。 Lucene的功能 本质: 输入若干个字符串, 然后Lucene为使用者提供了一个全文搜索服务, 最后告诉使用者要搜索的关键词在哪里。 搜索引擎 Lucene速度测试 测试一：250万记录，300M左右文本，生成索引380M左右，800线程下平均处理时间300ms。 测试二：37000记录，索引数据库中的两个varchar字段，索引文件2.6M，800线程下平均处理时间1.5ms。 Lucene核心 倒排索引 根据属性的值来查找记录。索引表中的每一项都包括一个属性值和具有该属性值的各记录的抵地址 由于不是由记录来确定属性值, 而是由属性值来确定记录的位置, 因此被被称为倒排索引(invertedindex) # import（输入） 1.Alex works in Facebook for three years. 2.John is a professional data-science analyzer. 3.Ronnie is just a noob in data-excavating field. 4

jieba “结巴”中文分词：做最好的 Python 中文分词组件 "Jieba" (Chinese for "to stutter") Chinese text segmentation: built to be the best Python Chinese word segmentation module. Scroll down for English documentation. 特点 支持三种分词模式： 精确模式，试图将句子最精确地切开，适合文本分析； 全模式，把句子中所有的可以成词的词语都扫描出来, 速度非常快，但是不能解决歧义； 搜索引擎模式，在精确模式的基础上，对长词再次切分，提高召回率，适合用于搜索引擎分词。 支持繁体分词 支持自定义词典 MIT 授权协议 算法 基于前缀词典实现高效的词图扫描，生成句子中汉字所有可能成词情况所构成的有向无环图 (DAG) 采用了动态规划查找最大概率路径, 找出基于词频的最大切分组合 对于未登录词，采用了基于汉字成词能力的 HMM 模型，使用了 Viterbi 算法 主要功能 分词 jieba.cut 方法接受三个输入参数: 需要分词的字符串；cut_all 参数用来控制是否采用全模式；HMM 参数用来控制是否使用 HMM 模型 jieba.cut_for_search 方法接受两个参数：需要分词的字符串；是否使用 HMM 模型

今天要分享的是关于lucene中另外一种丰富的查询方式----正则查询，lucene内置了许多的查询API，以及更强大的自定义查询方式的QueryParse，大部分情况下我们使用内置的查询API，基本上就可以满足我们的需求了，但是如果你想更灵活的定制自己的查询或者改写自己的查询API那么你完全可以继承QueryParse类来完成这项工作。 从某种方式上来说，正则查询（RegexpQuery）跟通配符查询（WildcardQuery）的功能很相似，因为他们都可以完成一样的工作，但是不同的是正则查询支持更灵活定制细化查询，这一点与通配符的泛化是不一样的，而且正则查询天生支持使用强大的正则表达式的来准确匹配一个或几个term，需要注意的是，使用正则查询的字段最好是不分词的，因为分词的字段可能会导致边界问题，从而使查询失败，得不到任何结果，这一点和WildcardQuery效果是一样的。 下面先来看一下，散仙的测试数据，为了看出分词与不分词给查询造成的影响，散仙的用同样的内容做测试，分词工具使用的是IK的分词器，截图如下： 在上图中，散仙使用2个字段存储一样的内容，一个是分过词的，一个没分过词的，下面给出使用正则查询的核心代码： RegexpQuery query=new RegexpQuery(new Term(field, ".*"+searchStr+".*")); //

IK Analyzer分词器 这个其实比较好配，奈何资源不好找，而且用solr搜中文一般都用这个我把分词器打了个包放在下面了。里面没有字典，希望哪位又好用的互通下有无。 http://pan.baidu.com/s/1pLjE2Tl 假设solr部署在tomcat上，位置webapp\solr 1、IKAnalyzer2012FF_u1.jar 放在solr\WEB-INF\lib 2、IKAnalyzer.cfg.xml和stopword.dic 放在solr\WEB-INF\classes IKAnalyzer.cfg.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> <properties> <comment>IK Analyzer 扩展配置</comment> <!--用户可以在这里配置自己的扩展字典 <entry key="ext_dict">ext.dic;</entry> --> <!--用户可以在这里配置自己的扩展停止词字典--> <entry key="ext_stopwords">stopword.dic;</entry> <!--放一些其他好用的字典--> </properties> 3

特别注意： solr版本对应的分词jar包的版本是不一样的 ，此处5.3.1的分词jar包版本在 https://github.com/EugenePig/ik-analyzer-solr5 可以下载，需要使用maven打包 based on IK Analyer 2012-FF Hotfix 1 added support for Lucene 5.1.0 API 作者在上面写到，这个版本是基于2012-FF Hotifx 1版本修改的，增加了对lucene 5以上的版本的支持 1，下载好文件后，解压，进入文件夹目录，使用对应的mvn命令打成jar包，然后将打好的jar包，拷贝到solr的对应lib目录中。2，修改solr_home目录中（在我们这里是my_solr）的schema.xml配置文件，在最后添加 <fieldType name="text_ik" class="solr.TextField"> <analyzer type="index" useSmart="false" class="org.wltea.analyzer.lucene.IKAnalyzer"/> <analyzer type="query" useSmart="true" class="org.wltea.analyzer.lucene.IKAnalyzer"/> </fieldType> 3

初次接触 Elasticsearch 的同学经常会遇到分词相关的难题，比如如下这些场景： 为什么明明有包含搜索关键词的文档，但结果里面就没有相关文档呢？ 我存进去的文档到底被分成哪些词(term)了？ 我得自定义分词规则，但感觉好麻烦呢，无从下手 如果你遇到过类似的问题，希望本文可以解决你的疑惑。 1. 上手 让我们从一个实例出发，如下创建一个文档： PUT test/doc/1 { "msg":"Eating an apple a day keeps doctor away" } 然后我们做一个查询，我们试图通过搜索 eat 这个关键词来搜索这个文档 POST test/_search { "query":{ "match":{ "msg":"eat" } } } ES的返回结果为0。这不太对啊，我们用最基本的字符串查找也应该能匹配到上面新建的文档才对啊！ 各位不要急，我们先来看看什么是分词。 2. 分词 搜索引擎的核心是倒排索引（这里不展开讲），而倒排索引的基础就是分词。所谓分词可以简单理解为将一个完整的句子切割为一个个单词的过程。在 es 中单词对应英文为 term 。我们简单看个例子： ES 的倒排索引即是根据分词后的单词创建，即 我 、 爱 、 北京 、 天安门 这4个单词。这也意味着你在搜索的时候也只能搜索这4个单词才能命中该文档。 实际上 ES

1、集群规划优化实践 1.1 基于目标数据量规划集群 在业务初期，经常被问到的问题，要几个节点的集群，内存、CPU要多大，要不要SSD？ 最主要的考虑点是：你的 目标存储数据量 是多大？可以针对目标数据量反推节点多少。 1.2 要留出容量Buffer 注意：Elasticsearch有三个警戒水位线，磁盘使用率达到85%、90%、95%。 不同警戒水位线会有不同的应急处理策略。 这点，磁盘容量选型中要规划在内。控制在 85%之下 是合理的。 当然，也可以通过配置做调整。 1.3 ES集群各节点尽量不要和其他业务功能复用一台机器。 除非内存非常大。 举例：普通服务器，安装了ES+Mysql+redis，业务数据量大了之后，势必会出现内存不足等问题。 1.4 磁盘尽量选择SSD Elasticsearch官方文档肯定 推荐SSD ，考虑到成本的原因。需要结合业务场景，如果业务对写入、检索速率有较高的速率要求，建议使用SSD磁盘。 阿里的业务场景，SSD磁盘比机械硬盘的速率提升了5倍。但要因业务场景而异。 1.5 内存配置要合理 官方建议：堆内存的大小是官方建议是：Min（32GB，机器内存大小/2）。 Medcl和wood大叔都有明确说过，不必要设置32/31GB那么大，建议： 热数据设置：26GB，冷数据：31GB 。 总体内存大小没有具体要求，但肯定是内容越大，检索性能越好。

es 对于text类型其实是分词存储的，但是有时候在聚合的时候，会发现这种情况下，会把字段分词后进行聚合。例如(1)A,B (2)B,C 然后聚合后B就是2个，A和C各一个。 这需要看业务需求了，如果确实需要这样的，就完美契合了，如果不希望这样分词起来再聚合，就是需要进行设置字段keyword，因为keyword是不会被分词的。 来源： https://www.cnblogs.com/chenmz1995/p/11582636.html