??xml version="1.0" encoding="utf-8" standalone="yes"?>久久久久久亚洲av无码蜜芽 ,中文字幕亚洲无线码a,综合久久久久久中文字幕亚洲国产国产综合一区首 http://www2.blogjava.net/gaich/category/1917.htmlzh-cnWed, 28 Feb 2007 19:28:38 GMTWed, 28 Feb 2007 19:28:38 GMT60lucenel构中文说明http://m.tkk7.com/gaich/archive/2005/06/30/6933.htmlgaichgaichThu, 30 Jun 2005 03:52:00 GMThttp://m.tkk7.com/gaich/archive/2005/06/30/6933.htmlhttp://m.tkk7.com/gaich/comments/6933.htmlhttp://m.tkk7.com/gaich/archive/2005/06/30/6933.html#Feedback0http://m.tkk7.com/gaich/comments/commentRss/6933.htmlhttp://m.tkk7.com/gaich/services/trackbacks/6933.html原文:http://www.matrix.org.cn/resource/article/34.html

论坛:http://www.matrix.org.cn/topic.shtml?forumId=32
索引文g格式

本文定义?/SPAN>LuceneQ版?/SPAN>1.3Q用到的索引文g的格式?/SPAN>

Jakarta Lucene是用Java写成的，同时有很多团体正在默默的用其他的E序语言来改写它。如果这些新的版本想?/SPAN>Jakarta Lucene兼容Q就需要一个与具体语言无关?/SPAN>Lucene索引文g格式。本文正是试图提供一个完整的与语a无关?/SPAN>Jakarta Lucene 1.3索引文g格式的规格定义?/SPAN>

随着Lucene不断发展Q本文也应该更新。不同语a写成?/SPAN>Lucene实现版本应当力遵守文g格式Q也必须产生本文的新版本?/SPAN>

本文同时提供兼容性批注，描述文g格式上与前一版本不同的地斏V?/SPAN>

定义

Lucene中最基础的概忉|索引Q?/SPAN>indexQ，文Q?/SPAN>documentQ，域（fieldQ和（termQ?/SPAN>

索引包含了一个文的序列?/SPAN>

· 文是一些域的序列?/SPAN>

· 域是一些项的序列?/SPAN>

· 就是一个字丌Ӏ?/SPAN>

存在于不同域中的同一个字串被认ؓ是不同的V因此项实际是用一对字串表C的Q第一个字串是域名Q第二个是域中的字串?/SPAN>

倒排索引

Z使得Z的搜烦更有效率Q烦引中Ҏ静态存储的?/SPAN>Lucene的烦引属于烦引方式中的倒排索引Q因为对于一个项q种索引可以列出包含它的文档。这刚好是文档与自然联pȝ倒置?/SPAN>

域的cd

Lucene中，域的文本可能以逐字的非倒排的方式存储在索引中。而倒排q的域称索引q了。域也可能同时被存储和被索引?/SPAN>

域的文本可能被分解许多项目而被索引Q或者就被用作一个项目而被索引。大多数的域是被分解q的Q但是有些时候某些标识符域被当做一个项目烦引是很有用的?/SPAN>

D（SegmentQ?/SPAN>

Lucene索引可能由多个子索引l成Q这些子索引成ؓDc每一D都是完整独立的索引Q能被搜索。烦引是q样作成的：

1. 为新加入的文创建新Dc?/SPAN>

2. 合ƈ已经存在的段?/SPAN>

搜烦旉要涉及到多个D和/或者多个烦引，每一个烦引又可能׃些段l成?/SPAN>

文档PDocument NumberQ?/SPAN>

内部的来_Lucene用一个整形（intergerQ的文h指示文。第一个被加入到烦引中的文档就?/SPAN>0P序加入的文将得到一个由前一个号码递增而来的号码?/SPAN>

注意文h可能改变的，所以在Lucene外部存储q些L时必d心。特别的Q号码的改变的情况如下：

