在搜索文档内容之前要做的事情就是对从各种不同来源(网页,数据库,电子邮件等)的文档进行索引,索引的过程就是对内容进行提取,规范化(通过对内容进行建模来实现),然后存储. 在索引的过程中有几个基本的概念,根据我自己的理解大概写一下: 文档(Document): 文档在索引和搜索的时候都会用到,是索引和搜索的基本单位(类似于关系数据库关系表中的记录),若我们对网页内容进行索引和搜索,则从互联网上爬下来的每一个网页最终都会经过分析,提取出其中有意义的部分(比如网页标题,URL,包含的关键字,发布日期等…
了解sql的朋友都知道,我们在查询的时候能够採用join查询,即对有一定关联关系的对象进行联合查询来对多维的数据进行整理.这个联合查询的方式挺方便的.跟我们现实生活中的托人找关系类似,我们想要完毕一件事.先找自己的熟人,然后通过熟人在一次找到其它,终于通过这样的手段找到想要联系到的人. 有点类似于"世间万物皆有联系"的感觉. lucene的join包提供了索引时join和查询时join的功能. Index-time join 大意是索引时join提供了查询时join的支持,且Index…
索引建立原则 确定针对该表的操作是大量的查询操作还是大量的增删改操作. 尝试建立索引来帮助特定的查询.检查自己的sql语句,为那些频繁在where子句中出现的字段建立索引. where语句中不得不对查询列采用函数查询,如upper函数,最好建立相应函数索引: 在SQL语句中经常进行GROUP BY.ORDER BY的字段上建立索引 用于联接的列(主健/外健)上建立索引: 在经常存取的多个列上建立复合索引,但要注意复合索引的建立顺序要按照使用的频度来确定: 尝试建立复合索引来进一步提高系统性能.修…
文章转自:http://www.cnblogs.com/zhengyun_ustc/p/slowquery2.html 写在前面的话: 之前曾说过"不要求每个人一定理解 联表查询(join/left join/inner join等)时的mysql运算过程",但对于字段选择性差意味着什么,组合索引字段顺序意味着什么,要求每个人必须了解: 重复上一次的话:把mysql客户端(如SQLyog,如HeidiSQL)放在桌面上,时不时拿出来 explain 一把,这是一种美德! 确保亲手查过S…
对Lucene代码优化 我们再次看回我们上一篇快速入门写过的代码,我来截取一些有代表性的: 以下代码在把数据填充到索引库,和从索引库查询数据的时候,都出现了.是重复代码! Directory directory = FSDirectory.open(new File("E:/createIndexDB")); //使用标准的分词算法对原始记录表进行拆分 Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_30); 以下的代码其…
经常使用Linux的开发人员或者运维人员,可能对configure->make->make install相当熟悉.事实上,这叫GNU构建系统,利用脚本和make程序在特定平台上构建软件.这种方式成为一种习惯,被广泛使用.本文从用户视角和开发者视角详细说明,这种构建方式的细节,以及开发者如何利用autoconf和automake等工具(autotools)创建兼容GNU构建系统的项目. 为了简化可移植构建的难度,在早期有一套autotools工具帮助程序员构建软件.我们熟知的configure…
案例描述 这是在索引重组过程中遇到的有意思的错误案例,搜索了一下也没有看到相关资料,估计我第一个碰到这类错误的人(It's just a joke).具体情况是YourSQLDba在做维护数据库索引时遇到了索引重组错误,然后我排查时就发现了这个案例.我下面用一个简单的测试例子演示一下具体情况. 数据库版本: SQL SERVER 2005 CREATE TABLE TEST   (   ID     INT,   Name   VARCHAR(12)   );   CREATE NONCLUST…
最近一直在做公司搜索的优化与维护,做完索引和搜索的分离之后,又有一个新需求,因为做的是歌曲方面的搜索,所以在数据库中有多个同歌名,同演唱者的的数据,这样在用户搜索的时候,会出来一大堆不同版本的歌曲,影响搜索质量,所以需要在建立索引库时做一个初步的过滤,因为只是一个简单的过滤,所以并不需要太精确. 首先呢是要确定哪些歌曲需要过滤,我调研后觉得对于同一歌名,同一演唱者的歌曲数量大于10时,就进行过滤,也即阀值为10,当然这个后期可以随时调整. 然后是需要确定过滤的维度,也即怎样确定一个歌曲就比另一个…
场景一,数据表规模不大,就几千行,即使不建索引,查询语句的返回时间也不长,这时建索引的意义就不大.当然,若就几千行,索引所占的空间也不多,所以这种情况下,顶多属于"性价比"不高. 场景二,某个商品表里有几百万条商品信息,同时每天会在一个时间点,往其中更新大概十万条左右的商品信息,现在用where语句查询特定商品时(比如where name = 'XXX')速度很慢.为了提升查询效率可以建索引,但当每天更新数据时,又会重建索引,这是要耗费时间的. 这时就需要综合考虑,甚至可以在更新前删除…