在做集群规划的时候，到底需要给集群的每个节点多少个核心数？这个问题一直困扰了我很久。最近一段时间做千亿数据，PB存储量集群规划的时候，突然想明白了这件事，大致可以用一个公式来计算！
我觉得这是一个非常重要的问题，非常值得重视。其实所谓的集群规划，无非就是根据数据量评估出需要的es节点数，每个节点应该需要多少的CPU，多少的磁盘，多少内存。其中磁盘毋庸置疑，每个节点不要挂过多的数据，如果你想要保证性能，每个节点不要超过4T数据。多了以后堆的压力会比较大（根据实际的生产经验）。至于内存，内存基本上也就是每个节点31G，不超过32G，防止指针压缩失效而浪费堆内存。我测试的上限值是32.95G。至少留一半的内存给linux的 OS Cache。也就是每个机器的标配是64G内存，最大4T硬盘，有条件的数据控制到2.5T以内。磁盘有条件的可以选择SSD，且做raid0。唯独cpu核心数难计算，如果不熟悉es底层检索原理，很难算出来每个节点需要多少个核心数。
下边我把核心数的计算推导成一个公式！
ES 集群规划 核心数计算公式
在es中，查询是search线程池去处理请求的。请求到了底层会落到分片上，分片是分配线程资源的最小单元！所以我们应该先计算出来需要的查询线程数
search thread pool = （单次请求命中总分片数 / 节点数） * 每秒最大并发数 * 单个分片的响应时间（换算成秒）
这里以最小集群规模，3个节点来计算。
假如单次请求命中的总分片数为15，那么每个节点5个分片。每秒并发数为10，单个分片请求时间为 0.2s（200ms ）
search thread pool size = 15 / 3 * 10 * 0.2 = 10
也就是说，想要满足以上的检索需求，则需要的最少search thread pool size 为10。在知道了需要查询线程数，然后就可以算CPU核心数了，注意这里我说的CPU核心数是指，逻辑核心数！
根据官网给出的公式，search thread pool size 的计算公式为：
CPU核心数 *3 / 2 +1
For count/search/suggest operations. Thread pool type is fixed_auto_queue_size with a size of int((# of available_processors * 3) / 2) + 1, and initial queue_size of 1000.
1000是请求队列的大小
所以我们需要的核心数为：
（ search thread pool size - 1）* 2 / 3
假如单次请求命中的总分片数为15，那么每个节点5个分片。每秒并发数为10，单个分片请求时间为 2s（2000ms ）
那么想要满足以上的检索需求，则需要最少的核心数为100。显然，单台机器的CPU核心数不可能给那么多。即使CPU核心数给到，磁盘的IO也会受限。
理论上来说 单个节点CPU的核心数不超过32核心。在16核心 - 32核心之间。取决于磁盘的IO能力。另外也会受限于JVM的GC。所以实际情况，可以结合理论推导公式，结合压测情况，来给核心数。
做压测，做压测，一定要做压测。根据压测结果配合公式来确定最终需要的核心数！