· 只有D内的号码是相同的，不同D之间不同，因而在一个比D广泛的上下文环境中使用q些LӞ必L变它们。标准的技术是Ҏ每一D号码多ؓ每一D分配一个段受将D内文档可{换到D外Ӟ加上D号。将某段外的文可{换到D内ӞҎ每段中可能的转换后号码范围来判断文属于那一D，q减调这一D늚D号。例如有两个?/SPAN>5个文档的D合qӞ那么W一D늚D号是0Q第二段D号5。第二段中的W三个文，在段外的L是8?/SPAN>

· 文删除后，q箋的号码就出现了间断。这可以通过合ƈ索引来解冻ID合q时删除的文档相应也删掉了，新合q而成的段q没有号码间断?/SPAN>

l论

索引D늻护着以下的信息：

· 域集合。包含了索引中用到的所有的域?/SPAN>

· 域值存储表。每一个文档都含有一?/SPAN>?/SPAN>属性－?/SPAN>?/SPAN>对的列表Q属性即为域名。这个列表用来存储文的一些附加信息，如标题，url或者访问数据库的一?/SPAN>ID。在搜烦时存储域的集合可以被q回。这个表以文号标识?/SPAN>

· 字典。这个字典含有所有文的所有域中用过的的，同时含有使用q它的文档的文档P以及指向使用频数信息和位|信息的指针?/SPAN>

· wC息。对于项字典中的每个，q些信息包含含有q个的文的LQ以及每个文中使用的次数?/SPAN>

· 位|信息。对于项字典中的每个，都存有在每个文中出现的各个位置?/SPAN>

· Normalization factors. For each field in each document, a value is stored that is multiplied into the score for hits on that field. 标准化因子。对于文档中的每一个域Q存有一个|用来以后乘以q个q个域的命中敎ͼhitsQ?/SPAN>

· 被删除的文档信息。这是一个可选文Ӟ用来表明那些文档已经删除了?/SPAN>

接下来的各部分部分详l描q这些信息?/SPAN>

文g的命名（File NamingQ?/SPAN>

同属于一个段的文件拥有相同的文g名，不同的扩展名。扩展名׃下讨论的各种文g格式定?/SPAN>

一般来_一个烦引存放一个目录，其所有段都存攑֜q个目录里，管我们不要求您q样做?/SPAN>

基本数据cdQ?/SPAN>Primitive TypesQ?/SPAN>

Byte

最基本的数据类型就是字节（byteQ?/SPAN>8位）。文件就是按字节序讉K的。其它的一些数据类型也定义为字节的序列Q文件的格式h字节意义上的独立性?/SPAN>

UInt32

32位无W号整数Q由四个字节l成Q高位优先?/SPAN>

UInt32 --> <Byte>4

Uint64

64位无W号整数Q由八字节组成，高位优先?/SPAN>

UInt64 --> <Byte>8

VInt

可变长的正整数类型，每字节的最高位表明q剩多少字节。每字节的低七位表明整数的倹{因此单字节的g0?/SPAN>127Q两字节g128?/SPAN>16,383Q等{?/SPAN>

VInt ~码CZ

Value
First byte
Second byte
Third byte

0
00000000



1
00000001



2
00000010



...




127
01111111



128
10000000
00000001


129
10000001
00000001


130
10000010
00000001


...




16,383
11111111
01111111


16,384
10000000
10000000
00000001

16,385
10000001
10000000
00000001

...

q种~码提供了一U在高效率解码时压羃数据的方法?/SPAN>

Chars

Lucene输出UNICODE字符序列Q用标?/SPAN>UTF-8~码?/SPAN>

String

Lucene输出?/SPAN>VINT和字W串l成的字ԌVINT表示字串长，字符串紧接其后?/SPAN>

String --> VInt, Chars

索引包含的文ӞPer-Index FilesQ?/SPAN>

q部分介l每个烦引包含的文g?/SPAN>

Segments文g

索引中活动的D存储在Segments文g中。每个烦引只能含有一个这L文gQ名?/SPAN>"segments".q个文g依次列出每个D늚名字和每个段的大?/SPAN>

Segments --> SegCount, <SegName, SegSize>SegCount

SegCount, SegSize --> UInt32

SegName --> String

SegName表示?/SPAN>segment的名字，同时作ؓ索引其他文g的前~?/SPAN>

SegSize是段索引中含有的文档数?/SPAN>

Lock文g

有一些文件用来表C另一个进E在使用索引?/SPAN>

· 如果存在"commit.lock"文gQ表C有q程在写"segments"文g和删除无用的D늃引文Ӟ或者表C有q程在读"segments"文g和打开某些D늚文g。在一个进E在d"segments"文gD信息后Q还没来得及打开所有该D늚文g前，q个Lock文g可以防止另一个进E删除这些文件?/SPAN>

· 如果存在"index.lock"文gQ表C有q程在向索引中加入文档，或者是从烦引中删除文。这个文仉止很多文件同时修改一个烦引?/SPAN>

Deleteable文g

名ؓ"deletetable"的文件包含了索引不再使用的文件的名字Q这些文件可能ƈ没有被实际的删除。这U情况只存在?/SPAN>Win32q_下，因ؓWin32下文件仍打开时ƈ不能删除?/SPAN>

Deleteable --> DelableCount, <DelableName>DelableCount

DelableCount --> UInt32

DelableName --> String

D包含的文gQ?/SPAN>Per-Segment FilesQ?/SPAN>

剩下的文件是每段中包含的文gQ因此由后缀来区分?/SPAN>

域（FieldQ?/SPAN>


域集合信息（Field InfoQ?/SPAN>

所有域名都存储在这个文件的域集合信息中Q这个文件以后缀.fnml尾?/SPAN>

FieldInfos (.fnm) --> FieldsCount, <FieldName, FieldBits>FieldsCount

FieldsCount --> VInt

FieldName --> String

FieldBits --> Byte

目前情况下，FieldBits只有使用低位Q对于已索引的域gؓ1Q对未烦引的域gؓ0?/SPAN>

文g中的域根据它们的ơ序~号。因此域0是文件中的第一个域Q域1是接下来的，{等。这个和文L~号方式相同?/SPAN>


域值存储表Q?/SPAN>Stored FieldsQ?/SPAN>

域值存储表使用两个文g表示Q?/SPAN>

1. 域烦引（.fdx文gQ?/SPAN>

如下Q对于每个文档这个文件包含指向域值的指针Q?/SPAN>

FieldIndex (.fdx) --> <FieldValuesPosition>SegSize

FieldValuesPosition --> Uint64

FieldValuesPosition指示的是某一文档的某域的域值在域值文件中的位|。因为域值文件含有定长的数据信息Q因而很Ҏ随机讉K。在域值文件中Q文?/SPAN>n的域g息就存在n*8位置处（The position of document n's field data is the Uint64 at n*8 in this file.Q?/SPAN>

2. 域|.fdt文gQ?/SPAN>

如下Q每个文的域g息包含：

FieldData (.fdt) --> <DocFieldData>SegSize

DocFieldData --> FieldCount, <FieldNum, Bits, Value>FieldCount

FieldCount --> VInt

FieldNum --> VInt

Bits --> Byte

Value --> String

目前情况下，Bits只有低位被用，gؓ1表示域名被分解过Qgؓ0表示未分解过?/SPAN>

字典（Term DictionaryQ?/SPAN>

字典用以下两个文g表示Q?/SPAN>

1. 信息（.tis文gQ?/SPAN>

TermInfoFile (.tis)--> TermCount, TermInfos

TermCount --> UInt32

TermInfos --> <TermInfo>TermCount

TermInfo --> <Term, DocFreq, FreqDelta, ProxDelta>

Term --> <PrefixLength, Suffix, FieldNum>

Suffix --> String

PrefixLength, DocFreq, FreqDelta, ProxDelta
--> VInt

信息按Ҏ序。项信息排序时先按项所属的域的文字序排序Q然后按照项的字串的文字序排序?/SPAN>

的字前~往往是共同的Q与字的后缀l成字?/SPAN>PrefixLength变量是表示与前一相同的前缀的字数。因此，如果前一个项的字?/SPAN>"bone"Q后一个是"boy"的话Q?/SPAN>PrefixLengthgؓ2Q?/SPAN>Suffixgؓ"y"?/SPAN>

FieldNum指明了项属于的域P而域名存储在.fdt文g中?/SPAN>

DocFreg表示的是含有该项的文的数量?/SPAN>

FreqDelta指明了项所?/SPAN>TermFreq变量?/SPAN>.frq文g中的位置。详l的_是指相对于前一个项的数据的位置偏移量（或者是0Q表C文件中W一个项Q?/SPAN>

ProxDelta指明了项所属的TermPosition变量?/SPAN>.prx文g中的位置。详l的_是指相对于前一个项的数据的位置偏移量（或者是0Q表C文件中W一个项Q?/SPAN>

2. 信息烦引（.tii文gQ?/SPAN>

每个信息烦引文件包?/SPAN>.tis文g中的128个条目，依照条目?/SPAN>.tis文g中的序。这栯计是Z一ơ将索引信息d内存能，然后使用它来随机的访?/SPAN>.tis文g?/SPAN>

q个文g的结构和.tis文g非常cMQ只在每个条目记录上增加了一个变?/SPAN>IndexDelta?/SPAN>

TermInfoIndex (.tii)--> IndexTermCount, TermIndices

IndexTermCount --> UInt32

TermIndices --> <TermInfo, IndexDelta>IndexTermCount

IndexDelta --> VInt

IndexDelta表示该项?/SPAN>TermInfo变量值在.tis文g中的位置。详l的Ԍ是指相对于前一个条目的偏移量（或者是0Q对于文件中W一个项Q?/SPAN>

w敎ͼFrequenciesQ?/SPAN>

.frq文g包含每一的文的列表，q有该项在对应文档中出现的频数?/SPAN>

FreqFile (.frq) --> <TermFreqs>TermCount

TermFreqs --> <TermFreq>DocFreq

TermFreq --> DocDelta, Freq?

DocDelta,Freq --> VInt

TermFreqs序列按照Ҏ排序Q依据于.tis文g中的，即项是隐含存在的Q?/SPAN>

TermFreq元组按照文号升序排列?/SPAN>

DocDelta军_了文号和频数。详l的_DocDelta/2表示相对于前一文L偏移量（或者是0Q表C?/SPAN>TermFreqs里面的第一）。当DocDelta是奇数时表示在该文档中频Cؓ1Q当DocDelta是偶数时Q另一?/SPAN>VIntQ?/SPAN>FreqQ就表示在该文中出现的频数?/SPAN>

例如Q假设某一在文7中出Cơ，在文?/SPAN>11中出C3ơ，?/SPAN>TermFreqs中就存在如下?/SPAN>VInts序列Q?/SPAN>

15, 22, 3

位|（PositionQ?/SPAN>

.prx文g包含了某文档中某出现的位置信息的列表?/SPAN>

ProxFile (.prx) --> <TermPositions>TermCount

TermPositions --> <Positions>DocFreq

Positions --> <PositionDelta>Freq

PositionDelta --> VInt

TermPositions按照Ҏ排序Q依据于.tis文g中的，即项是隐含存在的Q?/SPAN>

Positions元组按照文档号升序排列?/SPAN>

PositionDelta是相对于前一个出C|的偏移位置Q或者ؓ0Q表C是第一ơ在q个文中出玎ͼ?/SPAN>

例如Q假设某一在某文第4出玎ͼ在另一个文中W?/SPAN>5和W?/SPAN>9出玎ͼ存在如下的VInt序列Q?/SPAN>

4, 5, 4

标准化因子（Normalization FactorQ?/SPAN>

.nrm文g包含了每个文的标准化因子，标准化因子用来以后乘以这个这个域的命中数?/SPAN>

Norms (.nrm) --> <Byte>SegSize

每个字节记录一个QҎ。位0-2包含?/SPAN>3位的数部分Q位3-8包含?/SPAN>5位的指数部分?/SPAN>

按如下规则可这些字节{换ؓIEEE标准单精度QҎQ?/SPAN>

1. 如果该字节是0Q就是Q?/SPAN>0Q?/SPAN>

2. 否则Q设|新点数的标志位ؓ0Q?/SPAN>

3. 字节中的指数加?/SPAN>48后作为新的QҎ的指敎ͼ

4. 字节中的尾数映到新QҎ数的高3位；q且

5. 讄新QҎ数的低21位ؓ0?/SPAN>

被删除的文Q?/SPAN>Deleted DocumentQ?/SPAN>

.del文g是可选的Q只有在某段中存在删除操作后才存在：

Deletions (.del) --> ByteCount,BitCount,Bits

ByteSize,BitCount --> Uint32

Bits --> <Byte>ByteCount

ByteCount表示的是Bits列表?/SPAN>Byte的数量。典型的Q它{于Q?/SPAN>SegSize/8Q?/SPAN>+1?/SPAN>

BitCount表示Bits列表中多个已经被设|过了?/SPAN>

Bits列表包含了一些位Q?/SPAN>bitQ，序表示一个文档。当对应于文号的位被设|了Q就标志着q个文已经被删除了。位的顺序是从低到高。因此，如果Bits包含两个字节Q?/SPAN>0x00?/SPAN>0x02Q那么表C文?/SPAN>9已经删除了?/SPAN>

局限性（LimitationsQ?/SPAN>

在以上的文g格式中，好几处都有限刉和文档的最大个Cؓ32位数的极限，xq于40ѝ今天看来，q不会造成问题Q但是，长远的看Q可能造成问题。因此，q些极限应该或者换?/SPAN>UInt64cd的|或者更好的Q换?/SPAN>VIntcd的|VInt值没有上限）?/SPAN>

有两处地方的代码要求必须是定长的|他们是：

1. FieldValuesPosition变量Q存储于域烦引文件中Q?/SPAN>.fdx文gQ。它已经是一?/SPAN>UInt64型，所以不会有问题?/SPAN>

2. TermCount变量Q存储于信息文件中Q?/SPAN>.tis文gQ。这是最后输出到文g中的Q但是最先被dQ因此是存储于文件的最前端 。烦引代码先在这里写入一?/SPAN>0|然后在其他文件输出完毕后覆盖q个倹{所以无论它存储在什么地方，它都必须是一个定长的|它应该被变成UInt64型?/SPAN>

除此之外Q所有的UInt值都可以换成VInt型以L限制?/SPAN>



gaich 2005-06-30 11:52 发表评论
]]>竹笋炒肉 --- Lucene学习W记http://m.tkk7.com/gaich/archive/2005/06/30/6931.htmlgaichgaichThu, 30 Jun 2005 03:33:00 GMThttp://m.tkk7.com/gaich/archive/2005/06/30/6931.htmlhttp://m.tkk7.com/gaich/comments/6931.htmlhttp://m.tkk7.com/gaich/archive/2005/06/30/6931.html#Feedback0http://m.tkk7.com/gaich/comments/commentRss/6931.htmlhttp://m.tkk7.com/gaich/services/trackbacks/6931.htmlhttp://hedong.3322.org/archives/000206.html

Lucene是一套全文检索的APIQ对其介l的文章和应用的案例都多Q可参?A title=我的一lucene备忘 >lucene及本文的参考文献?BR>　　此次学习Q以实用ZQ一是简单应用，二是Web应用Q三是汉化，四相兛_用（Lucene主页上在SandBox中）?A name=more>

0、准备工?BR>　　?A title="lucene is a apache project" >Lucene的主?/A>下蝲目前的稳定版本lucene-1.2.tar.gzQ解压羃Q将lucene-1.2目录下的两个jar文glucene-1.2.jar和lucene-demo2-1.2.jar攑ֈ适当的目录下后，q将其加入到CLASSPATH环境变量中?

tar zxvf lucene-1.2.tar.gz <----解压~?BR>cd lucene-1.2
cp *.jar $DP<---存放jar文g的目录，Ҏ具体工作要求用实际目录替?/INS>
CLASSPATH=$CLASSPATH:$DP/lucene-1.2.jar:$DP/lucene-demos-1.2.jar; export CLASSPATH
winclasspath.gif如果不想在每ơ都d后，可以~辑/etc/profile或自q录下?profileQ将上面的最后一行加到文件的最后一行。Windows的设|，叛_桌面的“我的电脑”，选“高U”－Q“环境变量”－Q选中CLASSPATHQ＞“编辑”，在输入框中加入两个jar文g的全路径名，注意分隔W是分号(;)。参见右图?

1、运行demo

$ java org.apache.lucene.demo.IndexFiles /usr/local/man/man1/ <--对man文g建立索引
adding /usr/local/man/man1/mysql.1
...........
adding /usr/local/man/man1/cvs.1
1614 total milliseconds
$ java org.apache.lucene.demo.SearchFiles <--q行?/INS>
Query: password
Searching for: password
7 total matching documents
0. /usr/local/man/man1/mysql.1
......
6. /usr/local/man/man1/mysqlshow.1
Query:
OK!Lucene自待的demoq行成功
q个demoE序调用的主要API函数:
/*关于索引的主要函?/
File file=new File(argv[]);
IndexWriter writer = new IndexWriter("index", new StandardAnalyzer(), true);

Document doc = new Document();
doc.add(Field.Text("path", file.getPath()));
doc.add(Field.Keyword("modified",DateField.timeToString(file.lastModified())));
FileInputStream is = new FileInputStream(f);
Reader reader = new BufferedReader(new InputStreamReader(is));
doc.add(Field.Text("contents", reader));

writer.addDocument(doc);

writer.optimize();
writer.close();

/*关于索的主要函数*/
Searcher searcher = new IndexSearcher("index");
Analyzer analyzer = new StandardAnalyzer();
Query query = QueryParser.parse(lineforsearch, "contents", analyzer);
Hits hits = searcher.search(query);
for (int i = start; i < hits.length(); i++) {
Document doc = hits.doc(i);
String path = doc.get("path");
System.out.println(i + ". " + path);
}


3、运行LuceneWeb
　　假定tomcat装在$TOMCATHOME目录下，具体应用时用真实的目录替?TOMCATHOME?

cd $TOMCATHOME/webapps
mkdir lucenedb
cd lucenedb
java org.apache.lucene.demo.IndexHTML -create -index $TOMCAT/webapps/lucenedb ../examples<--用相对\径?.”，一来指明被索引的文件的位置Q二来用来显C索引文g的URLQ因为检索的jspE序在luceneweb子目录下.examples可用其它的真实应用的目录名来替换
cd ..
cp ~/lucene-1.2/luceneweb.war . <--luceneweb.war在你解压~生成的lucene-1.2目录?/INS>
../bin/shudown.sh
../bin/startup.sh

然后通过客户端访问http://yourdomain.com:8080/luceneweb,如果利览器应出现双所C的内容?IMG height=151 alt=luceneweb-1.gif src="http://hedong.3322.org/archives/pics/luceneweb-1.gif" width=499 align=right border=0>.再到服务器端
cd luceneweb
vi configuration.jsp <--indexLocation 的值改?"$TOMCATHOME/webapps/lucenedb";
cd ..
jar -ur luceneweb.war luceneweb
再到客户端，h刚才的页面，然后可以输入单词进行检索了。遗憄是，此是只能索英文单词。且如果命中的html面的title是汉字的话，昄也有问题。如图?BR>luceneweb-2.gif
　　此处的IndexHTML,可以对htm、html和txtcd的文件进行烦引，用的是一个HTMLParserQ除此以外与上一例基本相同?img src ="http://m.tkk7.com/gaich/aggbug/6931.html" width = "1" height = "1" />

gaich 2005-06-30 11:33 发表评论
]]>ZJava的全文烦引引擎Lucene?http://m.tkk7.com/gaich/archive/2005/06/30/6928.htmlgaichgaichThu, 30 Jun 2005 03:19:00 GMThttp://m.tkk7.com/gaich/archive/2005/06/30/6928.htmlhttp://m.tkk7.com/gaich/comments/6928.htmlhttp://m.tkk7.com/gaich/archive/2005/06/30/6928.html#Feedback0http://m.tkk7.com/gaich/comments/commentRss/6928.htmlhttp://m.tkk7.com/gaich/services/trackbacks/6928.html关键词：Lucene java full-text search engine Chinese word segment

内容摘要Q?/FONT>

Lucene是一个基于Java的全文烦引工具包?/FONT>

作者： 车东 Email: chedongATbigfoot.com/chedongATchedong.com

写于Q?002/08 最后更斎ͼ 03/16/2005 16:27:52

  1. ZJava的全文烦引引擎Lucene介：关于作者和Lucene的历?/A>
  2. 全文索的实现QLuene全文索引和数据库索引的比?/A>
  3. 中文切分词机制简介：Z词库和自动切分词法的比?/A>
  4. 具体的安装和使用介：pȝl构介绍和演C?/A>
  5. Hacking LuceneQ简化的查询分析器，删除的实玎ͼ定制的排序，应用接口的扩?/A>
  6. 从Lucene我们q可以学C?/A>

ZJava的全文烦?索引擎——Lucene

Lucene不是一个完整的全文索引应用Q而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各U应用中实现针对应用的全文烦?索功能?/P>

Lucene的作者：Lucene的A献?A >Doug Cutting是一位资深全文烦?索专Ӟ曄是V-Twin搜烦引擎(Apple的Copland操作pȝ的成׃一)的主要开发者，后在Excite担Q高pȝ架构设计师，目前从事于一些INTERNET底层架构的研I。他贡献出的Lucene的目标是为各U中型应用E序加入全文索功能?/P>

Lucene的发展历E：早先发布在作者自qwww.lucene.comQ后来发布在SourceForgeQ?001q年底成为APACHE基金会jakarta的一个子目Q?A >http://jakarta.apache.org/lucene/

已经有很多Java目都用了Lucene作ؓ其后台的全文索引引擎Q比较著名的有：

  • JiveQWEB论坛pȝQ?
  • EyebrowsQ邮件列表HTML归/览/查询pȝQ本文的主要参考文?A >TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrowspȝ的主要开发者之一Q而EyeBrows已经成ؓ目前APACHE目的主要邮件列表归系l?
  • Cocoon:ZXML的web发布框架Q全文检索部分用了Lucene

  • Eclipse:ZJava的开攑ּ发^収ͼ帮助部分的全文烦引用了Lucene

对于中文用户来说Q最兛_的问题是其是否支持中文的全文索。但通过后面对于Lucene的结构的介绍Q你会了解到׃Lucene良好架构设计Q对中文的支持只需对其语言词法分析接口q行扩展p实现对中文检索的支持?/P>

全文索的实现机制

Lucene的API接口设计的比较通用Q输入输出结构都很像数据库的?=>记录==>字段Q所以很多传l的应用的文件、数据库{都可以比较方便的映到Lucene的存储结?接口中。M上看Q可以先?B>Lucene当成一个支持全文烦引的数据库系l?/B>?/P>

比较一下Lucene和数据库Q?/P>
Lucene 数据?/TD>
索引数据源：doc(field1,field2...) doc(field1,field2...)
                  \  indexer /
                 _____________
                | Lucene Index|
                --------------
                 / searcher \
 l果输出QHits(doc(field1,field2) doc(field1...))
 
 索引数据源：record(field1,field2...) record(field1..)
              \  SQL: insert/
               _____________
              | DB  Index   |
               -------------
              / SQL: select \
l果输出Qresults(record(field1,field2..) record(field1...))
DocumentQ一个需要进行烦引的“单元?BR>一个Document由多个字D늻?/TD> RecordQ记录，包含多个字段
FieldQ字D?/TD> FieldQ字D?/TD>
HitsQ查询结果集Q由匚w的Documentl成 RecordSetQ查询结果集Q由多个Recordl成

全文??like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表（比如Q北京：12, 34，上vQ?,77……）Q它能够帮助读者比较快地找到相兛_容的늠。而数据库索引能够大大提高查询的速度原理也是一P惛_一下通过书后面的索引查找的速度要比一一地d定w多少倍……而烦引之所以效率高Q另外一个原因是它是排好序的?B>对于索系l来说核心是一个排序问?/B>?/P>

׃数据库烦引不是ؓ全文索引设计的，因此Q?B>使用like "%keyword%"Ӟ数据库烦引是不v作用?/B>Q在使用like查询Ӟ搜烦q程又变成类g一页M的遍历过E了Q所以对于含有模p查询的数据库服务来_LIKEҎ能的危x极大的。如果是需要对多个关键词进行模p匹配：like"%keyword1%" and like "%keyword2%" ...其效率也可惌知了?/P>

所以徏立一个高效检索系l的关键是徏立一个类gU技索引一L反向索引机制Q将数据源（比如多篇文章Q排序顺序存储的同时Q有另外一个排好序的关键词列表Q用于存储关键词==>文章映射关系Q利用这L映射关系索引Q[关键?=>出现关键词的文章~号Q出现次敎ͼ甚至包括位置Qv始偏U量Q结束偏U量Q，出现频率]Q检索过E就是把模糊查询变成多个可以利用索引的精查询的逻辑l合的过E?/B>。从而大大提高了多关键词查询的效率，所以，全文索问题归l到最后是一个排序问题?/P>

由此可以看出模糊查询相对数据库的_查询是一个非怸定的问题，q也是大部分数据库对全文索支持有限的原因。Lucene最核心的特征是通过Ҏ的烦引结构实C传统数据库不擅长的全文烦引机Ӟq提供了扩展接口Q以方便针对不同应用的定制?/P>

可以通过一下表格对比一下数据库的模p查询：

　 Lucene全文索引引擎 数据?/TD>
索引 数据源中的数据都通过全文索引一一建立反向索引 对于LIKE查询来说Q数据传l的索引是根本用不上的。数据需要逐个便利记录q行GREP式的模糊匚wQ比有烦引的搜烦速度要有多个数量U的下降?/TD>
匚w效果 通过词元(term)q行匚wQ通过语言分析接口的实玎ͼ可以实现对中文等非英语的支持?/TD> 使用Qlike "%net%" 会把netherlands也匹配出来，
多个关键词的模糊匚wQ用like "%com%net%"Q就不能匚w词序颠倒的xxx.net..xxx.com
匚w?/TD> 有匹配度法Q将匚wE度Q相似度Q比较高的结果排在前面?/TD> 没有匚wE度的控Ӟ比如有记录中net出现5词和出现1ơ的Q结果是一L?/TD>
l果输出 通过特别的算法，最匚w度最高的?00条结果输出，l果集是~冲式的批量读取的?/TD> q回所有的l果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放q些临时l果集?/TD>
可定制?/TD> 通过不同的语a分析接口实现Q可以方便的定制出符合应用需要的索引规则Q包括对中文的支持） 没有接口或接口复杂，无法定制
l论 高负载的模糊查询应用Q需要负责的模糊查询的规则，索引的资料量比较?/TD> 使用率低Q模p匹配规则简单或者需要模p查询的资料量少

全文索和数据库应用最大的不同在于Q让最相关?/SPAN>?00条结果满?8%以上用户的需?BR>
Lucene的创C处：

大部分的搜烦Q数据库Q引擎都是用B树结构来l护索引Q烦引的更新会导致大量的IO操作QLucene在实CQ对此稍微有所改进Q不是维护一个烦引文Ӟ而是在扩展烦引的时候不断创建新的烦引文Ӟ然后定期的把q些新的烦引文件合q到原先的大索引中（针对不同的更新策略，Ҏ的大可以调_Q这样在不媄响检索的效率的前提下Q提高了索引的效率?/P>

Lucene和其他一些全文检索系l?应用的比较：

　 Lucene 其他开源全文检索系l?/TD>
增量索引和批量烦?/TD> 可以q行增量的烦?Append)Q可以对于大量数据进行批量烦引，q且接口设计用于优化扚w索引和小扚w的增量烦引?/TD> 很多pȝ只支持批量的索引Q有时数据源有一点增加也需要重建烦引?/TD>
数据?/TD> Lucene没有定义具体的数据源Q而是一个文的l构Q因此可以非常灵zȝ适应各种应用Q只要前端有合适的转换器把数据源{换成相应l构Q， 很多pȝ只针对网，~Z其他格式文的灵zL?/TD>
索引内容抓取 Lucene的文是由多个字D늻成的Q甚臛_以控刉些字D需要进行烦引，那些字段不需要烦引，q一步烦引的字段也分为需要分词和不需要分词的cdQ?BR>   需要进行分词的索引Q比如：标题Q文章内容字D?BR>   不需要进行分词的索引Q比如：作?日期字段 ~Z通用性，往往文整个烦引了
语言分析 通过语言分析器的不同扩展实现Q?BR>可以qo掉不需要的词：an the of {，
西文语法分析Q将jumps jumped jumper都归l成jumpq行索引/?BR>非英文支持：对亚z语aQ阿拉伯语言的烦引支?/TD> 		~Z通用接口实现
查询分析 通过查询分析接口的实玎ͼ可以定制自己的查询语法规则：
比如Q?多个关键词之间的 + - and or关系{?/TD> 		　
q发讉K 能够支持多用L使用 　

　

关于亚洲语言的的切分词问?Word Segment)

对于中文来说Q全文烦引首先还要解决一个语a分析的问题，对于英文来说Q语句中单词之间是天焉过I格分开的，但亚z语a的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行烦引的话，q个词如何切分出来就是一个很大的问题?/P>

首先Q肯定不能用单个字符?si-gram)为烦引单元，否则查“上”时Q不能让含有“v上”也匚w?/P>

但一句话Q“北京天安门”，计算机如何按照中文的语言习惯q行切分呢？
“北?天安门?q是“北 ?天安门”？让计机能够按照语言习惯q行切分Q往往需要机器有一个比较丰富的词库才能够比较准的识别句中的单词?/P>

另外一个解决的办法是采用自动切分算法：单词按?元语?bigram)方式切分出来Q比如：
"北京天安? ==> "北京 京天 天安 安门"?/P>

q样Q在查询的时候，无论是查?北京" q是查询"天安?Q将查询词组按同L规则q行切分Q?北京"Q?天安安门"Q多个关键词之间按与"and"的关pȝ合，同样能够正确地映到相应的烦引中。这U方式对于其他亚z语aQ韩文，日文都是通用的?/P>

Z自动切分的最大优Ҏ没有词表l护成本Q实现简单，~点是烦引效率低Q但对于中小型应用来_Z2元语法的切分q是够用的。基?元切分后的烦引一般大和源文件差不多Q而对于英文，索引文g一般只有原文g?0%-40%不同Q?/P>

自动切分 词表切分
实现 实现非常?/TD> 实现复杂
查询 增加了查询分析的复杂E度Q?/TD> 适于实现比较复杂的查询语法规?/TD>
存储效率 索引冗余大，索引几乎和原文一样大 索引效率高，为原文大的30Q左?/TD>
l护成本 无词表维护成?/TD> 词表l护成本非常高：中日韩等语言需要分别维护?BR>q需要包括词频统计等内容
适用领域 嵌入式系l：q行环境资源有限
分布式系l：无词表同步问?BR>多语a环境Q无词表l护成本		 Ҏ询和存储效率要求高的专业搜烦引擎

目前比较大的搜烦引擎的语a分析法一般是Z以上2个机制的l合。关于中文的语言分析法Q大家可以在Google查关键词"wordsegment search"能找到更多相关的资料?/P>

安装和?/B>

下蝲Q?A >http://jakarta.apache.org/lucene/

注意QLucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCCQJavaCompilerCompilerQ纯Java的词法分析生成器Q，所以如果从源代码编译或需要修改其中的QueryParser、定制自q词法分析器，q需要从https://javacc.dev.java.net/下蝲javacc?/P>

lucene的组成结构：对于外部应用来说索引模块(index)和检索模?search)是主要的外部应用入口

org.apache.Lucene.search/ 搜烦入口
org.apache.Lucene.index/ 索引入口
org.apache.Lucene.analysis/ 语言分析?/TD>
org.apache.Lucene.queryParser/ 查询分析?/TD>
org.apache.Lucene.document/ 存储l构
org.apache.Lucene.store/  底层IO/存储l构
org.apache.Lucene.util/ 一些公用的数据l构

单的例子演示一下Lucene的用方法：

索引q程Q从命o行读取文件名Q多个）Q将文g分\?path字段)和内?body字段)2个字D进行存储，q对内容q行全文索引Q烦引的单位是Document对象Q每个Document对象包含多个字段Field对象Q针对不同的字段属性和数据输出的需求，对字D还可以选择不同的烦?存储字段规则Q列表如下：
Ҏ 切词 索引 存储 用?/TH>
Field.Text(String name, String value) Yes Yes Yes 切分词烦引ƈ存储Q比如：标题Q内容字D?/TD>
Field.Text(String name, Reader value) Yes Yes No 切分词烦引不存储Q比如：META信息Q?BR>不用于返回显C，但需要进行检索内?/TD>
Field.Keyword(String name, String value) No Yes Yes 不切分烦引ƈ存储Q比如：日期字段
Field.UnIndexed(String name, String value) No No Yes 不烦引，只存储，比如Q文件\?/TD>
Field.UnStored(String name, String value) Yes Yes No 只全文烦引，不存?/TD>
public class IndexFiles { 
  //使用ҎQ? IndexFiles [索引输出目录] [索引的文件列表] ... 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0];
    IndexWriter writer;
    //用指定的语言分析器构造一个新的写索引器（W?个参数表C是否ؓq加索引Q?BR>    writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);

    for (int i=1; i<args.length; i++) {
      System.out.println("Indexing file " + args[i]);
      InputStream is = new FileInputStream(args[i]);

      //构造包?个字DField的Document对象
      //一个是路径path字段Q不索引Q只存储
      //一个是内容body字段Q进行全文烦引，q存?BR>      Document doc = new Document();
      doc.add(Field.UnIndexed("path", args[i]));
      doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
      //文档写入烦?BR>      writer.addDocument(doc);
      is.close();
    };
    //关闭写烦引器
    writer.close();
  }
}
　

