• 渗透查询
渗透查询也被称为持久化查询、前瞻性搜索、文档路由、反向搜索和逆向搜索。
传统的搜索方式是存储文档并对其执行搜索查询。然而，在某些情况下，我们希望对新来的文档应用查询，以检测是否匹配。这种情况的典型例子包括监控系统，它们收集数据并在特定事件发生时通知用户，如某个指标达到某个阈值或监控数据中出现特定的值。另一个例子是新闻聚合，用户可能只想接收到特定类别或话题的通知，甚至是特定“关键词”的通知。
在这些情况下，传统搜索并不适合，因为它假设搜索是在整个集合上执行的。这种过程会因为用户数量的增加而倍增，导致在整个集合上运行大量查询，增加了系统负载。本节中描述的替代方法是存储查询，并将其与新文档或文档批次进行匹配。
Google Alerts、AlertHN、Bloomberg Terminal 和其他允许用户订阅特定内容的系统都使用了类似的技术。
使用 CALL PQ 执行渗透查询
关于渗透查询，最重要的概念是搜索查询已经存储在表中。您需要提供的是 要检查的文档，看它们是否与任何存储的规则匹配。
您可以通过 SQL 或 JSON 接口，以及编程语言客户端执行渗透查询。SQL 方法提供了更多灵活性，而 HTTP 方法更简单并提供了大部分所需的功能。下表帮助您理解两者的区别。
提供单个文档
CALL PQ('tbl', '{doc1}')
query.percolate.document{doc1}
提供单个文档（替代方案）
CALL PQ('tbl', 'doc1', 0 as docs_json)
-
提供多个文档
CALL PQ('tbl', ('doc1', 'doc2'), 0 as docs_json)
-
提供多个文档（替代方案）
CALL PQ('tbl', ('{doc1}', '{doc2}'))
-
提供多个文档（替代方案）
CALL PQ('tbl', '[{doc1}, {doc2}]')
-
返回匹配的文档 ID
0/1 as docs（默认禁用）
默认启用
使用文档的 ID 字段显示在结果中
'id field' as docs_id（默认禁用）
不可用
将输入文档视为 JSON
1 as docs_json（默认 1）
默认启用
将输入文档视为纯文本
0 as docs_json（默认 1）
不可用
返回匹配查询的所有信息
1 as query（默认 0）
默认启用
跳过无效的 JSON
1 as skip_bad_json（默认 0）
不可用
接下来我们展示如何工作。首先，创建一个包含两个字段的 PQ 表：
title（文本）
color（字符串）
然后添加三条规则：
纯全文检索。查询：
@title bag全文检索并过滤。查询：
@title shoes，过滤：color='red'全文检索并更复杂的过滤。查询：
@title shoes，过滤：color IN('blue', 'green')
SQL
JSON
PHP
Python
javascript
java
C#
TypeScript
Go
只告诉我哪些 PQ 规则匹配我的单个文档
第一个文档不匹配任何规则。它可能匹配前两个规则，但它们需要额外的过滤器。
第二个文档匹配一个规则。请注意，CALL PQ 默认情况下期望文档为 JSON，但如果您使用 0 as docs_json，则可以传递纯字符串。
SQL:
JSON:
PHP:
Python
javascript
java
C#
TypeScript
Go
我想知道与我的文档匹配的完整PQ规则。
SQL:
JSON:
PHP:
Python
javascript
java
C#
TypeScript
Go
多个文档如何处理？
请注意，使用 CALL PQ 时，可以通过以下几种方式提供多个文档：
以圆括号内的普通文档数组形式
('doc1', 'doc2')。这需要0 as docs_json以圆括号内的JSON数组形式
('{doc1}', '{doc2}')或者以标准JSON数组形式
'[{doc1}, {doc2}]'
SQL:
JSON:
PHP:
Python
javascript
java
C#
TypeScript
Go
我想知道哪些文档匹配了哪些规则
使用选项 1 as docs 可以让你看到提供的文档中哪些匹配了哪些规则。
SQL:
JSON:
PHP:
Python
javascript
java
C#
TypeScript
Go
静态id
默认情况下，匹配的文档id对应于你提供的文档列表中的相对编号。然而，在某些情况下，每个文档可能已经有自己的id。对于这种情况，可以在 CALL PQ 中使用选项 'id field name' as docs_id。
请注意，如果通过提供的字段名找不到id，则该PQ规则不会在结果中显示。
此选项仅在通过SQL执行 CALL PQ 时可用。
SQL:
我可能有无效的JSON，请跳过它们
当使用 CALL PQ 处理多个单独的JSON时，可以使用 1 as skip_bad_json 选项来跳过输入中的任何无效JSON。在下面的例子中，第2个查询由于无效的JSON而失败，但第3个查询通过使用 1 as skip_bad_json 避免了错误。请注意，在通过HTTP发送JSON查询时不可使用此选项，因为在这种情况下，整个JSON查询必须是有效的。
SQL:
我想提升渗透查询的性能
渗透查询是为高吞吐量和大数据量设计的。为了优化性能以获得更低的延迟和更高的吞吐量，可以考虑以下两种模式。
渗透表的分布模式以及渗透查询如何对其工作有以下两种模式：
稀疏模式（默认）。 适用于：大量文档，镜像PQ表。当文档集很大，而存储在PQ表中的查询集较小时，稀疏模式是有益的。在此模式下，传递的文档批次将被划分为多个代理节点处理，因此每个节点仅处理请求中的部分文档。Manticore会拆分文档集并将其分配给镜像。当代理节点完成查询处理后，Manticore会收集并合并结果，返回的最终查询集如同来自单个表一样。可以使用复制来辅助此过程。
分片模式。 适用于：大量PQ规则，规则分布在多个PQ表中。在此模式下，整个文档集会广播给分布式PQ表的所有表，而无需首先拆分文档。这在推送相对较少的文档集但存储的查询数量较大时很有帮助。在这种情况下，最好在每个节点上只存储部分PQ规则，然后将不同节点处理相同文档集与不同PQ规则集的结果进行合并。该模式必须显式设置，因为它会增加网络负载，并且需要具有不同PQ规则的表，无法通过复制直接完成。
假设你有一个定义为 pq_d2 的表：
每个 'pq' 和 'ptitle' 表包含：
SQL:
Python
javascript
javascript
java
C#
TypeScript
Go
然后你对分布式表执行 CALL PQ 查询，附带几个文档。
SQL:
Python
javascript
java
C#
TypeScript
Go
在之前的示例中，我们使用了默认的**稀疏（sparse）模式。为了演示分片（sharded）**模式，让我们创建一个由两个本地 PQ 表组成的分布式 PQ 表，并将两个文档添加到“products1”，一个文档添加到“products2”：
现在，如果你在 CALL PQ 中添加 'sharded' as mode，它会将文档发送到所有代理表（在本例中是本地表，但它们可以是远程的，以利用外部硬件）。此模式在 JSON 接口中不可用。
SQL:
注意，配置中代理镜像的语法（当多个主机被分配到一个 agent 行时，用 | 分隔）与 CALL PQ 查询模式无关。每个 agent 总是代表一个节点，无论为该代理指定了多少个高可用镜像。
我如何了解更多关于性能的信息？
在某些情况下，您可能希望获得更多关于每次检索查询的性能细节。为此，有一个选项 1 as verbose，它仅可通过 SQL 使用，允许你保存更多的性能指标。你可以在 CALL PQ 之后运行 SHOW META 查询来查看这些信息。有关详细信息，请参阅 SHOW META。
1 as verbose:
0 as verbose （默认）:
最后更新于