Php Elasticsearch-我需要JDBC驱动程序吗？

目标

将elasticsearch服务器与SQL数据库中的新数据和过期数据同步

问题

我有两种不同的方法可以达到这个目的，我不知道哪一种更好。我可以使用JDBC river插件直接连接到SQL数据库，将信息拉入elasticsearch。或者，我可以使用PHP客户端将数据推送到elasticsearch，使用以下代码作为示例：

// The Id of the document
$id = 1;

// Create a document
$tweet = array(
    'id'      => $id,
    'user'    => array(
        'name'      => 'mewantcookie',
        'fullName'  => 'Cookie Monster'
    ),
    'msg'     => 'Me wish there were expression for cookies like there is for apples. "A cookie a day make the doctor diagnose you with diabetes" not catchy.',
    'tstamp'  => '1238081389',
    'location'=> '41.12,-71.34',
    '_boost'  => 1.0
);
// First parameter is the id of document.
$tweetDocument = new \Elastica\Document($id, $tweet);

// Add tweet to type
$elasticaType->addDocument($tweetDocument);

// Refresh Index
$elasticaType->getIndex()->refresh();

我打算每三十分钟运行一次cron，检查数据库中不仅有“活动”标志而且没有“索引”标志的项目，这意味着我需要将它们添加到索引中

问题

---

鉴于我有两种方法以两种不同的方式在elasticsearch和mysql之间同步数据，那么每种方法的优缺点是什么。是否有一个特定的用例定义使用一个而不是另一个

我会使用河流法。

河流的优势：

• 已经建成了。只需下载它，设置您的配置，一切都完成了
• 测试。这条河被几个人使用过，因此错误得到了纠正
• 可定制。您可以设置两次运行之间的持续时间，定义用于获取新数据的sql语句，等等

您的解决方案的优点：

• 高度可定制，您可以随意使用脚本

您的解决方案的缺点：

• 需要特别的旗帜
• 容易出错（因为它长时间未经测试）

---

因此，只要您可以根据需要定制河流，就可以使用它。如果river不支持您想做的事情，那么您可以坚持使用自己的解决方案。

我会使用river方法甚至认为内部构建解决方案可能更易于定制

另一方面，jdbc river插件是一个已经构建的插件，到目前为止，它有大约20个贡献者。因此，在elasticsearch自身不断改进的过程中，您需要一个额外的团队来改进该工具

您只需安装它，甚至不需要复杂的配置就可以在集群和关系数据库之间设置一条河流

JDBCRiver解决方案的另一个优点是不需要处理内存管理。插件可以在“拉模式”下作为河流运行，也可以在“推模式”下作为馈线运行。在feeder模式下，插件在单独的JVM中运行，可以连接到远程Elasticsearch集群。我个人更喜欢river模式，因为在本例中，Elasticsearch将处理索引和内存管理问题

对于Elasticsearch文档的无模式索引模型，关系数据在内部转换为结构化JSON对象

两端都是可伸缩的。该插件可以并行地从不同的RDBMS源获取数据，多线程批量模式确保了索引到Elasticsearch时的高吞吐量

此解决方案的缺点之一是，在完成索引时不会通知。作为解决方案，我建议您使用来比较结果

river的另一个缺点是，它不会在更新时拉取，而是在插入或删除时拉取。我指的当然是sql操作更新、插入和删除

<强>第二手，您的解决方案可能带来一些优点和缺点，您可能需要考虑。 您的解决方案是高度可定制的，因此您可以根据需要管理脚本。但是考虑到任何可用的PHP Elasticsearch客户端（、或）的当前状态，甚至考虑到这些家伙在他们身上做得很好，与用于river的官方Elasticsearch JAVA API相比，它仍然被认为是一个不太成熟的API

<>你也应该考虑处理所有的错误，这些错误会使你的集群从内存丢失、管理、性能等方面产生错误。 例如：我试图在一个测试环境中，使用Elastica API将我的数据从数据库推送到集群，配置为32g RAM，每个8核运行@2.05GHz，构建一个概念验证，但没有涉及太多细节。我花了5个小时将1000万条记录从数据库推送到集群。与河流一样，同样的记录需要20分钟。当然，在我的代码中可能会有一些优化，但我认为它能带给我更多的时间。

因此，只要你能根据自己的需要定制河流，就可以使用它。如果河流不支持你想做的事情，那么你可以坚持自己的解决方案

---

<>强> nb: < /强>当然，可能还有其他的点你想考虑，但是这个主题在这里讨论很长。因此，我选择了一些要点，我发现您应该意识到这一点。

如果您一时忘记需要将初始数据导入Elasticsearch，我将使用事件系统将数据推送到Elasticsearch。从长远来看，这更有效

您的应用程序确切地知道什么时候需要通过Elasticsearch为某些内容编制索引。以您的tweet为例，在某个时刻，一条新tweet将进入您的应用程序（例如，用户编写一条）。这将触发

newTweet

事件。您有一个侦听器，它将侦听该事件，并在发送此类事件时将tweet存储在Elasticsearch中

如果您不想在web请求中使用资源/时间来执行此操作（并且您肯定不想执行此操作），侦听器可以向队列中添加作业（例如）。然后，您需要一名工作人员来接手这份工作，并将推文存储在Elasticsearch中

主要的优点是Elasticsearch更能保持最新