数据预热
假如说，哪怕是你就按照上述的方案去做了，es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍，比如说你写入一台机器 60G 数据，结果 filesystem cache 就 30G，还是有 30G 数据留在了磁盘上。
其实可以做数据预热。
举个例子，拿微博来说，你可以把一些大V，平时看的人很多的数据，你自己提前后台搞个系统，每隔一会儿，自己的后台系统去搜索一下热数据，刷到 filesystem cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。
或者是电商，你可以将平时查看最多的一些商品，比如说 iphone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 filesystem cache 里去。
对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里面去。这样下次别人访问的时候，性能一定会好很多。
冷热分离
es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 filesystem os cache 里，别让冷数据给冲刷掉。
你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 shard。3 台机器放热数据 index，另外 3 台机器放冷数据 index。然后这样的话，你大量的时间是在访问热数据 index，热数据可能就占总数据量的 10％，此时数据量很少，几乎全都保留在 filesystem cache 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10％ 的人去访问冷数据，90％ 的人在访问热数据，也无所谓了。
副本可能有助于提高吞吐量，但并非始终如此
除了提高弹性之外，副本还可以帮助提高吞吐量。例如，如果您有一个单分片索引和三个节点，则需要将副本数设置为2，以便总共拥有3个分片副本，利用所有节点。
现在，假设您有一个2分片索引和两个节点。在一种情况下，副本数为0，这意味着每个节点都拥有一个分片。在第二种情况下，副本数为1，这意味着每个节点都有两个分片。哪种设置在搜索效果方面效果最好？通常，每个节点的分片总数较少的设置会更好地执行。这样做的原因是，它为每个分片提供了更多的可用文件系统缓存份额，并且文件系统缓存可能是Elasticsearch的第一性能因素。同时，请注意，在单节点故障的情况下，没有副本的部署更容易失败，因此在吞吐量和可用性之间要进行权衡。
那么正确的副本数是多少？如果您的集群总共有num＿nodes个节点，总共有num＿primaries个主分片，并且如果您希望最多一次处理max＿failures个节点故障，那么适合您的副本数是max（max＿failures，ceil（num＿nodes ／ num＿primaries）－1）。
首页
