• 提示词明确要求JSON
• 提示词中给出JSON样例
• 指定结果开头字符为{
• 调整模型参数
• 重试

提示词明确要求JSON

这是最直接的方法，直接在提示词中提要求，类似这样：

请描述这张图片，输出用JSON格式

就可以让LLM输出JSON格式

当然，这种方法不是100%让结果是JSON，有时候结果会是Markdown，有时候干脆就不是结构化的文本。

提示词中给出JSON样例

给出JSON样例的好处，是可以让LLM在生成的JSON中使用指定的key name。

例如，提示这么写：

描述这张图片，输出为JSON格式，例如{“desc”: “somebody is dancing”, “character_count”: 3}

产生的结果真的就包含desc和character_count两个key。

这是一个业内公认的方法，但是，在实操过程中，我发现对llama 3.2 vision使用这招产生非JSON输出的概率反而更大了，可能因为『描述图片内容』这个任务不容易让LLM上道输出指定的JSON。

指定结果开头字符为{

前面的方法，有可能结果虽然包含JSON，但是在JSON之前还要加一段废话，为了强制LLM只输出JSON，还有一招，就是在提示词中要求LLM输出以{开头（当然JSON也可以是以[开头），这样更大概率输出的就只有JSON。

上面这些都是在提示词上做文章，除此之外，在模型参数上也可以做一些trick。

调整模型参数

对于OpenAI的API，可以通过调整 logit_bias 来操纵输出token的概率，比如下面的配置，可以增加 { 和 } 字符的输出概率，减少 ''' 的输出概率，从而增大输出为JSON的概率。

1
2
3
4
5
6
7

logit_bias: {
  "90": 10, //  token ID for "{"
  "92": 10,  //  token ID for "}"
  "19317": -10, // token ID for "'''"
  "19317": -10, // token ID for "'''"
  "74694": -10 // token ID for "```"   
}

llama 3.2没有对等的logits_bias参数，但是我试了一下调整 temperature 和 top_p 参数，降低temperature和top_p的值，可以让模型少点『创意思维』，老老实实规规矩矩输出，似乎（我只敢说似乎）能够让模型更大概率遵守提示词以JSON格式输出。

重试

• 依赖管理的始末
  • npm2
  • npm3
  • 结论
• PNPM
  • 依赖安装
  • 依赖管理原理
  • PNPM 机制
    • 基于软链接的 node_modules
  • PNPM 锁文件
• 总结

依赖管理的始末

npm2

使用早期的 npm1/2 安装依赖，node_modules 文件夹会以递归的形式呈现，严格按照 package.json 结构以及次级依赖的 package.json 结构将依赖安装到它们各自的 node_modules 中，直到次级依赖不再依赖其它模块。

就像下面这样，tea-app 依赖 tea-component 作为次级依赖，tea-component 会安装到 tea-component 的 node_modules 里面：

1
2
3
4
5
6
7
8

node_modules
└─ tea-app
   ├─ index.js
   ├─ package.json
   └─ node_modules
      └─ tea-component
         ├─ index.js
         └─ package.json

假设项目的中的两个依赖同时依赖了相同的次级依赖，那么它们二者的次级依赖将会被重复安装：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

node_modules
├─ tea-app
│  ├─ index.js
│  ├─ package.json
│  └─ node_modules
│      └─ tea-component
│          ├─ index.js
│          └─ package.json
└─ tea-chart
   ├─ index.js
   ├─ package.json
   └─ node_modules
       └─ tea-component
           ├─ index.js
           └─ package.json

这只是简单的例子，那如果 tea-component 还依赖别的包，别的包又依赖另外的包…… 在真实的开发场景中其问题还会更加恶劣：

1. 依赖层级太深，会导致文件路径过长
2. 重复的包被安装，导致 node_modules 文件体积巨大，占用过多的磁盘空间

npm3

自 npm3/yarn 开始，相比 npm1/2 项目依赖管理的方式有了很大的改变，不再是以往的“嵌套式”而是采用了“扁平化”方式去管理项目依赖。

这里继续拿上面的例子，tea-app 和 tea-chart 都依赖了 tea-component，依赖安装后呈现的是下面的这种扁平化目录：

1
2
3
4
5
6
7
8
9
10

node_modules
├─ tea-component
│  ├─ index.js
│  └─ package.json
├─ tea-app
│  ├─ index.js
│  └─ package.json
└─ tea-chart
   ├─ index.js
   └─ package.json

扁平化的目录的确解决了上一小节暴露的一些问题，同时也暴露了新的问题：

• Phantom dependencies

称为幽灵依赖，指的是在项目内引用未在 package.json 中定义的包。这个问题在 npm3 展现，因为早期的树形结构导致了依赖冗余和路径过深的问题，npm3 之后采用扁平化的结构，一些第三方包的次级依赖提升到了与第三方包同级。

一旦出现幽灵依赖的问题，可能会导致意想不到的错误，所以一定要正视：

1. 不兼容的版本（例如某一个 api 进行了重大更新)

2. 有可能会丢失依赖（某依赖不再依赖呈现在我们项目中的幽灵依赖)

   1 2	// tea-component 就属于是幽灵依赖，因为它是属于 tea-app、tea-chart 的次级依赖。 import { Button } from 'tea-component';

3. NPM doppelgangers

称为分身依赖依赖的同名包都会被重复安装。

在实际开发中也会出现这样的情景，假设 tea-app、tea-form 依赖 tea-component@2.0.0，tea-chart 依赖 tea-component@3.0.0，这时候会造成依赖冲突，解决冲突的方式会将对应的冲突包放到对应依赖目录的 node_mudules 中，类似下面结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

node_modules
├─ tea-component@3.0.0
│  ├─ index.js
│  └─ package.json
├─ tea-app
│  ├─ index.js
│  ├─ package.json
│  └─ node_modules
│      └─ tea-component@2.0.0
│          ├─ index.js
│          └─ package.json
├─ tea-form
│  ├─ index.js
│  ├─ package.json
│  └─ node_modules
│      └─ tea-component@2.0.0
│          ├─ index.js
│          └─ package.json
└─ tea-chart
   ├─ index.js
   └─ package.json

这时候会发现一个问题，tea-app、tea-form 的 node_modules 下都有重复且版本相同的 tea-component@2.0.0，这个问题就是我们正在所说的“分身依赖”的问题。这个问题就会导致 tea-app 中的 ConfigProvider 组件和 tea-form 的不是一个实例，无法生效。

常见的问题：

1. 项目打包会将这些“重身”的依赖都进行打包，增加产物体积
2. 无法共享库实例，引用的得到的是两个独立的实例
3. 重复 TypeScript 类型，可能会造成类型冲突

结论

1. 扁平化的 node_modules 结构允许访问没有在 package.json 中声明的依赖。
2. 安装效率低，大量依赖被重复安装，磁盘空间占用高。
3. 多个项目之间已经安装过的的包不能共享，每次都是重新安装。

PNPM

Fast, disk space efficient package manager (速度快、节省磁盘空间的软件包管理器)

当使用 npm 或 Yarn 时，如果你有 100 个项目，并且所有项目都有一个相同的依赖包，那么， 你在硬盘上就需要保存 100 份该相同依赖包的副本。然而，如果是使用 pnpm，依赖包将被 存放在一个统一的位置，因此：

如果你对同一依赖包需要使用不同的版本，则仅有 版本之间不同的文件会被存储起来。例如，如果某个依赖包包含 100 个文件，其发布了一个新 版本，并且新版本中只有一个文件有修改，则pnpm update只需要添加一个 新文件到存储中，而不会因为一个文件的修改而保存依赖包的 所有文件。

所有文件都保存在硬盘上的统一的位置。当安装软件包时， 其包含的所有文件都会硬链接自此位置，而不会占用 额外的硬盘空间。这让你可以在项目之间方便地共享相同版本的 依赖包。

最终结果就是以项目和依赖包的比例来看，你节省了大量的硬盘空间， 并且安装速度也大大提高了！

依赖安装

使用 pnpm 安装，pnpm 会将依赖存储在位于 .pnpm-store 目录下。只要你在同一机器下，下次安装依赖的时候 pnpm 会先检查 store 目录，如果有你需要的依赖则会通过一个硬链接到你的项目中去，而不是重新安装依赖。

依赖管理原理

pnpm 会将依赖存储在 store 目录下，通过符号链接的方式仅将项目的直接依赖项添加到 node_modules 的根目录下。

当使用 npm 或 yarn 安装依赖包时，所有软件包都将被提升到 node_modules 的 根目录下。其结果是，源码可以访问 本不属于当前项目所设定的依赖包。

PNPM 机制

如果 store 目录里面拥有即将需要下载的依赖，下载将会跳过，会向对应项目 node_modules 中去建立硬链接，并非去重新安装它。这里就表明为什么 pnpm 性能这么突出了，最大程度节省了时间消耗和磁盘空间。

基于软链接的 node_modules

pnpm 输出的 node_modules 与 npm/yarn 有很大的出入，并非是先者那样的“扁平化目录”而是“非扁平化目录”。

创建两个目录并分别运行 npm add express，pnpm add express。

这是使用 npm 安装 node_modules 的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

.bin
accepts
array-flatten
body-parser
bytes
content-disposition
cookie-signature
cookie
debug
depd
destroy
ee-first
encodeurl
escape-html
etag
express

这个则是 pnpm 安装 node_modules 的结构：

1
2
3

.pnpm
.modules.yaml
express

打开 .pnpm 目录会发现这些依赖都被“扁平化”了，每个包都携带着自己的版本号。pnpm 这样设计的目的我理解其实是为了解决“分身依赖”的问题。

假设我们有这么一个情景，项目中依赖了 tea-app@1.0.0、tea-chart@1.0.0 和 tea-component@2.0.0。tea-chart 和 tea-app 依赖了 tea-component@1.0.0 那它引用关系是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

node_modules
├─tea-app -> ./.pnpm/tea-app@1.0.0/node_modules/tea-app
├─tea-chart -> ./.pnpm/tea-chart@1.0.0/node_modules/tea-chart
├─tea-component -> ./.pnpm/tea-component@2.0.0/node_modules/tea-component
└─.pnpm
    ├─ tea-app@1.0.0
    │   └─ node_modules
    │       ├─ tea-component -> ../tea-component@1.0.0/node_modules/tea-component
    │       └─ tea-app -> <store>/tea-app
        ├─ tea-chart@1.0.0
    │   └─ node_modules
    │       ├─ tea-component -> ../tea-component@1.0.0/node_modules/tea-component
    │       └─ tea-chart -> <store>/tea-chart
        ├─ tea-component@1.0.0
    │   └─ node_modules
    │       └─ tea-component -> <store>/tea-component@1.0.0
    └─ tea-component@2.0.0
        └─ node_modules
            └─ tea-component -> <store>/tea-component@2.0.0

为什么需要通过软链接的方式去引用实际的依赖？

这样设计的目的是解决“幽灵依赖”的问题，只有声明过的依赖才会以软链接的形式出现在 node_modules 目录中。在实际项目中引用的是软链接，软链接指向的是 .pnpm 的真实依赖，所以在日常开发中不会引用到未在 package.json 声明的包。

PNPM 锁文件

pnpm 产出的是一个 pnpm-lock.yaml 格式的锁文件。

支持通过 pnpm import 从另一个包管理器的锁文件生成一个。支持的源文件：

• package-lock.json
• npm-shrinkwrap.json
• yarn.lock

总结

npm2 是通过嵌套的方式管理 node_modules 的，会有同样的依赖复制多次的问题。

npm3+ 和 yarn 是通过铺平的扁平化的方式来管理 node_modules，解决了嵌套方式的部分问题，但是引入了幽灵依赖的问题，并且同名的包只会提升一个版本的，其余的版本依然会复制多次。

pnpm 则是用了另一种方式，不再是复制了，而是都从全局 store 硬连接到 node_modules/.pnpm，然后之间通过软链接来组织依赖关系。

这样不但节省磁盘空间，也没有幽灵依赖问题，安装速度还快，从机制上来说完胜 npm 和 yarn。

Python 版本管理工具的主要作用是帮助开发者在同一台机器上管理多个 Python 版本和环境。这对于开发和部署不同项目非常有用，因为不同项目可能依赖不同的 Python 版本或者不同的包版本。具体来说，Python 版本管理工具应有以下功能：

（1）避免依赖冲突，不同的项目可能依赖不同版本的库，使用版本管理工具可以创建独立的虚拟环境，避免依赖冲突。

（2）简化开发流程，开发者可以轻松地在不同的 Python 版本之间切换，而不需要重新安装或配置 Python。

（3）便于部署，减少冲突。在开发环境中使用与生产环境相同的 Python 版本和依赖，可以减少部署时出现的问题。

（4）共享环境配置，提高开发环境一致性。可以将环境配置文件（如 requirements.txt 或 pyproject.toml）共享给团队成员，确保大家使用相同的开发环境。

一、工具选择

常见的管理工具有 Pyenv 和 Conda。Pyenv 是当前最流行的 Python 版本管理工具，支持多种 Python 版本，如 CPython、Anaconda、PyPy 等，功能全面且简单易用。Conda 最初由 Anaconda, Inc. 开发，主要用于 Python 和 R 编程语言的软件包（含 Python）及环境管理，特别适合跨平台、多语言项目，Python 版本管理只是其一小部分功能，若仅用于管理 Python 版本，Conda 有些大材小用，且系统较复杂、学习成本略高。相比之下，Pyenv 是常规项目 Python 版本管理的最优选择。

以下详细介绍 Pyenv 的使用方法。

二、Pyenv 安装

建议： 先卸载系统内置的 Python，否则可能导致 pyenv 设置不生效。

1. Windows

pyenv 本身是为 Unix 系统设计的。你可以使用 pyenv-win 这个项目，它是 pyenv 的 Windows 版本。

你需要在 PowerShell 中执行以下命令安装 pyenv-win：

1

Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

重新打开 PowerShell，运行 pyenv –version 检查安装是否成功。

2. Linux

你可以使用以下命令来安装 pyenv：

1

curl https://pyenv.run | bash

之后再将 pyenv 配置到环境变量中并使之生效，执行如下命令：

1
2
3
4

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc 
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc 
echo 'eval "$(pyenv init -)"' >> ~/.bashrc 
source ~/.bashrc

上述配置仅能使 pyenv 在 bash 环境生效，更多 shell 环境配置请参考：Set up your shell environment for Pyenv。配置的本质在于将$PYENV_ROOT 下的 shims 和 bin 目录配置到 PATH 变量中，且 shims 需配置在前。配置后的 PATH 如下：

1

# echo $PATH /root/.pyenv/shims:/root/.pyenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

三、Pyenv 基本用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

## 查看帮助文档 
pyenv
## 查看某个命令帮助文档
pyenv install --help
## 查看版本
pyenv version
## 检查 Python 是否正常运行 
python -c "import sys; print(sys.executable)" 
## 查看已安装的 Python 版本 
pyenv versions 
## 查看当前使用的 Python 版本 
pyenv version 
## 查看所有可用的 Python 版 
pyenv install --list
## 安装指定版本 
pyenv install 3.9.1 
## 验证
python --version
## 卸载指定版本 
pyenv uninstall 3.9.1
## 全局指定 Python 版本（影响所有项目） 
pyenv global 3.9.1 
## 局部指定 Python 版本（仅影响当前项目目录），指定后在当前项目目录内创建 .python-version 文件，保存版本信息## 优先级高于 global
pyenv local 3.9.1 
## 会话级指定 Python 版本（影响所有项目） 
pyenv shell 3.9.1
## 查看 python 的安装目录
pyenv which python 
## 重新生成 pyenv 的 shims 目录中的可执行文件
pyenv rehash

Python 安装常见问题，可参考：Python common build problems

四、Pyenv 核心原理 -Shims

pyenv 通过 Shims 实现了对不同 Python 版本的透明管理和切换。

1. 工作原理

上述环境配置中，在 PATH 环境变量最前面插入一个 shims 目录，$(pyenv root)/shims:$(pyenv root)/bin:/usr/local/bin:/usr/bin:/bin。通过一个称为 rehashing 的过程，pyenv 在该目录中维护垫片，以匹配每个已安装的 Python 版本中的每个 Python 命令，如： python、pip 等。

Shims 是轻量级可执行文件，它只是将你的命令传递给 pyenv。因此，在安装了 pyenv 的情况下，当你运行 pip 时，你的操作系统将执行以下操作：

（1）搜索 PATH 环境变量，寻找 pip 可执行文件

（2）在 $(pyenv root)/shims 中找到 pip

（3）运行名为 pip 的 shim，它将命令传递给 pyenv

2. 作用

（1）通过使用 Shims，pyenv 可以实现对不同项目使用不同 Python 版本的灵活管理，而不需要手动修改环境变量或路径。

（2）你可以方便地在全局、目录级别甚至是 shell 会话级别设置或切换 Python 版本，极大地方便了开发和测试工作。

3. 示例

（1）假设你在项目 A 中使用 Python 3.8，而在项目 B 中使用 Python 3.9。通过 pyenv 和 Shims，你可以在项目目录中分别设置 Python 版本：

1
2
3
4

# 在项目 A 目录中 
pyenv local 3.8.10 
# 在项目 B 目录中
pyenv local 3.9.5

（2）当你在项目 A 目录中运行 python 命令时，Shims 会确保调用的是 Python 3.8.10，而在项目 B 目录中则会调用 Python 3.9.5。

通过这种方式，Shims 实现了对不同 Python 版本的透明管理和切换。

五、Pyenv 初始化操作源码解读

1. pyenv init -

用于初始化 pyenv，使其在当前 shell 会话中工作。运行后，执行如下命令（相关说明附在注释中）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# 1.PATH 变量处理
## 该脚本将当前的 PATH 变量拆分为一个数组 paths，并赋予
## 通过遍历 paths 数组，检查每个路径是否为 '/root/.pyenv/shims'，如果是，则将其移除
PATH="$(bash --norc -ec 'IFS=:; paths=($PATH); 
for i in ${!paths[@]}; do 
if [[ ${paths[i]} == "''/root/.pyenv/shims''" ]]; then unset '\''paths[i]'\''; 
fi; done; 
echo "${paths[*]}"')" # 

# 2. 更新 PATH 变量
## 将 '/root/.pyenv/shims' 添加到 PATH 变量的最前面
export PATH="/root/.pyenv/shims:${PATH}"
## 设置 PYENV_SHELL 环境变量为 bash，sh 环境下，输出的是 shell
export PYENV_SHELL=bash
## sh 环境下，无该行代码，bash 环境下执行改行的作用是：source 命令加载 pyenv 的自动补全脚本
source '/root/.pyenv/libexec/../completions/pyenv.bash' 
## 通过 command 命令执行 pyenv rehash（主要作用是重新生成 pyenv 的 shims 目录中的可执行文件），并将错误输出重定向到 /dev/null
command pyenv rehash 2>/dev/null

# 3. 定义一个 pyenv 函数，该函数根据不同的子命令执行不同的操作
## 如果子命令是 activate、deactivate、rehash 或 shell，则通过 eval 执行 pyenv "sh-$command"
## 对于其他子命令，直接调用 command pyenv "$command" "$@"
pyenv() {
  local command
  command="${1:-}"
  if [ "$#" -gt 0 ]; then
    shift
  fi

  case "$command" in
  activate|deactivate|rehash|shell)
    eval "$(pyenv "sh-$command" "$@")"
    ;;
  *)
    command pyenv "$command" "$@"
    ;;
  esac
}