索引q程中可以看刎ͼ

  • 语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的Q虽然lucene~省提供?个比较通用的分析器SimpleAnalyser和StandardAnalyserQ这2个分析器~省都不支持中文Q所以要加入对中文语a的切分规则，需要修改这2个分析器?
  • Luceneq没有规定数据源的格式，而只提供了一个通用的结构（Document对象Q来接受索引的输入，因此输入的数据源可以是：数据库，WORD文QPDF文档QHTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象卛_q行索引?
  • 对于大批量的数据索引Q还可以通过调整IndexerWrite的文件合q率属性（mergeFactorQ来提高扚w索引的效率?

索过E和l果昄Q?/P>

搜烦l果q回的是Hits对象Q可以通过它再讉KDocument==>Field中的内容?/P>

假设Ҏbody字段q行全文索，可以查询结果的path字段和相应查询的匚w?score)打印出来Q?/P>

public class Search { 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0], queryString = args[1];
    //指向索引目录的搜索器
    Searcher searcher = new IndexSearcher(indexPath);
    //查询解析器：使用和烦引同L语言分析?BR>    Query query = QueryParser.parse(queryString, "body", 
                              new SimpleAnalyzer());
    //搜烦l果使用Hits存储
    Hits hits = searcher.search(query);
    //通过hits可以讉K到相应字D늚数据和查询的匚w?BR>    for (int i=0; i<hits.length(); i++) {
      System.out.println(hits.doc(i).get("path") + "; Score: " + 
                         hits.score(i));
    };
  }
}
在整个检索过E中Q语a分析器，查询分析器，甚至搜烦器（SearcherQ都是提供了抽象的接口，可以Ҏ需要进行定制?

