结合关系数据库和弹性搜索

Question

我们有大量的文本文件，我们想要自由文本/全文搜索，结合有关文本文件的关系结构化元数据。因此，搜索可以是“给我属于 X 组（或 X 的子组）、作者（Ari 和 Bari 和 Mari）、属于组织 Y 并包含文本“合成”的所有文件。后半部分一个是全文搜索，另一个已经作为关系数据存储在我们现有的数据库中。

在我们的数据库（相当复杂）中，存储了一种标识文件的方法，以及大量关于文件的各种元数据，分布在数十个表中，从简单的 1-1 关系到 1-多组 pr文件，甚至树结构关系（比如“这个文件是类型 X，类型 X 是类型 Y 的子组，等等）。而且这个元数据可能会随着时间的推移而改变，在整个应用程序中（这是巨大的）。

现在，我作为数据库管理员，认为这可以通过使用 SQL Server 搜索数据库中已有的结构化元数据来解决，将搜索限制为候选文件，然后将候选文件 id 传递给弹性搜索以获取完整-文本搜索。（在我们的代码中添加或提交文件时在弹性上重新索引文件是微不足道的）

然而，我们项目中的elastic-guys自然有不同的想法：从文件中提取所有元数据以及全文内容，进行elastic-search，并在elastic中专门运行搜索。

这使他们可以轻松地运行完整的 lucene 查询，并且从数据库中删除了负载，这很好。然而，这对我来说也带来了一个噩梦，以保持结构化元数据同步，并且由于数据的规模，不可能定期盲目地重新索引/同步所有内容。

我可以看到这两种选择的优点/顾虑。这种事情有最佳实践吗？

Answer 1

两者都用。

您和您的团队需要在此划定一条界限。SQLSERVER 比 ElasticSearch 更昂贵，因此当我遇到类似问题时，将 CPU 资源花在 Elasticsearch 上比花在 sqlserver 上更有意义。

有一些事情可以让您决定在 Elasticsearch 中索引文本数据

您正在寻找什么样的负载？

每分钟几次搜索或每秒几十次搜索？这是主观的，但如果您的大量数据库资源花费在这个查询上，您可能需要卸载它。

保持数据结构化

我发现 elasticsearch 查询语言远不如 SQL 直观。我强烈建议在标准关系数据库中拥有尽可能规范化的数据版本。然后以此为基础制定你的弹性指数。

Elasticsearch 擅长做很多事情，但使用聚合和/或子查询编写复杂的即席查询并不是其中之一。

那么如何同步数据呢？

触发器和队列是我一直在使用的。

在包含您要跟踪的数据的表上添加触发器。这是我所做的其中一个队列的样子。

触发器会记录操作（插入/更新/删除），然后您就知道在 Elasticsearch 索引中要做什么。我发现用弹性重建整个记录并不太昂贵，所以这就是我所做的。

这样，您就可以采用具有大型代码库的项目，并在 elasticsearch 中索引您喜欢的任何数据，而无需进行任何代码更改。一切都由您选择的 RDBMS 中的数据状态来处理。

Elasticsearch（以及所有其他 nosql/文档存储）拥有令人惊叹的用例，但将关系数据存储为主数据库并不是其中之一。为此使用关系数据库。