百姓网 Elasticsearch 2.x 升级之路
|
虽然他们算不上是 BUG,然而在 filtered query 只是 deprecated,而不是不能使用的情况下,这也太坑人了,遇到需要多集群滚动式升级的(比如我们),可能就会沿用 filtered query,以便能平滑升级,然后就会掉进深坑而不能自拔. 而 6)也算不上是 BUG,不过对于 doc_min_count = 0,大概率会触发 GC,使用任何 GC 策略都不能正常使用. 三、优化或建议1、Lucene version 在初期版本要显式的在 mapping::settings 中配置.后来的版本没有问题了.建议升级到较高版本以避免这种问题. 2、 aggerations 尽可能不要用在 analyzed fields,原因是 analyzed fields 是没有 doc_values的,另外 analyzed fields 分词之后,你进行 aggerations 也只能得到 term 的统计结果. 3、如果修改文档是增量的,并且不会带来数据覆盖问题,建议使用 update API(或 bulk update API),可接受部分数据更新,而不需要一个完整文档. 4、thread pool 调整. 如果一台服务器内存较大或者因为多集群原因需要配置多个 Elasticsearch JVM node,建议调整默认的 threadpool.search.size (默认值：int((available_processors * 3) / 2) + 1),比如默认值为 24,此时这台机器有 2 JVM node,可以根据各 node 大致的访问量、访问压力在 24 / 2 = 12 上下调整.如果更配置更多的 JVM 以有效利用 CPU 和内存,需要进行这个调整.否则 JVM 可能奔溃而无法启动. 5、count api (search api with size 0) Count API 在某种情况下是很有效,比如当你只想获得 Total Count 的时候,可以使用这个 API. 不过,2.1 以后已经使用 search API 并设置 size = 0 来代替了.新版本中 Elasticsearch Java 代码中 Count API 已经去除,但是应用层面 _count 还是保留的. 6、timeout 参数 2.x 必须加上 s,如 ：? timeout = 3s 四、百姓之道0、基本优化: 包括 硬件(CPU、Memory、SSD)、JVM 及其版本选择(Heap size,GC,JDK8)、系统配置(File Descriptors、VM/Virtual memory、Swap、Swappiness、mlockall). 我们使用多核服务器和大内存,一定程度上可以弥补非 SSD 磁盘. 一台服务器多个 JVM,版本为 JDK8；Heapsize 一般为 30G 以内,根据不同用途、索引大小和访问压力,Heapsize 有 5、10、20、30G 的不同配置,Heap NewSize 配置比较激进,通常大于 Heapsize 的一半；GC 选择 CMS GC. 1、routing : UID,first_category,city + second_category为了提供快速查询,根据业务特点对集群进行不同搭配,如用户访问(带有 Uid)将指向到 UID 集群；查询一个城市的二手手机将会指向到 city + second_category 集群；指定了类目的查询将指向 city + second_category 集群的 first_category 索引(我们的特点是一级类目基本固定). 2、fulltext && normal Cluster（编辑：网站开发网_盐城站长网 ） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