Hacking Lucene

化的查询分析?/B>

个h感觉lucene成ؓJAKARTA目后，d了太多的旉用于调试日趋复杂QueryParserQ而其中大部分是大多数用户q不很熟悉的Q目前LUCENE支持的语法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")

中间的逻辑包括Qand or + - &&||{符P而且q有"短语查询"和针对西文的前缀/模糊查询{，个h感觉对于一般应用来_q些功能有一些华而不实，其实能够实现目前cM于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择?/P>

d修改删除指定记录QDocumentQ?/B>

Lucene提供了烦引的扩展机制Q因此烦引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另徏索引Q然后利用IndexReader.delete(Termterm)Ҏ通过q个记录ID删除相应的Document?/P>

Ҏ某个字段值的排序功能

lucene~省是按照自q相关度算法（scoreQ进行结果排序的Q但能够Ҏ其他字段q行l果排序是一个在LUCENE的开发邮件列表中l常提到的问题，很多原先Z数据库应用都需要除了基于匹配度QscoreQ以外的排序功能。而从全文索的原理我们可以了解刎ͼM不基于烦引的搜烦q程效率都会D效率非常的低Q如果基于其他字D늚排序需要在搜烦q程中访问存储字D，速度回大大降低，因此非常是不可取的?/P>

但这里也有一个折中的解决ҎQ在搜烦q程中能够媄响排序结果的只有索引中已l存储的docID和scoreq?个参敎ͼ所以，Zscore以外的排序，其实可以通过数据源预先排好序，然后ҎdocIDq行排序来实现。这样就避免了在LUCENE搜烦l果外对l果再次q行排序和在搜烦q程中访问不在烦引中的某个字D倹{?/P>

q里需要修改的是IndexSearcher中的HitCollectorq程Q?/P>

...
　scorer.score(new HitCollector() {
	private float minScore = 0.0f;
	public final void collect(int doc, float score) {
	  if (score > 0.0f &&			  // ignore zeroed buckets
	      (bits==null || bits.get(doc))) {	  // skip docs not in bits
	    totalHits[0]++;
	    if (score >= minScore) {
              /* 原先QLucenedocID和相应的匚w度score例入l果命中列表中：
	       * hq.put(new ScoreDoc(doc, score));	  // update hit queue
               * 如果用doc ?1/doc 代替 scoreQ就实现了根据docID排或逆排
               * 假设数据源烦引时已经按照某个字段排好了序Q而结果根据docID排序也就实现?BR>               * 针对某个字段的排序，甚至可以实现更复杂的score和docID的拟合?BR>               */
              hq.put(new ScoreDoc(doc, (float) 1/doc )); 
	      if (hq.size() > nDocs) {		  // if hit queue overfull
		hq.pop();			  // remove lowest in hit queue
		minScore = ((ScoreDoc)hq.top()).score; // reset minScore
	      }
	    }
	  }
	}
      }, reader.maxDoc());

更通用的输入输出接?/B>

虽然lucene没有定义一个确定的输入文档格式Q但来多的h惛_使用一个标准的中间格式作ؓLucene的数据导入接口，然后其他数据Q比如PDF只需要通过解析器{换成标准的中间格式就可以q行数据索引了。这个中间格式主要以XMLZQ类似实现已l不?Q?个：

数据? WORD       PDF     HTML    DB       other
         \          |       |      |         /
                       XML中间格式
                            |
                     Lucene INDEX

目前q没有针对MSWord文档的解析器Q因为Word文和基于ASCII的RTF文不同Q需要用COM对象机制解析。这个是我在Google上查的相兌料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文转换成textQ?A >http://www.winfield.demon.nl/index.html


索引q程优化

索引一般分2U情况，一U是批量的索引扩展Q一U是大批量的索引重徏。在索引q程中，q不是每ơ新的DOC加入q去索引都重新进行一ơ烦引文件的写入操作Q文件I/O是一仉常消耗资源的事情Q?/P>

Lucene先在内存中进行烦引操作，q根据一定的扚wq行文g的写入。这个批ơ的间隔大Q文件的写入ơ数少Q但占用内存会很多。反之占用内存少Q但文gIO操作频繁Q烦引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造烦引器后根据应用环境的情况充分利用内存减少文g的操作。根据我的用经验：~省Indexer是每20条记录烦引后写入一ơ，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左叟?BR>

搜烦q程优化

lucene支持内存索引Q这L搜烦比基于文件的I/O有数量的速度提升?BR>http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和Ҏ索结果的前台的缓存也是必要的?BR>

Lucene面向全文索的优化在于首次索引索后Qƈ不把所有的记录QDocumentQ具体内容读取出来，而v只将所有结果中匚w度最高的?00条结果（TopDocsQ的ID攑ֈl果集缓存中q返回，q里可以比较一下数据库索：如果是一?0,000条的数据库检索结果集Q数据库是一定要把所有记录内定w取得以后再开始返回给应用l果集的。所以即使检索匹配L很多QLucene的结果集占用的内存空间也不会很多。对于一般的模糊索应用是用不到这么多的结果的Q头100条已l可以满?0%以上的检索需求?BR>

如果首批~存l果数用完后q要d更后面的l果时Searcher会再ơ检索ƈ生成一个上ơ的搜烦~存数大1倍的~存Qƈ再重新向后抓取。所以如果构造一个SearcherL1Q?20条结果，Searcher其实是进行了2ơ搜索过E：?00条取完后Q缓存结果用完，Searcher重新索再构造一?00条的l果~存Q依此类推，400条缓存，800条缓存。由于每ơSearcher对象消失后，q些~存也访问那不到了，你有可能惛_l果记录~存下来Q缓存数量保证?00以下以充分利用首ơ的l果~存Q不让Lucene费多次索，而且可以分q行l果~存?BR>

Lucene的另外一个特Ҏ在收集结果的q程中将匚w度低的结果自动过滤掉了。这也是和数据库应用需要将搜烦的结果全部返回不同之处?/P>

我的一些尝?/A>Q?/P>

从Lucene学到更多

Luene的确是一个面对对象设计的典范

  • 所有的问题都通过一个额外抽象层来方便以后的扩展和重用：你可以通过重新实现来达到自q目的Q而对其他模块而不需要；
  • 单的应用入口Searcher, IndexerQƈ调用底层一pdlg协同的完成搜索Q务；
  • 所有的对象的Q务都非常专一Q比如搜索过E：QueryParser分析查询语句{换成一pd的精查询的l合(Query),通过底层的烦引读取结构IndexReaderq行索引的读取，q用相应的打分器l搜索结果进行打?排序{。所有的功能模块原子化程度非帔RQ因此可以通过重新实现而不需要修改其他模块?nbsp;
  • 除了灉|的应用接口设计，Luceneq提供了一些适合大多数应用的语言分析器实玎ͼSimpleAnalyser,StandardAnalyserQ，q也是新用户能够很快上手的重要原因之一?

q些优点都是非常值得在以后的开发中学习借鉴的。作Z个通用工具包，Lunece的确l予了需要将全文索功能嵌入到应用中的开发者很多的便利?/P>

此外Q通过对Lucene的学习和使用Q我也更深刻地理解了Z么很多数据库优化设计中要求，比如Q?/P>

  • 可能对字段q行索引来提高查询速度Q但q多的烦引会Ҏ据库表的更新操作变慢Q而对l果q多的排序条Ӟ实际上往往也是性能的杀手之一?
  • 很多商业数据库对大批量的数据插入操作会提供一些优化参敎ͼq个作用和烦引器的merge_factor的作用是cM的，
  • 20%/80%原则Q查的结果多q不{于质量好，其对于q回l果集很大，如何优化q头几十条结果的质量往往才是最重要的?
  • 可能让应用从数据库中获得比较小的结果集Q因为即使对于大型数据库Q对l果集的随机讉K也是一个非常消耗资源的操作?BR>

参考资料：

Apache: Lucene Project
http://jakarta.apache.org/lucene/
Lucene开?用户邮g列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org

The Lucene search engine: Powerful, flexible, and free
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html

Lucene Tutorial
http://www.darksleep.com/puff/lucene/lucene.html

Notes on distributed searching with Lucene
http://home.clara.net/markharwood/lucene/

中文语言的切分词
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment

搜烦引擎工具介绍
http://searchtools.com/

Lucene作者Cutting的几论文和专利
http://lucene.sourceforge.net/publications.html 

Lucene?NET实现QdotLucene
http://sourceforge.net/projects/dotlucene/

Lucene作者Cutting的另外一个项目：ZJava的搜索引擎Nutch
http://www.nutch.org/   http://sourceforge.net/projects/nutch/

关于Z词表和N-Gram的切分词比较
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html

2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座：非常详细的Lucene架构解说



gaich 2005-06-30 11:19 发表评论
]]> վ֩ģ壺 99ƷƵѹۿ| þëƬѿһ| 99ƷƵ߹ۿ| ëƬv߲һ| ƷƵ| ߹ۿ| jyzzjyzzѹۿ| 輤һ| ĻѲ| ˳һ| Ʒҹҹ| þþƷƵ| һëƬ| ŷഺɫУ԰վ| ŮëƬaѧëƬ| ޳a޳av | ˳˳ۺþ| ҳվ߹ۿ| ޾Ʒר| ޳?߹ۿ| þùƷ| Ʒһɫ | ӰԺMV߹ۿƵ| þԭAV鶹| ۺƵ| avһ߲ | պƷרվ| | ƬAëƬ鴤ɫ| ֮4δɾ| ޹Ƭ߹ۿ| 100018Ƶ| ޾ƷۺϾþþþý| һA| ߹ۿavվ| 㽶Ƶ߹ۿ| Ƶһ| ҰƵѹۿ| þ99ȾƷѹۿţţ| ޹Ʒ߹ۿ| ޳avƬ߹ۿ|