我仍然试图了解say，每月一个索引，使用ElasticSearch在一个索引中每月一种类型的好处。
在我们的应用程序中，用户可能有超过500,000个数据记录（他们自己的相关用户ID数据，乘以数千个用户） - 一次提供10-100个文档。收集的数据将是UserData和TransactionHistory。
ElasticSearch pagination documentation很好地说明了为什么对于大量数据，最好创建多个索引：
要理解为什么深度分页存在问题，让我们想象一下 正在一个索引中搜索五个主分片。什么时候我们 请求结果的第一页（结果1到10），每个分片 产生自己的前10个结果并将它们返回给请求 节点，然后对所有50个结果进行排序以选择整体 前10名。
现在想象我们要求第1,000页 - 结果10,001到10,010。 除了每个碎片必须生成之外，一切都以相同的方式工作 其前10,010个结果。请求节点然后对所有进行排序 50,050结果并丢弃其中50,040个！
您可以在分布式系统中看到排序结果的成本 我们页面越深，指数级增长。有一个很好的理由 对于任何查询，网络搜索引擎都不会返回超过1,000个结果。
如上所述，这是有道理的。
根据收集的数据量，将UserData和TransactionHistory全部放在每月，每天或每周相同的带时间戳的索引中是否安全？
如果是这样，ES是否有基于计划自动创建具有这些类型的新索引的过程，并根据文件夹（或仅通过命名约定？）组织这些索引，或者是严格控制这些索引的创建由您的应用软件维护？
答案 0 :(得分：0)
您可以在应用程序端进行索引管理，可以使用某个调度程序，也可以在config中使用正确的index template + action.auto_create_index: false进行索引管理。在后面的例子中，您可以将文档索引到不存在的索引，在运行时创建其名称（即基于日期），它将在运行中创建。
谈论UserDate和TransactionHistory时，它实际上是基于您将在索引，索引/请求频率，嵌套/父子关系（如果有）中放入的数据。通常，您可以为此类数据设置单个索引，因为它似乎非常小。如果是这样的话，如果需要某些关系，甚至可以在时间范围切片的索引中复制这些数据。一般来说，它与数据仓库方法中的dimensions和facts管理非常相似。