Thursday, March 5, 2009

反向索引-Inverted Index

以下来自维基百科

倒排索引(Inverted index),也常被称为反向索引置入档案反向档案,是一种索引方法,被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。

有两种不同的反向索引形式:

  • 一条记录的水平反向索引(或者反向档案索引)包含每个引用单词的文档的列表。
  • 一个单词的水平反向索引(或者完全反向索引)又包含每个单词在一个文档中的位置。

后者的形式提供了更多的兼容性(比如短语搜索),但是需要更多的时间和空间来创建。 以英文为例,下面是要被索引的文本:
  • T0 = "it is what it is"
  • T1 = "what is it"
  • T2 = "it is a banana"

我们就能得到下面的反向文件索引:

 "a":      {2}
"banana": {2}
"is": {0, 1, 2}
"it": {0, 1, 2}
"what": {0, 1}

检索的条件"what", "is""it" 将对应这个集合:\{0,1\} \cap \{0,1,2\} \cap \{0,1,2\} = \{0,1\}

对相同的文字,我们得到后面这些完全反向索引,有文档数量和当前查询的单词结果组成的的成对数据。 同样,文档数量和当前查询的单词结果都从零开始。所以,"banana": {(2, 3)} 就是说 "banana"在第三个文档里 (T2),而且在第三个文档的位置是第四个单词(地址为 3)。

"a":      {(2, 2)}
"banana": {(2, 3)}
"is": {(0, 1), (0, 4), (1, 1), (2, 1)}
"it": {(0, 0), (0, 3), (1, 2), (2, 0)}
"what": {(0, 2), (1, 0)}

如果我们执行短语搜索"what is it" 我们得到这个短语的全部单词各自的结果所在文档为文档0和文档1。但是这个短语检索的连续的条件仅仅在文档1得到。

-------------------------------------------------------

为什么要提出这样一种索引方式呢?

举个例子,如果有两个文档,doc1 & doc2 内容分别如下:
Doc1: it is what it is.
Doc2: what is it.

正向索引建立:
文档名 关键字 次数
Doc1 it 2
Doc1 is 2
Doc1 what 1
Doc2 what 1
Doc2 is 1
Doc2 it 1

不难发现,对于单文档内部检索,正向索引的建立,可以保证快速的进行检索。但对于全文检索,却很难有很好的性能,甚至由于实际资源的限制,而不可行。

“正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。”

题外话:
在设计某个问题的解决方案时,可能自身由于一直深入于整个工作,对问题的理解越来越深,不断有新的思路出来,继续不断有些方案出来,从来最终形成了整个解决方案。但或许,在整个过程中的某个时刻,跳出来,可能会有更高效的方法。比方说,可以参照算法方法论,如动态规划、贪心算法等来进行具体方案的求解。

Keywords: Inverted index; full-text search

Monday, February 16, 2009

关于版本控制的思考

1. 对于一个公共的配置文件,可能一个产品的很多模块都在使用,经常会出现并行修改。我们需要将这个配置文件按照各个模块进行分拆吗?

驳斥:这本身就是版本控制工具的优点之一。对于公共配置文件而言,使用版本控制的并行修改再diff-merge 很好的解决了将文件按照功能进行分布造成的文件的繁多和复杂。

但是,如果该文件不是文本格式。比如对于开源的自动测试框架 Robot Framework,Test case 全是html的,内部都是表格,diff 不能很好的分辨出文件更改的部分,于是,就变成了最原始的手动diff,然后手动merge,当文件越来越大,带来的后果也许是灾难性的。按照功能对公共文件进行切割未必是个坏的、完全做无用功的方案。

2. 在对代码进行更改后,还需要在后面加上 // Modified by Chris, 2009.02.16. 类似字样吗?

驳斥:那干脆别用版本控制工具了。

的确,这个问题的争论在很多bbs上都看过了。使用任何一个版本控制工具,完全可以通过历史记录查到某某时间某某人修改过哪几行代码。但对遗留代码的更新时,加上自己的签名未必是个坏事儿。我们可以迅速地知道曾经改过那几行,以及在出现错误时,迅速去定位是否是自己更改的代码跟原先的代码冲突或者矛盾。

3. 在更改过bug时,是否需要在更改的语句后面,加上 // Bug fixed : why, how, pay attention. 等来描绘出现bug的条件,如何解决的,以及未来需要注意的。

驳斥:版本控制工具在提交时是可以添加comments的,添加上提交所更改的东西就可以了。或者可以使用其他的 bug trace 工具。

这样做当然是可以的。但比如后来,有人需要去进行代码的更改,刚好改了这一行,也许以前辛辛苦苦更改掉的bug,又出现了。但如果有这句注释在后面,在别人进行更改的时候,看到这行话,他就会知道,奥,这个地方可能会出现这样一个bug,需要注意这些东西。。。,也许代码质量会因此更高。

也许,上述的几个问题,对于某些人来讲可能嗤之以鼻,他会拿出一系列的解决方案来完美的解决这些问题。OK,那是好事儿。我在这儿想说的是,版本控制只是一个工具,不需要教条的为了遵守而遵守,有时候,一些不规范,不是末日。

Keywords: version control;