Elasticsearch Partitioning

haoman

Partitioning
Guide
Scaling Lucene

• Building Blocks
  
• Partitioning
  
• Replication
  
• Transaction Log
  

有2种通过将数据分区方式来scale搜索引擎: 基于文档（Document based partitioning）and 基于词条（Term based partitioning）. Elasticsearch 使用的基于文档的分区方式.
基于文档的分区（Document Based Partitioning）
每一个文档只存一个分区，每个分区持有整个文档集的一个子集，分区是一个功能完整的索引.
优点

• 每个分区都可以独立的处理查询.
  

• 可以非常简单的添加以文档为单位的索引信息.
  

• 网络开销很小，每个节点可以分别执行搜索，执行完了之后只需用返回文档的ID和评分信息就可以了，然后在其中一个我们执行分布式搜索的节点上执行合并就可以了.
  

缺点

• 查询如果需要在所有的分区上执行，那么它将执行 O(K*N) 次磁盘操作（K是词条（Term，或者理解为Field）的数量，N是分区的数量）.
  

在实用性的角度来看基于文档的分区方式已经被证明是一个构建大型的分布式信息检索系统的一种行之有效的方法, 关于这方面的详细内容，可以看 这里 talk by Jeffrey Dean (Google).
基于词条的分区（Term Based Partitioning）
每个分区拥有一部分词条，词条里面包含了整个index的文档数据.
一些基于词条分区的系统，如Riak Search (built on top of Riak key-value store engine) 或是 Lucandra/Solandra (on top of Cassandra). 尽管这些系统不是完全一样，但是它们都面临一个相似的挑战，当然也得益于相同的设计理念.
优点

• 一般来说，你只需要在很少的部分分区上执行查询就行了，比如，我们有5个term词条的查询，我们将至多命中5个分区，如果这5个term词条都保存同一个分区中，那么我们只需用访问一个分区即可，而不管我们是不是实际上有50个分区.
  

• 另外一个优势就是对应K个Term词条的查询，你只需用执行 O(K) 次磁盘查找（假设我们使用的优化过的实现）.
  

缺点

• 最主要的问题是Lucene Segment概念里面固有的很多结构都将失去。
  The main problem is that whole notion of Lucene Segment which is inherent to a lot of constructs in Lucene is lost.
  

• 对于那些复杂的查询，网络开销将会变得非常高，并且可能使得系统可用性大大降低，尤其是那些会expand出大量的term词条的查询，如fuzzy或者prefix查询.
  

• 另外一个问题就是获取每个文档的信息将会变得非常困难，举例来说，如果你想获取文档的一部分数据来做进一步的控制，比如（google的PageRank算法），获取每个文档的这些数据都会变得非常困难，因为这种分区的方式使得文档的数据被分散到了不同的地方，所以实现faceting、评分、自定义评分等等都将变得难以实现.