Solr学习之五

一、段管理

段是一个自包含，仅可读的solr的索引的子集。一旦一个段被刷新到持久存储后，它将不会改变。当添加新文档到你的索引时候，它们被写入到新的段中。因此，在你的索引中，有很多激活的段。一次查询必须从所有的段中去读数据，以便获得一个完成的结果集。从某种意义上说，有许多小的段将会影响你的查询性能。合并许多小段到少数的大段的过程一般被称为段的合并。

二、优化索引

优化索引是一个强制Lucene去合并存在的段到一定数量的大段的操作，这一定数量默认值为1.

举个例子，一个具有32个段的索引，优化后，只有一个段。因此优化是个需要耗费cpu、内存、和磁盘空间的昂贵操作，特别是对于大索引而言。一个大索引的完全优化，可能花费几个小时也不稀奇。

Solr社区对于是否优化索引的建议是更改你的段合并侧率。一个优化过的索引并不意味这慢的查询会突然变快。相反有时候不优化索引，查询性能仍然是可以接受的。

索引合并配置：

配置项	作用
ramBufferSizeMB	在文档被刷新到目录之前的缓存大小的最大内存设置；默认是100MB。增加这个值将会 缓存更多的文档在内存中，从而在索引的时候减少磁盘的IO。
maxBufferedDocs	在文档被刷新到目录之前，缓存的最大文档数量；默认值为1000个文档。
mergePolicy	控制Lucene执行段合并，比如决定多少个段合并为一个段。默认为TieredMergePolicy。
mergeFactor	控制一次合并多少个段。默认为10.最优设置，取决于你的平均文档大小，可用的内存和渴望的索引的吞吐量。
mergeScheduler	控制何时段合并运行。默认是在后台并发执行的，用的配置为：concurrentMergeScheduler

虽然这些配置在solrconfig.xml被注释掉，但是，后台段的合并在你的索引中仍然是可用的。在后台执行的。我建议你避免优化，避免更改段合并的设置，除非建索引的吞吐量成为你程序的问题的时候。

删除处理

在段被刷新到磁盘之后就是不可以改变的。删除操作，并不会从存在的段中删除已经存在的文档。

删除的文档并不会从你索引中删除，直到包含删除的段被合并。在底层，Lucene通过一个单独的数据结构来跟踪段。在大多数情况下，你不用担心合并进程。