我的目标是使用ElasticSearch v1.3.2来分析产品交叉销售，所以我需要筛选感兴趣的收据（例如含酒精产品）并查找每个类别的畅销产品。 新的数据将每月编入索引，同时我们将运行分析查询。
每个文档都是单个收据，包括总体信息（总销售额，商店编号等），单个产品信息（产品编号，产品编号，总价值）以及产品树不同级别上的汇总信息。 平均收据有8个项目，所以每个收据文件有10 – 100个嵌套文件。 总共有三千五百万份产品子文件（加上一些更多的产品树层次）。
目前，单个ES节点正在具有16 GB RAM（用于ES和OS的50/50）以及HDD上的虚拟磁盘上的Ubuntu虚拟机上运行。 总索引大小约为120 GB，由于较早的内存不足问题，所有字段都有“format：doc_values”。 在所有的数据caching在RAM上后，我得到了500 – 4000毫秒的响应时间，但是一旦数据变得足够大，ES就会停下来。 我有140个碎片（每个索引10个），大小从200 MB到2 GB不等。
运行一些基准查询后，ES失去它的性能，不断地使用CPU的50％做一些事情（甚至当查询没有运行时），头插件的查询到“localhost：9200 / stats？all = true”取决于45秒。 我安装了Marvel开发版本，并开始在/.marver-kibana/appdata/marvelOpts查询上报告404。
我真的需要更多的内存和/或更多的节点（目前内存是全部数据大小的13％），还是有一些调整我应该尝试？ 我想索引4倍的当前数据量。 早些时候，我在一台8GB的虚拟机上进行了testing，在一半的数据上出现类似的症状。 我会提供更多的信息，如果它会有用的。