2

来自 RDBMS 背景，并试图围绕 ElasticSearch 数据存储模式展开我的头脑......

目前在 SQL Server 中，我们有一个星型模式数据集市，RecordData. 行按用户 ID、与其余可搜索记录有关的地理位置、标题和描述（它们是自由文本搜索字段）来组织。

我想将其移至 ElasticSearch，并已阅读有关为每个用户创建单独索引的信息。如果我理解正确，根据这个建议，我会RecordData在每个用户索引中创建一个类型，对吗？对于Kibana分析而言，用户索引的推荐命名约定是什么？

我对此建议的一个问题是，您将如何在 ES 服务器上组织多个 Web 应用程序？您不想到处都有所有这些用户索引吗？

每个应用程序有一个索引，每个 SQL Server 表都有一个类型是不是很糟糕？

由于在 SQL Server 中，我们有其他用于用户配置的表，基于用户 ID，我认为我可以在用户索引中创建新的 ES 类型进行配置。这是推荐的模式吗？我宁愿这个 Web 应用程序没有两个数据库系统。

欢迎提出建议，谢谢。

4

1 回答 1

1

我经历了同样的事情，还有一些事情需要考虑。

数据建模

你说你今天使用星型模式。Elasticsearch 通常适用于非规范化数据，其中信息的全部位于每个文档中，这与星型模式不同。如果您可以使用非规范化，那很好，但我假设由于您已经拥有星型模式，因此非规范化数据不是一种选择，因为您不想在每次位置名称更改时都去更新数百万个文档（如果我了解用例）。至少在我的用例中，这不是一个选项。

标准化数据的 Elasticsearch 选项有哪些？

这让我们思考如何将星型模式的数据放入像 Elasticsearch 这样的系统中。文档中有几个选项，我关注的主要是

  • 嵌套对象 - 更多详细信息，请访问https://www.elastic.co/guide/en/elasticsearch/guide/current/nested-objects.html。在嵌套对象中，整个信息都保存在一个文档中，这意味着一个位置及其相关用户将位于一个文档中。这可能使它不是最佳的，因为文档会很大，而且位置名称的更改将需要更新整个文档。所以这更好，但仍然不是最优的。
  • 父子关系 - 更多详情，请访问https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child.html。在这种情况下，位置和用户记录将保存在单独的索引中，类似于关系数据库。这似乎是我们需要的正确建模。此选项的唯一主要问题是，截至撰写本文时，Kibana 4 并未提供基于父/子关系操作/聚合文档的方法。因此，如果您使用 Elasticsearch 的主要驱动力是 Kibana（这是我的），那么这种选择就消失了。如果您想从作为引擎的弹性搜索速度中受益，这似乎是您用例的理想选择。

在我看来，一旦你做对了数据建模，你所有的问题都会更容易回答。

关于服务器本身的组织，我们的组织方式是在负载均衡器后面有一个由 3 个弹性搜索节点组成的单独集群（所有这些都托管在云上），然后让所有 Web 应用程序使用弹性搜索 API。

希望有帮助。

于 2015-07-31T09:16:16.183 回答