ElasticSearch：对同一映射定义使用不同索引的优缺点

Question

假设我定义了两个 ElasticSearch 映射，例如：

"firstMapping" : {
    "properties" : {
        "name" : {
            "type" : "string"
        },
        "someProperty" : {
            "type" : "string"
        }
    }
}

和

"secondMapping" : {
    "properties" : {
        "name" : {
            "type" : "string"
        },
        "someOtherProperty" : {
            "type" : "string"
        }
    }
}

我有两个问题：

目前，这些映射是在两个不同的索引中创建的，没有明显的原因（除了通过计算一个映射中的文档数量来快速计算其索引中的元素数量，这似乎是一个非常虚假的原因）。

我认为这样做的首选方法是创建一个包含这两个相关映射的索引，因为关系数据库会包含许多不同的表。
对于每个映射，一个文档都有一个 "origin"，"realtime" 或 "batch"。 如您所愿已经猜到了，对于每个 "batch" 文档，应该有一个对应的 "realtime" 文档，每个文档基本上都包含相同的值。

换句话说，在该系统中，一个 "record" 应该正好由两个文档组成：一个 "batch" 文档和一个 "realtime" 文档，它们在其他方面是相同的。

因此，只有一个"batch"或"realtime"文档应该被认为是不正常的；因此需要有一种简单的方法来比较 "batch" 和 "realtime" 数据。

目前，每个映射实际上是在两个索引中创建的，这样
- batchFirstMappingIndex 包含 firstMapping 个 "batch" 来源的文档
- realtimeFirstMappingIndex 包含 firstMapping 个 "realtime" 来源的文档
（分别为 secondMapping）

由于映射本质上是类型，我想知道为两个来源设置一个映射是否更合适，例如：
```
"firstMappingWithOrigin" : {
    "properties" : {
        "origin" : {
            "type" : "boolean"
        },
        "name" : {
            "type" : "string"
        },
        "someProperty" : {
            "type" : "string"
        }
    }
}
```
（分别为 secondMapping） "batch" 的 false 值和 "realtime"

true

总而言之，我目前在 4 个单独的索引中有 4 个资源：

batchFirstMappingIndex/firstMapping
realtimeFirstMappingIndex/firstMapping
batchSecondMappingIndex/secondMapping
realtimeSecondMappingIndex/secondMapping

我认为我们可以很容易地在一个索引中只包含 2 个资源：

myIndex/firstMappingWithOrigin
myIndex/secondMappingWithOrigin

这两种解决方案的优点和缺点是什么？第二种方法的最佳理由是什么？

对于这两个问题，我特别关心的是：

读取（动态生成聚合）和写入性能
索引维护（例如 adding/removing/modifying 映射属性）
比较"batch"和"realtime"数据

Answer 1

ES 人员的以下文章应该对此有所说明：http://elastic.co/blog/index-vs-type

另请注意，"removing properties" 在 ES 中是不可能的，"modifying properties" 仅限于兼容的更改。

ElasticSearch：对同一映射定义使用不同索引的优缺点

ElasticSearch: pro and cons of having different indices for same mapping definition

architecture

database-design

elasticsearch