索引大小只有10G，但会有非常频繁的更新操作，比如1w/s tps对索引中的文档的更新操作。也有非常频繁的查询。
目前测试的结果是要4台 16核64G内存的ssd盘数据节点才能扛住写入负载，并且这时cpu使用率已非常高。
这种情况下不知道可不可以让数据直接存在内存中，是否能提高写入性能。另外如果支持这种方式，在维护上有没有什么注意事项。
目前测试的结果是要4台 16核64G内存的ssd盘数据节点才能扛住写入负载，并且这时cpu使用率已非常高。
这种情况下不知道可不可以让数据直接存在内存中，是否能提高写入性能。另外如果支持这种方式，在维护上有没有什么注意事项。
3 个回复
byx313 - BLOG:https://www.jianshu.com/u/43fd06f9589c
赞同来自:
但是我觉得这种方法的稳定性很低，你还是应该看下你在高并发下disk io的情况，我觉得是磁盘抗不住了。
wangxinrong
赞同来自:
出现问题时一般是cpu使用率很高，并且bulk queue和bulk reject开始大于0
应该也有不少和我有类似需求的吧，比如我记录的是手机客户端最新的状态信息，如果每1分钟更新一次，有50w个在线客户端，那平均每秒的更新请求就是8000个。
像这种情况ES层面有没有什么优化的思路呢？只能在业务逻辑上做优化了吗？
trycatchfinal
赞同来自: