[原]elasticsearch2.0对索引操作的一些优化

标签: | 发表时间:2015-12-25 04:46 | 作者:laigood12345
出处:http://blog.csdn.net/laigood12345

es2.0已经发布了,改进挺大的,对索引方面的优化的也挺多的。

持久化速率自动化
2.0之前es对于索引持久化到硬盘的速率默认是20mb一秒,这个值有时候会太小从而导致写入速度过慢从而影响索引速度。2.0对其进行了速率自动化的改进。当merge操作太慢时,会自动提高速率。当merge操作跟上来时再降低速率。这样会使突然间进行的大merge不至于占用整个节点的io从而影响到搜索和索引操作。

多数据文件目录支持
使用多个数据文件目录有两个好处,一是提高存储空间,二是提高io能力。
这个功能虽然之前的版本就有,但是原先的实现是基于lucene索引文件的,每次写索引文件时默认都放到空间更多的那个磁盘里,这样一个分片的数据可能分布在不同的磁盘里。这种方法的一个坏处就是当一个磁盘损坏时,在该磁盘有那怕一个索引文件的分片都会损坏。对于2.0来说,这个数据分布操作是以分片为单位的。也就是说当一个分片分配到这个节点时,节点会自动选择这个分片的索引文件分到那个磁盘目录,这样的话单个分片的索引文件只存在同一个磁盘,就算这个磁盘挂了也只是挂了该磁盘上的分片,其它磁盘的不受影响,并且多个磁盘也可以同时使用到。

默认使用doc_value属性
docvalue是lucene的新特性,它的作用是把字段的值存储在磁盘而不是在内存里,这样可以大大降低内存的使用减少gc的发生。对于2.0版,当一个字段设置为indexed并且为not analyzed时,es会自动帮它加上doc_value参数。

支持lucene5的BEST_COMPRESSION特性
BEST_COMPRESSION是lucene5的新索引压缩功能,默认lucene是使用LZ4压缩方式,使用BEST_COMPRESSION压缩的话压缩率更高,但在压缩时会损耗一些处理性能,也就是用处理能力换取存储空间。

对文档id的优化
在1.4.2版之前的es使用自动生成的id当出现网络问题时有可能出现重复的文档,现在进行了优化,每次都是update索引。并提高了通过id查询文档的性能。从1.4版本开始es默认生成的是Flake id而不是之前的uuid,主要是因为之前有人做过性能测试,Flake的文档查找性能比uuid的高一倍。

参考资料: 点击打开链接

作者:laigood12345 发表于2015/12/24 20:46:42 原文链接
阅读:4 评论:0 查看评论

相关 [elasticsearch2 索引 优化] 推荐:

索引SQL优化

- - SQL - 编程语言 - ITeye博客
(一)深入浅出理解索引SQL优化 (转).         实际上,您可以把索引理解为一种特殊的目录. 微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引、簇集索引)和非聚集索引(nonclustered index,也称非聚类索引、非簇集索引). 下面,我们举例来说明一下聚集索引和非聚集索引的区别:  .

oracle 索引优化

- - Oracle - 数据库 - ITeye博客
表:gzl_action_define. 字段:id:主键,有索引. name:一般字段,无索引. 1.使用索引(UNIQUE SCAN). 2.使用索引(RANGE SCAN). 3.不使用索引(TABLE ACCESS (FULL)). 4.使用索引(FAST FULL SCAN). 5.不使用索引(TABLE ACCESS (FULL)).

ElasticSearch索引优化

- - 行业应用 - ITeye博客
ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡. 所以从上我可以通过索引的settings进行第一优化:. 这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的. 所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡.

MySQL B+树索引及索引优化

- - 数据库 - ITeye博客
    MySQL的索引实现由很多种实现,包括hash索引,B+索引,全文索引等,本文只讨论B+树索引. 1.评价一个索引好坏主要看IO的访问次数,B+树红黑树来说,树高很小(出度很大)即可以有效降低IO的访问次数. B+数的高度h=logd(n),d越大,h越小,查询效率越高. 相对B树,B+树d可以很大,因为非叶子节点不存储数据,只存储key,在一个存储页上可以存储更多的key值.

sql优化-6(索引)

- - 数据库 - ITeye博客
索引查询要尽可能的避免回表,如果不可避免,需要关注聚合因子是否过大. 那么该条SQL将进行表扫描,扫描所有该表的数据块. 从数据块中找到记录,并且进行过滤. 可想而知,没有索引将会导致扫描该表所有数据块,性能低下. 那么该条SQL将进行索引扫描,在索引中找到b=5的位置,一般只需要扫描3个块左右就找到了.

Dex – MongoDB索引优化工具

- - NoSQLFan
Dex是一个开源的MongoDB 优化工具,它通过对查询日志和当前数据库索引进行分析,向管理员提出高效的索引优化策略. 在监控过程中,dex会通过stderr输出推荐的结果. 我们看到,在输出结果中,有一个shellCommand字段,里面就是添加索引的语句,如果你觉得dex的推荐不错,就可以直接复制这段脚本在 MongoDB上添加索引了.

mysql 索引优化 btree hash rtree

- - 数据库 - ITeye博客
mysql里目前只支持4种索引分别是:b-tree,full-text,hash以及r-tree索引. b-tree索引应该是mysql里最广泛的索引的了,除了archive,基本所有的存储引擎都支持它. 1.b-tree在myisam里的形式和innodb稍有不同. 在innodb里面有两种形态:其一是primary key形态其leafnode里存放的是数据.而且不仅存放了索引键的数据,还存放了其他字段的数据.其二是secondary index,其leafnode和普通的b-tree差不多,只是还存放了指向主键的信息.

MongoDB范围查询的索引优化

- - NoSQLFan
我们知道, MongoDB的 索引是B-Tree结构的,和MySQL的索引非常类似. 所以你应该听过这样的建议:创建索引的时候要考虑到sort操作,尽量把sort操作要用到的字段放到你的索引后面. 但是有的情况下,这样做反而会使你的查询性能更低. 比如我们进行下面这样的查询:. 查询条件是 {“country”: “A”},按 carsOwned 字段的正序排序.

MySQL学习(索引、引擎、优化)

- - 数据库 - ITeye博客
索引对于查询的速度至关重要,理解索引也是数据库调优的起点. 建立索引前,先设计好建立索引列的数据类型. 1)越小的数据类型性能越好:因为越小的数据类型对于硬盘读取、内存、CPU缓存都需要更少的空间,处理起来更快. 2)简单的数据类型更好:整型比字符型更好. 3)尽量避免使用NULL: 建立索引的列最好是Not Null约束的,如果一定要用NULL,可以用0或者某特殊值替代.

mysql性能优化-慢查询分析、优化索引和配置

- - 数据库 - ITeye博客
profiling分析查询. MySQL 数据库是常见的两个瓶颈是CPU和I/O的瓶颈,CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候. 磁盘I/O瓶颈发生在装入数据远大于 内存容量的时候,如果应用分布在网络上,那么查询量相当大的时候那么平瓶颈就会出现在网络上,我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态.