Question

目前正在制定一个概念，我们将实施一个模块来处理数据与Elasticsearch索引的同步。

在当前平台（由MySQL数据库支持）中，大多数数据都使用外键存储，据我所知，Elasticsearch以完全相反的方式存储数据：没有任何关系的平面。

我们假设我们有以下实体：

人
组织
地址

在MySQL数据库中，个人和组织都有一个外键可以解决。

在将个人/组织同步到Elasticsearch时，我们希望包含该特定实体的所有地址信息。最重要的是，我们还希望在Elasticsearch中存储单个地址。

一致性问题： 如果我们在平台上单独更新上述地址，我们需要确保每个（Elasticsearch）文档中使用此地址的“平面地址数据”也会更新...（在这种情况下，地址必须更新对于个人和组织......）

提议的解决方案： 当在Elasticsearch中同步一个对象时，我们会包含一些可以在以后用来保持数据一致的关系属性，让我们说这样做：

：在Elasticsearch中保存ID为1的人 CURL PUT到URL：http://elasticsearch-server:some_port/testindex/person/1

{
    "firstname" : "John",
    "lastname" : "Doe",
    "address" : {
        "street" : "Some street"
        "number" : "1"
        ...
    }
    "relations" : [
        { "entity" : "address", "id" : "1" }
        ...
    ]
}

在Elasticsearch中保存ID为1的组织 CURL PUT到URL：http://elasticsearch-server:some_port/testindex/organisation/1

{
    "name" : "Some name",
    "address" : {
        "street" : "Some street"
        "number" : "2"
        ...
    }
    "relations" : [
        { "entity" : "address", "id" : "2" }
        ...
    ]
}

在现有平台上，我们将实现以下逻辑，将地址同步到Elasticsearch：

保存地址对象（例如ID为1）
触发此对象与Elasticsearch的同步
完成同步后，对所有类型的Elasticsearch执行查找，其中与实体的关系等于“address”和id 1
对于返回的每种类型，检查平台上是否存在具有给定id的此类型，并触发此对象的“更新”和“同步”。（因为在同步过程中，地址信息将根据外键关系构建，这将包含更新的信息...）

有没有人对这种工作方式有任何反馈？这个想法有用吗？任何人对这种工作方式都有任何负面/积极的经历吗？

更新1：人员，组织和地址只是平台使用的众多实体/对象中的一小部分...我希望避免为任何未来的实体/对象构建任何限制...

更新2：数据已同步到Elasticsearch，因为我们有一个可以/将由第三方公司用来检索数据的API。

更新3：我们正在使用Elasticsearch 2.0，必须在设计阶段定义映射，这意味着我们定义（a）某个文档的父级，我们将不再可以灵活地在未来添加其他父母。（它仅限于修改现有类型的parens ......）

PS：我已经看过parent-child relationship和nested objects，由于他们的限制，他们没有提供我上面描述的问题的解决方案

Elasticsearch并保持关系数据的一致性

0 个答案: