【问题标题】:ElasticSearch usage with MySQLElasticSearch 在 MySQL 中的使用
【发布时间】:2017-03-17 14:15:00
【问题描述】:

我正在使用 ElasticSearch 作为网站的搜索组件。被索引并最终搜索的数据与保存在 MySQL DB 中的数据相同。

我的方法是在相应的 CRUD MySQL 操作发生时添加/删除/修改索引中的数据。

例如,创建操作如下所示:

public function savePost(Request $request) {
    //Firstly, create the object and save it to MySQL
    $post = new Post();
    $post->title = $request->title;
    $post->body = $request->body;
    //...
    //and so on
    $post->save();

    //Secondly, index this new data:
    $elasticSearchClient = ClientBuilder::create()->build();

    $params = [
        'index' => 'some_index_elasticsearch',
        'id' =>  $post->id,
        'type' => 'post',
        'timestamp' => time(),
        'body' => [
            'id' => $post->id,
            'title' => $post->title,
            'body' => $post->body,
            //... and so on
        ],
    ];

    $elasticSearchClient->index($params);

}

如果数据在 MySQL 中被删除/更新,我只需删除它或从索引中更新它。

这是将 MySQL 与 ElasticSearch(或任何其他类似技术,如 Sphinx)一起使用的正确方法吗?或者您会推荐一种更好的方法来使用 MySQL 作为 ElasticSearch 的数据源吗? (这实际上根本没有发生,因为 ElasticSearch 和 MySQL 之间根本没有交互)。

如果有任何不同,我正在使用 https://github.com/elastic/elasticsearch-php 与 ElasticSearch 进行交互。

澄清一下:到目前为止,这种方法确实有效 - 我只是不确定这是否是 正确 方式,或者是否有人能看到我在这种方式下可能遇到的问题东西。

【问题讨论】:

    标签: php mysql elasticsearch


    【解决方案1】:

    没有使用 Elasticsearch 的“正确方法”。 “正确”是相对的,因此“正确方式”是一种支持您的用例的方式。 Elasticsearch 不仅适用于一种特定的用例,而且适用于越来越多的不止一种用例。

    您描述的情况是完全有效的,即在 ES 中索引您在另一个 RDBMS(如 MySQL)中的任何内容,并确保索引的内容与主要事实来源同步。

    在你的用例中你需要记住的一件困难的事情是你必须保证 MySQL 和 ES 始终是 1:1 同步的,并且由于各种原因这并不一定容易做到:

    • 如果您需要关闭 ES 进行维护,但您的应用必须保持正常运行,无论出于何种原因,会发生什么情况?
    • 如果 ES 中出现问题并且文档没有被索引/更新/删除,会发生什么? (请记住,没有交易支持)

    还有其他方法可以同步 MySQL 和 ES,但不那么脆弱,例如by using the binlog.

    您需要问自己这些问题并找出缓解这些潜在问题的策略,因为我可以向您保证它们(和其他人)肯定会出现。

    总而言之,您的架构没有问题,成千上万的公司都在做完全相同的事情,但是,如果您的同步计划失败,您需要制定一个计划。

    【讨论】:

      【解决方案2】:

      ElasticSearch 不太适合 updating/deleting 大规模文档。

      many aproaches 试图尽量减少对其架构的这种不利影响的过载,但如果认为这会增加您的解决方案的复杂性。

      我建议你只在 MySQL 上保留 CRUD 操作,并使用 ES 作为 append-only。实际上,StackOverflow itself 和许多其他伟大的 TI 公司都在使用这种方法。

      【讨论】:

        猜你喜欢
        • 2015-05-05
        • 1970-01-01
        • 2023-01-24
        • 2016-06-21
        • 2021-02-27
        • 2015-07-20
        • 2016-05-10
        • 2017-03-11
        • 2013-06-23
        相关资源
        最近更新 更多