如何对从SQL Server到ElasticSearch的实时Web应用程序进行数据建模？

Question

在我们的 Web 应用程序中，我们使用 SQL Server 中的非规范化数据集市来处理基于地理位置的用户项目内容。

用户有 1..*项目，1..*地理区域。内容与 UserID、Project ID、地理区域的文本值、标题和说明（均已编制索引的自由文本搜索）一起存储（在数据集市中）：

UserID, ProjectID, Geo, Title, Description, Timestamp

现在想要将其转移到ElasticSearch中，什么是好的数据建模方法？

简单地说，对于数据集市，我正在考虑序列化数据对象（当前使用.Net和EntityFramework）以提供JSON表示并将其填充到ES中。这是一个好方法（也只需要最少的返工）？

关于对整个应用程序进行建模，我见过一些示例，其中 ES 类型将按用户进行组织，因此模型可能如下所示：

User
  User ID, Name, etc...
  ProfileSettings
     Setting1, Setting2, etc...           
  Geographies
     GeoID, GeoName
  Projects
     ProjectID, ProjectName
     ProjectContent
        Key (UserID:ProjectID:ProjectContentID), GeoName, Title, Description, Timestamp

所以这看起来整个 Web 应用程序可以从一个索引/类型运行。有点吓人，不是吗？

我想将来使用 Kibana 和其他分析工具，并且已经阅读了有关数据建模限制的信息，例如不使用父/子类型。

对于这样的东西，一个好的ElasticSearch数据模型会是什么样子的？

另一种提问方式是，如何使用ElasticSearch对实时Web应用程序进行建模，和/或将用户配置和配置文件存储在单独的RDBMS中会更好吗？

谢谢。

Answer 1

如果不了解业务和报告要求，这些问题总是很难回答。但以下是我从与ES的短暂经历中学到的一些准则：

1）您不必将它们全部放在一个索引中，因此“user”和“project”的单独索引可能效果最好。由于 ES 默认为所有字段编制索引，因此按用户搜索项目索引会很快。Kibana 可以搜索多个索引。

2）当时的普遍观点是保持索引尽可能平坦，因此同样的事情也适用于为用户配置文件设置使用单独的索引。

3）除了序列化和填充之外，创建映射可能是有利的。

关于用户配置和配置文件，我认为没有任何令人信服的理由使用 RDBMS。它们将由用户 ID 键控，没有联接要求，不需要 ACID 一致性和并发模型。NOSQL 解决方案将为您提供这些用例所需的模式灵活性。