es数据存取

ES写数据过程

1. 客户端选择一个node发送请求过去, 这个节点称之为协调节点(coordinating node)
2. 协调节点对document进行路由, 将节点转发到主分片的节点上面
3. 有主分片的节点处理实际请求, 然后将数据同步副本节点
4. 协调节点如果发现主分片和所有副本节点都写完后响应客户端

ES读数据过程 - 根据doc id进行查询

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了
哪个 shard 上面去，从那个 shard 去查询。

1. 客户端将请求发送任意一个node上面, 这个节点称之为协调节点
2. 协调节点会对文档的docid进行hash路由, 计算该文档存在所有的分片和副本之后, 然后再主分片和副本之间 round-robin 随机轮询算法, 选择一个节点处理该请求
3. 接收到请求的node, 返回document给协调节点
4. 协调节点将文档返回给客户端

ES检索流程

ES根据检索的关键字, 将所有文档全部检索出来后返回给客户端

1. 客户端发送一个请求到协调节点
2. 协调节点将该请求发送到所有的分片对应的主分片和副本上去
3. query phase 阶段: 每个shared将自己检索的结果(其实就是一些doc id)返回协调节点, 由协调节点进行合并, 排序, 分页操作后, 产生最后的结果
4. fetch phase 阶段: 有协调节点去各个node上拉取document数据, 返回给客户端

ES 分片设置理论

1. 每个分片的设置最大最好不好找过30G
2. 先预见n年后的ES的整个数据体量
3. 如果: 每天数的数据增量是100M
4. 每年的增量就是35G
5. 如果是设置2个副本, 则整体数据量大约是100G
6. 3年之后数据量是300G, 则分10个分片比较合适
7. 所有服务器的内存总和设置最少需要为150G
8. 性能最佳为300G的文件内存

ES 关于分页

由于ES的分片, 数据分散在各个服务的node节点上面, 分页检索是比较慢的, 举个例子:

1. 协调节点接收到分页请求后, 假如是查询的是第100页, 每页的数据是 10条
2. 各个分片会查询前1000条数据
3. 如果有5个分片那就是5000条数据
4. 接着协调节点会将所有的数据进行合并, 处理然后得到第100页的10条数据
5. 所以结论是 es是分页越深速度越慢

ES 分页的一些解决方案

1. 不允许深度分页
2. 使用 scroll api 下拉将每页数据拉出来