2. pyenv init –path

用于设置 PYENV_ROOT 环境变量，使得 pyenv 可以找到安装的 Python 版本。pyenv init - 包含 pyenv init --path 操作。

sh 或 bash 环境运行后，执行如下命令（相关说明附在注释中）：

1
2
3
4
5
6
7
8
9
10
11
12

## 该脚本将当前的 PATH 变量拆分为一个数组 paths，并赋予
## 通过遍历 paths 数组，检查每个路径是否为 '/root/.pyenv/shims'，如果是，则将其移除
PATH="$(bash --norc -ec 'IFS=:; paths=($PATH); 
for i in ${!paths[@]}; do 
if [[ ${paths[i]} == "''/root/.pyenv/shims''" ]]; then unset '\''paths[i]'\''; 
fi; done; 
echo "${paths[*]}"')"
## 将 '/root/.pyenv/shims' 添加到 PATH 变量的最前面
export PATH="/root/.pyenv/shims:${PATH}"
## 通过 command 命令执行 pyenv rehash，并将错误输出重定向到 /dev/null
command pyenv rehash 2>/dev/null

• 10a和16a插座的区别
  • 1、外观区别
  • 2、使用区别
  • 3、插座金属
  • 4、承受范围
• 哪些电器用16a插座

10a和16a插座的区别

1、外观区别

主要是插孔间距的尺寸区别。16a插座三插孔的孔距比10a插座更大。所以不同标准的插孔和插头并不能适用。

10a插座为五眼插：1个三眼、1个二眼，而16a插座是一个三眼插，比10a三眼插宽广些。

2、使用区别

16a插头和10a插头不通用，10a插头插不到16a插座里去，当然反过来也是不行的。

3、插座金属

16a插座承载电流大于10a插座，用到的铜也比较多，而10a插座用的材料也有所不同。

16a插座需要布置4平方毫米以上规格的铜线，而10a插座最好布置2.5平方毫米铜线。

4、承受范围

16a插座可以承受3000瓦以内电器功率，而10a插座功率控制在2200瓦以内，不然容易发生意外。

哪些电器用16a插座

家里常用的大功率电器主要是空调、电磁炉、热水器

16a插座是承受范围比较大的插座，家居中一般主要在空调电器上使用，所以我们经常可以见到空调的隔壁安装的是一个不一样的插座，这是对用电安全的需求

Lucene的索引里面存了些什么，如何存放的，也即Lucene的索引文件格式，是读懂Lucene源代码的一把钥匙。

当我们真正进入到Lucene源代码之中的时候，我们会发现:

• Lucene的索引过程，就是按照全文检索的基本过程，将倒排表写成此文件格式的过程。
• Lucene的搜索过程，就是按照此文件格式将索引进去的信息读出来，然后计算每篇文档打分(score)的过程。

参考官网 Apache Lucene - Index File Formats。

一、基本概念

下图就是Lucene生成的索引的一个实例：

Lucene的索引结构是有层次结构的，主要分以下几个层次：

• 索引(Index)：
  • 在Lucene中一个索引是放在一个文件夹中的。
  • 如上图，同一文件夹中的所有的文件构成一个Lucene索引。
