查询缓存将压缩的结果集存储在内存中，并在可能时对后续查询重用它们。您可以使用以下指令进行配置：
- qcache_max_bytes，缓存查询存储的内存使用限制。默认值为16 MB。将
qcache_max_bytes设置为0会完全禁用查询缓存。 - qcache_thresh_msec，缓存的最小查询耗时阈值。查询完成时间快于该值的将不被缓存。默认值为3000毫秒，即3秒。
- qcache_ttl_sec，缓存条目的TTL，即存活时间。查询将在此时间内保持缓存。默认值为60秒，即1分钟。
这些设置可以使用SET GLOBAL语句动态更改：
mysql> SET GLOBAL qcache_max_bytes=128000000;这些更改会立即生效，不再满足约束的缓存结果集会被立即丢弃。当动态缩减缓存大小时，最近最常用（MRU）的结果集优先保留。
查询缓存的工作方式如下。启用时，每个全文搜索结果将完整存储于内存中。这发生在全文匹配、过滤和排名之后，因此本质上我们存储的是total_found个{docid,weight}对。压缩匹配平均每个匹配耗用2到12字节不等，主要取决于连续docid之间的差异。查询完成后，我们检查耗时和大小阈值，要么保存压缩后的结果集以供重用，要么丢弃它。
请注意，查询缓存对内存的影响不限于qcache_max_bytes！例如，如果您运行10个并发查询，每个查询匹配最多100万条结果（经过过滤后），那么峰值临时内存使用可能在40 MB到240 MB之间，即使查询够快且未被缓存。
当表、全文查询（即MATCH()内容）和排序器都匹配，且过滤条件兼容时，查询可以使用缓存。具体而言：
MATCH()中的全文部分必须逐字节匹配。添加一个额外的空格，在查询缓存看来就是一个不同的查询。- 排序器（及其参数，如自定义排序器的参数）必须逐字节匹配。
- 过滤条件必须是原过滤条件的超集。您可以添加额外过滤条件仍然命中缓存。（在这种情况下，额外过滤条件将在缓存结果上应用。）但如果移除一个过滤条件，则视为新的查询。
缓存条目会按TTL过期，并在表轮换、TRUNCATE或ATTACH时失效。请注意，目前条目不会因任意RT表写入而失效！因此缓存的查询可能在TTL期间返回较旧的结果。
您可以通过SHOW STATUS 使用qcache_XXX变量查看当前缓存状态：
mysql> SHOW STATUS LIKE 'qcache%';
+-----------------------+----------+
| Counter | Value |
+-----------------------+----------+
| qcache_max_bytes | 16777216 |
| qcache_thresh_msec | 3000 |
| qcache_ttl_sec | 60 |
| qcache_cached_queries | 0 |
| qcache_used_bytes | 0 |
| qcache_hits | 0 |
+-----------------------+----------+
6 rows in set (0.00 sec)排序规则主要影响字符串属性的比较。它们定义了字符集编码以及 Manticore 在执行涉及字符串属性的 ORDER BY 或 GROUP BY 时用于比较字符串的策略。
字符串属性在索引过程中按原样存储，并且不附带字符集或语言信息。只要 Manticore 仅需将字符串逐字存储和返回给调用应用程序，这种方式是可以的。然而，当您要求 Manticore 按字符串值排序时，请求立即变得模糊。
首先，单字节（ASCII、ISO-8859-1 或 Windows-1251）字符串需要与可能用可变字节数编码每个字符的 UTF-8 字符串不同地处理。因此，我们需要知道字符集类型，以便正确地将原始字节解释为有意义的字符。
其次，我们还需要了解语言特定的字符串排序规则。例如，在 en_US 地区设置的美国规则下排序时，带变音符号的字符 ï（带变音符号的小写字母 i）应放在 z 之后的某个位置。但在考虑法语规则和 fr_FR 地区设置时，它应放在 i 和 j 之间。其他规则可能完全忽略重音符号，使得 ï 和 i 可以任意混合。
第三，在某些情况下，我们可能需要区分大小写的排序，而在其他情况下，则需要不区分大小写的排序。
排序规则封装了以下所有内容：字符集、语言规则以及大小写敏感性。Manticore 当前提供四种排序规则：
libc_cilibc_csutf8_general_cibinary
前两种排序规则依赖于几个标准 C 库（libc）调用，因此可以支持系统上安装的任何地区设置。它们分别提供不区分大小写（_ci）和区分大小写（_cs）的比较。默认情况下，它们使用 C 地区设置，实际上退化为逐字节比较。若要更改此设置，需要使用 collation_libc_locale 指令指定其他可用地区设置。系统上可用的地区设置列表通常可通过 locale 命令获得：
$ locale -a
C
en_AG
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NG
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
es_ES
fr_FR
POSIX
ru_RU.utf8
ru_UA.utf8系统地区设置的具体列表可能有所不同。请查阅操作系统文档以安装所需的额外地区设置。
utf8_general_ci 和 binary 地区设置内置于 Manticore 中。第一种是 UTF-8 数据的通用排序规则（无所谓的语言定制），其行为应类似于 MySQL 中的 utf8_general_ci 排序规则。第二种则是简单的逐字节比较。
排序规则可以通过 SQL 语句 SET collation_connection 按会话覆盖。所有后续 SQL 查询将使用该排序规则。否则，所有查询将使用服务器默认排序规则或 collation_server 配置指令中指定的排序规则。Manticore 当前默认使用 libc_ci 排序规则。
排序规则影响所有字符串属性的比较，包括 ORDER BY 和 GROUP BY 中的比较，因此根据选择的排序规则，返回的结果顺序或分组可能不同。请注意，排序规则不影响全文搜索；对此，请使用 charset_table。
当 Manticore 执行全扫描查询时，它可以使用普通扫描检查每个文档是否符合过滤条件，或者采用额外的数据和/或算法来加快查询执行速度。Manticore 使用基于代价的优化器（CBO），也称为“查询优化器”，来确定采用哪种方式。
CBO 还可以提升全文查询的性能。详见下文。
如果 CBO 判断某些措施能够提升性能，它可能决定将一个或多个查询过滤器替换为以下实体之一：
- docid 索引 利用一种特殊的仅包含 docid 的二级索引，存储在扩展名为
.spt的文件中。除了提升文档 ID 过滤器的性能外，docid 索引还用于加速文档 ID 到行 ID 的查找，并加快守护进程启动时大量 killlist 的应用。 - 列式扫描 依赖于列式存储，只能用于列式属性。它扫描每个值并对其应用过滤器，但进行了高度优化，通常比默认方法更快。
- 二级索引 默认为所有属性（除 JSON 外）生成。它们使用 PGM 索引 以及 Manticore 内置的倒排索引来检索对应某个值或值范围的行 ID 列表。二级索引存储在扩展名为
.spidx和.spjidx的文件中。 有关如何为 JSON 属性生成二级索引的信息，请参见 json_secondary_indexes。
优化器利用各种属性统计信息估算每条执行路径的代价，包括：
- 关于属性内数据分布的信息（直方图，存储在
.sphi文件中）。直方图在数据建立索引时自动生成，是 CBO 的主要信息来源。 - PGM（二级索引）信息，有助于估算需要读取的文档列表数量。这有助于评估文档列表合并性能及选择合适的合并算法（优先队列合并或位图合并）。
- 列式编码统计数据，用于估算列式数据解压性能。
- 列式最小-最大树。CBO 使用直方图估算应用过滤器后剩余的文档数，同时需要确定过滤器处理过的文档数。对于列式属性，部分评估最小-最大树用于此目的。
- 全文字典。CBO 利用词项统计信息估算全文树评估代价。
优化器计算查询中每个过滤器的执行代价。由于某些过滤器可以被多种实体替代（例如，对于文档 ID，Manticore 可用普通扫描、docid 索引查找、列式扫描（如果文档 ID 是列式的）以及二级索引），优化器会评估所有可用组合。但组合数最大限制为 1024。
为估算查询执行代价，优化器计算执行查询时所执行的最重要操作的预估代价。它采用预设常数代表每个操作的代价。
优化器对比各执行路径的代价，选择代价最低的路径以执行查询。
当处理带有属性过滤器的全文查询时，查询优化器在两条可能的执行路径间做出决定。一种是执行全文查询，获取匹配结果并应用过滤器；另一种是用上述一个或多个实体替换过滤器，从中获取行 ID 并注入全文匹配树。这样，全文搜索结果会与全扫描结果取交集。查询优化器估算全文树评估成本和计算过滤器结果的最佳路径，利用这些信息选择执行路径。
另一个考虑因素是多线程查询执行（当启用 pseudo_sharding 时）。CBO 意识到某些查询可并发执行，并将其纳入考量。CBO 优先考虑更短的查询执行时间（即延迟）胜过吞吐量。例如，如果使用列式扫描的查询能在多线程（占用多个 CPU 核心）中执行，且比单线程使用二级索引的查询更快，则优先多线程执行。
使用二级索引和 docid 索引的查询始终单线程执行，因为基准测试表明它们多线程执行几乎无益。
目前，优化器仅考虑 CPU 代价，不考虑内存或磁盘使用。
Manticore Search 支持将机器学习模型生成的嵌入向量添加到每个文档中，然后对它们进行最近邻搜索。这使您可以基于NLP算法构建相似性搜索、推荐、语义搜索和相关性排序等功能，包括图像、视频和声音搜索等。
嵌入是一种表示数据的方法 - 例如文本、图像或声音 - 作为高维空间中的向量。这些向量的构造是为了确保它们之间的距离反映了它们所代表数据的相似性。此过程通常使用诸如词嵌入（例如Word2Vec、BERT）用于文本或神经网络用于图像的算法。向量空间的高维特性，每个向量有多个分量，允许表示项目之间复杂而细致的关系。它们的相似性通过这些向量之间的距离来衡量，通常使用欧几里得距离或余弦相似度等方法。
Manticore Search 使用 HNSW 库启用 k-最近邻（KNN）向量搜索。此功能是 Manticore Columnar Library 的一部分。
要运行 KNN 搜索，您必须首先配置您的表。浮点向量和 KNN 搜索仅支持实时表（不支持普通表）。表需要至少一个 float_vector 属性，作为数据向量。您需要指定以下属性：
-
knn_type：必填设置；目前仅支持hnsw。 -
knn_dims：必填设置，指定索引的向量维度。 -
hnsw_similarity：必填设置，指定 HNSW 索引使用的距离函数。可接受的值为：L2- 平方 L2IP- 点积COSINE- 余弦相似度
注意： 使用
COSINE相似度时，插入时向量会自动归一化。这意味着存储的向量值可能与原始输入值不同，因为它们将被转换为单位向量（数学长度/幅度为 1.0 的向量），以实现高效的余弦相似度计算。这种归一化保留了向量的方向，同时标准化了其长度。 -
hnsw_m：可选设置，定义图中出边的最大数量。默认值为 16。 -
hnsw_ef_construction：可选设置，定义构建时间/准确性权衡。默认值为 200。
- SQL
- Config
create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' );table test_vec {
type = rt
...
rt_attr_float_vector = image_vector
knn = {"attrs":[{"name":"image_vector","type":"hnsw","dims":4,"hnsw_similarity":"L2","hnsw_m":16,"hnsw_ef_construction":200}]}
}注意： 关于普通模式中的自动嵌入，请参见下面的示例，该示例展示了如何在 knn 配置中使用 model_name 和 from 参数。
Query OK, 0 rows affected (0.01 sec)使用向量数据最简单的方法是使用 自动嵌入。使用此功能时，您创建一个带有 MODEL_NAME 和 FROM 参数的表，然后只需插入您的文本数据 - Manticore 会为您自动生成嵌入。
创建自动嵌入表时，请指定：
MODEL_NAME：使用的嵌入模型FROM：用于生成嵌入的字段（留空表示所有文本/字符串字段）
支持的嵌入模型：
- Sentence Transformers：任何 合适的 BERT 基 Hugging Face 模型（例如，
sentence-transformers/all-MiniLM-L6-v2）——不需要 API 密钥。Manticore 在您创建表时会下载该模型。 - Qwen本地嵌入: Qwen嵌入模型，如
Qwen/Qwen3-Embedding-0.6B——无需API密钥。Manticore在创建表时会下载该模型。 - OpenAI：OpenAI 嵌入模型，如
openai/text-embedding-ada-002- 需要API_KEY='<OPENAI_API_KEY>'参数 - Voyage：Voyage AI 嵌入模型 - 需要
API_KEY='<VOYAGE_API_KEY>'参数 - Jina：Jina AI 嵌入模型 - 需要
API_KEY='<JINA_API_KEY>'参数
有关设置 float_vector 属性的更多信息，请参见 此处。
- SQL
- Config
使用 sentence-transformers（不需要 API 密钥）
CREATE TABLE products (
title TEXT,
description TEXT,
embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='title'
);使用 Qwen 本地嵌入（无需API密钥）
CREATE TABLE products_qwen (
title TEXT,
description TEXT,
embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='Qwen/Qwen3-Embedding-0.6B' FROM='title' CACHE_PATH='/opt/homebrew/var/manticore/.cache/manticore'
);使用 OpenAI（需要 API_KEY 参数）
CREATE TABLE products_openai (
title TEXT,
description TEXT,
embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='openai/text-embedding-ada-002' FROM='title,description' API_KEY='...'
);使用所有文本字段进行嵌入（FROM 为空）
CREATE TABLE products_all (
title TEXT,
description TEXT,
embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM=''
);table products {
type = rt
path = /path/to/products
rt_field = title
rt_field = description
rt_attr_float_vector = embedding_vector
knn = {"attrs":[{"name":"embedding_vector","type":"hnsw","hnsw_similarity":"L2","hnsw_m":16,"hnsw_ef_construction":200,"model_name":"sentence-transformers/all-MiniLM-L6-v2","from":"title"}]}
}在普通模式下使用 OpenAI 和 API 密钥：
table products_openai {
type = rt
path = /path/to/products_openai
rt_field = title
rt_field = description
rt_attr_float_vector = embedding_vector
knn = {"attrs":[{"name":"embedding_vector","type":"hnsw","hnsw_similarity":"L2","hnsw_m":16,"hnsw_ef_construction":200,"model_name":"openai/text-embedding-ada-002","from":"title,description","api_key":"your-api-key-here"}]}
}使用所有文本字段（FROM 为空）：
table products_all {
type = rt
path = /path/to/products_all
rt_field = title
rt_field = description
rt_attr_float_vector = embedding_vector
knn = {"attrs":[{"name":"embedding_vector","type":"hnsw","hnsw_similarity":"L2","hnsw_m":16,"hnsw_ef_construction":200,"model_name":"sentence-transformers/all-MiniLM-L6-v2","from":""}]}
}普通模式的重要说明：
- 使用
model_name时，不得指定dims- 模型会自动确定向量维度。dims和model_name参数是互斥的。 - 不使用
model_name（手动向量插入）时，必须指定dims以指示向量维度。 from参数指定用于生成嵌入的字段（逗号分隔列表，或空字符串表示所有文本/字符串字段）。当使用model_name时，此参数是必需的。- 对于基于 API 的模型（OpenAI、Voyage、Jina），在 knn 配置中包含
api_key参数
使用自动嵌入时，在 INSERT 语句中不要指定向量字段。嵌入将根据 FROM 参数中指定的文本字段自动生成。
- SQL
仅插入文本数据 - 嵌入自动生成
INSERT INTO products (title) VALUES
('machine learning artificial intelligence'),
('banana fruit sweet yellow');插入多个字段 - 如果 FROM='title,description'，两者都用于嵌入
INSERT INTO products_openai (title, description) VALUES
('smartphone', 'latest mobile device with advanced features'),
('laptop', 'portable computer for work and gaming');插入空向量（文档从向量搜索中排除）
INSERT INTO products (title, embedding_vector) VALUES
('no embedding item', ());搜索的工作方式相同 - 提供您的查询文本，Manticore 将生成嵌入向量并查找相似文档：
- SQL
- JSON
SELECT id, knn_dist() FROM products WHERE knn(embedding_vector, 3, 'machine learning');使用文本查询与自动嵌入
POST /search
{
"table": "products",
"knn": {
"field": "embedding_vector",
"query": "machine learning",
"k": 3
}
}使用向量查询直接
POST /search
{
"table": "products",
"knn": {
"field": "embedding_vector",
"query": [0.1, 0.2, 0.3, 0.4],
"k": 3
}
}+------+------------+
| id | knn_dist() |
+------+------------+
| 1 | 0.12345678 |
| 2 | 0.87654321 |
+------+------------+
2 rows in set (0.00 sec){
"took": 0,
"timed_out": false,
"hits": {
"total": 2,
"total_relation": "eq",
"hits": [
{
"_id": 1,
"_score": 1,
"_knn_dist": 0.12345678,
"_source": {
"title": "machine learning artificial intelligence"
}
},
{
"_id": 2,
"_score": 1,
"_knn_dist": 0.87654321,
"_source": {
"title": "banana fruit sweet yellow"
}
}
]
}
}或者，您可以手动插入预计算的向量数据，确保其维度与创建表时指定的维度匹配。您也可以插入空向量；这意味着文档将被排除在向量搜索结果之外。
重要： 当使用 hnsw_similarity='cosine' 时，向量在插入时会自动归一化为单位向量（数学长度/幅度为 1.0 的向量）。这种归一化保留了向量的方向，同时标准化了其长度，这对于高效的余弦相似度计算是必需的。这意味着存储的值将与您原始输入值不同。
- SQL
- JSON
insert into test values ( 1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821) ), ( 2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406) );POST /insert
{
"table":"test_vec",
"id":1,
"doc": { "title" : "yellow bag", "image_vector" : [0.653448,0.192478,0.017971,0.339821] }
}
POST /insert
{
"table":"test_vec",
"id":2,
"doc": { "title" : "white bag", "image_vector" : [-0.148894,0.748278,0.091892,-0.095406] }
}Query OK, 2 rows affected (0.00 sec){
"table":"test",
"_id":1,
"created":true,
"result":"created",
"status":201
}
{
"table":"test",
"_id":2,
"created":true,
"result":"created",
"status":201
}现在，您可以使用 SQL 或 JSON 格式中的 knn 子句执行 KNN 搜索。两种接口支持相同的本质参数，无论您选择哪种格式，都能确保一致的体验：
- SQL:
select ... from <table name> where knn ( <field>, <query vector> [,<options>] ) - JSON:
POST /search { "table": "<table name>", "knn": { "field": "<field>", "query": "<text or vector>", "ef": <ef>, "rescore": <rescore>, "oversampling": <oversampling> } }
参数包括：
field: 这是包含向量数据的浮点向量属性的名称。k: 已弃用的选项。请改用查询limit。它曾用于指定单个 HNSW 索引应返回的文档数量。然而，最终结果中包含的文档数量可能会有所不同。例如，如果系统处理的是划分为磁盘块的实时表，每个块可能返回k个文档，导致总数超过指定的k（累积计数为num_chunks * k）。另一方面，如果在请求k个文档后，根据特定属性过滤掉一些文档，最终文档数量可能少于k。需要注意的是，参数k不适用于 ramchunks。在 ramchunks 的上下文中，检索过程的工作方式不同，因此k参数对返回文档数量的影响不适用。query:（推荐参数）搜索查询，可以是：- 文本字符串：如果字段配置了自动嵌入，则会自动转换为嵌入向量。如果字段未配置自动嵌入，将返回错误。
- 向量数组：与
query_vector的工作方式相同。
query_vector:（旧版参数）作为数字数组的搜索向量。仍支持以保持向后兼容性。 注意： 在同一请求中使用query或query_vector，不要同时使用两者。ef: 搜索期间使用的动态列表的大小。较高的ef会导致更准确但更慢的搜索。默认值为 10。rescore: 启用 KNN 重评分（默认启用）。在 SQL 中设置为0或在 JSON 中设置为false以禁用重评分。在使用量化向量完成 KNN 搜索（可能有过采样）后，距离将使用原始（全精度）向量重新计算，结果将重新排序以提高排名准确性。oversampling: 设置一个因子（浮点值），在执行 KNN 搜索时乘以k，导致使用量化向量检索的候选对象数量超过所需。默认应用oversampling=3.0。如果启用了重评分，这些候选对象可以稍后重新评估。过采样也适用于非量化向量。由于它增加了k，这会影响 HNSW 索引的工作方式，可能会导致结果准确性的小幅变化。
文档始终按其与搜索向量的距离排序。您指定的任何其他排序条件将在此主要排序条件之后应用。要获取距离，有一个内置函数称为 knn_dist()。
- SQL
- JSON
select id, knn_dist() from test where knn ( image_vector, (0.286569,-0.031816,0.066684,0.032926), { ef=2000, oversampling=3.0, rescore=1 } );POST /search
{
"table": "test",
"knn":
{
"field": "image_vector",
"query": [0.286569,-0.031816,0.066684,0.032926],
"ef": 2000,
"rescore": true,
"oversampling": 3.0
}
}+------+------------+
| id | knn_dist() |
+------+------------+
| 1 | 0.28146550 |
| 2 | 0.81527930 |
+------+------------+
2 rows in set (0.00 sec){
"took":0,
"timed_out":false,
"hits":
{
"total":2,
"total_relation":"eq",
"hits":
[
{
"_id": 1,
"_score":1,
"_knn_dist":0.28146550,
"_source":
{
"title":"yellow bag",
"image_vector":[0.653448,0.192478,0.017971,0.339821]
}
},
{
"_id": 2,
"_score":1,
"_knn_dist":0.81527930,
"_source":
{
"title":"white bag",
"image_vector":[-0.148894,0.748278,0.091892,-0.095406]
}
}
]
}
}HNSW 索引需要完全加载到内存中才能执行 KNN 搜索，这可能导致显著的内存消耗。为了减少内存使用，可以应用标量量化 - 一种通过用有限数量的离散值表示每个组件（维度）来压缩高维向量的技术。Manticore 支持 8 位和 1 位量化，这意味着每个向量组件从 32 位浮点数压缩为 8 位甚至 1 位，分别减少内存使用量 4 倍或 32 倍。这些压缩表示还允许更快的距离计算，因为可以在单个 SIMD 指令中处理更多向量组件。尽管标量量化会引入一些近似误差，但通常这是在搜索准确性和资源效率之间的值得权衡的折衷。为了获得更好的准确性，量化可以与重评分和过采样结合使用：检索的候选对象数量多于请求的数量，并且这些候选对象的距离使用原始 32 位浮点数向量重新计算。
支持的量化类型包括：
8bit：每个向量分量被量化为8位。1bit：每个向量分量被量化为1位。使用非对称量化，查询向量量化为4位并存储为1位。这种方法比简单的方法提供更高的精度，但会有一些性能上的折衷。1bitsimple：每个向量分量被量化为1位。此方法比1bit更快，但通常准确性较低。
- SQL
create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' quantization='1bit');Query OK, 0 rows affected (0.01 sec)注意：通过id查找相似文档需要Manticore Buddy。如果不起作用，请确保已安装Buddy。
基于特定文档的独特ID查找在向量空间中最相似的文档是一个常见任务。例如，当用户查看某个项目时，Manticore Search可以高效地识别并显示最相似的项目列表。以下是具体操作方法：
- SQL:
select ... from <表名> where knn ( <字段>, <k>, <文档id> ) - JSON:
POST /search { "table": "<table name>", "knn": { "field": "<field>", "doc_id": <document id>, "k": <k> } }
参数如下：
field：这是包含向量数据的浮点向量属性的名称。k：表示要返回的文档数量，并且是层次可导航小型世界（HNSW）索引的关键参数。它指定了单个HNSW索引应返回的文档数量。然而，最终结果中的文档数量可能会有所不同。例如，如果系统处理的是实时表并分成磁盘块，则每个块可能返回k个文档，导致总数超过指定的k（因为累积计数将是num_chunks * k）。另一方面，最终文档数量可能少于k，因为在请求k个文档后，根据某些属性可能会过滤掉一些文档。需要注意的是，参数k不适用于ramchunks。在ramchunks的上下文中，检索过程不同，因此k参数对返回的文档数量的影响不适用。文档id：用于KNN相似性搜索的文档ID。
- SQL
- JSON
select id, knn_dist() from test where knn ( image_vector, 5, 1 );POST /search
{
"table": "test",
"knn":
{
"field": "image_vector",
"doc_id": 1,
"k": 5
}
}+------+------------+
| id | knn_dist() |
+------+------------+
| 2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec){
"took":0,
"timed_out":false,
"hits":
{
"total":1,
"total_relation":"eq",
"hits":
[
{
"_id": 2,
"_score":1643,
"_knn_dist":0.81527930,
"_source":
{
"title":"white bag",
"image_vector":[-0.148894,0.748278,0.091892,-0.095406]
}
}
]
}
}- SQL
- JSON
select id, knn_dist() from test where knn ( image_vector, 5, (0.286569,-0.031816,0.066684,0.032926) ) and match('white') and id < 10;POST /search
{
"table": "test",
"knn":
{
"field": "image_vector",
"query": [0.286569,-0.031816,0.066684,0.032926],
"k": 5,
"filter":
{
"bool":
{
"must":
[
{ "match": {"_all":"white"} },
{ "range": { "id": { "lt": 10 } } }
]
}
}
}
}+------+------------+
| id | knn_dist() |
+------+------------+
| 2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec){
"took":0,
"timed_out":false,
"hits":
{
"total":1,
"total_relation":"eq",
"hits":
[
{
"_id": 2,
"_score":1643,
"_knn_dist":0.81527930,
"_source":
{
"title":"white bag",
"image_vector":[-0.148894,0.748278,0.091892,-0.095406]
}
}
]
}
}