全文搜索和 2 亿多条记录的数据库答案

【问题标题】：Database for Full Text Search and 200M+ Records全文搜索和 2 亿多条记录的数据库
【发布时间】：2017-08-12 23:35:39
【问题描述】：

我即将创建一个包含至少 2 亿个条目的庞大数据库。数据库需要可以使用全文搜索，并且速度应该很快。

我的数据库从许多不同的数据源获取数据，我需要定期导入新的或更新的数据。

将我的所有数据存储在 mysql 之类的关系数据库中，然后创建一个 nosql 文档数据库（例如 mongodb 或 elasticsearch）只是为了搜索，或者在以下方面没有任何好处，这是一个好主意吗？可靠性和冗余信息的预防？

【问题讨论】：

使用 elasticsearch，您可以从可靠性和横向可扩展性中受益，即速度是有代价的，但一般来说推荐软件的问题是题外话。
谢谢，但问题不在于“正确”的软件，而是更多关于在关系数据库中拥有相同数据是否有任何好处。
如果你需要only 文本搜索，你就可以单独使用 ES。如果您需要其他任何东西，例如事务、一致性等。我建议使用 SQL。

标签： mysql mongodb elasticsearch database

【解决方案1】：

我相信将主要记录保存在 SQL 数据库中并将它们复制到 noSQL 数据库是一种非常常见的方法。

ElasticSearch 有一个关于他们的resiliency 的持续状态页面。即使在最新版本中，ElasticSearch 也会丢失a number of different situations 中的数据。 ElasticSearch 索引结构的重大变化（例如添加分析器）需要您re-index 所有文档。如果您有其他文档来源，此过程会更安全。归根结底，ElasticSearch 并非旨在始终如一地存储文档 - 我只会在偶尔丢失数据不会造成灾难的情况下选择使用 ElasticSearch 作为主存储。

与 ElasticSearch 不同，MongoDB 被设计为resilient。您应该能够在 MongoDB 中安全地存储文档。我发现尝试在 MongoDB 中进行全文搜索可能会有点痛苦，至少与 ElasticSearch 相比是这样。在我看来，对于文本搜索，MongoDB 相对于 MySQL 的FULLTEXT 的唯一优势是它是分布式的。

我们现在正在运行 ElasticSearch 和 MySQL，其好处远远超过了额外基础设施和处理两者之间的复制带来的麻烦。我们之前曾尝试使用 noSQL 解决方案作为主数据存储，但结果是灾难性的。将 ES 与 MySQL 一起运行可以让您两全其美 - SQL 中数据的一致性和安全性，以及 ES 中可扩展、有效的全文搜索。

【讨论】：

【解决方案2】：

我不知道这是否适用于您的情况，但Evan Weaver compared a few of the common Rails search options (Sphinx, Ferret and Solr)，正在运行一些基准测试。

【讨论】：