- ES跨集群搜索（CCS）
- 分片的设计和管理
- 算分不准 dfs_query_then_fetch
- 如何设计分片数
- ES底层读写工作原理
- ES写入数据的过程
- ES读取数据的过程
- 写数据底层原理
- 提升集群的读写性能
ES跨集群搜索（CCS）
- ES水平扩展存在的问题
- 单集群水平扩展时，节点数不能无限增加
- 当集群的meta 信息(节点，索引，集群状态)过多会导致更新压力变大，单个Active Master会成为性能瓶颈，导致整个集群无法正常工作
- 早期版本，通过Tribe Node可以实现多集群访问的需求，但是还存在一定的问题
- Tribe Node会以Client Node的方式加入每个集群，集群中Master节点的任务变更需要Tribe Node 的回应才能继续
- Tribe Node 不保存Cluster State信息，一旦重启，初始化很慢
- 当多个集群存在索引重名的情况时，只能设置一种 Prefer 规则
- Elasticsearch 5.3 引入了跨集群搜索的功能 (Cross Cluster Search)，推荐使用
- 允许任何节点扮演联合节点，以轻量的方式，将搜索请求进行代理
- 不需要以Client Node的形式加入其他集群
elasticsearch.bat ‐E node.name=cluster0node ‐E cluster.name=cluster0 ‐E path.data=cluster0_data ‐E discovery.type=single‐node ‐E http.port=9200 ‐E t
ransport.port=9300
elasticsearch.bat ‐E node.name=cluster1node ‐E cluster.name=cluster1 ‐E path.data=cluster1_data ‐E discovery.type=single‐node ‐E http.port=9201 ‐E t
ransport.port=9301
elasticsearch.bat ‐E node.name=cluster2node ‐E cluster.name=cluster2 ‐E path.data=cluster2_data ‐E discovery.type=single‐node ‐E http.port=9202 ‐E t
ransport.port=9302
# 在每个集群上设置动态的设置
PUT _cluster/settings
{"persistent":{"cluster":{"remote":{
"cluster0":{"seeds":["127.0.0.1:9300"],"transport.ping_schedule":"30s"},
"cluster1":{"seeds":["127.0.0.1:9301"],"transport.compress":true,"skip_unavailable":true},
"cluster2":{"seeds":["127.0.0.1:9302"]}}}}}
- CCS的配置
- seeds 配置的远程集群的 remote cluster 的一个 node
- connected 如果至少有一个到远程集群的连接则为 true
- num_nodes_connected 远程集群中连接节点的数量
- max_connections_per_cluster 远程集群维护的最大连接数
- transport.ping_schedule 设置了tcp层面的活性监听
- skip_unavailable 默认是false，当对应的remote cluster不可用的话，则会报错
- 设置为true的话，当这个remote cluster不可用的时候，就会忽略
- cluster.remote.connections_per_cluster gateway nodes数量，默认是3
- cluster.remote.initial_connect_timeout 节点启动时等待远程节点的超时时间，默认是30s
- cluster.remote.node.attr 一个节点属性，用于过滤remote cluster中符合gateway nodes的节点
- 比如设置
cluster.remote.node.attr=gateway，那么将匹配节点属性 node.attr.gateway:true 的node才会被该node连接用来做CCS查询
- cluster.remote.connect 默认情况下，群集中的任意节点都可以充当federated client并连接到remote cluster
- cluster.remote.connect可以设置为 false（默认为true）以防止某些节点连接到 remote cluster
- 在使用api进行动态设置的时候每次都要把seeds带上
# 查询结果获取到所有集群符合要求的数据
GET /users,cluster1:users,cluster2:users/_search
{"query":{"range":{"age":{"gte":30,"lte":40}}}}
分片的设计和管理
- 单个分片
- 7.0开始，新创建一个索引时，默认只有一个主分片
- 单个索引，单个分片时候，集群无法实现水平扩展
- 两个分片
- 集群增加一个节点后，Elasticsearch 会自动进行分片的移动，也叫 Shard Rebalancing
算分不准 dfs_query_then_fetch
- 算分不准的原因
- 相关性算分在分片之间是相互独立的，每个分片都基于自己的分片上的数据进行相关度计算
- 这会导致打分偏离的情况，特别是数据量很少时
- 当文档总数很少的情况下，如果主分片大于1，主分片数越多，相关性算分会越不准
- 解决算分不准的方法
- 数据量不大的时候，可以将主分片数设置为1
- 当数据量足够大时候，只要保证文档均匀分散在各个分片上，结果一般就不会出现偏差
- 使用 DFS Query Then Fetch
- 搜索的URL中指定参数
_search?search_type=dfs_query_then_fetch - 到每个分片把各分片的词频和文档频率进行搜集，然后完整的进行一次相关性算分
- 耗费更加多的CPU和内存，执行性能低下，—般不建议使用
GET /blogs/_search?search_type=dfs_query_then_fetch
{"query":{"match":{"content":"elasticsearch"}}}
如何设计分片数
- 当分片数>节点数时
- 一旦集群中有新的数据节点加入，分片就可以自动进行分配
- 分片在重新分配时，系统不会有 downtime
- 多分片的好处: 一个索引如果分布在不同的节点，多个节点可以并行执行
- 分片过多所带来的副作用（Shard是Elasticsearch 实现集群水平扩展的最小单位）
- 每个分片是一个Lucene的索引，会使用机器的资源。过多的分片会导致额外的性能开销
- 每次搜索的请求，需要从每个分片上获取数据
- 分片的Meta 信息由Master节点维护。过多，会增加管理的负担。经验值，控制分片总数在10W以内
- 如何确定主分片数
- 从存储的物理角度看
- 搜索类应用，单个分片不要超过20 GB
- 日志类应用，单个分片不要大于50 GB
- 为什么要控制分片存储大小
- 提高Update 的性能
- 进行Merge 时，减少所需的资源
- 丢失节点后，具备更快的恢复速度
- 便于分片在集群内 Rebalancing
- 如何确定副本分片数（副本是主分片的拷贝）
- 提高系统可用性︰响应查询请求，防止数据丢失
- 需要占用和主分片一样的资源
- 对性能的影响
- 副本会降低数据的索引速度: 有几份副本就会有几倍的CPU资源消耗在索引上
- 会减缓对主分片的查询压力，但是会消耗同样的内存资源
- 如果机器资源充分，提高副本数，可以提高整体的查询 QPS
- ES的分片策略会尽量保证节点上的分片数大致相同，但是有些场景下会导致分配不均匀
- 扩容的新节点没有数据，导致新索引集中在新的节点
- 热点数据过于集中，可能会产生性能问题
- 可以通过调整分片总数，避免分配不均衡
index.routing.allocation.total_shards_per_node
- index级别的，表示这个index每个Node总共允许存在多少个shard，默认值是-1表示无穷多个
cluster.routing.allocation.total_shards_per_node
- cluster级别，表示集群范围内每个Node允许存在有多少个shard。默认值是-1表示无穷多个
- 如果目标Node的Shard数超过了配置的上限，则不允许分配Shard到该Node上
- index级别的配置会覆盖cluster级别的配置
ES底层读写工作原理
- 写请求是写入 primary shard，然后同步给所有的 replica shard
- 读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法
ES写入数据的过程
- 客户端选择一个node发送请求过去，这个node就是coordinating node (协调节点)
- coordinating node，对document进行路由，将请求转发给对应的node
- node上的primary shard处理请求，然后将数据同步到replica node
- coordinating node如果发现primary node和所有的replica node都搞定之后，就会返回请求到客户端
ES读取数据的过程
- 根据id查询数据的过程：根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询
- 客户端发送请求到任意一个 node，成为 coordinate node
- coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡
- 接收请求的 node 返回 document 给 coordinate node
- coordinate node 返回 document 给客户端
- 根据关键词查询数据的过程
- 客户端发送请求到一个 coordinate node
- 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以
- query phase：每个 shard 将自己的搜索结果返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
- fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端
写数据底层原理
- segment file: 存储倒排索引的文件，每个segment本质上就是一个倒排索引，每秒都会生成一个segment文件
- 当文件过多时es会自动进行segment merge（合并文件），合并时会同时将已经标注删除的文档物理删除
- commit point: 记录当前所有可用的segment，每个commit point都会维护一个.del文件
- 每个.del文件都有一个commit point文件（es删除数据本质是不属于物理删除）
- 当es做删改操作时首先会在.del文件中声明某个document已经被删除
- 文件内记录了在某个segment内某个文档已经被删除
- 当查询请求过来时在segment中被删除的文件是能够查出来的
- 但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉
- translog日志文件: 为了防止elasticsearch宕机造成数据丢失保证可靠存储
- es会将每次写入数据同时写到translog日志中
- os cache：操作系统里面，磁盘文件其实都有一个东西，叫做os cache，操作系统缓存
- 数据写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中去
- Refresh
- 将文档先保存在Index buffer中，以refresh_interval为间隔时间，定期清空 buffer，生成 segment
- 借助文件系统缓存的特性，先将segment放在文件系统缓存中，并开放查询，以提升搜索的实时性
- Translog
- Segment没有写入磁盘，即便发生了当机，重启后，数据也能恢复
- 从ES6.0开始默认配置是每次请求都会落盘
- Flush（ES自动完成）
- 删除旧的translog 文件
- 生成Segment并写入磁盘
- 更新commit point并写入磁盘
提升集群的读写性能
提升集群读取性能
- 数据建模
- 尽量将数据先行计算，然后保存到Elasticsearch 中。尽量避免查询时的 Script 计算
- 尽量使用Filter Context，利用缓存机制，减少不必要的算分
- 结合profile，explain API分析慢查询的问题，持续优化数据模型
- 避免使用
*开头的通配符查询
# 查询时的 Script 计算
GET blogs/_search
{"query":{"bool":{"must":[{"match":{"title":"elasticsearch"}}],"filter":{
"script":{"script":{"source":"doc['title.keyword'].value.length()>5"}}}}}}
- 优化分片
- 避免Over Sharing：一个查询需要访问每一个分片，分片过多，会导致不必要的查询开销
- 结合应用场景，控制单个分片的大小
- Search: 20GB
- Logging: 40GB
- Force-merge Read-only 索引
- 使用基于时间序列的索引，将只读的索引进行 force merge，减少segment数量
# 手动 force merge
POST /my_index/_forcemerge
提升写入性能的方法
- 写性能优化的目标: 增大写吞吐量，越高越好
- 客户端: 多线程，批量写
- 可以通过性能测试，确定最佳文档数量
- 多线程: 需要观察是否有HTTP 429（Too Many Requests）返回，实现 Retry以及线程数量的自动调节
- 服务器端: 单个性能问题，往往是多个因素造成的
- 需要先分解问题，在单个节点上进行调整并且结合测试，尽可能压榨硬件资源，以达到最高吞吐量
- 使用更好的硬件。观察CPU / IO Block
- 线程切换│堆栈状况
- 服务器端优化写入性能的一些手段
- 降低IO操作
- 使用ES自动生成的文档ld
- 一些相关的ES 配置，如Refresh Interval
- 降低 CPU 和存储开销
- 减少不必要分词
- 避免不需要旳doc_values
- 文档的字段尽量保证相同的顺予，可以提高文档的压缩率
- 尽可能做到写入和分片的均衡负载，实现水平扩展
- Shard Filtering / Write Load Balancer
- 调整Bulk 线程池和队列
- 注意：ES 的默认设置，已经综合考虑了数据可靠性，搜索的实时性，写入速度，一般不要盲目修改。一切优化，都要基于高质量的数据建模
- 建模时的优化
- 只需要聚合不需要搜索，index设置成false
- 不要对字符串使用默认的dynamic mapping。字段数量过多，会对性能产生比较大的影响
- Index_options控制在创建倒排索引时，哪些内容会被添加到倒排索引中
- 如果需要追求极致的写入速度，可以牺牲数据可靠性及搜索实时性以换取性能
- 牺牲可靠性: 将副本分片设置为0，写入完毕再调整回去
- 牺牲可靠性: 修改Translog的配置
- 牺牲搜索实时性︰增加Refresh Interval的时间
- 降低 Refresh的频率
- 增加refresh_interval 的数值。默认为1s ，如果设置成-1，会禁止自动refresh
- 避免过于频繁的refresh，而生成过多的segment 文件
- 但是会降低搜索的实时性
- 增大静态配置参数indices.memory.index_buffer_size
PUT /my_index/_settings
{"index":{"refresh_interval":"10s"}}
- 降低Translog写磁盘的频率，但是会降低容灾能力
- Index.translog.durability: 默认是request，每个请求都落盘。设置成async，异步写入
- lndex.translog.sync_interval：设置为60s，每分钟执行一次
- Index.translog.flush_threshod_size: 默认512 m，可以适当调大。当translog 超过该值，会触发flush
- 分片设定
- 副本在写入时设为0，完成后再增加
- 合理设置主分片数，确保均匀分配在所有数据节点上
- Index.routing.allocation.total_share_per_node: 限定每个索引在每个节点上可分配的主分片数
- 调整Bulk 线程池和队列
- 客户端
- 单个bulk请求体的数据量不要太大，官方建议大约5-15m
- 写入端的 bulk请求超时需要足够长，建议60s 以上
- 写入端尽量将数据轮询打到不同节点
- 服务器端
- 索引创建属于计算密集型任务，应该使用固定大小的线程池来配置
- 来不及处理的放入队列，线程数应该配置成CPU核心数+1，避免过多的上下文切换
- 队列大小可以适当增加，不要过大，否则占用的内存会成为GC的负担
PUT myindex
{"settings":{"index":{
"refresh_interval":"30s", # 30s 一次 refresh
"number_of_shards":"2"},"routing":{"allocation":{
"total_shards_per_node":"3" # 控制分片，避免数据热点
}},"translog":{"sync_interval":"30s",
"durability":"async" # 降低 translog 落盘频率
},"number_of_replicas":0},"mappings": {
"dynamic": false, # 避免不必要的字段索引，必要时可以通过 update by query 索引必要的字段
"properties":{}}}
1179
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
