elasticsearch

最新推荐文章于 2023-02-05 19:41:24 发布

weixin_33713707

最新推荐文章于 2023-02-05 19:41:24 发布

阅读量74

点赞数

文章标签：大数据 python

原文链接：https://my.oschina.net/kingwjb/blog/228934

版权

2019独角兽企业重金招聘Python工程师标准>>>

#Scaling Lucene# 怎样在Lucene之上构建一个分布式、高度伸缩、接近实时的搜索引擎呢？

building blocks
partitioning 分区策略最佳的将lucene的索引文档分割到多个分布式的分片中去
replication 分区复制方式保证系统的高可用性以及提高搜索的吞吐
transaction log 事务日志保证数据一致性

##Building Blocks## 当我们要构建一个分布式接近实时的搜索引擎，并且要让lucene可伸缩扩展，必须首先知道lucene的关键概念一个他们于我们要达成目标的一些局限性。

###Directory### Lucene Directory是一个抽象的文件系统的接口，用来允许你读写文件，不管lucene的索引是存放在内存中还是物理磁盘上，他都是通过lucene的Directory抽象层来访问和维护的。

###IndexWriter### IndexWriter用来添加、删除、更新lucene里面的索引文档。这些操作是在内存中完成以保证更好的性能，但是如果要保证这些操作的持久化，这些操作是需要flush到磁盘的。并且，flush操作或者显失的commit提交开销都是很大的，因为这些操作通常需要处理很多的文件，而处理这些文件有涉及到大量的磁盘IO。

此外，每次只能有一个IndexWriter对象来对一个索引目录进行索引操作，并且创建这个对象开销很大，所以次序尽可能去重用这个对象。

###Index Segmentgs### lucene索引被分解为很多段（segments）。每个索引段实际上时一个功能完整的lucene索引，一旦一个索引段创建完成，他将是不可变的，并且不能删除段里面的索引文档。commit提交操作用来往索引段里面添加一个新段。lucene内部会来对这段进行合并，所以我们必须要有策略来控制这些合并。(MergePolisy, MergeScheuler, … etc)。Because segments need to be kept at bay they are being merged continuously by internal Lucene processes (MergePolisy, MergeScheuler, … etc).

因为这些段是不可变的，所以可以用来作缓存（caching）是一个很好的选择，你可以加载所有的term词条并且创建一个跳跃列表（skip lists），或者用来构造FieldCache，如果段没有变化，你就不需要重新加载。

###IndexReader### IndexReader用来执行搜索索引。这个对象通过IndexWriter来提供，并且创建代价也是比较高。一旦IndexReader打开之后，他就不能够发现打开之后的索引变化，如果要知道这些由IndexWriter产生的索引变化，除非刷新IndexReader对象（当然前提需要flush操作）。搜索操作在内部其实是按段来进行的（每次一个段）。

###Near Real-Time Search### 获取一个新的IndexReader开销很大，所以也是我们不能每次已有索引操作就真得去获取一个新的IndexReader，你可以隔一段时间去刷新以下，比如每隔一秒钟等。这也是在这里称之为接近实时（near real-time）的原因。

###可能用来伸缩Lucene的途径（Possible approach to Scale Lucene）### ####Distributed Directory#### 其中一种途径用来伸缩Lucene就是使用分布式文件系统，大文件会被拆分成chunks块并且会保存到分布式文件系统（比如Coherence、Terracata、Gigapaces or Infinispan等等）。这样，IndexWriter和IndexReader都是工作在一个自定义的Directory分布式实现上，每个操作后面其实是分不了很多个节点，每个节点上面存储了索引文件的一部分。

但是这种方案会有一些问题：