• 段(Segment)：
  • 一个索引可以包含多个段，段与段之间是独立的，添加新文档可以生成新的段，不同的段可以合并。
  • 如上图，具有相同前缀文件的属同一个段，图中共两个段 “_0” 和 “_1”。
  • segments.gen和segments_5是段的元数据文件，也即它们保存了段的属性信息。
• 文档(Document)：
  • 文档是我们建索引的基本单位，不同的文档是保存在不同的段中的，一个段可以包含多篇文档。
  • 新添加的文档是单独保存在一个新生成的段中，随着段的合并，不同的文档合并到同一个段中。
• 域(Field)：
  • 一篇文档包含不同类型的信息，可以分开索引，比如标题，时间，正文，作者等，都可以保存在不同的域里。
  • 不同域的索引方式可以不同，在真正解析域的存储的时候，我们会详细解读。
• 词(Term)：
  • 词是索引的最小单位，是经过词法分析和语言处理后的字符串。

Lucene的索引结构中，即保存了正向信息，也保存了反向信息。

所谓正向信息：

• 按层次保存了从索引，一直到词的包含关系：索引(Index) –> 段(segment) –> 文档(Document) –> 域(Field) –> 词(Term)
• 也即此索引包含了那些段，每个段包含了那些文档，每个文档包含了那些域，每个域包含了那些词。
• 既然是层次结构，则每个层次都保存了本层次的信息以及下一层次的元信息，也即属性信息，比如一本介绍中国地理的书，应该首先介绍中国地理的概况，以及中国包含多少个省，每个省介绍本省的基本概况及包含多少个市，每个市介绍本市的基本概况及包含多少个县，每个县具体介绍每个县的具体情况。
• 如上图，包含正向信息的文件有：
  • segments_N保存了此索引包含多少个段，每个段包含多少篇文档。
  • XXX.fnm保存了此段包含了多少个域，每个域的名称及索引方式。
  • XXX.fdx，XXX.fdt保存了此段包含的所有文档，每篇文档包含了多少域，每个域保存了那些信息。
  • XXX.tvx，XXX.tvd，XXX.tvf保存了此段包含多少文档，每篇文档包含了多少域，每个域包含了多少词，每个词的字符串，位置等信息。

所谓反向信息：

• 保存了词典到倒排表的映射：词(Term) –> 文档(Document)
• 如上图，包含反向信息的文件有：
  • XXX.tis，XXX.tii保存了词典(Term Dictionary)，也即此段包含的所有的词按字典顺序的排序。
  • XXX.frq保存了倒排表，也即包含每个词的文档ID列表。
  • XXX.prx保存了倒排表中每个词在包含此词的文档中的位置。

在了解Lucene索引的详细结构之前，先看看Lucene索引中的基本数据类型。

二、基本类型

Lucene索引文件中，用以下基本类型来保存信息：

• Byte：是最基本的类型，长8位(bit)。
• UInt32：由4个Byte组成。
• UInt64：由8个Byte组成。
• VInt：
  • 变长的整数类型，它可能包含多个Byte，对于每个Byte的8位，其中后7位表示数值，最高1位表示是否还有另一个Byte，0表示没有，1表示有。
  • 越前面的Byte表示数值的低位，越后面的Byte表示数值的高位。
  • 例如130化为二进制为 1000, 0010，总共需要8位，一个Byte表示不了，因而需要两个Byte来表示，第一个Byte表示后7位，并且在最高位置1来表示后面还有一个Byte，所以为(1) 0000010，第二个Byte表示第8位，并且最高位置0来表示后面没有其他的Byte了，所以为(0) 0000001。

• Chars：是UTF-8编码的一系列Byte。
• String：一个字符串首先是一个VInt来表示此字符串包含的字符的个数，接着便是UTF-8编码的字符序列Chars。

三、基本规则

Lucene为了使的信息的存储占用的空间更小，访问速度更快，采取了一些特殊的技巧，然而在看Lucene文件格式的时候，这些技巧却容易使我们感到困惑，所以有必要把这些特殊的技巧规则提取出来介绍一下。

1. 前缀后缀规则(Prefix+Suffix)

Lucene在反向索引中，要保存词典(Term Dictionary)的信息，所有的词(Term)在词典中是按照字典顺序进行排列的，然而词典中包含了文档中的几乎所有的词，并且有的词还是非常的长的，这样索引文件会非常的大，所谓前缀后缀规则，即当某个词和前一个词有共同的前缀的时候，后面的词仅仅保存前缀在词中的偏移(offset)，以及除前缀以外的字符串(称为后缀)。

比如要存储如下词:term，termagancy，termagant，terminal，

如果按照正常方式来存储，需要的空间如下：

[VInt = 4] [t][e][r][m]，

[VInt = 10][t][e][r][m][a][g][a][n][c][y]，

[VInt = 9][t][e][r][m][a][g][a][n][t]，

[VInt = 8][t][e][r][m][i][n][a][l]

共需要35个Byte.

如果应用前缀后缀规则，需要的空间如下：

[VInt = 4] [t][e][r][m]，

[VInt = 4 (offset)][VInt = 6][a][g][a][n][c][y]，

[VInt = 8 (offset)][VInt = 1][t]，

[VInt = 4 (offset)][VInt = 4][i][n][a][l]

共需要22个Byte。

大大缩小了存储空间，尤其是在按字典顺序排序的情况下，前缀的重合率大大提高。

2. 差值规则(Delta)

在Lucene的反向索引中，需要保存很多整型数字的信息，比如文档ID号，比如词(Term)在文档中的位置等等。

由上面介绍，我们知道，整型数字是以VInt的格式存储的。随着数值的增大，每个数字占用的Byte的个数也逐渐的增多。所谓差值规则(Delta)就是先后保存两个整数的时候，后面的整数仅仅保存和前面整数的差即可。

比如要存储如下整数：16386，16387，16388，16389

如果按照正常方式来存储，需要的空间如下：

