⑴ 有用python做过中文分词全文索引的吗
pipinstallsnownlp#中文文本的情感分析
fromsnownlpimportSnowNLP
s=SnowNLP(u'这个东西真心很赞')
s.words#[u'这个',u'东西',u'真心',
#u'很',u'赞']
s.tags#[(u'这个',u'r'),(u'东西',u'n'),
#(u'真心',u'd'),(u'很',u'd'),
#(u'赞',u'Vg')]
s.sentiments#0.9769663402895832positive的概率
s.pinyin#[u'zhe',u'ge',u'dong',u'xi',
#u'zhen',u'xin',u'hen',u'zan']
s=SnowNLP(u'“繁体字”“繁体中文”的叫法在台湾亦很常见。')
s.han#u'“繁体字”“繁体中文”的叫法
#在台湾亦很常见。'
⑵ 如何从python中的多索引数据中获取索引号
你是说获取上面的项目编号吗？
试过项目编号获取没成功。但段落编号我搞定了：
a=activedocument.range(0,
selection.end).paragraphs.count
a里面就是当时光标所在的段落号，举例，全文有10段，光标在第3段，返回值就是3。
⑶ 如何在Python的Flask框架中实现全文搜索
灰常不幸的是，关系型数据库对全文检索的支持没有被标准化。不同的数据库通过它们自己的方式来实现全文检索，而且SQLAlchemy在全文检索上也没有提供一个好的抽象。
我们现在使用SQLite作为我们的数据库，所以我们可以绕开SQLAlchemy而使用SQLite提供的工具来创建一个全文检索索引。但这么做不怎么好，因为如果有一天我们换用别的数据库，那么我们就得重写另一个数据库的全文检索方法。
所以我们的方案是，我们将让我们现有的数据库处理常规数据，然后我们创建一个专门的数据库来解决全文检索。
⑷ 网络爬虫主要能干啥
网络爬虫，是一种自动获取网页内容的程序，是搜索引擎的重要组成部分。一般人能访问到的网页，爬虫也都能抓取。所谓的爬虫抓取，也是类似于我们浏览网页。但与普通人上网方式不同，爬虫是可以按照一定的规则，自动的采集信息。
举个例子，比如说你从事的是文字编辑工作，需求稿件量大，可是效率很低，最大的一个原因便是很多的时间花费在了采集资料上，假如继续按照之前手动浏览的方式，要么就是你通宵达旦熬夜加班，要么便是让其他人帮你，但显然两者都不方便。这种情况下，网络爬虫就显得很重要。
随着大数据时代的来临，网络爬虫在互联网中的地位将越来越重要。互联网中的数据是海量的，如何自动高效地获取互联网中我们感兴趣的信息并为我们所用是一个重要的问题，而爬虫技术就是为了解决这些问题而生的。
我们感兴趣的信息分为不同的类型：如果只是做搜索引擎，那么感兴趣的信息就是互联网中尽可能多的高质量网页；如果要获取某一垂直领域的数据或者有明确的检索需求，那么感兴趣的信息就是根据我们的检索和需求所定位的这些信息，此时，需要过滤掉一些无用信息。前者我们称为通用网络爬虫，后者我们称为聚焦网络爬虫。
⑸ 如何评价whoosh这个python搜索框架
Whoosh 是一个纯python实现的全文搜索组件。Whoosh不但功能完善，还非常的快。
Whoosh的作者是MattChaput，由Side Effects Software公司开发。项目的最初用于Houdini（Side Effects Software公司开发的3D动画软件）的在线帮助系统。Side Effects Software公司将该项目开源。
主要特性：
* 敏捷的API（Pythonic API）。
* 纯python实现，无二进制包。程序不会莫名其妙的崩溃。
* 按字段进行索引。
* 索引和搜索都非常的快 -- 是目前最快的纯python全文搜索引擎。
* 良好的构架，评分模块/分词模块/存储模块等各个模块都是可插拔的。
* 功能强大的查询语言（通过pyparsing实现功能）。
* 纯python实现的拼写检查（目前唯一的纯python拼写检查实现）
为啥选择Whoosh
* 纯python实现，省了编译二进制包的繁琐过程。
* python代码比java更容易读懂，而且用起来也更方便。（翻者注：这个容易引发口水）
* 在很多时候易用性比单纯的最求速度更重要。
Whoosh从其他的开源搜索引擎中获取了大量的灵感。 基础构建参考Lucene，使用KinoSearch的索引算法，部分评分算法来自Terrier，英文的词语态变化来自Minion.
⑹ 请教python操作数据库表的结果集的整理
，选择开始菜单中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打开【SQL Server Management Studio】窗口，并使用Windows或 SQL Server身份验证建立连接。
在【对象资源管理器】窗口中展开服务器，然后选择【数据库】节点
右键单击【数据库】节点，从弹出来的快捷菜单中选择【新建数据库】命令。
执行上述操作后，会弹出【新建数据库】对话框。在对话框、左侧有3个选项，分别是【常规】、【选项】和【文件组】。完成这三个选项中的设置会后，就完成了数据库的创建工作，
在【数据库名称】文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。
在【所有者】文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用【使用全文索引】复选框。
在【数据库文件】列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的【添加】、【删除】按钮添加或删除数据库文件。
切换到【选项页】、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。
切换到【文件组】页，在这里可以添加或删除文件组。
完成以上操作后，单击【确定】按钮关闭【新建数据库】对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再【对象资源管理器】窗口看到。
⑺ 如何使用织梦DedeCMS v5.7全文检索说明
1.1.开始前的准备工作
先从http://www.coreseek.cn/procts/ft_down/下载Coreseek 3.2.13,这里我们就以Windows环境为例:
下载后直接解压coreseek-3.2.13-win32.zip,我们这里假设解压到:D:\coreseek-3.2.13-win32.这里我们需要简单了解几个目录:
[D:\coreseek-3.2.13-win32\api]API接口目录,其中包括了php,python,ruby等操作实例,其中test_coreseek.php是一个不错的中文检索的例子.
[D:\****\bin]应用程序目录,其中包含以下几个文件
* indexer: 用于创建全文索引;
* search: 一个简单的命令行(CLI) 的测试程序，用于测试全文索引;
* searchd: 一个守护进程，其他软件可以通过这个守护进程进行全文检索;
* sphinxapi: 一系列searchd 的客户端API 库，用于流行的Web脚本开发语言(PHP, Python, Perl, Ruby, Java).
* spellmp: 一个简单的命令行工具，用于从 ispell 或 MySpell (OpenOffice内置绑定) 格式的字典中提取词条。当使用 wordforms 时可用这些词条对索引进行定制.
* indextool: 工具程序，用来转储关于索引的多项调试信息。 此工具是从版本Coreseek 3.1(Sphinx 0.9.9-rc2)开始加入的。
* mmseg: 工具程序和库，Coreseek用于提供中文分词和词典处理。
[D:\****\etc]sphinx配置目录
[D:\****\var]sphinx变量&索引&日志存放目录
1.2.创建配置文件
由于dedecms使用的是mysql,所以我们需要来配置一个mysql的sphinx模板配置,可以复制csft_mysql.conf改名为:csft_dedecmsv57.conf,例如我们这里仅做文章的全文检索,我们需要做如下配置:
先在DedeCMS中创建一个统计表,方法可以在DedeCMS后台[系统]->[SQL命令行工具]中执行下列代码:
CREATE TABLE `dede_sphinx` (
`countid` int(11) unsigned NOT NULL,
`maxaid` int(11) unsigned NOT NULL,
PRIMARY KEY (`countid`)
) ENGINE=MyISAM DEFAULT CHARSET=gbk
这是一个sphinx内容统计表,为了适合数据量较大的情况下分批生成索引而使用的.
创建完数据表后,我们对sphinx的配置文件,即csft_dedecmsv57.conf修改,内容如下,其中包含注释:
--------------------------------------------------------------------------------------------
#源定义
source mysql
{
type = mysql
# 数据库服务器基本配置信息
sql_host = 192.168.0.103
sql_user = dedev57
sql_pass = dedecms
sql_db = dedecmsv57gbk
sql_port = 3306
# 设定编码,这里我们是gbk编码,如果是utf-8,可以设置:
# sql_query_pre = SET NAMES utf8
sql_query_pre = SET NAMES gbk
# 数据检索增量
sql_range_step = 1000
#当前最新文档id数
sql_query_pre = REPLACE INTO dede_sphinx SELECT 1, MAX(id) FROM dede_archives
#检索条件
sql_query = SELECT ARC.id,ARC.typeid,ARC.typeid2,ARC.sortrank,ARC.flag,ARC.channel,ARC.ismake,ARC.arcrank,ARC.click,ARC.title,ARC.shorttitle,ARC.color,ARC.writer,ARC.source,ARC.litpic,ARC.pubdate,ARC.senddate,ARC.mtype,ARC.description,ARC.badpost,ARC.goodpost,ARC.scores,ARC.lastpost,ARC.keywords,ARC.mid,ART.body FROM dede_archives AS ARC LEFT JOIN dede_addonarticle AS ART ON ARC.id = ART.aid WHERE ARC.id>=$start AND ARC.id<=$end #sql_query第一列id需为整数
#title、body作为字符串/文本字段，被全文索引http://www.dede58.com/a/dedeaz/1678.html
⑻ elasticsearch JPA执行save方法后，发现elasticsearch有文件生成，但数据库中没数据
由于需要提升项目的搜索质量，最近研究了一下Elasticsearch，一款非常优秀的分布式搜索程序。最开始的一些笔记放到github，这里只是归纳总结一下。
首先，为什么要使用Elasticsearch？最开始的时候，我们的项目仅仅使用MySQL进行简单的搜索，然后一个不能索引的like语句，直接拉低MySQL的性能。后来，我们曾考虑过sphinx，并且sphinx也在之前的项目中成功实施过，但想想现在的数据量级，多台MySQL，以及搜索服务本身HA，还有后续扩容的问题，我们觉得sphinx并不是一个最优的选择。于是自然将目光放到了Elasticsearch上面。
根据官网自己的介绍，Elasticsearch是一个分布式搜索服务，提供Restful API，底层基于Lucene，采用多shard的方式保证数据安全，并且提供自动resharding的功能，加之github等大型的站点也采用 Elasticsearch作为其搜索服务，我们决定在项目中使用Elasticsearch。
对于Elasticsearch，如果要在项目中使用，需要解决如下问题：
索引，对于需要搜索的数据，如何建立合适的索引，还需要根据特定的语言使用不同的analyzer等。
搜索，Elasticsearch提供了非常强大的搜索功能，如何写出高效的搜索语句？
数据源，我们所有的数据是存放到MySQL的，MySQL是唯一数据源，如何将MySQL的数据导入到Elasticsearch？
对于1和2，因为我们的数据都是从MySQL生成，index的field是固定的，主要做的工作就是根据业务场景设计好对应的mapping以及search语句就可以了，当然实际不可能这么简单，需要我们不断的调优。
而对于3，则是需要一个工具将MySQL的数据导入Elasticsearch，因为我们对搜索实时性要求很高，所以需要将MySQL的增量数据实时导入，笔者唯一能想到的就是通过row based binlog来完成。而近段时间的工作，也就是实现一个MySQL增量同步到Elasticsearch的服务。
Lucene
Elasticsearch底层是基于Lucene的，Lucene是一款优秀的搜索lib，当然，笔者以前仍然没有接触使用过。:-)
Lucene关键概念：
Document：用来索引和搜索的主要数据源，包含一个或者多个Field，而这些Field则包含我们跟Lucene交互的数据。
Field：Document的一个组成部分，有两个部分组成，name和value。
Term：不可分割的单词，搜索最小单元。
Token：一个Term呈现方式，包含这个Term的内容，在文档中的起始位置，以及类型。
Lucene使用Inverted index来存储term在document中位置的映射关系。
譬如如下文档：
Elasticsearch Server 1.0 （document 1）
Mastring Elasticsearch （document 2）
Apache Solr 4 Cookbook （document 3）
使用inverted index存储，一个简单地映射关系：
Term
Count
Docuemnt
1.0 1
4 1
Apache 1
Cookbook 1
Elasticsearch 2 .
Mastering 1
Server 1
Solr 1
对于上面例子，我们首先通过分词算法将一个文档切分成一个一个的token，再得到该token与document的映射关系，并记录token出现的总次数。这样就得到了一个简单的inverted index。
Elasticsearch关键概念
要使用Elasticsearch，笔者认为，只需要理解几个基本概念就可以了。
在数据层面，主要有：
Index：Elasticsearch用来存储数据的逻辑区域，它类似于关系型数据库中的db概念。一个index可以在一个或者多个shard上面，同时一个shard也可能会有多个replicas。
Document：Elasticsearch里面存储的实体数据，类似于关系数据中一个table里面的一行数据。
document由多个field组成，不同的document里面同名的field一定具有相同的类型。document里面field可以重复出现，也就是一个field会有多个值，即multivalued。
Document type：为了查询需要，一个index可能会有多种document，也就是document type，但需要注意，不同document里面同名的field一定要是相同类型的。
Mapping：存储field的相关映射信息，不同document type会有不同的mapping。
对于熟悉MySQL的童鞋，我们只需要大概认为Index就是一个db，document就是一行数据，field就是table的column，mapping就是table的定义，而document type就是一个table就可以了。
Document type这个概念其实最开始也把笔者给弄糊涂了，其实它就是为了更好的查询，举个简单的例子，一个index，可能一部分数据我们想使用一种查询方式，而另一部分数据我们想使用另一种查询方式，于是就有了两种type了。不过这种情况应该在我们的项目中不会出现，所以通常一个index下面仅会有一个 type。
在服务层面，主要有：
Node: 一个server实例。
Cluster：多个node组成cluster。
Shard：数据分片，一个index可能会存在于多个shards，不同shards可能在不同nodes。
Replica：shard的备份，有一个primary shard，其余的叫做replica shards。
Elasticsearch之所以能动态resharding，主要在于它最开始就预先分配了多个shards（貌似是1024），然后以shard为单位进行数据迁移。这个做法其实在分布式领域非常的普遍，codis就是使用了1024个slot来进行数据迁移。
因为任意一个index都可配置多个replica，通过冗余备份的方式保证了数据的安全性，同时replica也能分担读压力，类似于MySQL中的slave。
Restful API
Elasticsearch提供了Restful API，使用json格式，这使得它非常利于与外部交互，虽然Elasticsearch的客户端很多，但笔者仍然很容易的就写出了一个简易客户端用于项目中，再次印证了Elasticsearch的使用真心很容易。
Restful的接口很简单，一个url表示一个特定的资源，譬如/blog/article/1，就表示一个index为blog，type为aritcle，id为1的document。
而我们使用http标准method来操作这些资源，POST新增，PUT更新，GET获取，DELETE删除，HEAD判断是否存在。
这里，友情推荐httpie，一个非常强大的http工具，个人感觉比curl还用，几乎是命令行调试Elasticsearch的绝配。
一些使用httpie的例子:
# create
http POST :9200/blog/article/1 title="hello elasticsearch" tags:='["elasticsearch"]'
# get
http GET :9200/blog/article/1
# update
http PUT :9200/blog/article/1 title="hello elasticsearch" tags:='["elasticsearch", "hello"]'
# delete
http DELETE :9200/blog/article/1
# exists
http HEAD :9200/blog/article/1
索引和搜索
虽然Elasticsearch能自动判断field类型并建立合适的索引，但笔者仍然推荐自己设置相关索引规则，这样才能更好为后续的搜索服务。
我们通过定制mapping的方式来设置不同field的索引规则。
而对于搜索，Elasticsearch提供了太多的搜索选项，就不一一概述了。
索引和搜索是Elasticsearch非常重要的两个方面，直接关系到产品的搜索体验，但笔者现阶段也仅仅是大概了解了一点，后续在详细介绍。
同步MySQL数据
Elasticsearch是很强大，但要建立在有足量数据情况下面。我们的数据都在MySQL上面，所以如何将MySQL的数据导入Elasticsearch就是笔者最近研究的东西了。
虽然现在有一些实现，譬如elasticsearch-river-jdbc，或者elasticsearch-river-mysql，但笔者并不打算使用。
elasticsearch-river-jdbc的功能是很强大，但并没有很好的支持增量数据更新的问题，它需要对应的表只增不减，而这个几乎在项目中是不可能办到的。
elasticsearch-river-mysql倒是做的很不错，采用了python-mysql-replication来通过binlog获取变更的数据，进行增量更新，但它貌似处理MySQL mp数据导入的问题，不过这个笔者真的好好确认一下？话说，python-mysql-replication笔者还提交过pull解决了minimal row image的问题，所以对elasticsearch-river-mysql这个项目很有好感。只是笔者决定自己写一个出来。
为什么笔者决定自己写一个，不是因为笔者喜欢造轮子，主要原因在于对于这种MySQL syncer服务（增量获取MySQL数据更新到相关系统），我们不光可以用到Elasticsearch上面，而且还能用到其他服务，譬如cache上面。所以笔者其实想实现的是一个通用MySQL syncer组件，只是现在主要关注Elasticsearch罢了。
项目代码在这里go-mysql-elasticsearch，现已完成第一阶段开发，内部对接测试中。
go-mysql-elasticsearch的原理很简单，首先使用mysqlmp获取当前MySQL的数据，然后在通过此时binlog的name和position获取增量数据。
一些限制：
binlog一定要变成row-based format格式，其实我们并不需要担心这种格式的binlog占用太多的硬盘空间，MySQL 5.6之后GTID模式都推荐使用row-based format了，而且通常我们都会把控SQL语句质量，不允许一次性更改过多行数据的。
需要同步的table最好是innodb引擎，这样mysqlmp的时候才不会阻碍写操作。
需要同步的table一定要有主键，好吧，如果一个table没有主键，笔者真心会怀疑设计这个table的同学编程水平了。多列主键也是不推荐的，笔者现阶段不打算支持。
一定别动态更改需要同步的table结构，Elasticsearch只能支持动态增加field，并不支持动态删除和更改field。通常来说，如果涉及到alter table，很多时候已经证明前期设计的不合理以及对于未来扩展的预估不足了。
更详细的说明，等到笔者完成了go-mysql-elasticsearch的开发，并通过生产环境中测试了，再进行补充。
总结
最近一周，笔者花了不少时间在Elasticsearch上面，现在算是基本入门了。其实笔者觉得，对于一门不懂的技术，找一份靠谱的资料（官方文档或者入门书籍），蛋疼的对着资料敲一遍代码，不懂的再问google，最后在将其用到实际项目，这门技术就算是初步掌握了，当然精通还得在下点功夫。
现在笔者只是觉得Elasticsearch很美好，上线之后铁定会有坑的，那时候只能慢慢填了。话说，笔者是不是要学习下java了，省的到时候看不懂代码就惨了。:-)
⑼ 如何 用 python 和elasticsearch 做全文检索
#coding:utf-8
from elasticsearch import Elasticsearch
es = Elasticsearch([{'host':'192.168.3.22','port':9200}])
def match_phrase(url):
res = es.search(index="yu", body={'query':{'match_phrase':{'domain':url}}})
result = []
for de in res['hits']['hits']:
result.append(de['_source'])
return result
print match_phrase('SHA256WithRSA')