发帖
雷达卡
基于 React + Redux/Mobx 搞定复杂项目状态管理
弹性搜索的极限书写优化
从集群规划的角度来看
你的问题核心是es集群的极限读写能力。这个问题要从es的集群规划来回答。好的能力是建立在健康的集群基础上的。集群规划包括集群的节点数量，索引的切片数量，你提到我们需要明确es集群中节点的分工(不同的节点承担不同角色的利益，不同角色节点的职责不同，消耗的资源也不同。数据节点用于处理碎片数据。协调节点用于合并结果，主节点用于管理集群元数据。如果节点混在一起，会有大量任务进来，可能导致主节点裂脑。经过合理的角色分配，我们可以将不同的资源分配给不同的角色节点，实现资源利用率最大化)。此外，集群规划还包括每个节点应该分配多少资源。
对于es索引的映射结构，还需要注意的是，要充分评估索引的功能，明确每个字段的含义，以决定是否分词，是还是不是存储。
追求es极致的读写能力，我们不能忽视的一点是:硬件资源，最有代表性的是CPU核数和磁盘读写能力(有可能的话升级SSD，但是不要设置磁盘矩阵。如果一台服务器上有多个节点，我们可以为数据节点挂载不同的磁盘目录。)还要考虑网络传输能力，尤其是索引碎片数量较多时，所有碎片得到的结果都要传输到协调节点进行汇总。仍然需要根据实际硬件资源和实际指标要求进行压力测量，以达到CPU和IO的临界最大值，至少不允许一种资源限制其他资源的使用。
es的堆要合理分配，也就是和JVM有关。如果我们节点分配的堆内存比较大，比如31G，可以使用G1垃圾收集器(这里需要真正研究一下JVM中的垃圾收集器，才知道为什么分配)。写压力测试的时候要注意我们的堆和垃圾收集以及上面的硬件资源。
论批量的极限书写
我负责测试阿里云数据中心提供的es私有云。让我告诉你一些我做过的事。
首先我看了es的压力测试报告。他们说我们可以在特定资源下每秒写5W，但是我们实际的压力测试结果是关于4W的。其实es的写作能力是不能用篇数来衡量的。应该是文档的累积大小。我们写能力差的原因是，这个时候es簇的极限写能力在磁盘上，大概9M点每秒。我们测了阿里的测试数据，按照文件大小计算。他们的文档比较小，我们的文档内容比较大。最终结果是:阿里测试数据文档大小* 5W ~=我们自己的数据* 4W ~= 10M。
在此过程中，进行了以下优化:
1.合理计算水桶提交的文件数量，大概10M左右。
2.如果允许，将群集的副本数设置为0。
3.增加刷新间隔。
4.增加批量写入的线程数量。我们已经提升到大约八个批量写线程。发现没有明显的提升，集群的负载已经很高了。
5.如果可以的话，使用自动生成的id(这个看业务，具体场景下只需要自定义ip即可。例如，网络空间映射中的资源描述应该有一个键值作为id)。
6.根据公式合理调整索引缓冲区。
7.如果可以控制的话，通过设置routting，最好是把一批数据打到同一个片上执行。
关于es的查询
时间有限，这里就不说查询技巧了。
说说你问的关于查询时如何预热数据的问题。
我和阿里云数据中心的人聊过es，结论是不是所有的数据都要放在es里。对于我们的网络空间映射场景，我们对资产的描述通常有几十到几百个维度描述字段。我们必须保存这些字段，以用于平台搜索功能的所有方面。就像他们说的，es的极端资源分配，最好是把所有存储的数据都缓存在内存里。对于网络空间的测绘场景，数据都在10T以上，甚至更多，不可能全部缓存。而是基于专家系统特征的检索能力。
当我搜索基于10T数据的单个索引时，我发现并不是所有的查询都很耗时。我要抓取es中耗时且数量庞大的查询操作，通过定期的轮换训练将这些操作预热加载到内存中。这其实就是去短板的做法。
你说的预热，是想提高查询性能，减少召回时间。除了一些查询技巧，做了一些测试后发现，通过缩减搜索结果集，也就是拆分索引。可以有效提高检索的性能(但是需要写一条到业务中所有路由器的路由，入库时需要双写甚至多写)。
基于 React + Redux/Mobx 搞定复杂项目状态管理
download链接：https://pan.baidu.com/s/1Z3PCL4jDtz6LJ0MZ-vsBfQ?pwd=1bai
提取码：1bai
--来自百度网盘超级会员V5的分享
京公网安备 11010802022788号