[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，

[(1) 000, 0011][(1) 000, 0000][(0) 000, 0001]，

[(1) 000, 0100][(1) 000, 0000][(0) 000, 0001]，

[(1) 000, 0101][(1) 000, 0000][(0) 000, 0001]

供需12个Byte。

如果应用差值规则来存储，需要的空间如下：

[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，

[(0) 000, 0001]，

[(0) 000, 0001]，

[(0) 000, 0001]

共需6个Byte。

大大缩小了存储空间，而且无论是文档ID，还是词在文档中的位置，都是按从小到大的顺序，逐渐增大的。

3. 或然跟随规则(A, B?)

Lucene的索引结构中存在这样的情况，某个值A后面可能存在某个值B，也可能不存在，需要一个标志来表示后面是否跟随着B。

一般的情况下，在A后面放置一个Byte，为0则后面不存在B，为1则后面存在B，或者0则后面存在B，1则后面不存在B。

但这样要浪费一个Byte的空间，其实一个Bit就可以了。

在Lucene中，采取以下的方式：A的值左移一位，空出最后一位，作为标志位，来表示后面是否跟随B，所以在这种情况下，A/2是真正的A原来的值。

如果去读Apache Lucene - Index File Formats这篇文章，会发现很多符合这种规则的：

• .frq文件中的DocDelta[, Freq?]，DocSkip,PayloadLength?
• .prx文件中的PositionDelta,Payload? (但不完全是，如下表分析)

当然还有一些带?的但不属于此规则的：

• .frq文件中的SkipChildLevelPointer?，是多层跳跃表中，指向下一层表的指针，当然如果是最后一层，此值就不存在，也不需要标志。
• .tvf文件中的Positions?, Offsets?。
  • 在此类情况下，带?的值是否存在，并不取决于前面的值的最后一位。
  • 而是取决于Lucene的某项配置，当然这些配置也是保存在Lucene索引文件中的。
  • 如Position和Offset是否存储，取决于.fnm文件中对于每个域的配置(TermVector.WITH_POSITIONS和TermVector.WITH_OFFSETS)

为什么会存在以上两种情况，其实是可以理解的：

• 对于符合或然跟随规则的，是因为对于每一个A，B是否存在都不相同，当这种情况大量存在的时候，从一个Byte到一个Bit如此8倍的空间节约还是很值得的。
• 对于不符合或然跟随规则的，是因为某个值的是否存在的配置对于整个域(Field)甚至整个索引都是有效的，而非每次的情况都不相同，因而可以统一存放一个标志。

文章中对如下格式的描述令人困惑：

Positions –> <PositionDelta,Payload?> ^Freq

Payload –> <PayloadLength?,PayloadData>

PositionDelta和Payload是否适用或然跟随规则呢？如何标识PayloadLength是否存在呢？

其实PositionDelta和Payload并不符合或然跟随规则，Payload是否存在，是由.fnm文件中对于每个域的配置中有关Payload的配置决定的(FieldOption.STORES_PAYLOADS) 。

当Payload不存在时，PayloadDelta本身不遵从或然跟随原则。

当Payload存在时，格式应该变成如下：Positions –> <PositionDelta,PayloadLength?,PayloadData> ^Freq

从而PositionDelta和PayloadLength一起适用或然跟随规则。

4. 跳跃表规则(Skip list)

为了提高查找的性能，Lucene在很多地方采取的跳跃表的数据结构。

跳跃表(Skip List)是如图的一种数据结构，有以下几个基本特征：

• 元素是按顺序排列的，在Lucene中，或是按字典顺序排列，或是按从小到大顺序排列。
• 跳跃是有间隔的(Interval)，也即每次跳跃的元素数，间隔是事先配置好的，如图跳跃表的间隔为3。
• 跳跃表是由层次的(level)，每一层的每隔指定间隔的元素构成上一层，如图跳跃表共有2层。

需要注意一点的是，在很多数据结构或算法书中都会有跳跃表的描述，原理都是大致相同的，但是定义稍有差别：

• 对间隔(Interval)的定义： 如图中，有的认为间隔为2，即两个上层元素之间的元素数，不包括两个上层元素；有的认为是3，即两个上层元素之间的差，包括后面上层元素，不包括前面的上层元素；有的认为是4，即除两个上层元素之间的元素外，既包括前面，也包括后面的上层元素。Lucene是采取的第二种定义。
• 对层次(Level)的定义：如图中，有的认为应该包括原链表层，并从1开始计数，则总层次为3，为1，2，3层；有的认为应该包括原链表层，并从0计数，为0，1，2层；有的认为不应该包括原链表层，且从1开始计数，则为1，2层；有的认为不应该包括链表层，且从0开始计数，则为0，1层。Lucene采取的是最后一种定义。

跳跃表比顺序查找，大大提高了查找速度，如查找元素72，原来要访问2，3，7，12，23，37，39，44，50，72总共10个元素，应用跳跃表后，只要首先访问第1层的50，发现72大于50，而第1层无下一个节点，然后访问第2层的94，发现94大于72，然后访问原链表的72，找到元素，共需要访问3个元素即可。

然而Lucene在具体实现上，与理论又有所不同，在具体的格式中，会详细说明。

四、具体格式

上面曾经交代过，Lucene保存了从Index到Segment到Document到Field一直到Term的正向信息，也包括了从Term到Document映射的反向信息，还有其他一些Lucene特有的信息。下面对这三种信息一一介绍。

4.1. 正向信息

Index –> Segments (segments.gen, segments_N) –> Field(fnm, fdx, fdt) –> Term (tvx, tvd, tvf)

上面的层次结构不是十分的准确，因为segments.gen和segments_N保存的是段(segment)的元数据信息(metadata)，其实是每个Index一个的，而段的真正的数据信息，是保存在域(Field)和词(Term)中的。

4.1.1. 段的元数据信息(segments_N)

一个索引(Index)可以同时存在多个segments_N(至于如何存在多个segments_N，在描述完详细信息之后会举例说明)，然而当我们要打开一个索引的时候，我们必须要选择一个来打开，那如何选择哪个segments_N呢？

Lucene采取以下过程：

• 其一，在所有的segments_N中选择N最大的一个。基本逻辑参照SegmentInfos.getCurrentSegmentGeneration(File[] files)，其基本思路就是在所有以segments开头，并且不是segments.gen的文件中，选择N最大的一个作为genA。

• 其二，打开segments.gen，其中保存了当前的N值。其格式如下，读出版本号(Version)，然后再读出两个N，如果两者相等，则作为genB。

1
2
3
4
5
6
7
8
9

IndexInput genInput = directory.openInput(IndexFileNames.SEGMENTS_GEN);//"segments.gen"  
int version = genInput.readInt();//读出版本号  
if (version == FORMAT_LOCKLESS) {//如果版本号正确  
    long gen0 = genInput.readLong();//读出第一个N  
    long gen1 = genInput.readLong();//读出第二个N  
    if (gen0 == gen1) {//如果两者相等则为genB  
        genB = gen0;  
    }  
}

• 其三，在上述得到的genA和genB中选择最大的那个作为当前的N，方才打开segments_N文件。其基本逻辑如下：

  1 2 3 4

  if (genA > genB) gen = genA; else gen = genB;

如下图是segments_N的具体格式：

• Format：
  • 索引文件格式的版本号。
  • 由于Lucene是在不断开发过程中的，因而不同版本的Lucene，其索引文件格式也不尽相同，于是规定一个版本号。
  • Lucene 2.1此值-3，Lucene 2.9时，此值为-9。
  • 当用某个版本号的IndexReader读取另一个版本号生成的索引的时候，会因为此值不同而报错。
• Version：
  • 索引的版本号，记录了IndexWriter将修改提交到索引文件中的次数。
  • 其初始值大多数情况下从索引文件里面读出，仅仅在索引开始创建的时候，被赋予当前的时间，已取得一个唯一值。
  • 其值改变在 IndexWriter.commit->IndexWriter.startCommit->SegmentInfos.prepareCommit->SegmentInfos.write->writeLong(++version)
  • 其初始值之所最初取一个时间，是因为我们并不关心IndexWriter将修改提交到索引的具体次数，而更关心到底哪个是最新的。IndexReader中常比较自己的version和索引文件中的version是否相同来判断此IndexReader被打开后，还有没有被IndexWriter更新。

1
2
3
4
5

//在DirectoryReader中有一下函数。

public boolean isCurrent() throws CorruptIndexException, IOException {  
  return SegmentInfos.readCurrentVersion(directory) == segmentInfos.getVersion();  
}

• NameCount
  • 是下一个新段(Segment)的段名。
  • 所有属于同一个段的索引文件都以段名作为文件名，一般为_0.xxx, _0.yyy, _1.xxx, _1.yyy ……
  • 新生成的段的段名一般为原有最大段名加一。
  • 如同的索引，NameCount读出来是2，说明新的段为_2.xxx, _2.yyy

• SegCount
  • 段(Segment)的个数。
  • 如上图，此值为2。
• SegCount个段的元数据信息：
  • SegName
    • 段名，所有属于同一个段的文件都有以段名作为文件名。
    • 如上图，第一个段的段名为”_0”，第二个段的段名为”_1”
  • SegSize
    • 此段中包含的文档数
    • 然而此文档数是包括已经删除，又没有optimize的文档的，因为在optimize之前，Lucene的段中包含了所有被索引过的文档，而被删除的文档是保存在.del文件中的，在搜索的过程中，是先从段中读到了被删除的文档，然后再用.del中的标志，将这篇文档过滤掉。
    • 如下的代码形成了上图的索引，可以看出索引了两篇文档形成了_0段，然后又删除了其中一篇，形成了_0_1.del，又索引了两篇文档形成_1段，然后又删除了其中一篇，形成_1_1.del。因而在两个段中，此值都是2。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX\_DIR), new StandardAnalyzer(Version.LUCENE\_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);  
writer.setUseCompoundFile(false);  
indexDocs(writer, docDir);//docDir中只有两篇文档

//文档一为：Students should be allowed to go out with their friends, but not allowed to drink beer.

//文档二为：My friend Jerry went to school to see his students but found them drunk which is not allowed.

writer.commit();//提交两篇文档，形成\_0段。

writer.deleteDocuments(new Term("contents", "school"));//删除文档二  
writer.commit();//提交删除，形成\_0\_1.del  
indexDocs(writer, docDir);//再次索引两篇文档，Lucene不能判别文档与文档的不同，因而算两篇新的文档。  
writer.commit();//提交两篇文档，形成\_1段  
writer.deleteDocuments(new Term("contents", "school"));//删除第二次添加的文档二  
writer.close();//提交删除，形成\_1\_1.del

• • DelGen
    • .del文件的版本号
    • Lucene中，在optimize之前，删除的文档是保存在.del文件中的。
    • 在Lucene 2.9中，文档删除有以下几种方式：
      • IndexReader.deleteDocument(int docID)是用IndexReader按文档号删除。
      • IndexReader.deleteDocuments(Term term)是用IndexReader删除包含此词(Term)的文档。
      • IndexWriter.deleteDocuments(Term term)是用IndexWriter删除包含此词(Term)的文档。
      • IndexWriter.deleteDocuments(Term[] terms)是用IndexWriter删除包含这些词(Term)的文档。
      • IndexWriter.deleteDocuments(Query query)是用IndexWriter删除能满足此查询(Query)的文档。
      • IndexWriter.deleteDocuments(Query[] queries)是用IndexWriter删除能满足这些查询(Query)的文档。
      • 原来的版本中Lucene的删除一直是由IndexReader来完成的，在Lucene 2.9中虽可以用IndexWriter来删除，但是其实真正的实现是在IndexWriter中，保存了readerpool，当IndexWriter向索引文件提交删除的时候，仍然是从readerpool中得到相应的IndexReader，并用IndexReader来进行删除的。下面的代码可以说明：

1
2
3
4

IndexWriter.applyDeletes()
-> DocumentsWriter.applyDeletes(SegmentInfos)
  -> reader.deleteDocument(doc);

• • • • DelGen是每当IndexWriter向索引文件中提交删除操作的时候，加1，并生成新的.del文件。

• • DocStoreOffset

  • DocStoreSegment

  • DocStoreIsCompoundFile

    • 对于域(Stored Field)和词向量(Term Vector)的存储可以有不同的方式，即可以每个段(Segment)单独存储自己的域和词向量信息，也可以多个段共享域和词向量，把它们存储到一个段中去。
    • 如果DocStoreOffset为-1，则此段单独存储自己的域和词向量，从存储文件上来看，如果此段段名为XXX，则此段有自己的XXX.fdt，XXX.fdx，XXX.tvf，XXX.tvd，XXX.tvx文件。DocStoreSegment和DocStoreIsCompoundFile在此处不被保存。
    • 如果DocStoreOffset不为-1，则DocStoreSegment保存了共享的段的名字，比如为YYY，DocStoreOffset则为此段的域及词向量信息在共享段中的偏移量。则此段没有自己的XXX.fdt，XXX.fdx，XXX.tvf，XXX.tvd，XXX.tvx文件，而是将信息存放在共享段的YYY.fdt，YYY.fdx，YYY.tvf，YYY.tvd，YYY.tvx文件中。
    • DocumentsWriter中有两个成员变量：String segment是当前索引信息存放的段，String docStoreSegment是域和词向量信息存储的段。两者可以相同也可以不同，决定了域和词向量信息是存储在本段中，还是和其他的段共享。
    • IndexWriter.flush(boolean triggerMerge, boolean flushDocStores, boolean flushDeletes)中第二个参数flushDocStores会影响到是否单独或是共享存储。其实最终影响的是DocumentsWriter.closeDocStore()。每当flushDocStores为false时，closeDocStore不被调用，说明下次添加到索引文件中的域和词向量信息是同此次共享一个段的。直到flushDocStores为true的时候，closeDocStore被调用，从而下次添加到索引文件中的域和词向量信息将被保存在一个新的段中，不同此次共享一个段(在这里需要指出的是Lucene的一个很奇怪的实现，虽然下次域和词向量信息是被保存到新的段中，然而段名却是这次被确定了的，在initSegmentName中当docStoreSegment == null时，被置为当前的segment，而非下一个新的segment，docStoreSegment = segment，于是会出现如下面的例子的现象)。
    • 好在共享域和词向量存储并不是经常被使用到，实现也或有缺陷，暂且解释到此。

    IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX_DIR), new StandardAnalyzer(Version.LUCENE_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);
    writer.setUseCompoundFile(false);

indexDocs(writer, docDir);  writer.flush();

//flush生成segment “_0”，并且flush函数中，flushDocStores设为false，也即下个段将同本段共享域和词向量信息，这时DocumentsWriter中的docStoreSegment= “_0”。

indexDocs(writer, docDir);  writer.commit();

//commit生成segment “_1”，由于上次flushDocStores设为false，于是段”_1”的域以及词向量信息是保存在”_0”中的，在这个时刻，段”_1”并不生成自己的”_1.fdx”和”_1.fdt”。然而在commit函数中，flushDocStores设为true，也即下个段将单独使用新的段来存储域和词向量信息。然而这时，DocumentsWriter中的docStoreSegment= “_1”，也即当段”_2”存储其域和词向量信息的时候，是存在”_1.fdx”和”_1.fdt”中的，而段”_1”的域和词向量信息却是存在”_0.fdt”和”_0.fdx”中的，这一点非常令人困惑。 如图writer.commit的时候，_1.fdt和_1.fdx并没有形成。

indexDocs(writer, docDir);  writer.flush();

//段”_2”形成，由于上次flushDocStores设为true，其域和词向量信息是新创建一个段保存的，却是保存在_1.fdt和_1.fdx中的，这时候才产生了此二文件。

indexDocs(writer, docDir);  writer.flush();

//段”_3”形成，由于上次flushDocStores设为false，其域和词向量信息是共享一个段保存的，也是是保存在_1.fdt和_1.fdx中的

indexDocs(writer, docDir);  writer.commit();

//段”_4”形成，由于上次flushDocStores设为false，其域和词向量信息是共享一个段保存的，也是是保存在_1.fdt和_1.fdx中的。然而函数commit中flushDocStores设为true，也意味着下一个段将新创建一个段保存域和词向量信息，此时DocumentsWriter中docStoreSegment= “_4”，也表明了虽然段”_4”的域和词向量信息保存在了段”_1”中，将来的域和词向量信息却要保存在段”_4”中。此时”_4.fdx”和”_4.fdt”尚未产生。

indexDocs(writer, docDir);  writer.flush();

//段”_5”形成，由于上次flushDocStores设为true，其域和词向量信息是新创建一个段保存的，却是保存在_4.fdt和_4.fdx中的，这时候才产生了此二文件。

indexDocs(writer, docDir);  writer.commit();  writer.close();

