正文一：Full Text Search Engines vs. DBMS 发表于2009年
正文二：Elasticsearch — A High-Performance Full-Text Search Engine 发表于2016年
不知道大家有没有想过一个问题：数据库服务也支持全文搜索，但我们为什么要用全文搜索引擎！ 如果说是全文搜索引擎更快或者性能更好，那为什么呢？我们都知道solr和elasticsearch都是基于Lucene的，那Lucene又是基于什么做的全文搜索呢？
好吧，我只是有这些疑问，闲着没事儿，权当玩儿，翻译两篇文章！
本宝宝总结两点：1，全文搜索引擎更适用于非结构化的文本查询；2，对于类似于Mongo这种document型数据库，全文搜索引擎胜在对索引的维护
正文一：全文搜索引擎 VS 数据库管理系统
很多数据库用户经常在想：究竟是哪些内容，是一个数据库不能做到，而一个全文搜索引擎能做到的。毕竟，大多数数据库都提供了基于文本的搜索，即使这似乎有一些马后炮的嫌疑。 但在同时，很多搜索引擎提供了一些功能，比如：存储和一些逻辑操作。 那么，作为用户究竟该如何做决定呢？ 在这篇文章里，Marc Krellenstein 对比数据库，给出了全文搜索引擎的优势。
简介
全文搜索引擎可以做什么
全文搜索引擎胜在快速和高效的查询大批量非结构化的文本—文档或者其他包好自由结构文本的记录，并且返回这些基于用于搜索匹配的结果文档，他们可以根据具体的数值或者字段去进行快速高效的排序、分类等。一个系统的 全文搜索功能应该是丰富并且灵活的，并且还需要支持基本关键字的查询：互联网式+/-语法，布尔运算符的使用，有限的真实或伪自然语言处理，邻近操作，查找类似等。关联排序功能定义了一个查询操作的最好匹配结果。在数据库中，他们通常会作为一个整体：文档中邻近的查询术语的接近度，特定术语，字段或文档的特殊权重等等。
这些传统的文档通常只有一种类型或者结构。这种结构通常由主要的自由结构文本字段（例如，文档的主体或产品的主要描述），附加的辅助自由结构文本字段（例如，标题或摘要）和一些非文本或 更多约束的文本字段（例如，出版日期，大小，价格，产品代码等）。 将主文本字段称为主要数据或文本以及与其相关的其他字段（标题，价格等）通常是作为元数据。 然而，这些文件或记录 - 这些术语可以互换使用来指代全文搜索系统中的单个索引“项目” - 也可以被视为简单的字段连接。 任何数量的这些字段可以是自由结构文本，并且它们中的任何一个可以是非文本或更多约束的文本数据（例如，一些数量的商品代码之一）
全文搜索系统通常采用这些数据索引和搜索的视图：每个文档/记录只是字段的集合。 给定的搜索总是针对单个字段或某些字段的组合运行，尽管最终用户可能不知道这一点，特别是如果默认是一起搜索所有字段。
全文搜索系统通常依赖某些类型的索引来执行查询。 最常见的是反向索引，它有效地列出了每个文档中的每个术语 - 每个单词，数字等 - 以及哪些文档包含该术语的指示（以及如果搜索短语或其他邻近操作被支持的位置） 他们通常是这样）。 每个字段可能有一个单独的索引，或者所有字段可以包含在单个索引中。 在给定的文档中，一个或多个字段可能没有价值。 然而，所有文档的结构是相同的，因为给定全文索引的所有文档的可能字段集合是相同的。
全文搜索系统通常包含处理非文本字段的一些功能，例如范围搜索，按任何字段排序结果的能力等。但是这些功能并不像关系数据库那么强大。
搜索结果将来自一组具有一组字段的索引文档。该集合可能是许多来源和许多类型的文档的汇总。为索引定义的一组字段将需要包括从任何文档来源搜索的所有字段。这可能意味着某些信息需要重复某些字段，例如，如果城市字段是波士顿，还需要存储或搜索状态信息，州将需要是马萨诸塞州每个城市波士顿的记录。在“归一化”的关系数据库中，波士顿在马萨诸塞州的事实只会存储一次。一些全文系统可以提供一些有效“连接”不同类型的数据的能力，从而最小化这种冗余。这可以通过附加的特殊索引结构，通过预定义的“过滤器”查询来完成，该查询保留关于常见查询约束的信息（有效地加入具有存储查询的查询）或通过多遍搜索技术。这些多记录类型的功能不像在关系数据库中一样丰富或直截了当。
除索引数据之外，大多数现代全文搜索系统（包括Lucene / Solr）可让您实际存储和检索其原始形式的数据。他们这样做的一个原因是能够轻松地填充具有实际数据的搜索结果列表。文件的标题或摘要 - 以便更容易查看哪些文档最相关并值得开放以进行全面审核。所选文件/记录通常从原始位置开始打开，但也可以将整个文档/记录存储在搜索系统中，并从系统内查看。现代全文搜索系统还支持增量索引，包括添加，删除或更新记录的能力。尽管如此，全文系统在快速安全地处理事务更新的能力上有所限制。这部分是因为文本搜索的全文系统的速度和规模优势很好地归功于复杂的索引压缩，以表示在数百万个特定文档中可能出现给定的单词。这种压缩限制了选择性索引更新的能力。然而，一些全文搜索引擎通常在基于内存的索引分区中支持近实时更新，后者在后台的某个时刻将其转换为更充分的基于磁盘的索引。
全文搜索系统的最优功能可以归纳如下：
1，子秒搜索结果指出哪些文件可能在数百万或数十亿的用户搜索中包含一个或多个术语（单词，数字等）。 这包括对所有文本字段的良好搜索，以及搜索非文本数据的功能有限。 这还可以包括基于特定领域的具体值的有效内容或搜索结果的分类或搜索结果。
2，丰富灵活的文本查询工具和复杂的排名功能，以找到最好的文档/记录。
3，添加，删除或更新文档/记录的基本功能。
4，存储数据的基本功能（而不是简单的索引和搜索）。 并不是所有的全文搜索系统都支持这种功能，但大多数都包括Lucene / Solr。
5，搜索和操纵实际表示不同记录类型的数据的功能有限。
什么时候使用全文搜索引擎
可能建议在关系数据库中选择全文搜索系统的应用程序要求是与全文搜索系统的上述优点和限制相对应的应用要求：
1，大量的自由结构的文本数据（或包含此类数据的记录）要搜索或 方面/分类 - 数十万或数百万个文件/记录（或更多）。
2， 支持大量基于交互式文本的查询。
3，需求非常灵活的全文搜索查询。
4，对高度相关的搜索结果的需求未被可用的关系数据库所满足。
5， 对不同记录类型，非文本数据操作或安全事务处理的需求相对较少。
该列表首先提供了选择全文搜索系统的一些原因，或者迁移关系数据库应用程序的部分或全部。这种数据库应用程序在应用程序开始时可能已经足够了，但由于数据增加，用户数量或搜索请求的类型，现在具有一个或另一个性能或有效性问题。移动到全文搜索系统的许多人实际上只是在寻找其非结构化内容的情况下发现自己。在某些情况下，这是因为关系数据库的原始选择因为应用程序的真正“关系”（多表）或“数据库管理”（事务处理）要求而减少，而只是因为需要持久存储数据和数据库似乎是一个自然的选择，可用。数据库技能的提供和缺乏全文搜索技能也可能是一个原因。但是，虽然数据库可能已经足够一段时间的全文搜索需求，但它正在支持，环境的变化或仅仅是对更好的文本搜索的需求，现在激励用户寻找更好的解决方案。
即使数据库中存在多个记录类型，一旦数据平坦化，全文本搜索系统仍然可能是更有效的工具，即来自不同表格的记录被组合成适合全文的单个更长记录格式 搜索引擎。 只要没有大量的表组成要搜索的数据，并且前提是多表记录操纵（和复杂的事务处理）不是应用程序的关键组件，这通常是有效的。 许多关系数据库应用程序属于这一类别，只有一个或几个表格和有限的丰富的事务处理或恢复的需求。 （事实上，如果真正的DBMS需求足够小，那么即使全文搜索需求不显着，搜索引擎也可能会更快，但功能上更为充分。
在某些情况下，由于应用程序需求，数据将需要保留在关系数据库中，但数据库提供的全文搜索在某些方面是不够的。 在这些情况下，数据可能会导出到文本系统中，以进行全文索引和搜索，两个系统一起使用。 这样的出口可能是相对静态的（例如，夜间过程）或更加动态 - 数据在飞行中提取和/或更快地被索引，或许是实时的。 最好的全文搜索系统提供了一种机制，可以将关系数据库中的表格数据轻松映射到全文系统的索引字段。
总结
全文搜索系统擅长高速搜索和大量数据的分析。 它们在处理多记录类型或事务处理方面不如关系数据库那么强大，但在许多情况下它们可能适合这些需求。 一些DBMS应用程序真的在那里，因为方便，而不是因为他们要求关系型数据库管理系统的功能。 如果DBMS不再满足应用程序的需要，这些应用程序可以成功迁移到全文搜索系统。 其他应用程序可以部分迁移到全文搜索系统，以支持全文搜索需求，或者可以将数据索引到两者中以提供每种优点。
---------------------------机翻结束，懒是一种病，得治---------------------------------------
正文二：Elasticsearch—高性能全文搜索引擎
一般而言，在我们的脑子里会很快的浮现出一个疑问：在这种场景下，哪一种全文搜索方案是性能最优的呢？
阅读这篇短文，看看我们是怎么回答这个问题的！
大部分的开发人员会学习到几个好的解决方案，这些解决方案可以高效的处理百万级别的全文搜索：
MongoDB，使用自定义功能、mysql、postgreSQL、Elasticsearch
所有这些都是可靠的数据管理系统，但是，当我们在选择一个最好的全文搜索方案时，我们仍然需要考虑2个点。第一：SQL 全文搜索对于设置索引和查询来说，相当简单。但是，这里有几个缺陷：
1，我们几乎无法控制索引
2，在特定的索引、词法、内容方面，我们几乎无能为力
3，搜索将会运行在DBMS服务器，而这通常是我们最无力扩展的基础设施
第二：我们知道，在前期，Elasticsearch需要做更多的工作，因为我们需要设置并且维护分布式集群节点。我们也需要提供代码去控制我们的索引——这也可能是一个有计划的工作：根据更改后的日志（处理新的/更改的数据），去构建用于索引的片段。与SQL一样，我们还需要花费时间来构建查询。 但是，我们拥有一个巨大的惊喜，这个惊喜是来源于我们对于Elasticsearch所做的一切努力：
1，精确控制我们的索引和查询
2，完美的可扩展性，因为我们可以提供我们需要的集群节点
3，本地文档、索引访问
现在，我们让你进入一个“秘密”。与SQL系统相反，使用Elasticsearch，完全不需要修改数据的本地形式（或执行初步映射）来适应查询的结构。
很多应用的数据层，一个很重要紧急的开发工作就是去设计关于数据恢复的方法。在Elasticsearch里面，这仍然是一件极其重要的工作，但是，这也正是其精妙所在：我们可以让数据在本地（源文档），并且根据这些本地数据建立索引。然后，我们可以配置Elasticsearch去匹配这些在源文档的数据。这样做的优势是：我们不需要去建立一些额外的字段去绑定文档。
至此，有人可能会说：“但是，我依然没有发现Elasticsearch有什么吸引人的，我还是喜欢用DBMS” 是的，我们曾经也这样认为。
可能你也正在寻找其他的应用场景去增长自信，但是，请思考：我们的一些在Qbox的职工通常会活跃在StackOverflow.com。我们也了解到，Stack Overflow是建立在SQL 全文搜索的平台上的。 伴随着Stack Overflow平台的发展，当功能和性能成为主要的限制时，他们也从SQL 全文搜索变成了Elasticsearch。
我们可以很有信心的说，这是值得的。是的，我们必须进行额外的初始配置工作。但是，当我们考虑使用Elasticsearch在大数据集上返回Sub-Second响应的总体工作量和成本时，这是SQL数据库或Mongo解决方案所需的总体工作量的很小一部分。对于SQL系统，需要在数据存储之外执行如此多的预处理才能使数据可搜索。使用这些传统系统，实现Elasticsearch提供的性能和查询灵活性的平衡将是一个巨大的挑战。