//段”_6”形成，由于上次flushDocStores设为false，其域和词向量信息是共享一个段保存的，也是是保存在_4.fdt和_4.fdx中的

• • HasSingleNormFile
    • 在搜索的过程中，标准化因子(Normalization Factor)会影响文档最后的评分。
    • 不同的文档重要性不同，不同的域重要性也不同。因而每个文档的每个域都可以有自己的标准化因子。
    • 如果HasSingleNormFile为1，则所有的标准化因子都是存在.nrm文件中的。
    • 如果HasSingleNormFile不是1，则每个域都有自己的标准化因子文件.fN
  • NumField
    • 域的数量
  • NormGen
    • 如果每个域有自己的标准化因子文件，则此数组描述了每个标准化因子文件的版本号，也即.fN的N。
  • IsCompoundFile
    • 是否保存为复合文件，也即把同一个段中的文件按照一定格式，保存在一个文件当中，这样可以减少每次打开文件的个数。
    • 是否为复合文件，由接口IndexWriter.setUseCompoundFile(boolean)设定。
    • 非符合文件同符合文件的对比如下图：
• • DeletionCount
    • 记录了此段中删除的文档的数目。
  • HasProx
    • 如果至少有一个段omitTf为false，也即词频(term freqency)需要被保存，则HasProx为1，否则为0。
  • Diagnostics
    • 调试信息。

• User map data

  • 保存了用户从字符串到字符串的映射Map

• CheckSum

  • 此文件segment_N的校验和。

读取此文件格式参考SegmentInfos.read(Directory directory, String segmentFileName):

• int format = input.readInt();

• version = input.readLong(); // read version

• counter = input.readInt(); // read counter

• for (int i = input.readInt(); i > 0; i–) // read segmentInfos

  • add(new SegmentInfo(directory, format, input));
    • name = input.readString();
    • docCount = input.readInt();
    • delGen = input.readLong();
    • docStoreOffset = input.readInt();
    • docStoreSegment = input.readString();
    • docStoreIsCompoundFile = (1 == input.readByte());
    • hasSingleNormFile = (1 == input.readByte());
    • int numNormGen = input.readInt();
    • normGen = new long[numNormGen];
    • for(int j=0;j
    • normGen[j] = input.readLong();
  • isCompoundFile = input.readByte();
  • delCount = input.readInt();
  • hasProx = input.readByte() == 1;
  • diagnostics = input.readStringStringMap();

• userData = input.readStringStringMap();

• final long checksumNow = input.getChecksum();

• final long checksumThen = input.readLong();

4.1.2. 域(Field)的元数据信息(.fnm)

一个段(Segment)包含多个域，每个域都有一些元数据信息，保存在.fnm文件中，.fnm文件的格式如下：

• FNMVersion
  • 是fnm文件的版本号，对于Lucene 2.9为-2
• FieldsCount
  • 域的数目
• 一个数组的域(Fields)
  • FieldName：域名，如”title”，”modified”，”content”等。
  • FieldBits:一系列标志位，表明对此域的索引方式
    • 最低位：1表示此域被索引，0则不被索引。所谓被索引，也即放到倒排表中去。
      • 仅仅被索引的域才能够被搜到。
      • Field.Index.NO则表示不被索引。
      • Field.Index.ANALYZED则表示不但被索引，而且被分词，比如索引”hello world”后，无论是搜”hello”，还是搜”world”都能够被搜到。
      • Field.Index.NOT_ANALYZED表示虽然被索引，但是不分词，比如索引”hello world”后，仅当搜”hello world”时，能够搜到，搜”hello”和搜”world”都搜不到。
      • 一个域出了能够被索引，还能够被存储，仅仅被存储的域是搜索不到的，但是能通过文档号查到，多用于不想被搜索到，但是在通过其它域能够搜索到的情况下，能够随着文档号返回给用户的域。
      • Field.Store.Yes则表示存储此域，Field.Store.NO则表示不存储此域。
    • 倒数第二位：1表示保存词向量，0为不保存词向量。
      • Field.TermVector.YES表示保存词向量。
      • Field.TermVector.NO表示不保存词向量。
    • 倒数第三位：1表示在词向量中保存位置信息。
      • Field.TermVector.WITH_POSITIONS
    • 倒数第四位：1表示在词向量中保存偏移量信息。
      • Field.TermVector.WITH_OFFSETS
    • 倒数第五位：1表示不保存标准化因子
      • Field.Index.ANALYZED_NO_NORMS
      • Field.Index.NOT_ANALYZED_NO_NORMS
    • 倒数第六位：是否保存payload

要了解域的元数据信息，还要了解以下几点：

• 位置(Position)和偏移量(Offset)的区别
  • 位置是基于词Term的，偏移量是基于字母或汉字的。

• 索引域(Indexed)和存储域(Stored)的区别
  • 一个域为什么会被存储(store)而不被索引(Index)呢？在一个文档中的所有信息中，有这样一部分信息，可能不想被索引从而可以搜索到，但是当这个文档由于其他的信息被搜索到时，可以同其他信息一同返回。
  • 举个例子，读研究生时，您好不容易写了一篇论文交给您的导师，您的导师却要他所第一作者而您做第二作者，然而您导师不想别人在论文系统中搜索您的名字时找到这篇论文，于是在论文系统中，把第二作者这个Field的Indexed设为false，这样别人搜索您的名字，永远不知道您写过这篇论文，只有在别人搜索您导师的名字从而找到您的文章时，在一个角落表述着第二作者是您。
• payload的使用
  • 我们知道，索引是以倒排表形式存储的，对于每一个词，都保存了包含这个词的一个链表，当然为了加快查询速度，此链表多用跳跃表进行存储。
  • Payload信息就是存储在倒排表中的，同文档号一起存放，多用于存储与每篇文档相关的一些信息。当然这部分信息也可以存储域里(stored Field)，两者从功能上基本是一样的，然而当要存储的信息很多的时候，存放在倒排表里，利用跳跃表，有利于大大提高搜索速度。
  • Payload的存储方式如下图：

• • Payload主要有以下几种用法：
    • 存储每个文档都有的信息：比如有的时候，我们想给每个文档赋一个我们自己的文档号，而不是用Lucene自己的文档号。于是我们可以声明一个特殊的域(Field)”_ID”和特殊的词(Term)”_ID”，使得每篇文档都包含词”_ID”，于是在词”_ID”的倒排表里面对于每篇文档又有一项，每一项都有一个payload，于是我们可以在payload里面保存我们自己的文档号。每当我们得到一个Lucene的文档号的时候，就能从跳跃表中查找到我们自己的文档号。

//声明一个特殊的域和特殊的词

public static final String ID_PAYLOAD_FIELD = “_ID”;

public static final String ID_PAYLOAD_TERM = “_ID”;

public static final Term ID_TERM = new Term(ID_PAYLOAD_TERM, ID_PAYLOAD_FIELD);

//声明一个特殊的TokenStream，它只生成一个词(Term)，就是那个特殊的词，在特殊的域里面。

static class SinglePayloadTokenStream extends TokenStream {
private Token token;
private boolean returnToken = false;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SinglePayloadTokenStream(String idPayloadTerm) {  
    char[] term = idPayloadTerm.toCharArray();  
    token = new Token(term, 0, term.length, 0, term.length);  
}

void setPayloadValue(byte[] value) {  
    token.setPayload(new Payload(value));  
    returnToken = true;  
}

public Token next() throws IOException {  
    if (returnToken) {  
        returnToken = false;  
        return token;  
    } else {  
        return null;  
    }  
}  

}

//对于每一篇文档，都让它包含这个特殊的词，在特殊的域里面

SinglePayloadTokenStream singlePayloadTokenStream = new SinglePayloadTokenStream(ID_PAYLOAD_TERM);
singlePayloadTokenStream.setPayloadValue(long2bytes(id));
doc.add(new Field(ID_PAYLOAD_FIELD, singlePayloadTokenStream));

//每当得到一个Lucene的文档号时，通过以下的方式得到payload里面的文档号

long id = 0;
TermPositions tp = reader.termPositions(ID_PAYLOAD_TERM);
boolean ret = tp.skipTo(docID);
tp.nextPosition();
int payloadlength = tp.getPayloadLength();
byte[] payloadBuffer = new byte[payloadlength];
tp.getPayload(payloadBuffer, 0);
id = bytes2long(payloadBuffer);
tp.close();

• • • 影响词的评分
      • 在Similarity抽象类中有函数public float scorePayload(byte [] payload, int offset, int length) 可以根据payload的值影响评分。
• 读取域元数据信息的代码如下：

FieldInfos.read(IndexInput, String)

• int firstInt = input.readVInt();
• size = input.readVInt();
• for (int i = 0; i < size; i++)
  • String name = input.readString();
  • byte bits = input.readByte();
  • boolean isIndexed = (bits & IS_INDEXED) != 0;
  • boolean storeTermVector = (bits & STORE_TERMVECTOR) != 0;
  • boolean storePositionsWithTermVector = (bits & STORE_POSITIONS_WITH_TERMVECTOR) != 0;
  • boolean storeOffsetWithTermVector = (bits & STORE_OFFSET_WITH_TERMVECTOR) != 0;
  • boolean omitNorms = (bits & OMIT_NORMS) != 0;
  • boolean storePayloads = (bits & STORE_PAYLOADS) != 0;
  • boolean omitTermFreqAndPositions = (bits & OMIT_TERM_FREQ_AND_POSITIONS) != 0;

4.1.3. 域(Field)的数据信息(.fdt，.fdx)

• 域数据文件(fdt):
  • 真正保存存储域(stored field)信息的是fdt文件
  • 在一个段(segment)中总共有segment size篇文档，所以fdt文件中共有segment size个项，每一项保存一篇文档的域的信息
  • 对于每一篇文档，一开始是一个fieldcount，也即此文档包含的域的数目，接下来是fieldcount个项，每一项保存一个域的信息。
  • 对于每一个域，fieldnum是域号，接着是一个8位的byte，最低一位表示此域是否分词(tokenized)，倒数第二位表示此域是保存字符串数据还是二进制数据，倒数第三位表示此域是否被压缩，再接下来就是存储域的值，比如new Field(“title”, “lucene in action”, Field.Store.Yes, …)，则此处存放的就是”lucene in action”这个字符串。
• 域索引文件(fdx)
  • 由域数据文件格式我们知道，每篇文档包含的域的个数，每个存储域的值都是不一样的，因而域数据文件中segment size篇文档，每篇文档占用的大小也是不一样的，那么如何在fdt中辨别每一篇文档的起始地址和终止地址呢，如何能够更快的找到第n篇文档的存储域的信息呢？就是要借助域索引文件。
  • 域索引文件也总共有segment size个项，每篇文档都有一个项，每一项都是一个long，大小固定，每一项都是对应的文档在fdt文件中的起始地址的偏移量，这样如果我们想找到第n篇文档的存储域的信息，只要在fdx中找到第n项，然后按照取出的long作为偏移量，就可以在fdt文件中找到对应的存储域的信息。
• 读取域数据信息的代码如下：

Document FieldsReader.doc(int n, FieldSelector fieldSelector)

• long position = indexStream.readLong();//indexStream points to “.fdx”
• fieldsStream.seek(position);//fieldsStream points to “fdt”
• int numFields = fieldsStream.readVInt();
• for (int i = 0; i < numFields; i++)
  • int fieldNumber = fieldsStream.readVInt();
  • byte bits = fieldsStream.readByte();
  • boolean compressed = (bits & FieldsWriter.FIELD_IS_COMPRESSED) != 0;
  • boolean tokenize = (bits & FieldsWriter.FIELD_IS_TOKENIZED) != 0;
  • boolean binary = (bits & FieldsWriter.FIELD_IS_BINARY) != 0;
  • if (binary)
    • int toRead = fieldsStream.readVInt();
    • final byte[] b = new byte[toRead];
    • fieldsStream.readBytes(b, 0, b.length);
    • if (compressed)
      • int toRead = fieldsStream.readVInt();
      • final byte[] b = new byte[toRead];
      • fieldsStream.readBytes(b, 0, b.length);
      • uncompress(b),
  • else
    • fieldsStream.readString()

4.1.3. 词向量(Term Vector)的数据信息(.tvx，.tvd，.tvf)

词向量信息是从索引(index)到文档(document)到域(field)到词(term)的正向信息，有了词向量信息，我们就可以得到一篇文档包含那些词的信息。

• 词向量索引文件(tvx)
  • 一个段(segment)包含N篇文档，此文件就有N项，每一项代表一篇文档。
  • 每一项包含两部分信息：第一部分是词向量文档文件(tvd)中此文档的偏移量，第二部分是词向量域文件(tvf)中此文档的第一个域的偏移量。
• 词向量文档文件(tvd)
  • 一个段(segment)包含N篇文档，此文件就有N项，每一项包含了此文档的所有的域的信息。
  • 每一项首先是此文档包含的域的个数NumFields，然后是一个NumFields大小的数组，数组的每一项是域号。然后是一个(NumFields - 1)大小的数组，由前面我们知道，每篇文档的第一个域在tvf中的偏移量在tvx文件中保存，而其他(NumFields - 1)个域在tvf中的偏移量就是第一个域的偏移量加上这(NumFields - 1)个数组的每一项的值。
• 词向量域文件(tvf)
  • 此文件包含了此段中的所有的域，并不对文档做区分，到底第几个域到第几个域是属于那篇文档，是由tvx中的第一个域的偏移量以及tvd中的(NumFields - 1)个域的偏移量来决定的。
  • 对于每一个域，首先是此域包含的词的个数NumTerms，然后是一个8位的byte，最后一位是指定是否保存位置信息，倒数第二位是指定是否保存偏移量信息。然后是NumTerms个项的数组，每一项代表一个词(Term)，对于每一个词，由词的文本TermText，词频TermFreq(也即此词在此文档中出现的次数)，词的位置信息，词的偏移量信息。
• 读取词向量数据信息的代码如下：

TermVectorsReader.get(int docNum, String field, TermVectorMapper)

• int fieldNumber = fieldInfos.fieldNumber(field);//通过field名字得到field号
• seekTvx(docNum);//在tvx文件中按docNum文档号找到相应文档的项
• long tvdPosition = tvx.readLong();//找到tvd文件中相应文档的偏移量
• tvd.seek(tvdPosition);//在tvd文件中按偏移量找到相应文档的项
• int fieldCount = tvd.readVInt();//此文档包含的域的个数。
• for (int i = 0; i < fieldCount; i++) //按域号查找域
  • number = tvd.readVInt();
  • if (number == fieldNumber)
    • found = i;
• position = tvx.readLong();//在tvx中读出此文档的第一个域在tvf中的偏移量
• for (int i = 1; i <= found; i++)
  • position += tvd.readVLong();//加上所要找的域在tvf中的偏移量
• tvf.seek(position);
• int numTerms = tvf.readVInt();
• byte bits = tvf.readByte();
• storePositions = (bits & STORE_POSITIONS_WITH_TERMVECTOR) != 0;
• storeOffsets = (bits & STORE_OFFSET_WITH_TERMVECTOR) != 0;
• for (int i = 0; i < numTerms; i++)
  • start = tvf.readVInt();
  • deltaLength = tvf.readVInt();
  • totalLength = start + deltaLength;
  • tvf.readBytes(byteBuffer, start, deltaLength);
  • term = new String(byteBuffer, 0, totalLength, “UTF-8”);
  • if (storePositions)
    • positions = new int[freq];
    • int prevPosition = 0;
    • for (int j = 0; j < freq; j++)
      • positions[j] = prevPosition + tvf.readVInt();
      • prevPosition = positions[j];
  • if (storeOffsets)
    • offsets = new TermVectorOffsetInfo[freq];
    • int prevOffset = 0;
    • for (int j = 0; j < freq; j++)
    • int startOffset = prevOffset + tvf.readVInt();
    • int endOffset = startOffset + tvf.readVInt();
    • offsets[j] = new TermVectorOffsetInfo(startOffset, endOffset);
    • prevOffset = endOffset;

4.2. 反向信息

反向信息是索引文件的核心，也即反向索引。

反向索引包括两部分，左面是词典(Term Dictionary)，右面是倒排表(Posting List)。

在Lucene中，这两部分是分文件存储的，词典是存储在tii，tis中的，倒排表又包括两部分，一部分是文档号及词频，保存在frq中，一部分是词的位置信息，保存在prx中。

• Term Dictionary (tii, tis)
  • –> Frequencies (.frq)
  • –> Positions (.prx)

4.2.1. 词典(tis)及词典索引(tii)信息

在词典中，所有的词是按照字典顺序排序的。

• 词典文件(tis)
  • TermCount：词典中包含的总的词数
  • IndexInterval：为了加快对词的查找速度，也应用类似跳跃表的结构，假设IndexInterval为4，则在词典索引(tii)文件中保存第4个，第8个，第12个词，这样可以加快在词典文件中查找词的速度。
  • SkipInterval：倒排表无论是文档号及词频，还是位置信息，都是以跳跃表的结构存在的，SkipInterval是跳跃的步数。
  • MaxSkipLevels：跳跃表是多层的，这个值指的是跳跃表的最大层数。
  • TermCount个项的数组，每一项代表一个词，对于每一个词，以前缀后缀规则存放词的文本信息(PrefixLength + Suffix)，词属于的域的域号(FieldNum)，有多少篇文档包含此词(DocFreq)，此词的倒排表在frq，prx中的偏移量(FreqDelta, ProxDelta)，此词的倒排表的跳跃表在frq中的偏移量(SkipDelta)，这里之所以用Delta，是应用差值规则。
• 词典索引文件(tii)
  • 词典索引文件是为了加快对词典文件中词的查找速度，保存每隔IndexInterval个词。
  • 词典索引文件是会被全部加载到内存中去的。
  • IndexTermCount = TermCount / IndexInterval：词典索引文件中包含的词数。
  • IndexInterval同词典文件中的IndexInterval。
  • SkipInterval同词典文件中的SkipInterval。
  • MaxSkipLevels同词典文件中的MaxSkipLevels。
  • IndexTermCount个项的数组，每一项代表一个词，每一项包括两部分，第一部分是词本身(TermInfo)，第二部分是在词典文件中的偏移量(IndexDelta)。假设IndexInterval为4，此数组中保存第4个，第8个，第12个词。。。
• 读取词典及词典索引文件的代码如下：

origEnum = new SegmentTermEnum(directory.openInput(segment + “.” + IndexFileNames.TERMS_EXTENSION,readBufferSize), fieldInfos, false);//用于读取tis文件

• int firstInt = input.readInt();
• size = input.readLong();
• indexInterval = input.readInt();
• skipInterval = input.readInt();
• maxSkipLevels = input.readInt();

SegmentTermEnum indexEnum = new SegmentTermEnum(directory.openInput(segment + “.” + IndexFileNames.TERMS_INDEX_EXTENSION, readBufferSize), fieldInfos, true);//用于读取tii文件

• indexTerms = new Term[indexSize];
• indexInfos = new TermInfo[indexSize];
• indexPointers = new long[indexSize];
• for (int i = 0; indexEnum.next(); i++)
  • indexTerms[i] = indexEnum.term();
  • indexInfos[i] = indexEnum.termInfo();
  • indexPointers[i] = indexEnum.indexPointer;

4.2.2. 文档号及词频(frq)信息

文档号及词频文件里面保存的是倒排表，是以跳跃表形式存在的。

• 此文件包含TermCount个项，每一个词都有一项，因为每一个词都有自己的倒排表。
• 对于每一个词的倒排表都包括两部分，一部分是倒排表本身，也即一个数组的文档号及词频，另一部分是跳跃表，为了更快的访问和定位倒排表中文档号及词频的位置。
• 对于文档号和词频的存储应用的是差值规则和或然跟随规则，Lucene的文档本身有以下几句话，比较难以理解，在此解释一下：

For example, the TermFreqs for a term which occurs once in document seven and three times in document eleven, with omitTf false, would be the following sequence of VInts:

15, 8, 3

If omitTf were true it would be this sequence of VInts instead:

7,4

首先我们看omitTf=false的情况，也即我们在索引中会存储一个文档中term出现的次数。

例子中说了，表示在文档7中出现1次，并且又在文档11中出现3次的文档用以下序列表示：15，8，3.

那这三个数字是怎么计算出来的呢？

首先，根据定义TermFreq –> DocDelta[, Freq?]，一个TermFreq结构是由一个DocDelta后面或许跟着Freq组成，也即上面我们说的A+B？结构。

DocDelta自然是想存储包含此Term的文档的ID号了，Freq是在此文档中出现的次数。

所以根据例子，应该存储的完整信息为[DocID = 7, Freq = 1] [DocID = 11, Freq = 3](见全文检索的基本原理章节)。

然而为了节省空间，Lucene对编号此类的数据都是用差值来表示的，也即上面说的规则2，Delta规则，于是文档ID就不能按完整信息存了，就应该存放如下：

[DocIDDelta = 7, Freq = 1][DocIDDelta = 4 (11-7), Freq = 3]

然而Lucene对于A+B?这种或然跟随的结果，有其特殊的存储方式，见规则3，即A+B?规则，如果DocDelta后面跟随的Freq为1，则用DocDelta最后一位置1表示。

如果DocDelta后面跟随的Freq大于1，则DocDelta得最后一位置0，然后后面跟随真正的值，从而对于第一个Term，由于Freq为1，于是放在DocDelta的最后一位表示，DocIDDelta = 7的二进制是000 0111，必须要左移一位，且最后一位置一，000 1111 = 15，对于第二个Term，由于Freq大于一，于是放在DocDelta的最后一位置零，DocIDDelta = 4的二进制是0000 0100，必须要左移一位，且最后一位置零，0000 1000 = 8，然后后面跟随真正的Freq = 3。

于是得到序列：[DocDleta = 15][DocDelta = 8, Freq = 3]，也即序列，15，8，3。

如果omitTf=true，也即我们不在索引中存储一个文档中Term出现的次数，则只存DocID就可以了，因而不存在A+B?规则的应用。

[DocID = 7][DocID = 11]，然后应用规则2，Delta规则，于是得到序列[DocDelta = 7][DocDelta = 4 (11 - 7)]，也即序列，7，4.

• 对于跳跃表的存储有以下几点需要解释一下：
  • 跳跃表可根据倒排表本身的长度(DocFreq)和跳跃的幅度(SkipInterval)而分不同的层次，层次数为NumSkipLevels = Min(MaxSkipLevels, floor(log(DocFreq/log(SkipInterval)))).
  • 第Level层的节点数为DocFreq/(SkipInterval^(Level + 1))，level从零计数。
  • 除了最低层之外，其他层都有SkipLevelLength来表示此层的二进制长度(而非节点的个数)，方便读取某一层的跳跃表到缓存里面。
  • 高层在前，低层在后，当读完所有的高层后，剩下的就是最低一层，因而最后一层不需要SkipLevelLength。这也是为什么Lucene文档中的格式描述为 ^{NumSkipLevels-1}, SkipLevel，也即低NumSKipLevels-1层有SkipLevelLength，最后一层只有SkipLevel，没有SkipLevelLength。
  • 除最低层以外，其他层都有SkipChildLevelPointer来指向下一层相应的节点。
  • 每一个跳跃节点包含以下信息：文档号，payload的长度，文档号对应的倒排表中的节点在frq中的偏移量，文档号对应的倒排表中的节点在prx中的偏移量。
  • 虽然Lucene的文档中有以下的描述，然而实验的结果却不是完全准确的：

Example: SkipInterval = 4, MaxSkipLevels = 2, DocFreq = 35. Then skip level 0 has 8 SkipData entries, containing the 3^rd, 7^th, 11^th, 15^th, 19^th, 23^rd, 27^th, and 31^st document numbers in TermFreqs. Skip level 1 has 2 SkipData entries, containing the 15^th and 31^st document numbers in TermFreqs.

按照描述，当SkipInterval为4，且有35篇文档的时候，Skip level = 0应该包括第3，第7，第11，第15，第19，第23，第27，第31篇文档，Skip level = 1应该包括第15，第31篇文档。

然而真正的实现中，跳跃表节点的时候，却向前偏移了，偏移的原因在于下面的代码：

• FormatPostingsDocsWriter.addDoc(int docID, int termDocFreq)
  • final int delta = docID - lastDocID;
  • if ((++df % skipInterval) == 0)
    • skipListWriter.setSkipData(lastDocID, storePayloads, posWriter.lastPayloadLength);
    • skipListWriter.bufferSkip(df);

从代码中，我们可以看出，当SkipInterval为4的时候，当docID = 0时，++df为1，1%4不为0，不是跳跃节点，当docID = 3时，++df=4，4%4为0，为跳跃节点，然而skipData里面保存的却是lastDocID为2。

所以真正的倒排表和跳跃表中保存一下的信息：

4.2.3. 词位置(prx)信息

词位置信息也是倒排表，也是以跳跃表形式存在的。

• 此文件包含TermCount个项，每一个词都有一项，因为每一个词都有自己的词位置倒排表。
• 对于每一个词的都有一个DocFreq大小的数组，每项代表一篇文档，记录此文档中此词出现的位置。这个文档数组也是和frq文件中的跳跃表有关系的，从上面我们知道，在frq的跳跃表节点中有ProxSkip，当SkipInterval为3的时候，frq的跳跃表节点指向prx文件中的此数组中的第1，第4，第7，第10，第13，第16篇文档。
• 对于每一篇文档，可能包含一个词多次，因而有一个Freq大小的数组，每一项代表此词在此文档中出现一次，则有一个位置信息。
• 每一个位置信息包含：PositionDelta(采用差值规则)，还可以保存payload，应用或然跟随规则。

4.3. 其他信息

4.3.1. 标准化因子文件(nrm)

为什么会有标准化因子呢？从第一章中的描述，我们知道，在搜索过程中，搜索出的文档要按与查询语句的相关性排序，相关性大的打分(score)高，从而排在前面。相关性打分(score)使用向量空间模型(Vector Space Model)，在计算相关性之前，要计算Term Weight，也即某Term相对于某Document的重要性。在计算Term Weight时，主要有两个影响因素，一个是此Term在此文档中出现的次数，一个是此Term的普通程度。显然此Term在此文档中出现的次数越多，此Term在此文档中越重要。

这种Term Weight的计算方法是最普通的，然而存在以下几个问题：

• 不同的文档重要性不同。有的文档重要些，有的文档相对不重要，比如对于做软件的，在索引书籍的时候，我想让计算机方面的书更容易搜到，而文学方面的书籍搜索时排名靠后。
• 不同的域重要性不同。有的域重要一些，如关键字，如标题，有的域不重要一些，如附件等。同样一个词(Term)，出现在关键字中应该比出现在附件中打分要高。
• 根据词(Term)在文档中出现的绝对次数来决定此词对文档的重要性，有不合理的地方。比如长的文档词在文档中出现的次数相对较多，这样短的文档比较吃亏。比如一个词在一本砖头书中出现了10次，在另外一篇不足100字的文章中出现了9次，就说明砖头书应该排在前面码？不应该，显然此词在不足100字的文章中能出现9次，可见其对此文章的重要性。

由于以上原因，Lucene在计算Term Weight时，都会乘上一个标准化因子(Normalization Factor)，来减少上面三个问题的影响。

标准化因子(Normalization Factor)是会影响随后打分(score)的计算的，Lucene的打分计算一部分发生在索引过程中，一般是与查询语句无关的参数如标准化因子，大部分发生在搜索过程中，会在搜索过程的代码分析中详述。

标准化因子(Normalization Factor)在索引过程总的计算如下：

它包括三个参数：

• Document boost：此值越大，说明此文档越重要。
• Field boost：此域越大，说明此域越重要。
• lengthNorm(field) = (1.0 / Math.sqrt(numTerms))：一个域中包含的Term总数越多，也即文档越长，此值越小，文档越短，此值越大。

从上面的公式，我们知道，一个词(Term)出现在不同的文档或不同的域中，标准化因子不同。比如有两个文档，每个文档有两个域，如果不考虑文档长度，就有四种排列组合，在重要文档的重要域中，在重要文档的非重要域中，在非重要文档的重要域中，在非重要文档的非重要域中，四种组合，每种有不同的标准化因子。

于是在Lucene中，标准化因子共保存了(文档数目乘以域数目)个，格式如下：

• 标准化因子文件(Normalization Factor File: nrm)：
  • NormsHeader：字符串“NRM”外加Version，依Lucene的版本的不同而不同。
  • 接着是一个数组，大小为NumFields，每个Field一项，每一项为一个Norms。
  • Norms也是一个数组，大小为SegSize，即此段中文档的数量，每一项为一个Byte，表示一个浮点数，其中02为尾数，38为指数。

4.3.2. 删除文档文件(del)

• 被删除文档文件(Deleted Document File: .del)
  • Format：在此文件中，Bits和DGaps只能保存其中之一，-1表示保存DGaps，非负值表示保存Bits。
  • ByteCount：此段中有多少文档，就有多少个bit被保存，但是以byte形式计数，也即Bits的大小应该是byte的倍数。
  • BitCount：Bits中有多少位被至1，表示此文档已经被删除。
  • Bits：一个数组的byte，大小为ByteCount，应用时被认为是byte*8个bit。
  • DGaps：如果删除的文档数量很小，则Bits大部分位为0，很浪费空间。DGaps采用以下的方式来保存稀疏数组：比如第十，十二，三十二个文档被删除，于是第十，十二，三十二位设为1，DGaps也是以byte为单位的，仅保存不为0的byte，如第1个byte，第4个byte，第1个byte十进制为20，第4个byte十进制为1。于是保存成DGaps，第1个byte，位置1用不定长正整数保存，值为20用二进制保存，第2个byte，位置4用不定长正整数保存，用差值为3，值为1用二进制保存，二进制数据不用差值表示。

五、总体结构

• 图示为Lucene索引文件的整体结构：
  • 属于整个索引(Index)的segment.gen，segment_N，其保存的是段(segment)的元数据信息，然后分多个segment保存数据信息，同一个segment有相同的前缀文件名。
  • 对于每一个段，包含域信息，词信息，以及其他信息(标准化因子，删除文档)
  • 域信息也包括域的元数据信息，在fnm中，域的数据信息，在fdx，fdt中。
  • 词信息是反向信息，包括词典(tis, tii)，文档号及词频倒排表(frq)，词位置倒排表(prx)。

大家可以通过看源代码，相应的Reader和Writer来了解文件结构，将更为透彻。

参考资料

• https://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623597.html
• https://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623599.html

在寻找部署静态网页的方法吗？这几个开源的静态网站生成工具可以帮你迅速部署界面优美、功能强大的静态网站，无需掌握复杂的 HTML 和 CSS 技能。

静态网站是什么？

技术上来讲，静态网站是指网页不是由服务器动态生成的。HTML、CSS 和 JavaScript 文件就静静地躺在服务器的某个路径下，它们的内容与终端用户接收到的版本是一样的。原始的源码文件已经提前编译好了，源码在每次请求后都不会变化。

Linux.CN 是一个依赖多个数据库的动态网站，当有浏览器的请求时，网页就会生成并提供服务。大部分网站是动态的，你与这些网站互动时，大量的内容会经常改变。

静态网站有一些好处，比如加载时间更短，请求的服务器资源更少、更安全（值得商榷）。

传统上，静态网站更适合于创建只有少量网页、内容变化不频繁的小网站。

然而，随着静态网站生成工具出现后，静态网站的适用范围越来越大。你还可以使用这些工具搭建博客网站。

我整理了几个开源的静态网站生成工具，这些工具可以帮你搭建界面优美的网站。

最好的开源静态网站生成工具

请注意，静态网站不会提供很复杂的功能。如果你需要复杂的功能，那么你可以参考适用于动态网站的最佳开源 CMS列表。

1、Jekyll

Jekyll 是用 Ruby 写的最受欢迎的开源静态生成工具之一。实际上，Jekyll 是 GitHub 页面 的引擎，它可以让你免费用 GitHub 托管网站。

你可以很轻松地跨平台配置 Jekyll，包括 Ubuntu。它利用 Markdown、Liquid（模板语言）、HTML 和 CSS 来生成静态的网页文件。如果你要搭建一个没有广告或推广自己工具或服务的产品页的博客网站，它是个不错的选择。

它还支持从常见的 CMS（内容管理系统Content management system）如 Ghost、WordPress、Drupal 7 迁移你的博客。你可以管理永久链接、类别、页面、文章，还可以自定义布局，这些功能都很强大。因此，即使你已经有了一个网站，如果你想转成静态网站，Jekyll 会是一个完美的解决方案。你可以参考官方文档或 GitHub 页面了解更多内容。

• Jekyll

2、Hugo

Hugo 是另一个很受欢迎的用于搭建静态网站的开源框架。它是用 Go 语言写的。

它运行速度快、使用简单、可靠性高。如果你需要，它也可以提供更高级的主题。它还提供了一些有用的快捷方式来帮助你轻松完成任务。无论是组合展示网站还是博客网站，Hogo 都有能力管理大量的内容类型。

如果你想使用 Hugo，你可以参照它的官方文档或它的 GitHub 页面来安装以及了解更多相关的使用方法。如果需要的话，你还可以将 Hugo 部署在 GitHub 页面或任何 CDN 上。

• Hugo

3、Hexo

Hexo 是一个有趣的开源框架，基于 Node.js。像其他的工具一样，你可以用它搭建相当快速的网站，不仅如此，它还提供了丰富的主题和插件。

它还根据用户的每个需求提供了强大的 API 来扩展功能。如果你已经有一个网站，你可以用它的迁移扩展轻松完成迁移工作。

你可以参照官方文档或 GitHub 页面 来使用 Hexo。

• Hexo

4、Gatsby

Gatsby 是一个越来越流行的开源网站生成框架。它使用 React.js 来生成快速、界面优美的网站。

几年前在一个实验性的项目中，我曾经非常想尝试一下这个工具，它提供的成千上万的新插件和主题的能力让我印象深刻。与其他静态网站生成工具不同的是，你可以使用 Gatsby 生成一个网站，并在不损失任何功能的情况下获得静态网站的好处。

它提供了与很多流行的服务的整合功能。当然，你可以不使用它的复杂的功能，或将其与你选择的流行 CMS 配合使用，这也会很有趣。你可以查看他们的官方文档或它的 GitHub 页面了解更多内容。

• Gatsby

5、VuePress

VuePress 是由 Vue.js 支持的静态网站生成工具，而 Vue.js 是一个开源的渐进式 JavaScript 框架。

如果你了解 HTML、CSS 和 JavaScript，那么你可以无压力地使用 VuePress。你应该可以找到几个有用的插件和主题来为你的网站建设开个头。此外，看起来 Vue.js 的更新一直很活跃，很多开发者都在关注 Vue.js，这是一件好事。

你可以参照他们的官方文档和 GitHub 页面了解更多。

• VuePress

6、Nuxt.js

Nuxt.js 使用了 Vue.js 和 Node.js，但它致力于模块化，并且有能力依赖服务端而非客户端。不仅如此，它的目标是为开发者提供直观的体验，并提供描述性错误，以及详细的文档等。

正如它声称的那样，在你用来搭建静态网站的所有工具中，Nuxt.js 可以做到功能和灵活性两全其美。他们还提供了一个 Nuxt 线上沙盒，让你不费吹灰之力就能直接测试它。

你可以查看它的 GitHub 页面和官方网站了解更多。

• Nuxt.js

7、Docusaurus

Docusaurus 是一个有趣的开源静态网站生成工具，为搭建文档类网站量身定制。它还是 Facebook 开源计划的一个项目。

Docusaurus 是用 React 构建的。你可以使用所有的基本功能，像文档版本管理、文档搜索和翻译大多是预先配置的。如果你想为你的产品或服务搭建一个文档网站，那么可以试试 Docusaurus。

你可以从它的 GitHub 页面和它的官网获取更多信息。

• Docusaurus

8、Eleventy

Eleventy 自称是 Jekyll 的替代品，旨在以更简单的方法来制作更快的静态网站。

它似乎很容易上手，而且它还提供了适当的文档来帮助你。如果你想找一个简单的静态网站生成工具，Eleventy 似乎会是一个有趣的选择。

你可以参照它的 GitHub 页面和官网来了解更多的细节。

• Eleventy

9、Publii

Publii 是一个令人印象深刻的开源 CMS，它能使生成一个静态网站变得很容易。它是用 Electron 和 Vue.js 构建的。如果有需要，你也可以把你的文章从 WorkPress 网站迁移过来。此外，它还提供了与 GitHub 页面、Netlify 及其它类似服务的一键同步功能。

如果你利用 Publii 生成一个静态网站，你还可以得到一个所见即所得的编辑器。你可以从官网下载它，或者从它的 GitHub 页面了解更多信息。

• Publii

10、Primo

一个有趣的开源静态网站生成工具，目前开发工作仍很活跃。虽然与其他的静态生成工具相比，它还不是一个成熟的解决方案，有些功能还不完善，但它是一个独特的项目。

Primo 旨在使用可视化的构建器帮你构建和搭建网站，这样你就可以轻松编辑和部署到任意主机上。

你可以参照官网或查看它的 GitHub 页面了解更多信息。

• Primo

结语

还有很多文章中没有列出的网站生成工具。然而，我试图提到最好的静态生成器，为您提供最快的加载时间，最好的安全性和令人印象深刻的灵活性。

列表中没有你最喜欢的工具？在下面的评论中告诉我。

via: https://itsfoss.com/open-source-static-site-generators/

作者：Ankush Das 选题：lujun9972 译者：Xiaobin.Liu 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文分3部分: 1. 怎么使用STL进行高效的查找: 借用传统STL算法对元素进行范围搜索 2. 搜索STL容器: 当你有直接读取STL容器里元素的权限时, 怎么进行高效准确的搜索(与简单的范围搜索相比较) 3. STL搜索算法的秘密: 向公众展示不为人知的算法, 这些算法在已经学习过的人眼里确实是很有用的

STL根据查看方式的不同, 一共分为两种: 排序的和不排序的. * 排序集合的遍历, 通常需要对数时长, 而乱序集合的遍历, 需要线性时长 * 排序容器中比较元素大小的函数根据equivalence(comparing with <), 而乱序容器中的函数根据equality(comparing with ==).

本文将展示对于在一个范围内搜索一个给定的值, C++怎么样去阐述下面3个问题: * 它存在否 * 它在哪 * 它应该在什么位置(排序容器)

Is it there?

乱序容器的元素

这个问题可以用std::find来表达(需要和与范围的终点值的比较相结合):

vector<int> v = ... // v filled with values
if (std::find(v.begin(), v.end(), 42) != v.end())
{
...

“Is it there"这个问题也可以用std::count来表达:

vector<int> v = ... // v filled with values
if (std::count(v.begin(), v.end(), 42))
{
...

std::count()的返回值会被隐式地转换成if条件里的bool值: 如果该范围里有至少一个值为42, 则返回true.

与std::find相比, std::count的优劣: 优势:

• std::count避免了与范围的end值相比较

弊端:

• std::count遍历整个集合, 而std::find在第一个与要查找的值相等的位置停下
• 可以证明, 对于"想要查找某个值"这件事, std::find 表达得更明确 基于以上, std::find用得更多.

Note 若要确认某个值存在而非是与要搜索的值相等, 请使用std::count_if, std::find_if, std::find_if_not

排序容器的元素

使用的算法是std::binary_search, 此函数返回一个bool值, 此bool值表示在集合中是否存在与搜索的值相等的元素.

std::set<int> numbers = // sorted elements
bool is42InThere = std::binary_search(numbers.begin(), numbers.end(), 42);
```</int>

### Where is it?
(当确定了要搜索的值存在后,) 我们想更进一步, 得到指向那个元素的迭代器.

#### 乱序容器的元素

使用std::find. 返回指向第一个与搜索的值相等的元素的迭代器, 如果找不到, 则返回集合的终点.

​

std::vector numbers = … auto searchResult = std::find(numbers.begin(), numbers.end(), 42);

if (searchResult != numbers.end()) { …

#### 排序容器的元素

对于排序集合, STL并没有像std::find一样直接的算法. std::find并不是为排序容器设计的, 因为它依据的是"=="而不是"<", 消耗的时间为线性时长而不是对数时长.
对于一个给定的容器, 如果容器内元素的"equality"和"equivalence"是相同的, 且你能接受消耗的线性时长, 那么std::find会为你返回正确的结果, 你也能从它简单直接的接口中获益. **但是,** 不能忘记, std::find并不是为排序容器设计的.

这里推荐使用`std::equal_range`. (并非`std::lower_bound`)
函数原型: 

​

template< class ForwardIt, class T > std::pair<forwardit,forwardit> equal_range( ForwardIt first, ForwardIt last, const T& value );

`std::equal_range` 返回与搜索值相等的元素的范围, 这个范围用一对集合内的迭代器表示. 这两个迭代器分别指向 与搜索值相等的范围里第一个元素和最后一个元素的下一个位置.</forwardit,forwardit>

然而, 它的接口有些笨重:
例A:

std::vector v = {3, 7, 3, 11, 3, 3, 2}; sort(v.begin(), v.end());

// equal_range, attempt 1: natively clumsy std::pair<std::vector::iterator, std::vector::iterator> range1 = equal_range(v.begin(), v.end(), 3); std::for_each(range1.first, range1.second, doSomething);

用一个`typedef` 或者`using`让它更简洁:
例B:

std::vector v = {3, 7, 3, 11, 3, 3, 2}; sort(v.begin(), v.end());</std::vector

using IteratorPair = std::pair<std::vector::iterator, std::vector::iterator>;</std::vector

// equal_range, attempt 2: with the classical typedef IteratorPair range2 = equal_range(v.begin(), v.end(), 3); std::for_each(range2.first, range2.second, doSomething);

例B确实简洁了很多, 但是仍有一个根本问题: 没有考虑 抽象等级.
尽管返回的是一个范围, 但这对迭代器强迫我们在操作返回的范围时必须按照"第一""第二"这种方式来写代码. 范围就应该用"首""尾"这种方式来表达. 这不仅给我们在其他地方使用这个返回值时造成很大的麻烦, 而且使代码很别扭.

为了解决这个问题, 我么可以把`std::equal_range` 返回的迭代器对封装进一个有"范围"这种语义的`object`

​

template

class Range

{

public:

Range(std::pair range)

m_begin(range.first), m_end(range.second) {} typename Container::iterator begin() { return m_begin; } typename Container::iterator end() { return m_end; }

private: typename Container::iterator m_begin; typename Container::iterator m_end; };

注意: 尽管`std::equal_range` 返回的结果是一个"范围", 但是`std::begin` 和 `std::end` 不能用在这个结果上. 而上面的封装解决了这个问题.
可以像下面这样使用:

​

std::vector v = {3, 7, 3, 11, 3, 3, 2}; sort(v.begin(), v.end());

// equal_range, attempt 3: natural al last Rangestd::vector\ range3 = equal_range(v.begin(), v.end(), 3); std::for_each(range3.begin(), range3.end(), doSomething);

不管你使用上面的哪种方式, `std::equal_range` 都会返回一个范围, 要确定它是否为空, 可以通过检查那两个迭代器(是否相等)或者使用`std::distance` 检查它的大小. </std::vector<int>

​

bool noElementFound = range3.begin() == range3.end(); size_t numberOfElementFound = std::distance(range3.begin(), range3.end()) ```

Where should it be?

这个问题仅仅针对排序的范围, 因为对于乱序的范围, 某个元素可能会存在任何位置.

对于排序的范围, 这个问题可以简化为: 如果它存在, 那么它在哪儿? 如果它不存在, 那么它应该在哪儿?

这个问题可以用算法std::lower_bound 和std::upper_bound 来解释.

当你理解了std::equal_range 后, 上面这句话就很容易理解了: std::lower_bound 和std::upper_bound 都会返回 std::equal_range 返回的那个迭代器对的第一个和第二个迭代器.

要插入某个值x, 使用std::lower_bound 得到指向 在范围里与x相等的元素之前的位置的迭代器, 使用std::upper_bound 得到指向 在范围里与x相等的元素之后的位置的迭代器.

注意: 如果仅仅是搜索某个元素, 永远不要使用std::lower_bound

与std::find 相反, 你不能根据 判断std::lower_bound 返回的迭代器是否与终点的迭代器相等 来判断要搜索的值是否存在于这个集合. 事实上, 如果这个值在集合里不存在, 则std::lower_bound 返回它应该在的位置, 而不是终点的迭代器. 所以, 你不仅需要确认返回的迭代器不是终点的迭代器, 还要确认它指向的元素跟要搜索的值是相等的.

总结

Question to express in C++

NOT SORTED

SORTED

Is it there?

std::find != end

std::binary_search

Where is it?

std::find

std::equal_range

Where should it be?

std::lower_bound / std::upper_bound

原文地址: http://www.fluentcpp.com/2017/01/16/how-to-stdfind-something-efficiently-with-the-stl/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io