diff --git a/.translation-cache/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md.json b/.translation-cache/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md.json index b3b60a9905..0550f07e52 100644 --- a/.translation-cache/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md.json +++ b/.translation-cache/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md.json @@ -6,5 +6,13 @@ "russian": "# Присоединение к кластеру репликации\n\n\n\nЧтобы присоединиться к существующему кластеру, необходимо указать как минимум:\n\n* [имя](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) кластера\n\n* `host:port` другого узла в кластере, к которому вы присоединяетесь\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\nВ большинстве случаев вышеуказанного достаточно, если существует один кластер репликации. Однако, если вы создаёте несколько кластеров репликации, необходимо также задать [путь](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) и убедиться, что директория доступна.\n\n\n\nCODE_BLOCK_12\n\n\n\nУзел присоединяется к кластеру, получая данные от указанного узла и, в случае успеха, обновляет списки узлов на всех остальных узлах кластера так же, как если бы это было сделано вручную через [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Этот список используется для повторного присоединения узлов к кластеру при перезапуске.\n\nСуществует два списка узлов:\n\n1.`cluster__nodes_set`: используется для повторного присоединения узлов к кластеру при перезапуске. Он обновляется на всех узлах так же, как это делает [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Команда `JOIN CLUSTER` выполняет это обновление автоматически. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_set`.\n\n2. `cluster__nodes_view`: этот список содержит все активные узлы, используемые для репликации, и не требует ручного управления. [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) фактически копирует этот список узлов в список узлов, используемых для повторного присоединения при перезапуске. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_view`.\n\n\n\nКогда узлы расположены в разных сетевых сегментах или дата-центрах, опция [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) может быть задана явно. Это минимизирует трафик между узлами и использует шлюзовые узлы для межсоединения между дата-центрами. Следующий код присоединяется к существующему кластеру с использованием опции [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster).\n\n> **Примечание:** список кластера `cluster__nodes_set` не обновляется автоматически при использовании этого синтаксиса. Для его обновления используйте [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_22\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_24\n\n\n\nКоманда `JOIN CLUSTER` работает синхронно и завершается, как только узел получает все данные от других узлов кластера и синхронизируется с ними.\n\nОперация `JOIN CLUSTER` может завершиться с ошибкой, указывающей на дублирование [server_id](../../Server_settings/Searchd.md#server_id). Это происходит, когда присоединяющийся узел имеет такой же `server_id`, как и существующий узел в кластере. Чтобы решить эту проблему, убедитесь, что каждый узел в кластере репликации имеет уникальный [server_id](../../Server_settings/Searchd.md#server_id). Вы можете изменить значение по умолчанию [server_id](../../Server_settings/Searchd.md#server_id) в разделе \"searchd\" вашего конфигурационного файла на уникальное значение перед попыткой присоединения к кластеру.\n\n" }, "is_code_or_comment": false + }, + "503bbd34df544dda270d2dfe2995ea121d0608853f3644b498569085ce45f093": { + "original": "# Joining a replication cluster\n\n\n\nTo join an existing cluster, you must specify at least:\n\n* The [name](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) of the cluster\n\n* The `host:port` of another node in the cluster you are joining\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\nIn most cases, the above is sufficient when there is a single replication cluster. However, if you are creating multiple replication clusters, you must also set the [path](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) and ensure that the directory is available.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nA node joins a cluster by obtaining data from a specified node and, if successful, updates the node lists across all other cluster nodes in the same way as if it was done manually through [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). This list is used to re-join nodes to the cluster upon restart.\n\nThere are two lists of nodes:\n\n1.`cluster__nodes_set`: used to re-join nodes to the cluster upon restart. It is updated across all nodes in the same way as [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) does. `JOIN CLUSTER` command performs this update automatically. The [Cluster status](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) displays this list as `cluster__nodes_set`.\n\n2. `cluster__nodes_view`: this list contains all active nodes used for replication and does not require manual management. [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) actually copies this list of nodes to the list of nodes used to re-join upon restart. The [Cluster status](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) displays this list as `cluster__nodes_view`.\n\n\n\nWhen nodes are located in different network segments or data centers, the [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) option may be set explicitly. This minimizes traffic between nodes and utilizes gateway nodes for intercommunication between data centers. The following code joins an existing cluster using the [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) option.\n\n> **Note:** The cluster `cluster__nodes_set` list is not updated automatically when this syntax is used. To update it, use [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\nThe `JOIN CLUSTER` command works synchronously and completes as soon as the node receives all data from the other nodes in the cluster and is in sync with them.\n\nThe `JOIN CLUSTER` operation can fail with an error message indicating a duplicate [server_id](../../Server_settings/Searchd.md#server_id). This occurs when the joining node has the same `server_id` as an existing node in the cluster. To resolve this issue, ensure that each node in the replication cluster has a unique [server_id](../../Server_settings/Searchd.md#server_id). You can change the default [server_id](../../Server_settings/Searchd.md#server_id) in the \"searchd\" section of your configuration file to a unique value before attempting to join the cluster.\n\n", + "translations": { + "chinese": "# 加入复制集群\n\n\n\n要加入现有集群，您必须至少指定：\n\n* 集群的 [名称](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster)\n\n* 您要加入的集群中另一个节点的 `host:port`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\n在大多数情况下，当只有单个复制集群时，上述方式已足够。然而，如果您创建多个复制集群，则必须同时设置 [path](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 并确保该目录可用。\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n节点通过从指定节点获取数据加入集群，如果成功，则会在所有其他集群节点上以与手动执行 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 相同的方式更新节点列表。此列表用于在重启时重新加入节点到集群。\n\n有两个节点列表：\n\n1.`cluster__nodes_set`：用于在重启时重新加入节点到集群。它会在所有节点上以与 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 操作相同的方式更新。`JOIN CLUSTER` 命令自动执行此更新。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示该列表为 `cluster__nodes_set`。\n\n2.`cluster__nodes_view`：这个列表包含所有用于复制的活跃节点，无需手动管理。[ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 实际上是将该活动节点列表复制到重启时使用的节点列表中。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示该列表为 `cluster__nodes_view`。\n\n\n\n当节点位于不同的网络段或数据中心时，可以显式设置 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项。这可以最小化节点间的流量，并利用网关节点实现数据中心间的通信。以下代码示例使用 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项加入现有集群。\n\n> **注意：** 当使用此语法时，集群 `cluster__nodes_set` 列表不会自动更新。要更新它，请使用 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md)。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\n`JOIN CLUSTER` 命令是同步工作的，一旦节点接收到集群中其他节点的所有数据并与其同步后即完成。\n\n`JOIN CLUSTER` 操作可能因重复的 [server_id](../../Server_settings/Searchd.md#server_id) 而失败，错误信息中会提示相同的 server_id。这种情况发生在加入的节点与集群中已有节点具有相同的 `server_id`。为解决该问题，请确保复制集群中的每个节点均有唯一的 [server_id](../../Server_settings/Searchd.md#server_id)。您可以在配置文件的 \"searchd\" 部分更改默认的 [server_id](../../Server_settings/Searchd.md#server_id) 为唯一值，然后再尝试加入集群。\n\n", + "russian": "# Присоединение к кластеру репликации\n\n\n\nЧтобы присоединиться к существующему кластеру, вы должны указать как минимум:\n\n* [имя](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) кластера\n\n* `host:port` другого узла в кластере, к которому вы присоединяетесь\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\nВ большинстве случаев вышеуказанного достаточно, если имеется один кластер репликации. Однако, если вы создаёте несколько кластеров репликации, необходимо также задать [путь](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) и обеспечить доступность директории.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nУзел присоединяется к кластеру, получая данные от указанного узла и, в случае успеха, обновляет списки узлов по всем остальным узлам кластера так же, как если бы это было сделано вручную с помощью [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Этот список используется для повторного присоединения узлов к кластеру при перезапуске.\n\nСуществует два списка узлов:\n\n1. `cluster__nodes_set`: используется для повторного присоединения узлов к кластеру при перезапуске. Он обновляется на всех узлах так же, как это делает [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Команда `JOIN CLUSTER` выполняет это обновление автоматически. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_set`.\n\n2. `cluster__nodes_view`: этот список содержит все активные узлы, используемые для репликации, и не требует ручного управления. [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) фактически копирует этот список узлов в список узлов для повторного присоединения при перезапуске. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_view`.\n\n\n\nКогда узлы расположены в разных сетевых сегментах или дата-центрах, опция [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) может задаваться явно. Это минимизирует трафик между узлами и использует шлюзовые узлы для межцентровой связи. Следующий код присоединяет существующий кластер, используя опцию [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster).\n\n> **Примечание:** список кластера `cluster__nodes_set` не обновляется автоматически при использовании этого синтаксиса. Для обновления используйте [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\nКоманда `JOIN CLUSTER` работает синхронно и завершается, как только узел получает все данные от других узлов кластера и синхронизируется с ними.\n\nОперация `JOIN CLUSTER` может завершиться с ошибкой, указывающей на дублирование [server_id](../../Server_settings/Searchd.md#server_id). Это происходит, когда присоединяемый узел имеет тот же `server_id`, что и уже существующий узел в кластере. Для решения этой проблемы убедитесь, что у каждого узла в кластере репликации уникальный [server_id](../../Server_settings/Searchd.md#server_id). Вы можете изменить значение по умолчанию [server_id](../../Server_settings/Searchd.md#server_id) в разделе \"searchd\" вашего конфигурационного файла на уникальное значение до попытки присоединения к кластеру.\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Creating_a_table/Data_types.md.json b/.translation-cache/Creating_a_table/Data_types.md.json index 4f5cc9184e..3c499d61bd 100644 --- a/.translation-cache/Creating_a_table/Data_types.md.json +++ b/.translation-cache/Creating_a_table/Data_types.md.json @@ -54,5 +54,29 @@ "russian": "# Типы данных\n\n## Полнотекстовые поля и атрибуты\n\nТипы данных Manticore можно разделить на две категории: полнотекстовые поля и атрибуты.\n\n### Синтаксис имени поля\n\nИмена полей в Manticore должны соответствовать следующим правилам:\n\n* Могут содержать буквы (a-z, A-Z), цифры (0-9) и дефисы (-)\n\n* Должны начинаться с буквы\n\n* Цифры могут появляться только после букв\n\n* Подчеркивание (`_`) — единственный разрешённый специальный символ\n\n* Имена полей не чувствительны к регистру\n\nНапример:\n\n* Допустимые имена полей: `title`, `product_id`, `user_name_2`\n\n* Недопустимые имена полей: `2title`, `-price`, `user@name`\n\n### Полнотекстовые поля\n\nПолнотекстовые поля:\n\n* могут индексироваться с помощью алгоритмов обработки естественного языка, поэтому по ним можно искать ключевые слова\n\n* не могут использоваться для сортировки или группировки\n\n* можно получить исходное содержимое документа\n\n* исходное содержимое документа можно использовать для подсветки\n\nПолнотекстовые поля представлены типом данных `text`. Все остальные типы данных называются «атрибутами».\n\n### Атрибуты\n\nАтрибуты — это не полнотекстовые значения, связанные с каждым документом, которые можно использовать для фильтрации, сортировки и группировки по неполнотекстовым критериям во время поиска.\n\nЧасто требуется обрабатывать результаты полнотекстового поиска не только на основе совпадения ID документа и его ранга, но и на основе ряда других значений, связанных с документом. Например, может понадобиться отсортировать результаты поиска новостей по дате, а затем по релевантности, или искать товары в заданном ценовом диапазоне, или ограничить поиск по блогу постами, сделанными выбранными пользователями, или сгруппировать результаты по месяцу. Для эффективного выполнения таких задач Manticore позволяет добавлять к каждому документу не только полнотекстовые поля, но и дополнительные атрибуты. Эти атрибуты можно использовать для фильтрации, сортировки или группировки полнотекстовых совпадений, а также для поиска только по атрибутам.\n\nАтрибуты, в отличие от полнотекстовых полей, не индексируются полнотекстово. Они хранятся в таблице, но по ним нельзя выполнять полнотекстовый поиск.\n\n\n\nХорошим примером атрибутов может служить таблица сообщений форума. Предположим, что полнотекстовым поиском должны быть доступны только поля title и content — но иногда требуется ограничить поиск определённым автором или подфорумом (то есть искать только те строки, у которых есть конкретные значения author_id или forum_id); или сортировать совпадения по столбцу post_date; или группировать совпадающие сообщения по месяцу из post_date и подсчитывать количество совпадений в каждой группе.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_1\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_2\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_9\n\n\n\n\n\nВ этом примере показан запуск полнотекстового запроса с фильтрацией по `author_id`, `forum_id` и сортировкой по `post_date`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_13\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_15\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_16\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_17\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_18\n\n\n\n### Строковое и колонковое хранение атрибутов\n\nManticore поддерживает два типа хранения атрибутов:\n\n* строковое — традиционное хранение, доступное в Manticore Search из коробки\n\n* колонковое — предоставляется [Manticore Columnar Library](https://github.com/manticoresoftware/columnar)\n\nКак можно понять из названий, они хранят данные по-разному. Традиционное **строковое хранение**:\n\n* хранит атрибуты без сжатия\n\n* все атрибуты одного документа хранятся в одной строке рядом друг с другом\n\n* строки хранятся одна за другой\n\n* доступ к атрибутам осуществляется просто умножением ID строки на шаг (длину одного вектора) и получением нужного атрибута из рассчитанного адреса в памяти. Это обеспечивает очень низкую задержку случайного доступа.\n\n* атрибуты должны находиться в памяти для достижения приемлемой производительности, иначе из-за строковой природы хранения Manticore может читать с диска слишком много ненужных данных, что во многих случаях не оптимально.\n\nВ случае **колонкового хранения**:\n\n* каждый атрибут хранится независимо от всех остальных в отдельной «колонке»\n\n* хранилище разбито на блоки по 65536 записей\n\n* блоки хранятся в сжатом виде. Это часто позволяет хранить всего несколько различных значений вместо хранения всех значений, как в строковом хранении. Высокое сжатие позволяет быстрее читать с диска и значительно снижает требования к памяти\n\n* при индексировании данных схема хранения выбирается для каждого блока отдельно. Например, если все значения в блоке одинаковы, он получает «const» хранение, и для всего блока хранится только одно значение. Если в блоке менее 256 уникальных значений, он получает «table» хранение и хранит индексы в таблицу значений вместо самих значений\n\n* поиск в блоке может быть досрочно отклонён, если ясно, что запрашиваемое значение отсутствует в блоке.\n\nКолонковое хранение было разработано для обработки больших объёмов данных, которые не помещаются в ОЗУ, поэтому рекомендации таковы:\n\n* если у вас достаточно памяти для всех атрибутов, вы получите выгоду от строкового хранения\n\n* в противном случае колонковое хранение всё равно может обеспечить достойную производительность с гораздо меньшим потреблением памяти, что позволит хранить гораздо больше документов в таблице" }, "is_code_or_comment": false + }, + "8dc590cdb324a503dc56c28ae292f615f420743f43017ae6ce3d1bb5de5a966f": { + "original": "\n\nCODE_BLOCK_219\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_220\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_221\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_222\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_223\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_224\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_225\n\n\n\n\n\nIt supports filtering and aggregation, but not sorting. Filtering can be done using a condition that requires at least one element to pass (using [ANY()](../Functions/Arrays_and_conditions_functions.md#ANY%28%29)) or all elements ([ALL()](../Functions/Arrays_and_conditions_functions.md#ALL%28%29)) to pass.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_226\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_227\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_228\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_229\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_230\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_231\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_232\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_234\n\n\n\n\n\nInformation like [least](../Functions/Mathematical_functions.md#LEAST%28%29) or [greatest](../Functions/Mathematical_functions.md#GREATEST%28%29) element and length of the list can be extracted. An example shows ordering by the least element of a multi-value attribute.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_235\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_236\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_237\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_238\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_239\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_240\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_241\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_242\n\n\n\nCODE_BLOCK_243\n\n\n\n\n\nWhen grouping by a multi-value attribute, a document will contribute to as many groups as there are different values associated with that document. For instance, if a collection contains exactly one document having a 'product_codes' multi-value attribute with values 5, 7, and 11, grouping on 'product_codes' will produce 3 groups with `COUNT(*)`equal to 1 and `GROUPBY()` key values of 5, 7, and 11, respectively. Also, note that grouping by multi-value attributes may lead to duplicate documents in the result set because each document can participate in many groups.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\n\n\nThe order of the numbers inserted as values of multivalued attributes is not preserved. Values are stored internally as a sorted set.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_246\n\n\n\nCODE_BLOCK_247\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_248\n\n\n\nCODE_BLOCK_249\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_250\n\n\n\nCODE_BLOCK_251\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_252\n\n\n\nCODE_BLOCK_253\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_254\n\n\n\nCODE_BLOCK_255\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_256\n\n\n\nCODE_BLOCK_257\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_258\n\n\n\nCODE_BLOCK_259\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_260\n\n\n\nCODE_BLOCK_261\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_262\n\n\n\nCODE_BLOCK_263\n\n\n\n## Multi-value big integer\n\n\n\nA data type that allows storing variable-length lists of 64-bit signed integers. It has the same functionality as multi-value integer.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_264\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_265\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_266\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_267\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_268\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_269\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_270\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_271\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_272\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_273\n\n\n\n## Columnar attribute properties\n\nWhen you use the columnar storage you can specify the following properties for the attributes.\n\n\n\n### fast_fetch\n\nBy default, Manticore Columnar storage stores all attributes in a columnar fashion, as well as in a special docstore row by row. This enables fast execution of queries like `SELECT * FROM ...`, especially when fetching a large number of records at once. However, if you are sure that you do not need it or wish to save disk space, you can disable it by specifying `fast_fetch='0'` when creating a table or (if you are defining a table in a config) by using `columnar_no_fast_fetch` as shown in the following example.\n\n\n\nCODE_BLOCK_274\n\n\n\nCODE_BLOCK_275\n\n\n\nCODE_BLOCK_276\n\n", + "translations": { + "chinese": "\n\nCODE_BLOCK_219\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_220\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_221\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_222\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_223\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_224\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_225\n\n\n\n\n\nIt supports filtering and aggregation, but not sorting. Filtering can be done using a condition that requires at least one element to pass (using [ANY()](../Functions/Arrays_and_conditions_functions.md#ANY%28%29)) or all elements ([ALL()](../Functions/Arrays_and_conditions_functions.md#ALL%28%29)) to pass.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_226\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_227\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_228\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_229\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_230\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_231\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_232\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_234\n\n\n\n\n\nInformation like [least](../Functions/Mathematical_functions.md#LEAST%28%29) or [greatest](../Functions/Mathematical_functions.md#GREATEST%28%29) element and length of the list can be extracted. An example shows ordering by the least element of a multi-value attribute.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_235\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_236\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_237\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_238\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_239\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_240\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_241\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_242\n\n\n\nCODE_BLOCK_243\n\n\n\n\n\nWhen grouping by a multi-value attribute, a document will contribute to as many groups as there are different values associated with that document. For instance, if a collection contains exactly one document having a 'product_codes' multi-value attribute with values 5, 7, and 11, grouping on 'product_codes' will produce 3 groups with `COUNT(*)`equal to 1 and `GROUPBY()` key values of 5, 7, and 11, respectively. Also, note that grouping by multi-value attributes may lead to duplicate documents in the result set because each document can participate in many groups.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\n\n\nThe order of the numbers inserted as values of multivalued attributes is not preserved. Values are stored internally as a sorted set.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_246\n\n\n\nCODE_BLOCK_247\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_248\n\n\n\nCODE_BLOCK_249\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_250\n\n\n\nCODE_BLOCK_251\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_252\n\n\n\nCODE_BLOCK_253\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_254\n\n\n\nCODE_BLOCK_255\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_256\n\n\n\nCODE_BLOCK_257\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_258\n\n\n\nCODE_BLOCK_259\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_260\n\n\n\nCODE_BLOCK_261\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_262\n\n\n\nCODE_BLOCK_263\n\n\n\n## Multi-value big integer\n\n\n\nA data type that allows storing variable-length lists of 64-bit signed integers. It has the same functionality as multi-value integer.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_264\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_265\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_266\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_267\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_268\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_269\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_270\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_271\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_272\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_273\n\n\n\n## Columnar attribute properties\n\nWhen you use the columnar storage you can specify the following properties for the attributes.\n\n\n\n### fast_fetch\n\nBy default, Manticore Columnar storage stores all attributes in a columnar fashion, as well as in a special docstore row by row. This enables fast execution of queries like `SELECT * FROM ...`, especially when fetching a large number of records at once. However, if you are sure that you do not need it or wish to save disk space, you can disable it by specifying `fast_fetch='0'` when creating a table or (if you are defining a table in a config) by using `columnar_no_fast_fetch` as shown in the following example.\n\n\n\nCODE_BLOCK_274\n\n\n\nCODE_BLOCK_275\n\n\n\nCODE_BLOCK_276\n\n", + "russian": "\n\nCODE_BLOCK_219\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_220\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_221\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_222\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_223\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_224\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_225\n\n\n\n\n\nIt supports filtering and aggregation, but not sorting. Filtering can be done using a condition that requires at least one element to pass (using [ANY()](../Functions/Arrays_and_conditions_functions.md#ANY%28%29)) or all elements ([ALL()](../Functions/Arrays_and_conditions_functions.md#ALL%28%29)) to pass.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_226\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_227\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_228\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_229\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_230\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_231\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_232\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_234\n\n\n\n\n\nInformation like [least](../Functions/Mathematical_functions.md#LEAST%28%29) or [greatest](../Functions/Mathematical_functions.md#GREATEST%28%29) element and length of the list can be extracted. An example shows ordering by the least element of a multi-value attribute.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_235\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_236\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_237\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_238\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_239\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_240\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_241\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_242\n\n\n\nCODE_BLOCK_243\n\n\n\n\n\nWhen grouping by a multi-value attribute, a document will contribute to as many groups as there are different values associated with that document. For instance, if a collection contains exactly one document having a 'product_codes' multi-value attribute with values 5, 7, and 11, grouping on 'product_codes' will produce 3 groups with `COUNT(*)`equal to 1 and `GROUPBY()` key values of 5, 7, and 11, respectively. Also, note that grouping by multi-value attributes may lead to duplicate documents in the result set because each document can participate in many groups.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\n\n\nThe order of the numbers inserted as values of multivalued attributes is not preserved. Values are stored internally as a sorted set.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_246\n\n\n\nCODE_BLOCK_247\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_248\n\n\n\nCODE_BLOCK_249\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_250\n\n\n\nCODE_BLOCK_251\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_252\n\n\n\nCODE_BLOCK_253\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_254\n\n\n\nCODE_BLOCK_255\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_256\n\n\n\nCODE_BLOCK_257\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_258\n\n\n\nCODE_BLOCK_259\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_260\n\n\n\nCODE_BLOCK_261\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_262\n\n\n\nCODE_BLOCK_263\n\n\n\n## Multi-value big integer\n\n\n\nA data type that allows storing variable-length lists of 64-bit signed integers. It has the same functionality as multi-value integer.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_264\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_265\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_266\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_267\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_268\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_269\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_270\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_271\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_272\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_273\n\n\n\n## Columnar attribute properties\n\nWhen you use the columnar storage you can specify the following properties for the attributes.\n\n\n\n### fast_fetch\n\nBy default, Manticore Columnar storage stores all attributes in a columnar fashion, as well as in a special docstore row by row. This enables fast execution of queries like `SELECT * FROM ...`, especially when fetching a large number of records at once. However, if you are sure that you do not need it or wish to save disk space, you can disable it by specifying `fast_fetch='0'` when creating a table or (if you are defining a table in a config) by using `columnar_no_fast_fetch` as shown in the following example.\n\n\n\nCODE_BLOCK_274\n\n\n\nCODE_BLOCK_275\n\n\n\nCODE_BLOCK_276\n\n" + }, + "is_code_or_comment": true + }, + "95addb2561615d10e3980ecee78e1f6e6e7eb2129c9074cecd9217e4ba124901": { + "original": "CODE_BLOCK_277\n\n", + "translations": { + "chinese": "CODE_BLOCK_277\n\n", + "russian": "CODE_BLOCK_277\n\n" + }, + "is_code_or_comment": false + }, + "e0361a6b08f16278abe21ef97ffdf5664b91a3ea6b5b499d167224361ddeaaee": { + "original": "Float vector attributes allow storing variable-length lists of floats, primarily used for machine learning applications and similarity searches. This type differs from [multi-valued attributes](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) (MVAs) in several important ways:\n\n- Preserves the exact order of values (unlike MVAs which may reorder)\n\n- Retains duplicate values (unlike MVAs which deduplicate)\n\n- No additional processing during insertion (unlike MVAs which sort and deduplicate)\n\nFloat vector attributes allow storing variable-length lists of floats, primarily used for machine learning applications and similarity searches. \n\n### Usage and Limitations\n\n- Currently only supported in real-time tables\n\n- Can only be utilized in KNN (k-nearest neighbor) searches\n\n- Not supported in plain tables or other functions/expressions\n\n- When used with KNN settings, you cannot `UPDATE` `float_vector` values. Use `REPLACE` instead\n\n- When used without KNN settings, you can `UPDATE` `float_vector` values\n\n- Float vectors cannot be used in regular filters or sorting\n\n- The only way to filter by `float_vector` values is through vector search operations (KNN)\n\n### Common Use Cases\n\n- Text embeddings for semantic search\n\n- Recommendation system vectors\n\n- Image embeddings for similarity search\n\n- Feature vectors for machine learning\n\n** Keep in mind that the `float_vector` data type is not compatible with the [Auto schema](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema) mechanism. **\n\nFor more details on setting up float vectors and using them in searches, see [KNN search](../Searching/KNN.md).\n\n### Auto Embeddings (Recommended)\n\nThe most convenient way to work with float vectors is using **auto embeddings**. This feature automatically generates embeddings from your text data using machine learning models, eliminating the need to manually compute and insert vectors.\n\n#### Benefits of Auto Embeddings\n\n- **Simplified workflow**: Just insert text, embeddings are generated automatically\n\n- **No manual vector computation**: No need to run separate embedding models\n\n- **Consistent embeddings**: Same model ensures consistent vector representations\n\n- **Multiple model support**: Choose from [sentence-transformers](https://huggingface.co/sentence-transformers/models), OpenAI, Voyage, and Jina models\n\n- **Flexible field selection**: Control which fields are used for embedding generation\n\n#### Creating tables with auto embeddings\n\nWhen creating a table with auto embeddings, specify these additional parameters:\n\n- `MODEL_NAME`: The embedding model to use for automatic vector generation\n\n- `FROM`: Which fields to use for embedding generation (empty string means all text/string fields)\n\n**Supported embedding models:**\n\n- **Sentence Transformers**: Any [suitable BERT-based Hugging Face model](https://huggingface.co/sentence-transformers/models) (e.g., `sentence-transformers/all-MiniLM-L6-v2`) — no API key needed. Manticore downloads the model when you create the table.\n\n- **OpenAI**: OpenAI embedding models like `openai/text-embedding-ada-002` - requires `API_KEY=''` parameter\n\n- **Voyage**: Voyage AI embedding models - requires `API_KEY=''` parameter\n\n- **Jina**: Jina AI embedding models - requires `API_KEY=''` parameter\n\n\n\n##### SQL:\n\n\n\nUsing [sentence-transformers model](https://huggingface.co/sentence-transformers/models) (no API key needed)\n\nCODE_BLOCK_199\n\nUsing OpenAI model (requires API_KEY parameter)\n\nCODE_BLOCK_200\n\nUsing all text fields for embeddings (FROM is empty)\n\nCODE_BLOCK_201\n\n\n\n##### JSON:\n\n\n\nUsing [sentence-transformers model](https://huggingface.co/sentence-transformers/models) (no API key needed)\n\nCODE_BLOCK_202\n\nUsing OpenAI model (requires API_KEY parameter)\n\nCODE_BLOCK_203\n\nUsing all text fields for embeddings (FROM is empty)\n\nCODE_BLOCK_204\n\n\n\n#### FROM parameter usage\n\nThe `FROM` parameter controls which fields are used for embedding generation:\n\n- **Specific fields**: `FROM='title'` - only the title field is used\n\n- **Multiple fields**: `FROM='title,description'` - both title and description are concatenated and used\n\n- **All text fields**: `FROM=''` (empty) - all `text` (full-text field) and `string` (string attribute) fields in the table are used\n\n- **Empty vectors**: You can still insert empty vectors using `()` to exclude documents from vector search\n\n#### Inserting data with auto embeddings\n\nWhen using auto embeddings, **do not specify the vector field** in your INSERT statements. The embeddings are automatically generated from the specified text fields:\n\nCODE_BLOCK_205\n\n### Manual Float Vector Usage\n\n\n\nAlternatively, you can work with manually computed float vectors. \n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_206\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_207\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_208\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_209\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_210\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_211\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_212\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_213\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_214\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_215\n\n\n\n## Multi-value integer (MVA)\n\n\n\nMulti-value attributes allow storing variable-length lists of 32-bit unsigned integers. This can be useful for storing one-to-many numeric values, such as tags, product categories, and properties.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_216\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Python:", + "translations": { + "chinese": "浮点向量属性允许存储可变长度的浮点列表，主要用于机器学习应用和相似性搜索。这种类型与[多值属性](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29)（MVA）在几个重要方面不同：\n\n- 保留值的确切顺序（不像MVA可能重新排序）\n\n- 保留重复值（不像MVA去重）\n\n- 插入时无额外处理（不像MVA会排序和去重）\n\n浮点向量属性允许存储可变长度的浮点列表，主要用于机器学习应用和相似性搜索。\n\n### 用法和限制\n\n- 目前仅支持实时表\n\n- 只能用于KNN（k近邻）搜索\n\n- 不支持普通表或其他函数/表达式\n\n- 使用KNN设置时，不能`UPDATE` `float_vector`值，应使用`REPLACE`\n\n- 不使用KNN设置时，可以`UPDATE` `float_vector`值\n\n- 浮点向量不能用于常规过滤或排序\n\n- 唯一通过`float_vector`值过滤的方法是通过向量搜索操作（KNN）\n\n### 常见用例\n\n- 语义搜索的文本嵌入\n\n- 推荐系统向量\n\n- 用于相似性搜索的图像嵌入\n\n- 机器学习的特征向量\n\n** 请注意，`float_vector`数据类型与[自动模式](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema)机制不兼容。**\n\n有关设置浮点向量及其搜索使用的详细信息，请参阅[KNN搜索](../Searching/KNN.md)。\n\n### 自动嵌入（推荐）\n\n使用**自动嵌入**是处理浮点向量最便捷的方法。此功能通过机器学习模型自动从文本数据生成嵌入，免去了手动计算和插入向量的需要。\n\n#### 自动嵌入的优点\n\n- **简化流程**：只需插入文本，嵌入自动生成\n\n- **无需手动计算向量**：无需运行独立的嵌入模型\n\n- **嵌入一致性**：相同模型确保向量表现一致\n\n- **支持多模型**：可选择[sentence-transformers](https://huggingface.co/sentence-transformers/models)、OpenAI、Voyage 和 Jina模型\n\n- **灵活字段选择**：控制用于生成嵌入的字段\n\n#### 创建带自动嵌入的表\n\n创建带自动嵌入的表时，指定以下附加参数：\n\n- `MODEL_NAME`：用于自动生成向量的嵌入模型\n\n- `FROM`：用于生成嵌入的字段（空字符串表示所有文本/字符串字段）\n\n**支持的嵌入模型：**\n\n- **Sentence Transformers**：任何[适用的基于BERT的Hugging Face模型](https://huggingface.co/sentence-transformers/models)（例如，`sentence-transformers/all-MiniLM-L6-v2`）— 无需API密钥。Manticore在创建表时下载模型。\n\n- **OpenAI**：OpenAI嵌入模型，如`openai/text-embedding-ada-002` - 需要`API_KEY=''`参数\n\n- **Voyage**：Voyage AI嵌入模型 - 需要`API_KEY=''`参数\n\n- **Jina**：Jina AI嵌入模型 - 需要`API_KEY=''`参数\n\n\n\n##### SQL:\n\n\n\n使用[sentence-transformers模型](https://huggingface.co/sentence-transformers/models)（无需API密钥）\n\nCODE_BLOCK_199\n\n使用OpenAI模型（需要API_KEY参数）\n\nCODE_BLOCK_200\n\n使用所有文本字段进行嵌入（FROM为空）\n\nCODE_BLOCK_201\n\n\n\n##### JSON:\n\n\n\n使用[sentence-transformers模型](https://huggingface.co/sentence-transformers/models)（无需API密钥）\n\nCODE_BLOCK_202\n\n使用OpenAI模型（需要API_KEY参数）\n\nCODE_BLOCK_203\n\n使用所有文本字段进行嵌入（FROM为空）\n\nCODE_BLOCK_204\n\n\n\n#### FROM参数用法\n\n`FROM`参数控制用于生成嵌入的字段：\n\n- **特定字段**：`FROM='title'` - 仅使用title字段\n\n- **多个字段**：`FROM='title,description'` - 将title和description拼接后使用\n\n- **所有文本字段**：`FROM=''`（空） - 使用表中所有`text`（全文字段）和`string`（字符串属性）字段\n\n- **空向量**：仍然可以使用`()`插入空向量，以排除文档参与向量搜索\n\n#### 使用自动嵌入插入数据\n\n使用自动嵌入时，**不要在INSERT语句中指定向量字段**。嵌入将自动从指定文本字段生成：\n\nCODE_BLOCK_205\n\n### 手动浮点向量用法\n\n\n\n或者，你可以使用手动计算的浮点向量。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_206\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_207\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_208\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_209\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_210\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_211\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_212\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_213\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_214\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_215\n\n\n\n## 多值整数（MVA）\n\n\n\n多值属性允许存储可变长度的32位无符号整数列表。适合存储一对多的数值，比如标签、产品类别和属性。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_216\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Python:", + "russian": "Атрибуты векторных чисел с плавающей запятой позволяют хранить списки чисел с плавающей запятой переменной длины, в основном используемые для приложений машинного обучения и поиска по сходству. Этот тип отличается от [мультизначных атрибутов](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) (MVA) несколькими важными аспектами:\n\n- Сохраняет точный порядок значений (в отличие от MVA, которые могут менять порядок)\n\n- Сохраняет повторяющиеся значения (в отличие от MVA, которые устраняют дубликаты)\n\n- Нет дополнительной обработки при вставке (в отличие от MVA, которые сортируют и устраняют дубликаты)\n\nАтрибуты векторных чисел с плавающей запятой позволяют хранить списки чисел с плавающей запятой переменной длины, в основном используемые для приложений машинного обучения и поиска по сходству.\n\n### Использование и ограничения\n\n- В настоящее время поддерживаются только в таблицах реального времени\n\n- Могут использоваться только в KNN (k-ближайших соседей) поисках\n\n- Не поддерживаются в обычных таблицах или других функциях/выражениях\n\n- При использовании с настройками KNN нельзя `UPDATE` значения `float_vector`. Используйте `REPLACE`\n\n- При использовании без настроек KNN можно `UPDATE` значения `float_vector`\n\n- Векторы с плавающей запятой не могут использоваться в обычных фильтрах или сортировках\n\n- Единственный способ фильтровать по значениям `float_vector` — через операции векторного поиска (KNN)\n\n### Основные случаи использования\n\n- Встраивания текста для семантического поиска\n\n- Векторы рекомендательных систем\n\n- Встраивания изображений для поиска по сходству\n\n- Векторы признаков для машинного обучения\n\n** Учтите, что тип данных `float_vector` несовместим с механизмом [Auto schema](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema). **\n\nПодробнее о настройке векторов с плавающей запятой и использовании их в поисках смотрите в разделе [KNN search](../Searching/KNN.md).\n\n### Авто встраивания (рекомендуется)\n\nСамый удобный способ работы с векторами с плавающей запятой — использование **авто встраиваний**. Эта функция автоматически генерирует встраивания из вашего текстового контента с помощью моделей машинного обучения, избавляя от необходимости вручную вычислять и вставлять векторы.\n\n#### Преимущества авто встраиваний\n\n- **Упрощенный процесс**: Просто вставляйте текст, встраивания генерируются автоматически\n\n- **Нет необходимости вручную считать векторы**: Не нужно запускать отдельные модели встраивания\n\n- **Единообразные встраивания**: Одна и та же модель обеспечивает согласованные векторные представления\n\n- **Поддержка нескольких моделей**: Выбор из моделей [sentence-transformers](https://huggingface.co/sentence-transformers/models), OpenAI, Voyage и Jina\n\n- **Гибкий выбор полей**: Контроль над тем, какие поля используются для генерации встраиваний\n\n#### Создание таблиц с авто встраиваниями\n\nПри создании таблицы с авто встраиваниями указывайте следующие дополнительные параметры:\n\n- `MODEL_NAME`: модель встраивания, используемая для автоматической генерации векторов\n\n- `FROM`: какие поля использовать для генерации встраиваний (пустая строка означает все текстовые/строковые поля)\n\n**Поддерживаемые модели встраивания:**\n\n- **Sentence Transformers**: Любая [подходящая модель на базе BERT с Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — не требуется ключ API. Manticore скачивает модель при создании таблицы.\n\n- **OpenAI**: модели встраивания OpenAI, например `openai/text-embedding-ada-002` — требуется параметр `API_KEY=''`\n\n- **Voyage**: модели встраивания Voyage AI — требуется параметр `API_KEY=''`\n\n- **Jina**: модели встраивания Jina AI — требуется параметр `API_KEY=''`\n\n\n\n##### SQL:\n\n\n\nИспользование модели [sentence-transformers](https://huggingface.co/sentence-transformers/models) (ключ API не нужен)\n\nCODE_BLOCK_199\n\nИспользование модели OpenAI (требуется параметр API_KEY)\n\nCODE_BLOCK_200\n\nИспользование всех текстовых полей для встраиваний (FROM пустой)\n\nCODE_BLOCK_201\n\n\n\n##### JSON:\n\n\n\nИспользование модели [sentence-transformers](https://huggingface.co/sentence-transformers/models) (ключ API не нужен)\n\nCODE_BLOCK_202\n\nИспользование модели OpenAI (требуется параметр API_KEY)\n\nCODE_BLOCK_203\n\nИспользование всех текстовых полей для встраиваний (FROM пустой)\n\nCODE_BLOCK_204\n\n\n\n#### Использование параметра FROM\n\nПараметр `FROM` контролирует, какие поля используются для генерации встраиваний:\n\n- **Конкретные поля**: `FROM='title'` — используется только поле title\n\n- **Несколько полей**: `FROM='title,description'` — объединяются и используются поля title и description\n\n- **Все текстовые поля**: `FROM=''` (пустое) — используются все поля `text` (полнотекстовое поле) и `string` (строковые атрибуты) таблицы\n\n- **Пустые векторы**: Вы всё равно можете вставлять пустые векторы при помощи `()` для исключения документов из векторного поиска\n\n#### Вставка данных с авто встраиваниями\n\nПри использовании авто встраиваний **не указывайте поле вектора** в операторах INSERT. Встраивания автоматически генерируются из указанных текстовых полей:\n\nCODE_BLOCK_205\n\n### Ручное использование векторов с плавающей запятой\n\n\n\nАльтернативно, можно работать с вручную вычисленными векторами с плавающей запятой.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_206\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_207\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_208\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_209\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_210\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_211\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_212\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_213\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_214\n\n\n\n##### config:\n\n\n\nCODE_BLOCK_215\n\n\n\n## Мультизначное целое число (MVA)\n\n\n\nМультизначные атрибуты позволяют хранить списки 32-битных беззнаковых целых чисел переменной длины. Это полезно для хранения числовых значений \"один ко многим\", таких как теги, категории товаров и свойства.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_216\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Python:" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md.json b/.translation-cache/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md.json index ec3c9abe11..c267e21692 100644 --- a/.translation-cache/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md.json +++ b/.translation-cache/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md.json @@ -54,5 +54,29 @@ "russian": "Этот параметр определяет таблицу(ы), к которым будет применяться kill-list. Совпадения в целевой таблице, которые обновляются или удаляются в текущей таблице, будут подавлены. В режиме `:kl` документы для подавления берутся из [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md). В режиме `:id` все идентификаторы документов из текущей таблицы подавляются в целевой. Если ни один из режимов не указан, будут применяться оба режима. [Подробнее о kill-list здесь](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)\n\nЗначение: **не указано** (по умолчанию), target_table_name:kl, target_table_name:id, target_table_name. Допускается несколько значений\n\n#### columnar_attrs\n\nCODE_BLOCK_49\n\nЭтот параметр конфигурации определяет, какие атрибуты должны храниться в [колоночном хранилище](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) вместо построчного хранилища.\n\nВы можете установить `columnar_attrs = *`, чтобы хранить все поддерживаемые типы данных в колоночном хранилище.\n\nКроме того, `id` является поддерживаемым атрибутом для хранения в колоночном хранилище.\n\n#### columnar_strings_no_hash\n\nCODE_BLOCK_50\n\nПо умолчанию все строковые атрибуты, хранящиеся в колоночном хранилище, сохраняют предварительно вычисленные хэши. Эти хэши используются для группировки и фильтрации. Однако они занимают дополнительное место, и если вам не нужно группировать по этому атрибуту, вы можете сэкономить место, отключив генерацию хэшей.\n\n### Создание таблицы реального времени онлайн через CREATE TABLE\n\n\n\n##### Общий синтаксис CREATE TABLE\n\nCODE_BLOCK_51\n\n##### Типы данных:\n\nДля получения дополнительной информации о типах данных смотрите [подробнее о типах данных здесь](../../Creating_a_table/Data_types.md).\n\n| Тип | Эквивалент в конфигурационном файле | Примечания | Псевдонимы |\n\n| - | - | - | - |\n\n| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | Опции: indexed, stored. По умолчанию: **оба**. Чтобы сохранить текст хранимым, но индексированным, укажите только \"stored\". Чтобы сохранить текст только индексированным, укажите только \"indexed\". | string |\n\n| [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint)\t| целое число\t | int, uint |\n\n| [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint)\t| большое целое число\t | |\n\n| [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | число с плавающей точкой | |\n\n| [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | вектор чисел с плавающей точкой | |\n\n| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | мульти-целое число | |\n\n| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | мульти-большое целое число | |\n\n| [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | булево значение | |\n\n| [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | |\n\n| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | строка. Опция `indexed, attribute` сделает значение полнотекстово индексируемым и одновременно фильтруемым, сортируемым и группируемым | |\n\n| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) |\t[rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | временная метка | |\n\n| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N — максимальное количество бит для хранения | |\n\n\n\n##### Примеры создания таблицы реального времени через CREATE TABLE\n\n\n\nCODE_BLOCK_52\n\nЭто создаёт таблицу \"products\" с двумя полями: \"title\" (полнотекстовый) и \"price\" (число с плавающей точкой), и устанавливает \"morphology\" в \"stem_en\".\n\nCODE_BLOCK_53\n\nЭто создаёт таблицу \"products\" с тремя полями:\n\n* \"title\" индексируется, но не хранится.\n\n* \"description\" хранится, но не индексируется.\n\n* \"author\" хранится и индексируется одновременно.\n\n\n\n## Engine\n\nCODE_BLOCK_54\n\nПараметр engine изменяет стандартное [хранилище атрибутов](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) для всех атрибутов в таблице. Вы также можете указать `engine` [отдельно для каждого атрибута](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages).\n\nДля информации о том, как включить колоночное хранилище для простой таблицы, смотрите [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs).\n\nЗначения:\n\n* columnar - Включает колоночное хранилище для всех атрибутов таблицы, кроме [json](../../Creating_a_table/Data_types.md#JSON)\n\n* **rowwise (по умолчанию)** - Не изменяет ничего и использует традиционное построчное хранилище для таблицы.\n\n## Другие настройки\n\nСледующие настройки применимы как для таблиц реального времени, так и для простых таблиц, независимо от того, указаны ли они в конфигурационном файле или установлены онлайн с помощью команды `CREATE` или `ALTER`.\n\n### Связанные с производительностью\n\n#### Доступ к файлам таблицы\n\nManticore поддерживает два режима доступа для чтения данных таблицы: seek+read и mmap." }, "is_code_or_comment": false + }, + "d4c07dbe713bda497e105ef3b4dd8679653ac27520a69d227d57413b99fc2d5b": { + "original": "This setting controls the size of blocks used by the document storage. The default value is 16kb. When original document text is stored using stored_fields or stored_only_fields, it is stored within the table and compressed for efficiency. To optimize disk access and compression ratios for small documents, these documents are concatenated into blocks. The indexing process collects documents until their total size reaches the threshold specified by this option. At that point, the block of documents is compressed. This option can be adjusted to achieve better compression ratios (by increasing the block size) or faster access to document text (by decreasing the block size).\n\nValue: size, default **16k**.\n\n#### docstore_compression\n\nCODE_BLOCK_59\n\nThis setting determines the type of compression used for compressing blocks of documents stored in document storage. If stored_fields or stored_only_fields are specified, the document storage stores compressed document blocks. 'lz4' offers fast compression and decompression speeds, while 'lz4hc' (high compression) sacrifices some compression speed for a better compression ratio. 'none' disables compression completely.\n\nValues: **lz4** (default), lz4hc, none.\n\n#### docstore_compression_level\n\nCODE_BLOCK_60\n\nThe compression level used when 'lz4hc' compression is applied in document storage. By adjusting the compression level, you can find the right balance between performance and compression ratio when using 'lz4hc' compression. Note that this option is not applicable when using 'lz4' compression.\n\nValue: An integer between 1 and 12, with a default of **9**.\n\n#### preopen\n\nCODE_BLOCK_61\n\nThis setting indicates that searchd should open all table files on startup or rotation, and keep them open while running. By default, the files are not pre-opened. Pre-opened tables require a few file descriptors per table, but they eliminate the need for per-query open() calls and are immune to race conditions that might occur during table rotation under high load. However, if you are serving many tables, it may still be more efficient to open them on a per-query basis in order to conserve file descriptors.\n\nValue: **0** (default), or 1.\n\n#### read_buffer_docs\n\nCODE_BLOCK_62\n\nBuffer size for storing the list of documents per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time.\n\nValue: size, default **256k**, minimum value is 8k.\n\n#### read_buffer_hits\n\nCODE_BLOCK_63\n\nBuffer size for storing the list of hits per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time.\n\nValue: size, default **256k**, minimum value is 8k.\n\n### Plain table disk footprint settings\n\n#### inplace_enable\n\n\n\nCODE_BLOCK_64\n\nEnables in-place table inversion. Optional, default is 0 (uses separate temporary files).\n\nThe `inplace_enable` option reduces the disk footprint during indexing of plain tables, while slightly slowing down indexing (it uses approximately 2 times less disk, but yields around 90-95% of the original performance).\n\nIndexing is comprised of two primary phases. During the first phase, documents are collected, processed, and partially sorted by keyword, and the intermediate results are written to temporary files (.tmp*). During the second phase, the documents are fully sorted and the final table files are created. Rebuilding a production table on-the-fly requires approximately 3 times the peak disk footprint: first for the intermediate temporary files, second for the newly constructed copy, and third for the old table that will be serving production queries in the meantime. (Intermediate data is comparable in size to the final table.) This may be too much disk footprint for large data collections, and the `inplace_enable` option can be used to reduce it. When enabled, it reuses the temporary files, outputs the final data back to them, and renames them upon completion. However, this may require additional temporary data chunk relocation, which is where the performance impact comes from.\n\nThis directive has no effect on [searchd](../../Starting_the_server/Manually.md), it only affects the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_65\n\n\n\n#### inplace_hit_gap\n\n\n\nCODE_BLOCK_66\n\nThe option [In-place inversion](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable) fine-tuning option. Controls preallocated hitlist gap size. Optional, default is 0.\n\nThis directive only affects the [searchd](../../Starting_the_server/Manually.md) tool, and does not have any impact on the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_67\n\n\n\n#### inplace_reloc_factor\n\n\n\nCODE_BLOCK_68\n\nThe inplace_reloc_factor setting determines the size of the relocation buffer within the memory arena used during indexing. The default value is 0.1.\n\nThis option is optional and only affects the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) tool, not the [searchd](../../Starting_the_server/Manually.md) server.\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_69\n\n\n\n#### inplace_write_factor\n\n\n\nCODE_BLOCK_70\n\nControls the size of the buffer used for in-place writing during indexing. Optional, with a default value of 0.1.\n\nIt's important to note that this directive only impacts the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) tool and not the [searchd](../../Starting_the_server/Manually.md) server.\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_71\n\n", + "translations": { + "chinese": "此设置控制文档存储中使用的块大小。默认值为16kb。当使用stored_fields或stored_only_fields存储原始文档文本时，其存储在表中并进行压缩以提高效率。为了优化小型文档的磁盘访问和压缩比，这些文档被连接成块。索引过程会收集文档，直到其总大小达到此选项指定的阈值。此时，文档块将被压缩。该选项可以调整以实现更好的压缩比（通过增加块大小）或更快的文档文本访问速度（通过减小块大小）。\n\n值：大小，默认 **16k**。\n\n#### docstore_compression\n\nCODE_BLOCK_59\n\n此设置决定了用于压缩文档存储中压缩文档块的压缩类型。如果指定了stored_fields或stored_only_fields，文档存储将存储压缩的文档块。'lz4'提供快速的压缩和解压速度，而'lz4hc'（高压缩）则牺牲一些压缩速度以获得更好的压缩比。'none' 完全禁用压缩。\n\n值：**lz4**（默认），lz4hc，none。\n\n#### docstore_compression_level\n\nCODE_BLOCK_60\n\n在文档存储中应用'lz4hc'压缩时使用的压缩级别。通过调整压缩级别，您可以在使用'lz4hc'压缩时找到性能与压缩比之间的最佳平衡。注意，当使用'lz4'压缩时，此选项不适用。\n\n值：1到12之间的整数，默认值为 **9**。\n\n#### preopen\n\nCODE_BLOCK_61\n\n此设置表示searchd应在启动或轮换时打开所有表文件，并在运行时保持打开状态。默认情况下，文件未预先打开。预先打开的表每个表需要几个文件描述符，但它们消除了每次查询调用open()的需求，且在高负载下表轮换时不会发生竞态条件。然而，如果您服务许多表，按查询方式打开它们可能更有效以节省文件描述符。\n\n值：**0**（默认），或1。\n\n#### read_buffer_docs\n\nCODE_BLOCK_62\n\n用于存储每个关键字的文档列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。\n\n值：大小，默认 **256k**，最小值为8k。\n\n#### read_buffer_hits\n\nCODE_BLOCK_63\n\n用于存储每个关键字的命中列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。\n\n值：大小，默认 **256k**，最小值为8k。\n\n### 纯表磁盘占用设置\n\n#### inplace_enable\n\n\n\nCODE_BLOCK_64\n\n启用原位表反转。可选，默认值为0（使用单独的临时文件）。\n\n`inplace_enable`选项减少了纯表索引期间的磁盘占用，同时稍微降低索引速度（使用约减少2倍磁盘，但性能约为原始的90-95%）。\n\n索引由两个主要阶段组成。第一阶段，收集文档，按照关键字处理和部分排序，中间结果写入临时文件（.tmp*）。第二阶段，文档完成排序，创建最终表文件。在生产环境中动态重建表大约需要3倍峰值磁盘空间：首先是中间临时文件，占用和最终表相当；其次是新建表的副本；第三是仍在服务的旧表。这对于大型数据集合来说磁盘占用可能过大，可以使用`inplace_enable`选项减小它。启用后，复用临时文件，将最终数据输出回临时文件，完成后重命名它们。但是可能需要额外的临时数据块重新定位，这就是性能影响的来源。\n\n此指令不影响[searchd](../../Starting_the_server/Manually.md)，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)。\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_65\n\n\n\n#### inplace_hit_gap\n\n\n\nCODE_BLOCK_66\n\n[原位反转](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable)的微调选项。控制预分配的命中列表间隙大小。可选，默认值为0。\n\n此指令仅影响[searchd](../../Starting_the_server/Manually.md)工具，对[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)无影响。\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_67\n\n\n\n#### inplace_reloc_factor\n\n\n\nCODE_BLOCK_68\n\ninplace_reloc_factor设置确定索引期间内存区中重定位缓冲区的大小。默认值为0.1。\n\n此选项可选，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_69\n\n\n\n#### inplace_write_factor\n\n\n\nCODE_BLOCK_70\n\n控制索引期间用于原位写入的缓冲区大小。可选，默认值为0.1。\n\n需注意，此指令仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_71\n\n", + "russian": "Этот параметр контролирует размер блоков, используемых хранилищем документов. Значение по умолчанию — 16 Кб. Когда текст оригинального документа сохраняется с использованием stored_fields или stored_only_fields, он хранится внутри таблицы и сжимается для повышения эффективности. Для оптимизации доступа к диску и коэффициентов сжатия для малых документов эти документы конкатенируются в блоки. Процесс индексации собирает документы, пока их общий размер не достигнет порога, указанного этим параметром. В этот момент блок документов сжимается. Этот параметр можно настроить для достижения лучшего коэффициента сжатия (увеличением размера блока) или более быстрого доступа к тексту документа (уменьшением размера блока).\n\nЗначение: size, по умолчанию **16k**.\n\n#### docstore_compression\n\nCODE_BLOCK_59\n\nЭтот параметр определяет тип сжатия, используемый для сжатия блоков документов, хранящихся в документном хранилище. Если указаны stored_fields или stored_only_fields, хранилище документов сохраняет сжатые блоки документов. 'lz4' предлагает высокую скорость сжатия и распаковки, тогда как 'lz4hc' (высокое сжатие) жертвует некоторой скоростью сжатия ради лучшего коэффициента сжатия. 'none' полностью отключает сжатие.\n\nЗначения: **lz4** (по умолчанию), lz4hc, none.\n\n#### docstore_compression_level\n\nCODE_BLOCK_60\n\nУровень сжатия, используемый при применении сжатия 'lz4hc' в документном хранилище. Настройка уровня сжатия позволяет подобрать оптимальный баланс между производительностью и коэффициентом сжатия при использовании сжатия 'lz4hc'. Обратите внимание, что этот параметр не применяется при использовании сжатия 'lz4'.\n\nЗначение: целое число от 1 до 12, по умолчанию **9**.\n\n#### preopen\n\nCODE_BLOCK_61\n\nЭтот параметр указывает, что searchd должен открыть все файлы таблиц при запуске или ротации и удерживать их открытыми во время работы. По умолчанию файлы не открываются заранее. Предварительно открытые таблицы требуют нескольких дескрипторов файлов на таблицу, но устраняют необходимость вызовов open() для каждого запроса и защищены от условий гонки, которые могут возникнуть при ротации таблиц под высокой нагрузкой. Однако, если обслуживается много таблиц, может быть эффективнее открывать их по запросу, чтобы экономить дескрипторы файлов.\n\nЗначение: **0** (по умолчанию) или 1.\n\n#### read_buffer_docs\n\nCODE_BLOCK_62\n\nРазмер буфера для хранения списка документов для каждого ключевого слова. Увеличение этого значения приведет к большему использованию памяти во время выполнения запроса, но может уменьшить время ввода-вывода.\n\nЗначение: size, по умолчанию **256k**, минимальное значение 8k.\n\n#### read_buffer_hits\n\nCODE_BLOCK_63\n\nРазмер буфера для хранения списка попаданий для каждого ключевого слова. Увеличение этого значения приведет к большему использованию памяти во время выполнения запроса, но может уменьшить время ввода-вывода.\n\nЗначение: size, по умолчанию **256k**, минимальное значение 8k.\n\n### Настройки отслеживания размера плоской таблицы на диске\n\n#### inplace_enable\n\n\n\nCODE_BLOCK_64\n\nВключает инверсию таблицы на месте. Опционально, по умолчанию 0 (используются отдельные временные файлы).\n\nОпция `inplace_enable` уменьшает размер дискового пространства, занятого при индексации плоских таблиц, слегка замедляя индексацию (использует примерно в 2 раза меньше диска, но показывает около 90–95% от исходной производительности).\n\nИндексация состоит из двух основных фаз. На первой фазе документы собираются, обрабатываются и частично сортируются по ключевому слову, а промежуточные результаты записываются во временные файлы (.tmp*). Во второй фазе документы полностью сортируются и создаются конечные файлы таблицы. Перестройка рабочей таблицы в реальном времени требует примерно в 3 раза больше пикового объема дискового пространства: сначала для промежуточных временных файлов, затем для вновь созданной копии, и ещё для старой таблицы, которая в это время обрабатывает производственные запросы. (Промежуточные данные сравнимы по размеру с конечной таблицей.) Это может быть слишком большой расход дискового пространства для больших коллекций данных, и опция `inplace_enable` может использоваться для его сокращения. При включении она переиспользует временные файлы, выводит в них конечные данные и переименовывает их по завершении. Однако это может потребовать дополнительной релокации блоков временных данных, что и объясняет снижение производительности.\n\nЭта директива не влияет на [searchd](../../Starting_the_server/Manually.md), она применяется только к инструменту [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_65\n\n\n\n#### inplace_hit_gap\n\n\n\nCODE_BLOCK_66\n\nОпция тонкой настройки [инверсии на месте](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable). Управляет размером заранее выделенного пространства для пропусков в списках попаданий. Опционально, по умолчанию 0.\n\nЭта директива влияет только на инструмент [searchd](../../Starting_the_server/Manually.md) и не оказывает воздействия на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_67\n\n\n\n#### inplace_reloc_factor\n\n\n\nCODE_BLOCK_68\n\nПараметр inplace_reloc_factor определяет размер буфера для релокации внутри арены памяти, используемой во время индексации. Значение по умолчанию — 0.1.\n\nЭта опция опциональна и влияет только на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool), а не на сервер [searchd](../../Starting_the_server/Manually.md).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_69\n\n\n\n#### inplace_write_factor\n\n\n\nCODE_BLOCK_70\n\nКонтролирует размер буфера, используемого для записи на месте во время индексации. Опционально, значение по умолчанию 0.1.\n\nВажно отметить, что эта директива влияет только на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) и не затрагивает сервер [searchd](../../Starting_the_server/Manually.md).\n\n\n\n##### CONFIG:\n\n\n\nCODE_BLOCK_71\n\n" + }, + "is_code_or_comment": false + }, + "03fae5169e50350879644a9d386ecb6e32c0ad564c7a4a83d921b79298c085a0": { + "original": "The following settings are applicable for both real-time and plain tables, regardless of whether they are specified in a configuration file or set online using the `CREATE` or `ALTER` command.\n\n### Performance related\n\n#### Accessing table files\n\nManticore supports two access modes for reading table data: seek+read and mmap.\n\nIn seek+read mode, the server uses the `pread` system call to read document lists and keyword positions, represented by the `*.spd` and `*.spp` files. The server uses internal read buffers to optimize the reading process, and the size of these buffers can be adjusted using the options [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) and [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits).There is also the option [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen) that controls how Manticore opens files at start.\n\nIn mmap access mode, the search server maps the table's file into memory using the `mmap` system call, and the OS caches the file contents. The options [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) and [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) have no effect for corresponding files in this mode. The mmap reader can also lock the table's data in memory using the`mlock` privileged call, which prevents the OS from swapping the cached data out to disk.\n\nTo control which access mode to use, the options **access_plain_attrs**, **access_blob_attrs**, **access_doclists**, **access_hitlists** and **access_dict** are available, with the following values:\n\n| Value | Description |\n\n| - | - |\n\n| file | server reads the table files from disk with seek+read using internal buffers on file access |\n\n| mmap | server maps the table files into memory and OS caches up its contents on file access |\n\n| mmap_preread | server maps the table files into memory and a background thread reads it once to warm up the cache |\n\n| mlock | server maps the table files into memory and then executes the mlock() system call to cache up the file contents and lock it into memory to prevent it being swapped out |\n\n| Setting | Values | Description |\n\n| - | - | - |\n\n| access_plain_attrs | mmap, **mmap_preread** (default), mlock | controls how `*.spa` (plain attributes) `*.spe` (skip lists) `*.spt` (lookups) `*.spm` (killed docs) will be read |\n\n| access_blob_attrs | mmap, **mmap_preread** (default), mlock | controls how `*.spb` (blob attributes) (string, mva and json attributes) will be read |\n\n| access_doclists | **file** (default), mmap, mlock | controls how `*.spd` (doc lists) data will be read |\n\n| access_hitlists | **file** (default), mmap, mlock | controls how `*.spp` (hit lists) data will be read |\n\n| access_dict | mmap, **mmap_preread** (default), mlock | controls how `*.spi` (dictionary) will be read |\n\nHere is a table which can help you select your desired mode:\n\n| table part |\tkeep it on disk |\tkeep it in memory |\tcached in memory on server start | lock it in memory |\n\n| - | - | - | - | - |\n\n| plain attributes in [row-wise](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) (non-columnar) storage, skip lists, word lists, lookups, killed docs | \tmmap | mmap |\t**mmap_preread** (default) | mlock |\n\n| row-wise string, multi-value attributes (MVA) and json attributes | mmap | mmap | **mmap_preread** (default) | mlock |\n\n| [columnar](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) numeric, string and multi-value attributes | always | only by means of OS | no | not supported |\n\n| doc lists | **file** (default) | mmap | no\t| mlock |\n\n| hit lists | **file** (default) | mmap | no\t| mlock |\n\n| dictionary | mmap | mmap | **mmap_preread** (default) | mlock |\n\n##### The recommendations are:\n\n* For the **fastest search response time** and ample memory availability, use [row-wise](../../Creating_a_table/Data_types.md#JSON) attributes and lock them in memory using `mlock`. Additionally, use mlock for doclists/hitlists.\n\n* If you prioritize **can't afford lower performance after start** and are willing to accept longer startup time, use the [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options). option. If you desire faster searchd restart, stick to the default `mmap_preread` option.\n\n* If you are looking to **conserve memory**, while still having enough memory for all attributes, skip the use of `mlock`. The operating system will determine what should be kept in memory based on frequent disk reads.\n\n* If row-wise attributes **do not fit into memory**, opt for [columnar attributes](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)\n\n* If full-text search **performance is not a concern**, and you wish to save memory, use `access_doclists/access_hitlists=file`\n\nThe default mode offers a balance of:\n\n* mmap,\n\n* Prereading non-columnar attributes,\n\n* Seeking and reading columnar attributes with no preread,\n\n* Seeking and reading doclists/hitlists with no preread.\n\nThis provides a decent search performance, optimal memory utilization, and faster searchd restart in most scenarios.\n\n### Other performance related settings\n\n#### attr_update_reserve\n\nCODE_BLOCK_57\n\nThis setting reserves extra space for updates to blob attributes such as multi-value attributes (MVA), strings, and JSON. The default value is 128k. When updating these attributes, their length may change. If the updated string is shorter than the previous one, it will overwrite the old data in the `*.spb` file. If the updated string is longer, it will be written to the end of the `*.spb` file. This file is memory-mapped, making resizing it a potentially slow process, depending on the operating system's memory-mapped file implementation. To avoid frequent resizing, you can use this setting to reserve extra space at the end of the .spb file.\n\nValue: size, default **128k**.\n\n#### docstore_block_size\n\nCODE_BLOCK_58", + "translations": { + "chinese": "以下设置适用于实时和普通表，无论它们是在配置文件中指定还是通过 `CREATE` 或 `ALTER` 命令在线设置。\n\n### 性能相关\n\n#### 访问表文件\n\nManticore 支持两种读取表数据的访问模式：seek+read 和 mmap。\n\n在 seek+read 模式中，服务器使用 `pread` 系统调用读取文档列表和关键字位置，这些由 `*.spd` 和 `*.spp` 文件表示。服务器使用内部读取缓冲区来优化读取过程，缓冲区大小可以通过选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 调整。还有一个选项 [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen) 控制 Manticore 如何在启动时打开文件。\n\n在 mmap 访问模式中，搜索服务器使用 `mmap` 系统调用将表文件映射到内存中，操作系统缓存文件内容。选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 对应文件在此模式下无效。mmap 读取器还可以使用特权调用 `mlock` 锁定表数据在内存中，防止操作系统将缓存数据换出到磁盘。\n\n为了控制使用哪种访问模式，提供了选项 **access_plain_attrs**、**access_blob_attrs**、**access_doclists**、**access_hitlists** 和 **access_dict**，其值如下：\n\n| 值 | 描述 |\n\n| - | - |\n\n| file | 服务器使用内部缓冲区通过 seek+read 从磁盘读取表文件 |\n\n| mmap | 服务器将表文件映射到内存中，操作系统缓存其内容 |\n\n| mmap_preread | 服务器将表文件映射到内存中，后台线程读取一次以预热缓存 |\n\n| mlock | 服务器将表文件映射到内存后执行 mlock() 系统调用，将文件内容缓存并锁定在内存中防止被换出 |\n\n| 设置 | 值 | 描述 |\n\n| - | - | - |\n\n| access_plain_attrs | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spa`（普通属性）`*.spe`（跳跃列表）`*.spt`（查找表）`*.spm`（已删除文档） |\n\n| access_blob_attrs | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spb`（blob 属性）（字符串、多值和 json 属性） |\n\n| access_doclists | **file**（默认）, mmap, mlock | 控制如何读取 `*.spd`（文档列表）数据 |\n\n| access_hitlists | **file**（默认）, mmap, mlock | 控制如何读取 `*.spp`（命中列表）数据 |\n\n| access_dict | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spi`（字典） |\n\n下面的表格帮助您选择所需模式：\n\n| 表部分 | 保持在磁盘 | 保持在内存 | 服务器启动时缓存于内存 | 锁定在内存 |\n\n| - | - | - | - | - |\n\n| 使用[行式](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)（非列式）存储的普通属性、跳跃列表、词表、查找表、已删除文档 | mmap | mmap | **mmap_preread**（默认） | mlock |\n\n| 行式字符串、多值属性（MVA）和 json 属性 | mmap | mmap | **mmap_preread**（默认） | mlock |\n\n| [列式](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) 数值、字符串和多值属性 | 始终 | 仅由操作系统实现 | 否 | 不支持 |\n\n| 文档列表 | **file**（默认） | mmap | 否 | mlock |\n\n| 命中列表 | **file**（默认） | mmap | 否 | mlock |\n\n| 字典 | mmap | mmap | **mmap_preread**（默认） | mlock |\n\n##### 推荐如下：\n\n* 若需**最快的搜索响应时间**且内存充足，使用[行式](../../Creating_a_table/Data_types.md#JSON)属性并通过 `mlock` 锁定它们在内存中。同时，文档列表/命中列表也使用 mlock。\n\n* 若优先考虑**启动后不可接受性能下降**，并且愿意接受较长启动时间，使用 [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options) 选项。如需搜索守护进程更快重启，请保持默认 `mmap_preread`。\n\n* 若想**节省内存**，同时保证所有属性有足够内存，避免使用 `mlock`，操作系统将根据频繁的磁盘读取决定缓存内容。\n\n* 若行式属性**无法完全放入内存**，请选择[列式属性](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。\n\n* 若全文搜索**性能不是关键**且希望节省内存，使用 `access_doclists/access_hitlists=file`。\n\n默认模式平衡了：\n\n* mmap，\n\n* 预读取非列式属性，\n\n* 列式属性无预读取的 seek+read，\n\n* 文档列表/命中列表无预读取的 seek+read。\n\n这在大多数情况下提供了良好的搜索性能、优化的内存利用和更快的搜索守护进程重启。\n\n### 其他性能相关设置\n\n#### attr_update_reserve\n\nCODE_BLOCK_57\n\n此设置为 Blob 属性（如多值属性（MVA）、字符串和 JSON）更新预留额外空间。默认值为128k。更新这些属性时，其长度可能变化。如果更新后的字符串比之前短，会覆盖 `*.spb` 文件中的旧数据；如果更新后的字符串更长，则写到 `*.spb` 文件末尾。该文件被内存映射，重新调整大小可能因操作系统的内存映射文件实现而较慢。为避免频繁调整大小，可使用此设置在 .spb 文件末尾预留额外空间。\n\n值：大小，默认 **128k**。\n\n#### docstore_block_size\n\nCODE_BLOCK_58", + "russian": "Следующие настройки применимы как к таблицам реального времени, так и к обычным таблицам, вне зависимости от того, указаны ли они в конфигурационном файле или установлены онлайн с помощью команды `CREATE` или `ALTER`.\n\n### Настройки, связанные с производительностью\n\n#### Доступ к файлам таблиц\n\nManticore поддерживает два режима доступа для чтения данных таблиц: seek+read и mmap.\n\nВ режиме seek+read сервер использует системный вызов `pread` для чтения списков документов и позиций ключевых слов, которые представлены файлами `*.spd` и `*.spp`. Сервер использует внутренние буферы чтения для оптимизации процесса чтения, и размер этих буферов можно регулировать с помощью опций [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits). Также существует опция [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen), которая управляет тем, как Manticore открывает файлы при старте.\n\nВ режиме mmap сервер поиска отображает файл таблицы в память с помощью системного вызова `mmap`, а ОС кэширует содержимое файла. Опции [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) не влияют на соответствующие файлы в этом режиме. mmap-читалка также может заблокировать данные таблицы в памяти с помощью привилегированного вызова `mlock`, что предотвращает выгрузку кэшированных данных на диск.\n\nДля управления используемым режимом доступа доступны опции **access_plain_attrs**, **access_blob_attrs**, **access_doclists**, **access_hitlists** и **access_dict** со следующими значениями:\n\n| Значение | Описание |\n\n| - | - |\n\n| file | сервер читает файлы таблиц с диска с помощью seek+read, используя внутренние буферы при доступе к файлу |\n\n| mmap | сервер отображает файлы таблиц в память, а ОС кэширует их содержимое при доступе к файлу |\n\n| mmap_preread | сервер отображает файлы таблиц в память, а фоновый поток один раз читает их для прогрева кэша |\n\n| mlock | сервер отображает файлы таблиц в память и затем выполняет системный вызов mlock() для кэширования содержимого файла и блокировки его в памяти, чтобы избежать выгрузки |\n\n| Настройка | Значения | Описание |\n\n| - | - | - |\n\n| access_plain_attrs | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будут читаться файлы `*.spa` (простые атрибуты), `*.spe` (списки пропусков), `*.spt` (поисковые обращения), `*.spm` (удалённые документы) |\n\n| access_blob_attrs | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будут читаться файлы `*.spb` (blob-атрибуты) (строковые, мульти-значения и json атрибуты) |\n\n| access_doclists | **file** (по умолчанию), mmap, mlock | управляет тем, как будут читаться данные `*.spd` (списки документов) |\n\n| access_hitlists | **file** (по умолчанию), mmap, mlock | управляет тем, как будут читаться данные `*.spp` (списки попаданий) |\n\n| access_dict | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будет читаться файл `*.spi` (словарь) |\n\nНиже представлена таблица, которая поможет вам выбрать желаемый режим:\n\n| часть таблицы |\tхранить на диске |\tхранить в памяти |\tкэшировать в памяти при старте сервера | блокировать в памяти |\n\n| - | - | - | - | - |\n\n| простые атрибуты в [построчном](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) (неколоночном) хранении, списки пропусков, словари, поисковые обращения, удалённые документы | \tmmap | mmap |\t**mmap_preread** (по умолчанию) | mlock |\n\n| построчные строковые, мульти-значимые атрибуты (MVA) и json атрибуты | mmap | mmap | **mmap_preread** (по умолчанию) | mlock |\n\n| [колоночные](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) числовые, строковые и мульти-значимые атрибуты | всегда | только средствами ОС | нет | не поддерживается |\n\n| списки документов | **file** (по умолчанию) | mmap | нет\t| mlock |\n\n| списки попаданий | **file** (по умолчанию) | mmap | нет\t| mlock |\n\n| словарь | mmap | mmap | **mmap_preread** (по умолчанию) | mlock |\n\n##### Рекомендации:\n\n* Для **максимально быстрого отклика поиска** при достаточном объёме памяти используйте [построчные](../../Creating_a_table/Data_types.md#JSON) атрибуты и блокируйте их в памяти с помощью `mlock`. Также применяйте mlock для списков документов и списков попаданий.\n\n* Если для вас важен **обеспеченный старт с максимальной производительностью** и вы готовы пожертвовать временем запуска, используйте параметр [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options). Если хотите более быстрый перезапуск searchd, придерживайтесь опции по умолчанию `mmap_preread`.\n\n* Если вы стремитесь **экономить память**, но при этом достаточно памяти для всех атрибутов, пропустите использование `mlock`. Операционная система сама определит, что должно оставаться в памяти, исходя из частоты чтения с диска.\n\n* Если построчные атрибуты **не помещаются в память**, выберите [колоночные атрибуты](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages).\n\n* Если производительность полнотекстового поиска **не критична**, и вы хотите экономить память, используйте `access_doclists/access_hitlists=file`.\n\nРежим по умолчанию обеспечивает баланс между:\n\n* mmap,\n\n* предварительным чтением неколоночных атрибутов,\n\n* чтением и поиском построчных атрибутов без предварительного чтения,\n\n* чтением списков документов и списков попаданий без предварительного чтения.\n\nЭто обеспечивает достойную производительность поиска, оптимальное использование памяти и более быстрый перезапуск searchd в большинстве случаев.\n\n### Другие настройки, связанные с производительностью\n\n#### attr_update_reserve\n\nCODE_BLOCK_57\n\nЭта настройка резервирует дополнительное пространство для обновлений blob-атрибутов, таких как мульти-значимые атрибуты (MVA), строки и JSON. Значение по умолчанию — 128k. При обновлении этих атрибутов их длина может изменяться. Если обновлённая строка короче предыдущей, она перезапишет старые данные в файле `*.spb`. Если обновлённая строка длиннее, она будет записана в конец файла `*.spb`. Этот файл отображается в память, что делает изменение размера потенциально медленным процессом в зависимости от реализации памяти отображаемых файлов операционной системой. Чтобы избежать частого изменения размера файла, можно использовать эту настройку для резервирования дополнительного пространства в конце файла .spb.\n\nЗначение: размер, по умолчанию **128k**.\n\n#### docstore_block_size\n\nCODE_BLOCK_58" + }, + "is_code_or_comment": false + }, + "37c4305c983c2a3a330f54e962db40f998da39081532c78fa10e43f2ecbaa6ee": { + "original": "This setting determines the table(s) to which the kill-list will be applied. Matches in the targeted table that are updated or deleted in the current table will be suppressed. In `:kl` mode, the documents to suppress are taken from the [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md). In `:id` mode, all document IDs from the current table are suppressed in the targeted one. If neither is specified, both modes will take effect. [Learn more about kill-lists here](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)\n\nValue: **not specified** (default), target_table_name:kl, target_table_name:id, target_table_name. Multiple values are allowed\n\n#### columnar_attrs\n\nCODE_BLOCK_49\n\nThis configuration setting determines which attributes should be stored in [the columnar storage](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) instead of the row-wise storage.\n\nYou can set `columnar_attrs = *` to store all supported data types in the columnar storage.\n\nAdditionally, `id` is a supported attribute to store in the columnar storage.\n\n#### columnar_strings_no_hash\n\nCODE_BLOCK_50\n\nBy default, all string attributes stored in columnar storage store pre-calculated hashes. These hashes are used for grouping and filtering. However, they occupy extra space, and if you don't need to group by that attribute, you can save space by disabling hash generation.\n\n### Creating a real-time table online via CREATE TABLE\n\n\n\n##### General syntax of CREATE TABLE\n\nCODE_BLOCK_51\n\n##### Data types:\n\nFor more information on data types, see [more about data types here](../../Creating_a_table/Data_types.md).\n\n| Type | Equivalent in a configuration file | Notes | Aliases |\n\n| - | - | - | - |\n\n| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | Options: indexed, stored. Default: **both**. To keep text stored, but indexed, specify \"stored\" only. To keep text indexed only, specify \"indexed\" only. | string |\n\n| [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint)\t| integer\t | int, uint |\n\n| [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint)\t| big integer\t | |\n\n| [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | float | |\n\n| [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | a vector of float values | |\n\n| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | multi-integer | |\n\n| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | multi-bigint | |\n\n| [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | boolean | |\n\n| [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | |\n\n| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | string. Option `indexed, attribute` will make the value full-text indexed and filterable, sortable and groupable at the same time | |\n\n| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) |\t[rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | timestamp | |\n\n| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N is the max number of bits to keep | |\n\n\n\n##### Examples of creating a real-time table via CREATE TABLE\n\n\n\nCODE_BLOCK_52\n\nThis creates the \"products\" table with two fields: \"title\" (full-text) and \"price\" (float), and sets the \"morphology\" to \"stem_en\".\n\nCODE_BLOCK_53\n\nThis creates the \"products\" table with three fields:\n\n* \"title\" is indexed, but not stored.\n\n* \"description\" is stored, but not indexed.\n\n* \"author\" is both stored and indexed.\n\n\n\nCODE_BLOCK_54\n\nThis creates the \"products\" table with two fields: \"title\" (full-text) and \"price\" (float), and sets the \"morphology\" to \"stem_en\".\n\nCODE_BLOCK_55\n\nThis creates the \"products\" table with three fields:\n\n* \"title\" is indexed, but not stored.\n\n* \"description\" is stored, but not indexed.\n\n* \"author\" is both stored and indexed.\n\n\n\n## Engine\n\nCODE_BLOCK_56\n\nThe engine setting changes the default [attribute storage](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) for all attributes in the table. You can also specify `engine` [separately for each attribute](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages).\n\nFor information on how to enable columnar storage for a plain table, see [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs) .\n\nValues:\n\n* columnar - Enables columnar storage for all table attributes, except for [json](../../Creating_a_table/Data_types.md#JSON)\n\n* **rowwise (default)** - Doesn't change anything and uses the traditional row-wise storage for the table.\n\n## Other settings", + "translations": { + "chinese": "此设置确定将应用杀死列表的表。当前表中更新或删除的目标表中的匹配项将被抑制。在 `:kl` 模式下，要抑制的文档取自 [杀死列表](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)。在 `:id` 模式下，当前表中的所有文档 ID 在目标表中被抑制。如果两者都未指定，则两种模式都会生效。[在此处了解有关杀死列表的更多信息](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)\n\n值：**未指定**（默认），target_table_name:kl，target_table_name:id，target_table_name。允许多个值\n\n#### columnar_attrs\n\nCODE_BLOCK_49\n\n此配置设置确定哪些属性应存储在[列存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)中，而不是行存储中。\n\n您可以设置 `columnar_attrs = *` 来将所有支持的数据类型存储在列存储中。\n\n此外，`id` 是支持存储在列存储中的属性。\n\n#### columnar_strings_no_hash\n\nCODE_BLOCK_50\n\n默认情况下，所有存储在列存储中的字符串属性都会存储预先计算的哈希值。这些哈希值用于分组和过滤。然而，它们会占用额外空间，如果您不需要按此属性分组，可以通过禁用哈希生成来节省空间。\n\n### 通过 CREATE TABLE 在线创建实时表\n\n\n\n##### CREATE TABLE 的通用语法\n\nCODE_BLOCK_51\n\n##### 数据类型：\n\n有关数据类型的更多信息，请参见[有关数据类型的更多内容](../../Creating_a_table/Data_types.md)。\n\n| 类型 | 配置文件中的等价项 | 备注 | 别名 |\n\n| - | - | - | - |\n\n| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | 选项：indexed, stored。默认：**两者都有**。要保持文本被存储但被索引，仅指定 \"stored\"。要保持文本仅被索引，仅指定 \"indexed\"。 | string |\n\n| [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint)\t| 整数\t | int, uint |\n\n| [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint)\t| 大整数\t | |\n\n| [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | 浮点数 | |\n\n| [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | 浮点值向量 | |\n\n| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | 多整数 | |\n\n| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | 多大整数 | |\n\n| [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | 布尔值 | |\n\n| [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | |\n\n| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | 字符串。选项 `indexed, attribute` 将使该值同时具备全文索引以及可过滤、可排序和可分组的属性 | |\n\n| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) |\t[rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | 时间戳 | |\n\n| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N 是可保留的最大位数 | |\n\n\n\n##### 通过 CREATE TABLE 创建实时表的示例\n\n\n\nCODE_BLOCK_52\n\n这将创建一个名为 \"products\" 的表，包含两个字段：“title”（全文）和 “price”（浮点），并将“morphology”设置为“stem_en”。\n\nCODE_BLOCK_53\n\n这将创建一个名为 \"products\" 的表，包含三个字段：\n\n* \"title\" 被索引，但不存储。\n\n* \"description\" 被存储，但不索引。\n\n* \"author\" 同时存储和索引。\n\n\n\nCODE_BLOCK_54\n\n这将创建一个名为 \"products\" 的表，包含两个字段：“title”（全文）和 “price”（浮点），并将“morphology”设置为“stem_en”。\n\nCODE_BLOCK_55\n\n这将创建一个名为 \"products\" 的表，包含三个字段：\n\n* \"title\" 被索引，但不存储。\n\n* \"description\" 被存储，但不索引。\n\n* \"author\" 同时存储和索引。\n\n\n\n## 引擎\n\nCODE_BLOCK_56\n\nengine 设置改变表中所有属性的默认[属性存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。您也可以为[每个属性分别指定 engine](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages)。\n\n有关如何为普通表启用列存储的信息，请参见 [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs)。\n\n值：\n\n* columnar - 为所有表属性启用列存储，除 [json](../../Creating_a_table/Data_types.md#JSON) 类型外\n\n* **rowwise（默认）** - 不改变任何内容，使用传统的行存储方式。\n\n## 其他设置", + "russian": "Этот параметр определяет таблицу(ы), к которой будет применяться kill-list. Совпадения в целевой таблице, которые обновляются или удаляются в текущей таблице, будут подавляться. В режиме `:kl` документы для подавления берутся из [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md). В режиме `:id` все идентификаторы документов из текущей таблицы подавляются в целевой. Если ни один режим не указан, будут применяться оба режима. [Узнайте больше о kill-list здесь](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)\n\nЗначение: **не указано** (по умолчанию), target_table_name:kl, target_table_name:id, target_table_name. Разрешено использовать несколько значений\n\n#### columnar_attrs\n\nCODE_BLOCK_49\n\nЭтот параметр конфигурации определяет, какие атрибуты должны храниться в [колоночном хранилище](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) вместо построчного хранилища.\n\nВы можете задать `columnar_attrs = *`, чтобы хранить все поддерживаемые типы данных в колоночном хранилище.\n\nКроме того, атрибут `id` поддерживается для хранения в колоночном хранилище.\n\n#### columnar_strings_no_hash\n\nCODE_BLOCK_50\n\nПо умолчанию все строковые атрибуты, хранящиеся в колоночном хранилище, хранят предварительно вычисленные хеши. Эти хеши используются для группировки и фильтрации. Однако они занимают дополнительное пространство, и если вам не нужно группировать по этому атрибуту, вы можете сэкономить место, отключив генерацию хешей.\n\n### Создание таблицы в реальном времени через CREATE TABLE\n\n\n\n##### Общий синтаксис CREATE TABLE\n\nCODE_BLOCK_51\n\n##### Типы данных:\n\nДля получения дополнительной информации о типах данных смотрите [больше о типах данных здесь](../../Creating_a_table/Data_types.md).\n\n| Тип | Эквивалент в конфигурационном файле | Примечания | Псевдонимы |\n\n| - | - | - | - |\n\n| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | Опции: indexed, stored. По умолчанию: **оба**. Чтобы сохранить текст в хранилище, но без индексации, укажите только \"stored\". Чтобы сохранить только индексируемый текст, укажите только \"indexed\". | string |\n\n| [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint)\t| целое число\t | int, uint |\n\n| [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint)\t| большое целое число\t | |\n\n| [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | число с плавающей точкой | |\n\n| [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | вектор чисел с плавающей точкой | |\n\n| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | множество целых чисел | |\n\n| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | множество больших целых чисел | |\n\n| [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | булево значение | |\n\n| [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | |\n\n| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | строка. Опция `indexed, attribute` позволит сделать значение полнотекстово индексируемым, а также фильтруемым, сортируемым и группируемым одновременно | |\n\n| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) |\t[rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | метка времени | |\n\n| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N — максимальное количество бит, которое нужно сохранить | |\n\n\n\n##### Примеры создания таблицы в реальном времени через CREATE TABLE\n\n\n\nCODE_BLOCK_52\n\nЭто создаёт таблицу \"products\" с двумя полями: \"title\" (полнотекстовое) и \"price\" (float) и устанавливает \"morphology\" на \"stem_en\".\n\nCODE_BLOCK_53\n\nЭто создаёт таблицу \"products\" с тремя полями:\n\n* \"title\" индексируется, но не сохраняется.\n\n* \"description\" сохраняется, но не индексируется.\n\n* \"author\" сохраняется и индексируется одновременно.\n\n\n\nCODE_BLOCK_54\n\nЭто создаёт таблицу \"products\" с двумя полями: \"title\" (полнотекстовое) и \"price\" (float) и устанавливает \"morphology\" на \"stem_en\".\n\nCODE_BLOCK_55\n\nЭто создаёт таблицу \"products\" с тремя полями:\n\n* \"title\" индексируется, но не сохраняется.\n\n* \"description\" сохраняется, но не индексируется.\n\n* \"author\" сохраняется и индексируется одновременно.\n\n\n\n## Engine\n\nCODE_BLOCK_56\n\nПараметр engine изменяет стандартное [хранение атрибутов](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) для всех атрибутов в таблице. Также можно указать `engine` [отдельно для каждого атрибута](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages).\n\nДля информации о том, как включить колоночное хранение для простой таблицы, смотрите [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs) .\n\nЗначения:\n\n* columnar — Включает колоночное хранение для всех атрибутов таблицы, кроме [json](../../Creating_a_table/Data_types.md#JSON)\n\n* **rowwise (по умолчанию)** — Ничего не меняет и использует традиционное построчное хранение для таблицы.\n\n## Другие настройки" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Creating_a_table/Local_tables/Real-time_table.md.json b/.translation-cache/Creating_a_table/Local_tables/Real-time_table.md.json index 3e55d26161..e1eef01408 100644 --- a/.translation-cache/Creating_a_table/Local_tables/Real-time_table.md.json +++ b/.translation-cache/Creating_a_table/Local_tables/Real-time_table.md.json @@ -14,5 +14,21 @@ "russian": "# Таблица в реальном времени\n\n**Таблица в реальном времени** — это основной тип таблицы в Manticore. Она позволяет добавлять, обновлять и удалять документы, и вы можете видеть эти изменения сразу же. Вы можете настроить таблицу в реальном времени в конфигурационном файле или использовать команды, такие как `CREATE`, `UPDATE`, `DELETE` или `ALTER`.\n\nВнутри таблица в реальном времени состоит из одной или нескольких [простых таблиц](../../Creating_a_table/Local_tables/Plain_table.md), называемых **чанками**. Существуют два типа чанков:\n\n* несколько **дисковых чанков** — они сохраняются на диске и структурированы как [простая таблица](../../Creating_a_table/Local_tables/Plain_table.md).\n\n* один **RAM-чанк** — хранится в памяти и собирает все изменения.\n\nРазмер RAM-чанка контролируется настройкой [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit). Как только этот лимит достигается, RAM-чанк переносится на диск как дисковый чанк. Если дисковых чанков становится слишком много, Manticore [объединяет некоторые из них](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) для улучшения производительности.\n\n### Создание таблицы в реальном времени:\n\nВы можете создать новую таблицу в реальном времени двумя способами: с помощью команды `CREATE TABLE` или через [_mapping endpoint](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:) HTTP JSON API.\n\n#### Команда CREATE TABLE:\n\n\n\nВы можете использовать эту команду как через SQL, так и через HTTP протоколы:\n\n\n\n##### Создание таблицы в реальном времени через SQL протокол:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### Создание таблицы в реальном времени через JSON по HTTP:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Создание таблицы в реальном времени через PHP клиент:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Создание таблицы в реальном времени через конфигурационный файл:\n\n\n\nCODE_BLOCK_13\n\n\n\n#### _mapping API:\n\n> ПРИМЕЧАНИЕ: API `_mapping` требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если он не работает, убедитесь, что Buddy установлен.\n\n\n\nВ качестве альтернативы вы можете создать новую таблицу через endpoint `_mapping`. Этот endpoint позволяет определить структуру таблицы, похожую на Elasticsearch, которая будет преобразована в таблицу Manticore.\n\nТело вашего запроса должно иметь следующую структуру:\n\nCODE_BLOCK_14\n\nПри создании таблицы типы данных Elasticsearch будут сопоставлены с типами Manticore согласно следующим правилам:\n\n- aggregate_metric => json\n\n- binary => string\n\n- boolean => bool\n\n- byte => int\n\n- completion => string\n\n- date => timestamp\n\n- date_nanos => bigint\n\n- date_range => json\n\n- dense_vector => json\n\n- flattened => json\n\n- flat_object => json\n\n- float => float\n\n- float_range => json\n\n- geo_point => json\n\n- geo_shape => json\n\n- half_float => float\n\n- histogram => json\n\n- integer => int\n\n- integer_range => json\n\n- ip => string\n\n- ip_range => json\n\n- keyword => string\n\n- knn_vector => float_vector\n\n- long => bigint\n\n- long_range => json\n\n- match_only_text => text\n\n- object => json\n\n- point => json\n\n- scaled_float => float\n\n- search_as_you_type => text\n\n- shape => json\n\n- short => int\n\n- text => text\n\n- unsigned_long => int\n\n- version => string\n\n\n\n##### Создание таблицы в реальном времени через endpoint _mapping:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n#### CREATE TABLE LIKE:\n\n\n\nВы можете создать копию таблицы в реальном времени, с данными или без них. Обратите внимание, что если таблица большая, копирование с данными может занять некоторое время. Копирование работает в синхронном режиме, но если соединение прервется, оно продолжится в фоновом режиме.\n\nCODE_BLOCK_17\n\n> ПРИМЕЧАНИЕ: Копирование таблицы требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если оно не работает, убедитесь, что Buddy установлен.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Пример (С ДАННЫМИ):\n\n\n\nCODE_BLOCK_19\n\n\n\n### 👍 Что вы можете делать с таблицей в реальном времени:\n\n* [Добавлять документы](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md).\n\n* Обновлять атрибуты и полнотекстовые поля с помощью процесса [Update](../../Quick_start_guide.md#Update).\n\n* [Удалять документы](../../Quick_start_guide.md#Delete).\n\n* [Очищать таблицу](../../Emptying_a_table.md).\n\n* Изменять схему онлайн с помощью команды `ALTER`, как описано в разделе [Изменение схемы онлайн](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode).\n\n* Определять таблицу в конфигурационном файле, как подробно описано в разделе [Определение таблицы](../../Creating_a_table/Local_tables/Real-time_table.md).\n\n* Использовать функцию [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) для автоматического присвоения ID.\n\n### ⛔ Что вы не можете делать с таблицей в реальном времени:\n\n* Загружать данные с помощью функции [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool).\n\n* Подключать её к [источникам](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) для удобного индексирования из внешнего хранилища." }, "is_code_or_comment": false + }, + "3b7547929d3b2a3aff49a10583d8aac428d556e6fc0aaa9dc2226e698d2fad07": { + "original": "* Connect it to [sources](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) for easy indexing from external storage.\n\n* Update the [killlist_target](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#killlist_target), as it is automatically managed by the real-time table.\n\n#### Real-time table files structure\n\nThe following table outlines the different file extensions and their respective descriptions in a real-time table:\n\n| Extension | Description |\n\n| - | - |\n\n| `.lock` | A lock file that ensures that only one process can access the table at a time. |\n\n| `.ram` | The RAM chunk of the table, stored in memory and used as an accumulator of changes. |\n\n| `.meta` | The headers of the real-time table that define its structure and settings. |\n\n| `.*.sp*` | Disk chunks that are stored on disk with the same format as plain tables. They are created when the RAM chunk size exceeds the rt_mem_limit.|\n\n For more information on the structure of disk chunks, refer to the [plain table files structure](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure).\n\n", + "translations": { + "chinese": "* 将其连接到 [sources](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md)，以便于从外部存储进行索引。\n\n* 更新 [killlist_target](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#killlist_target)，因为它由实时表自动管理。\n\n#### 实时表文件结构\n\n下表概述了实时表中不同文件扩展名及其相应的描述：\n\n| 扩展名 | 描述 |\n\n| - | - |\n\n| `.lock` | 一个锁文件，确保一次只有一个进程可以访问该表。 |\n\n| `.ram` | 表的内存块，存储在内存中，用作更改的累加器。 |\n\n| `.meta` | 定义实时表结构和设置的头文件。 |\n\n| `.*.sp*` | 存储在磁盘上的磁盘块，格式与普通表相同。当 RAM 块大小超过 rt_mem_limit 时创建。|\n\n 有关磁盘块结构的更多信息，请参阅[普通表文件结构](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure)。\n\n", + "russian": "* Подключите его к [источникам](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) для удобного индексирования из внешнего хранилища.\n\n* Обновите [killlist_target](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#killlist_target), так как он автоматически управляется таблицей реального времени.\n\n#### Структура файлов таблицы реального времени\n\nВ следующей таблице приведены различные расширения файлов и их описание в таблице реального времени:\n\n| Extension | Description |\n\n| - | - |\n\n| `.lock` | Файл блокировки, который гарантирует, что к таблице одновременно может получить доступ только один процесс. |\n\n| `.ram` | RAM-чанк таблицы, хранящийся в памяти и используемый как аккумулятор изменений. |\n\n| `.meta` | Заголовки таблицы реального времени, которые определяют её структуру и настройки. |\n\n| `.*.sp*` | Дисковые чанки, которые хранятся на диске в том же формате, что и простые таблицы. Они создаются, когда размер RAM чанка превышает rt_mem_limit.|\n\n Для получения дополнительной информации о структуре дисковых чанков обратитесь к [структуре файлов простой таблицы](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure).\n\n" + }, + "is_code_or_comment": false + }, + "a55b3a9f6fe733e5a63427e2036dd88b0fab34f52b9bc3f9e2ae62201c3b8978": { + "original": "# Real-time table\n\nA **real-time table** is a main type of table in Manticore. It lets you add, update, and delete documents, and you can see these changes right away. You can set up a real-time Table in a configuration file or use commands like `CREATE`, `UPDATE`, `DELETE`, or `ALTER`.\n\nInternally a real-time table consists of one or more [plain tables](../../Creating_a_table/Local_tables/Plain_table.md) called **chunks**. There are two kinds of chunks:\n\n* multiple **disk chunks** - these are saved on a disk and are structured like a [plain table](../../Creating_a_table/Local_tables/Plain_table.md).\n\n* single **ram chunk** - this is kept in memory and collects all changes.\n\nThe size of the RAM chunk is controlled by the [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit) setting. Once this limit is reached, the RAM chunk is transferred to disk as a disk chunk. If there are too many disk chunks, Manticore [combines some of them](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) to improve performance.\n\n### Creating a real-time table:\n\nYou can create a new real-time table in two ways: by using the `CREATE TABLE` command or through the [_mapping endpoint](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:) of the HTTP JSON API.\n\n#### CREATE TABLE command:\n\n\n\nYou can use this command via both SQL and HTTP protocols:\n\n\n\n##### Creating a real-time table via SQL protocol:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### Creating a real-time table via JSON over HTTP:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Creating a real-time table via PHP client:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Creating a real-time table via a configuration file:\n\n\n\nCODE_BLOCK_13\n\n\n\n#### _mapping API:\n\n> NOTE: The `_mapping` API requires [Manticore Buddy](Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\n\n\nAlternatively, you can create a new table via the `_mapping` endpoint. This endpoint allows you to define an Elasticsearch-like table structure to be converted to a Manticore table.\n\nThe body of your request must have the following structure:\n\nCODE_BLOCK_14\n\nWhen creating a table, Elasticsearch data types will be mapped to Manticore types according to the following rules:\n\n- aggregate_metric => json\n\n- binary => string\n\n- boolean => bool\n\n- byte => int\n\n- completion => string\n\n- date => timestamp\n\n- date_nanos => bigint\n\n- date_range => json\n\n- dense_vector => json\n\n- flattened => json\n\n- flat_object => json\n\n- float => float\n\n- float_range => json\n\n- geo_point => json\n\n- geo_shape => json\n\n- half_float => float\n\n- histogram => json\n\n- integer => int\n\n- integer_range => json\n\n- ip => string\n\n- ip_range => json\n\n- keyword => string\n\n- knn_vector => float_vector\n\n- long => bigint\n\n- long_range => json\n\n- match_only_text => text\n\n- object => json\n\n- point => json\n\n- scaled_float => float\n\n- search_as_you_type => text\n\n- shape => json\n\n- short => int\n\n- text => text\n\n- unsigned_long => int\n\n- version => string\n\n\n\n##### Creating a real-time table via the _mapping endpoint:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n#### CREATE TABLE LIKE:\n\n\n\nYou can create a copy of a real-time table, with or without its data. Please note that if the table is large, copying it with data may take some time. Copying works in synchronous mode, but if the connection is dropped, it will continue in the background.\n\nCODE_BLOCK_17\n\n> NOTE: Copying a table requires [Manticore Buddy](Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Example (WITH DATA):\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### JSON example (WITH DATA):\n\n\n\nCODE_BLOCK_21\n\n\n\n### 👍 What you can do with a real-time table:\n\n* [Add documents](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md).\n\n* Update attributes and full-text fields using the [Update](../../Quick_start_guide.md#Update) process.\n\n* [Delete documents](../../Quick_start_guide.md#Delete).\n\n* [Empty the table](../../Emptying_a_table.md).\n\n* Change the schema online with the `ALTER` command, as explained in [Change schema online](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode).\n\n* Define the table in a configuration file, as detailed in [Define table](../../Creating_a_table/Local_tables/Real-time_table.md).\n\n* Use the [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) feature for automatic ID provisioning.\n\n### ⛔ What you cannot do with a real-time table:\n\n* Ingest data using the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) feature.", + "translations": { + "chinese": "# 实时表\n\n**实时表** 是 Manticore 中的主要表类型。它允许您添加、更新和删除文档，并且可以立即看到这些更改。您可以在配置文件中设置实时表，或者使用诸如 `CREATE`、`UPDATE`、`DELETE` 或 `ALTER` 之类的命令。\n\n内部实时表由一个或多个称为 **chunks** 的[普通表](../../Creating_a_table/Local_tables/Plain_table.md)组成。有两种类型的 chunk：\n\n* 多个 **磁盘 chunk** - 这些存储在磁盘上，结构类似于[普通表](../../Creating_a_table/Local_tables/Plain_table.md)。\n\n* 单个 **内存 chunk** - 保存在内存中，收集所有更改。\n\n内存 chunk 的大小由 [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit) 设置控制。一旦达到该限制，内存 chunk 会被转移到磁盘，成为一个磁盘 chunk。如果磁盘 chunk 过多，Manticore 会[合并其中的一些](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)以提高性能。\n\n### 创建实时表：\n\n您可以通过两种方式创建新的实时表：使用 `CREATE TABLE` 命令，或通过 HTTP JSON API 的 [_mapping 端点](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:)。\n\n#### CREATE TABLE 命令：\n\n\n\n您可以通过 SQL 和 HTTP 协议使用此命令：\n\n\n\n##### 通过 SQL 协议创建实时表：\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### 通过 HTTP 的 JSON 创建实时表：\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### 通过 PHP 客户端创建实时表：\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python：\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio：\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript：\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Java：\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#：\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust：\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Typescript：\n\n\n\nCODE_BLOCK_11\n\n\n\n##### Go：\n\n\n\nCODE_BLOCK_12\n\n\n\n##### 通过配置文件创建实时表：\n\n\n\nCODE_BLOCK_13\n\n\n\n#### _mapping API:\n\n> 注意：`_mapping` API 需要[Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确认 Buddy 已安装。\n\n\n\n另一方面，您也可以通过 `_mapping` 端点创建新表。此端点允许您定义类似 Elasticsearch 的表结构，然后转换为 Manticore 表。\n\n请求体必须具有以下结构：\n\nCODE_BLOCK_14\n\n创建表时，Elasticsearch 数据类型将按以下规则映射到 Manticore 类型：\n\n- aggregate_metric => json\n\n- binary => string\n\n- boolean => bool\n\n- byte => int\n\n- completion => string\n\n- date => timestamp\n\n- date_nanos => bigint\n\n- date_range => json\n\n- dense_vector => json\n\n- flattened => json\n\n- flat_object => json\n\n- float => float\n\n- float_range => json\n\n- geo_point => json\n\n- geo_shape => json\n\n- half_float => float\n\n- histogram => json\n\n- integer => int\n\n- integer_range => json\n\n- ip => string\n\n- ip_range => json\n\n- keyword => string\n\n- knn_vector => float_vector\n\n- long => bigint\n\n- long_range => json\n\n- match_only_text => text\n\n- object => json\n\n- point => json\n\n- scaled_float => float\n\n- search_as_you_type => text\n\n- shape => json\n\n- short => int\n\n- text => text\n\n- unsigned_long => int\n\n- version => string\n\n\n\n##### 通过 _mapping 端点创建实时表：\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n#### CREATE TABLE LIKE:\n\n\n\n您可以创建实时表的副本，可以选择包含或不包含其数据。请注意，如果表较大，复制带数据的表可能需要一些时间。复制是同步进行的，但如果连接中断，它将继续在后台进行。\n\nCODE_BLOCK_17\n\n> 注意：复制表需要 [Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确认 Buddy 已安装。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_18\n\n\n\n##### 示例（带数据）：\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### JSON 示例（带数据）：\n\n\n\nCODE_BLOCK_21\n\n\n\n### 👍 使用实时表您可以做的事情：\n\n* [添加文档](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md)。\n\n* 使用 [Update](../../Quick_start_guide.md#Update) 过程更新属性和全文字段。\n\n* [删除文档](../../Quick_start_guide.md#Delete)。\n\n* [清空表](../../Emptying_a_table.md)。\n\n* 使用 `ALTER` 命令在线更改表模式，详见[在线更改模式](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode)。\n\n* 在配置文件中定义表，详见[定义表](../../Creating_a_table/Local_tables/Real-time_table.md)。\n\n* 使用 [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) 特性进行自动 ID 分配。\n\n### ⛔ 使用实时表您不能做的事情：\n\n* 使用 [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) 功能导入数据。", + "russian": "# Таблица в реальном времени\n\n**Таблица в реальном времени** — это основной тип таблицы в Manticore. Она позволяет добавлять, обновлять и удалять документы, при этом вы сразу же видите эти изменения. Вы можете настроить таблицу в реальном времени в конфигурационном файле или использовать команды вроде `CREATE`, `UPDATE`, `DELETE` или `ALTER`.\n\nВнутри таблица в реальном времени состоит из одного или нескольких [plain tables](../../Creating_a_table/Local_tables/Plain_table.md), называемых **чанками**. Существуют два типа чанков:\n\n* несколько **дисковых чанков** — они сохраняются на диске и имеют структуру, похожую на [plain table](../../Creating_a_table/Local_tables/Plain_table.md).\n\n* один **RAM-чанк** — хранится в памяти и собирает все изменения.\n\nРазмер RAM-чанка контролируется настройкой [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit). Когда этот лимит достигается, RAM-чанк переносится на диск как дисковый чанк. Если дисковых чанков становится слишком много, Manticore [объединяет часть из них](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) для повышения производительности.\n\n### Создание таблицы в реальном времени:\n\nВы можете создать новую таблицу в реальном времени двумя способами: используя команду `CREATE TABLE` или через [_mapping endpoint](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:) HTTP JSON API.\n\n#### Команда CREATE TABLE:\n\n\n\nВы можете использовать эту команду как через SQL, так и через HTTP протоколы:\n\n\n\n##### Создание таблицы в реальном времени через SQL протокол:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### Создание таблицы в реальном времени через JSON поверх HTTP:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Создание таблицы в реальном времени через PHP клиент:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Создание таблицы в реальном времени через конфигурационный файл:\n\n\n\nCODE_BLOCK_13\n\n\n\n#### _mapping API:\n\n> ПРИМЕЧАНИЕ: API `_mapping` требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\n\n\nВ качестве альтернативы вы можете создать новую таблицу через endpoint `_mapping`. Этот endpoint позволяет определить структуру таблицы, похожую на Elasticsearch, которая будет преобразована в таблицу Manticore.\n\nТело запроса должно иметь следующую структуру:\n\nCODE_BLOCK_14\n\nПри создании таблицы типы данных Elasticsearch будут сопоставлены с типами Manticore согласно следующим правилам:\n\n- aggregate_metric => json\n\n- binary => string\n\n- boolean => bool\n\n- byte => int\n\n- completion => string\n\n- date => timestamp\n\n- date_nanos => bigint\n\n- date_range => json\n\n- dense_vector => json\n\n- flattened => json\n\n- flat_object => json\n\n- float => float\n\n- float_range => json\n\n- geo_point => json\n\n- geo_shape => json\n\n- half_float => float\n\n- histogram => json\n\n- integer => int\n\n- integer_range => json\n\n- ip => string\n\n- ip_range => json\n\n- keyword => string\n\n- knn_vector => float_vector\n\n- long => bigint\n\n- long_range => json\n\n- match_only_text => text\n\n- object => json\n\n- point => json\n\n- scaled_float => float\n\n- search_as_you_type => text\n\n- shape => json\n\n- short => int\n\n- text => text\n\n- unsigned_long => int\n\n- version => string\n\n\n\n##### Создание таблицы в реальном времени через endpoint _mapping:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n#### CREATE TABLE LIKE:\n\n\n\nВы можете создать копию таблицы в реальном времени с данными или без них. Обратите внимание, что если таблица большая, копирование с данными может занять некоторое время. Копирование работает в синхронном режиме, но если соединение прервано, процесс продолжится в фоне.\n\nCODE_BLOCK_17\n\n> ПРИМЕЧАНИЕ: Копирование таблицы требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Пример (С ДАННЫМИ):\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Пример JSON (С ДАННЫМИ):\n\n\n\nCODE_BLOCK_21\n\n\n\n### 👍 Что можно делать с таблицей в реальном времени:\n\n* [Добавлять документы](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md).\n\n* Обновлять атрибуты и полнотекстовые поля через процесс [Update](../../Quick_start_guide.md#Update).\n\n* [Удалять документы](../../Quick_start_guide.md#Delete).\n\n* [Очищать таблицу](../../Emptying_a_table.md).\n\n* Менять схему онлайн с помощью команды `ALTER`, как описано в [Изменении схемы онлайн](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode).\n\n* Определять таблицу в конфигурационном файле, подробно описано в [Определение таблицы](../../Creating_a_table/Local_tables/Real-time_table.md).\n\n* Использовать функцию [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) для автоматической генерации ID.\n\n### ⛔ Что нельзя делать с таблицей в реальном времени:\n\n* Загружать данные с помощью [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)." + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Creating_a_table/NLP_and_tokenization/Wordforms.md.json b/.translation-cache/Creating_a_table/NLP_and_tokenization/Wordforms.md.json index 9f1e07fb8f..6cdc750d8b 100644 --- a/.translation-cache/Creating_a_table/NLP_and_tokenization/Wordforms.md.json +++ b/.translation-cache/Creating_a_table/NLP_and_tokenization/Wordforms.md.json @@ -6,5 +6,13 @@ "russian": "# Формы слов\n\nФормы слов применяются после токенизации входящего текста по правилам [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table). Они по сути позволяют заменить одно слово другим. Обычно это используется для приведения различных форм слова к одной нормальной форме (например, нормализация всех вариантов таких как \"walks\", \"walked\", \"walking\" к нормальной форме \"walk\"). Также это может использоваться для реализации исключений [стемминга](../../Creating_a_table/NLP_and_tokenization/Morphology.md), поскольку стемминг не применяется к словам, найденным в списке форм.\n\n## wordforms\n\nCODE_BLOCK_0\n\n\n\nСловарь форм слов. Опционально, по умолчанию пустой.\n\nСловари форм слов используются для нормализации входящих слов как при индексации, так и при поиске. Поэтому, когда речь идет о [plain table](../../Creating_a_table/Local_tables/Plain_table.md), требуется выполнить ротацию таблицы, чтобы применить изменения в файле форм слов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Пример в Plain режиме:\n\n\n\nCODE_BLOCK_10\n\n\n\nПоддержка форм слов в Manticore разработана для эффективной работы с большими словарями. Они умеренно влияют на скорость индексации; например, словарь с 1 миллионом записей замедляет полнотекстовую индексацию примерно в 1.5 раза. Скорость поиска при этом не страдает. Дополнительное потребление RAM примерно равно размеру файла словаря, и словари разделяются между таблицами. Например, если один и тот же файл форм слов размером 50 МБ указан для 10 разных таблиц, дополнительное потребление RAM `searchd` будет около 50 МБ.\n\n\n\nФайл словаря должен быть в простом текстовом формате. Каждая строка должна содержать исходную и целевую формы слова в кодировке UTF-8, разделённые знаком \"больше\" (>). Правила из [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) будут применены при загрузке файла. Поэтому, если вы не изменяете `charset_table`, ваши формы слов будут нечувствительны к регистру, как и остальные данные, индексируемые полнотекстово. Ниже приведён пример содержимого файла:\n\n\n\nCODE_BLOCK_11\n\n\n\nВ комплекте есть утилита [Spelldump](../../Miscellaneous_tools.md#spelldump), которая помогает создать файл словаря в формате, читаемом Manticore. Утилита может читать исходные файлы словарей `.dict` и `.aff` в формате `ispell` или `MySpell`, как в комплекте с OpenOffice.\n\nВы можете сопоставить несколько исходных слов с одним целевым словом. Процесс происходит на уровне токенов, а не исходного текста, поэтому различия в пробелах и разметке игнорируются.\n\n\n\nВы можете использовать символ `=>` вместо `>`. Также допускаются комментарии (начинающиеся с `#`). Наконец, если строка начинается с тильды (`~`), форма слова будет применена после морфологии, а не до (обратите внимание, что в этом случае поддерживается только одно исходное и одно целевое слово).\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\nЕсли вам нужно использовать `>`, `=` или `~` как обычные символы, вы можете экранировать их, предваряя обратным слэшем (`\\`). И `>`, и `=` должны быть экранированы таким образом. Вот пример:\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\nВы можете указать несколько целевых токенов:\n\n\n\nCODE_BLOCK_14\n\n\n\n\n\nВы можете указать несколько файлов, а не только один. Маски могут использоваться как шаблоны, и все подходящие файлы будут обработаны в простом порядке возрастания:\n\nВ режиме RT допускаются только абсолютные пути.\n\nЕсли используются многобайтовые кодировки и имена файлов содержат нелатинские символы, итоговый порядок может быть не совсем алфавитным. Если одно и то же определение формы слова встречается в нескольких файлах, используется последнее, переопределяющее предыдущие.\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n" }, "is_code_or_comment": false + }, + "7534d78c52f2bb692da560ad5ee9d323c1d0270c1d405c2dd07d2fba90f02ddd": { + "original": "# Word forms\n\nWord forms are applied after tokenizing incoming text by [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) rules. They essentially let you replace one word with another. Normally, that would be used to bring different word forms to a single normal form (e.g. to normalize all the variants such as \"walks\", \"walked\", \"walking\" to the normal form \"walk\"). It can also be used to implement [stemming](../../Creating_a_table/NLP_and_tokenization/Morphology.md) exceptions, because stemming is not applied to words found in the forms list.\n\n## wordforms\n\nCODE_BLOCK_0\n\n\n\nWord forms dictionary. Optional, default is empty.\n\nThe word forms dictionaries are used to normalize incoming words both during indexing and searching. Therefore, when it comes to a [plain table](../../Creating_a_table/Local_tables/Plain_table.md), it's required to rotate the table in order to pick up changes in the word forms file.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Plain mode example:\n\n\n\nCODE_BLOCK_10\n\n\n\nWord forms support in Manticore is designed to handle large dictionaries well. They moderately affect indexing speed; for example, a dictionary with 1 million entries slows down full-text indexing by about 1.5 times. Searching speed is not affected at all. The additional RAM impact is roughly equal to the dictionary file size, and dictionaries are shared across tables. For instance, if the very same 50 MB word forms file is specified for 10 different tables, the additional `searchd` RAM usage will be about 50 MB.\n\n\n\nThe dictionary file should be in a simple plain text format. Each line should contain source and destination word forms in UTF-8 encoding, separated by a 'greater than' sign. The rules from the [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) will be applied when the file is loaded. Therefore, if you do not modify `charset_table`, your word forms will be case-insensitive, similar to your other full-text indexed data. Below is a sample of the file contents:\n\n\n\nCODE_BLOCK_11\n\n\n\nThere is a bundled utility called [Spelldump](../../Miscellaneous_tools.md#spelldump) that helps you create a dictionary file in a format that Manticore can read. The utility can read from source `.dict` and `.aff` dictionary files in the `ispell` or `MySpell` format, as bundled with OpenOffice.\n\nYou can map several source words to a single destination word. The process happens on tokens, not the source text, so differences in whitespace and markup are ignored.\n\n\n\nYou can use the `=>` symbol instead of `>`. Comments (starting with `#`) are also allowed. Finally, if a line starts with a tilde (`~`), the wordform will be applied after morphology, instead of before (note that only a single source and destination word are supported in this case).\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\nIf you need to use `>`, `=` or `~` as normal characters, you can escape them by preceding each with a backslash (`\\`). Both `>` and `=` should be escaped in this manner. Here's an example:\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\nYou can specify multiple destination tokens:\n\n\n\nCODE_BLOCK_14\n\n\n\n\n\nYou can specify multiple files, not just one. Masks can be used as a pattern, and all matching files will be processed in simple ascending order:\n\nIn the RT mode, only absolute paths are allowed.\n\nIf multi-byte codepages are used and file names include non-latin characters, the resulting order may not be exactly alphabetic. If the same wordform definition is found in multiple files, the latter one is used and overrides previous definitions.\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n", + "translations": { + "chinese": "# 词形变换\n\n词形变换在通过[charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table)规则对传入文本进行分词后应用。它们本质上允许你用一个单词替换另一个单词。通常，这用于将不同的词形形式归一为一个标准形式（例如，将所有变体如“walks”、“walked”、“walking”归一为标准形式“walk”）。它也可以用来实现[词干提取](../../Creating_a_table/NLP_and_tokenization/Morphology.md)的例外，因为在词形变换列表中找到的单词不会应用词干提取。\n\n## wordforms\n\nCODE_BLOCK_0\n\n\n\n词形变换字典。可选，默认为空。\n\n词形变换字典用于在建立索引和搜索时规范传入的单词。因此，对于[plain表](../../Creating_a_table/Local_tables/Plain_table.md)来说，需要轮换表以便应用词形变换文件中的更改。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Plain mode example:\n\n\n\nCODE_BLOCK_10\n\n\n\nManticore中的词形变换支持设计为能够良好处理大型字典。它们中等程度地影响索引速度；例如，包含100万个条目的字典会使全文索引速度降低约1.5倍。搜索速度完全不受影响。额外的内存占用大致等于字典文件大小，并且字典在多个表之间共享。例如，如果完全相同的50 MB词形变换文件被指定给10个不同的表，额外的`searchd`内存使用将约为50 MB。\n\n\n\n字典文件应为简单的纯文本格式。每行应包含源词形和目标词形，使用UTF-8编码，并由“greater than”符号分隔。加载文件时将应用[charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table)规则。因此，如果你不修改`charset_table`，词形变换将是大小写不敏感的，类似于你的其他全文索引数据。下面是文件内容的示例：\n\n\n\nCODE_BLOCK_11\n\n\n\n有一个捆绑的工具叫做[Spelldump](../../Miscellaneous_tools.md#spelldump)，帮助你创建Manticore能读取的字典文件格式。该工具能够读取以`ispell`或`MySpell`格式的源`.dict`和`.aff`字典文件，这些文件随OpenOffice捆绑提供。\n\n你可以将多个源单词映射到一个目标单词。此过程对词元进行，而非源文本，因此空白和标记的差异会被忽略。\n\n\n\n你可以使用`=>`符号代替`>`。允许添加注释（以`#`开头）。最后，如果一行以波浪号(`~`)开头，词形变换将在形态学处理后应用，而非之前（注意，此情况下仅支持单一的源词和目标词）。\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\n如果需要将`>`、`=`或`~`作为普通字符使用，可以通过在前面加反斜杠(`\\`)进行转义。`>`和`=`均应如此转义。示例：\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\n你可以指定多个目标词元：\n\n\n\nCODE_BLOCK_14\n\n\n\n\n\n你可以指定多个文件，而不仅限于一个。可以使用通配符作为模式，所有匹配的文件将按简单升序处理：\n\n在RT模式中，仅允许绝对路径。\n\n如果使用多字节编码页且文件名包含非拉丁字符，结果顺序可能并非字母排序。如果在多个文件中发现同一个词形变换定义，则以后定义的将覆盖之前的。\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n", + "russian": "# Формы слов\n\nФормы слов применяются после разбиения входящего текста на токены по правилам [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table). Они по сути позволяют заменить одно слово другим. Обычно это используется для приведения разных форм слова к единой нормальной форме (например, для нормализации всех вариантов таких как \"walks\", \"walked\", \"walking\" к нормальной форме \"walk\"). Также это может использоваться для реализации исключений при [стемминге](../../Creating_a_table/NLP_and_tokenization/Morphology.md), поскольку стемминг не применяется к словам, найденным в списке форм.\n\n## wordforms\n\nCODE_BLOCK_0\n\n\n\nСловарь форм слов. Опционально, по умолчанию пустой.\n\nСловари форм слов используются для нормализации входящих слов как при индексации, так и при поиске. Поэтому, когда речь идет о [plain table](../../Creating_a_table/Local_tables/Plain_table.md), требуется ротация таблицы, чтобы применились изменения в файле форм слов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Пример в режиме Plain:\n\n\n\nCODE_BLOCK_10\n\n\n\nПоддержка форм слов в Manticore спроектирована для эффективной работы с большими словарями. Они умеренно влияют на скорость индексации; например, словарь с 1 миллионом записей замедляет полнотекстовую индексацию примерно в 1.5 раза. Скорость поиска при этом не ухудшается. Дополнительное использование RAM примерно равно размеру файла словаря, а словари используются совместно между таблицами. Например, если один и тот же файл форм слов размером 50 МБ задан для 10 разных таблиц, дополнительное потребление оперативной памяти `searchd` составит около 50 МБ.\n\n\n\nФайл словаря должен быть в простом текстовом формате. Каждая строка должна содержать исходную и конечную форму слова в кодировке UTF-8, разделённые знаком больше (>). Правила из [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) применяются при загрузке файла. Следовательно, если вы не изменяете `charset_table`, ваши формы слов будут регистронезависимыми, как и другие полнотекстовые данные. Ниже приведён пример содержимого файла:\n\n\n\nCODE_BLOCK_11\n\n\n\nСуществует утилита [Spelldump](../../Miscellaneous_tools.md#spelldump), которая помогает создавать файл словаря в формате, читаемом Manticore. Утилита может читать исходные файлы словарей `.dict` и `.aff` в форматах `ispell` или `MySpell`, поставляемые с OpenOffice.\n\nВы можете отображать несколько исходных слов на одно целевое. Процесс происходит на уровне токенов, а не исходного текста, так что различия в пробелах и разметке игнорируются.\n\n\n\nВы можете использовать символ `=>` вместо `>`. Также разрешены комментарии (начинающиеся с `#`). Наконец, если строка начинается с тильды (`~`), форма слова будет применена после морфологического анализа, а не до него (обратите внимание, что в таком случае поддерживается только одна исходная и одна конечная форма слова).\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\nЕсли вам нужно использовать `>`, `=` или `~` как обычные символы, их можно экранировать, поставив перед каждым обратный слеш (`\\`). И `>`, и `=` следует экранировать именно так. Вот пример:\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\nМожно указать несколько целевых токенов:\n\n\n\nCODE_BLOCK_14\n\n\n\n\n\nВы можете указать несколько файлов, а не только один. Маски могут использоваться в качестве шаблона, и все подходящие файлы будут обработаны в простом порядке возрастания:\n\nВ режиме RT разрешены только абсолютные пути.\n\nЕсли используются многобайтовые кодировки и в именах файлов есть нелатинские символы, итоговый порядок может быть не совсем алфавитным. Если одно и то же определение формы слова встречается в нескольких файлах, используется последнее, переопределяющее предыдущие.\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md.json b/.translation-cache/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md.json index 73d75cb4a6..baccbbf7c1 100644 --- a/.translation-cache/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md.json +++ b/.translation-cache/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md.json @@ -6,5 +6,13 @@ "russian": "# Добавление правил в таблицу перколяции\n\n\n\nВ [таблице перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) хранятся документы, которые являются правилами запроса перколяции и должны строго соответствовать схеме из четырёх полей:\n\n| поле | тип | описание |\n\n| - | - | - |\n\n| id | bigint | идентификатор правила PQ (если не указан, будет назначен автоматически) |\n\n| query | string | полнотекстовый запрос (может быть пустым), совместимый с [таблицей перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| filters | string | дополнительные фильтры по полям, не являющимся полнотекстовыми (может быть пустым), совместимые с [таблицей перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| tags | string | строка с одним или несколькими тегами, разделёнными запятыми, которые могут использоваться для выборочного отображения/удаления сохранённых запросов |\n\nЛюбые другие имена полей не поддерживаются и вызовут ошибку.\n\n**Внимание:** Вставка/замена правил PQ в формате JSON через SQL не сработает. Другими словами, операторы, специфичные для JSON (`match` и т.п.), будут рассматриваться просто как части текста правила, которые должны совпадать с документами. Если вы предпочитаете синтаксис JSON, используйте HTTP-эндпоинт вместо `INSERT`/`REPLACE`.\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON\n\n\n\nСуществует два способа добавить запрос перколяции в таблицу перколяции:\n\n* Запрос в формате JSON, совместимом с /search, описанном в [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON)\n\nCODE_BLOCK_2\n\n* Запрос в формате SQL, описанном в [синтаксисе запросов search](../../Searching/Filters.md#Queries-in-SQL-format)\n\nCODE_BLOCK_3\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_7\n\n\n\n##### java\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\n## Автоматическое назначение ID\n\nЕсли вы не указываете ID, он будет назначен автоматически. Подробнее об авто-ID можно прочитать [здесь](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### JSON\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n## Отсутствие схемы в SQL\n\nЕсли в SQL-команде `INSERT` опустить схему, ожидаются следующие параметры:\n\n1. ID. Можно использовать `0` в качестве ID, чтобы вызвать автоматическую генерацию ID.\n\n2. Query - полнотекстовый запрос.\n\n3. Tags - строка тегов правила PQ.\n\n4. Filters - дополнительные фильтры по атрибутам.\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n\n\n## Замена правил в таблице PQ\n\nЧтобы заменить существующее правило PQ новым в SQL, просто используйте обычную команду [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md). Существует специальный синтаксис `?refresh=1` для замены правила PQ **определённого в JSON-режиме** через HTTP JSON интерфейс.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n" }, "is_code_or_comment": false + }, + "90dba9eae6a49991dd1ca6e760bd4e398088ff47c2b40898439d7833f02ed072": { + "original": "# Adding rules to a percolate table\n\n\n\nIn a [percolate table](../../Creating_a_table/Local_tables/Percolate_table.md) documents that are percolate query rules are stored and must follow the exact schema of four fields:\n\n| field | type | description |\n\n| - | - | - |\n\n| id | bigint | PQ rule identifier (if omitted, it will be assigned automatically) |\n\n| query | string | Full-text query (can be empty) compatible with the [percolate table](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| filters | string | Additional filters by non-full-text fields (can be empty) compatible with the [percolate table](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| tags | string | A string with one or many comma-separated tags, which may be used to selectively show/delete saved queries |\n\nAny other field names are not supported and will trigger an error.\n\n**Warning:** Inserting/replacing JSON-formatted PQ rules via SQL will not work. In other words, the JSON-specific operators (`match` etc) will be considered just parts of the rule's text that should match with documents. If you prefer JSON syntax, use the HTTP endpoint instead of `INSERT`/`REPLACE`.\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON\n\n\n\nThere are two ways you can add a percolate query into a percolate table:\n\n* Query in JSON /search compatible format, described at [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON)\n\nCODE_BLOCK_2\n\n* Query in SQL format, described at [search query syntax](../../Searching/Filters.md#Queries-in-SQL-format)\n\nCODE_BLOCK_3\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_7\n\n\n\n##### java\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\n## Auto ID provisioning\n\nIf you don't specify an ID, it will be assigned automatically. You can read more about auto-ID [here](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### JSON\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n## No schema in SQL\n\nIn case of omitted schema in SQL `INSERT` command, the following parameters are expected:\n\n1. ID. You can use `0` as the ID to trigger auto-ID generation.\n\n2. Query - Full-text query.\n\n3. Tags - PQ rule tags string.\n\n4. Filters - Additional filters by attributes.\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n## Replacing rules in a PQ table\n\nTo replace an existing PQ rule with a new one in SQL, just use a regular [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md) command. There's a special syntax `?refresh=1` to replace a PQ rule **defined in JSON mode** via the HTTP JSON interface.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n", + "translations": { + "chinese": "# 向 percolate 表添加规则\n\n\n\n在 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) 中，存储了 percolate 查询规则，必须遵循包含四个字段的精确模式：\n\n| 字段 | 类型 | 描述 |\n\n| - | - | - |\n\n| id | bigint | PQ 规则标识符（如果省略，将自动分配） |\n\n| query | string | 全文查询（可为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| filters | string | 通过非全文字段的附加过滤器（可为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| tags | string | 一个包含一个或多个逗号分隔标签的字符串，可用于有选择地显示/删除已保存的查询 |\n\n任何其他字段名不被支持，且会触发错误。\n\n**警告：** 通过 SQL 插入/替换 JSON 格式的 PQ 规则将无法正常工作。换句话说，JSON 特定操作符（如 `match` 等）将被视为规则文本的一部分，应与文档匹配。如果您希望使用 JSON 语法，请使用 HTTP 端点而不是 `INSERT`/`REPLACE`。\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON\n\n\n\n添加 percolate 查询到 percolate 表有两种方式：\n\n* 使用 JSON /search 兼容格式的查询，详见 [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON)\n\nCODE_BLOCK_2\n\n* 使用 SQL 格式的查询，详见 [search query syntax](../../Searching/Filters.md#Queries-in-SQL-format)\n\nCODE_BLOCK_3\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_7\n\n\n\n##### java\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\n## 自动 ID 分配\n\n如果未指定 ID，将自动分配。您可以在[此处](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID)阅读有关自动 ID 的更多信息。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### JSON\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n## SQL 中无模式\n\n如果 SQL `INSERT` 命令中省略了模式，则期望如下参数：\n\n1. ID。您可以使用 `0` 作为 ID 来触发自动生成 ID。\n\n2. Query - 全文查询。\n\n3. Tags - PQ 规则标签字符串。\n\n4. Filters - 通过属性的附加过滤器。\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n## 替换 PQ 表中的规则\n\n要在 SQL 中用新规则替换现有的 PQ 规则，只需使用常规的 [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md) 命令。通过 HTTP JSON 接口替换**以 JSON 模式定义的** PQ 规则，有一个特殊语法 `?refresh=1`。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n", + "russian": "# Добавление правил в таблицу percolate\n\n\n\nВ [таблице percolate](../../Creating_a_table/Local_tables/Percolate_table.md) хранятся документы с правилами перколяции, и они должны строго соответствовать схеме из четырёх полей:\n\n| поле | тип | описание |\n\n| - | - | - |\n\n| id | bigint | Идентификатор правила PQ (если не указан, будет назначен автоматически) |\n\n| query | string | Полнотекстовый запрос (может быть пустым), совместимый с [таблицей percolate](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| filters | string | Дополнительные фильтры по не полнотекстовым полям (может быть пустым), совместимый с [таблицей percolate](../../Creating_a_table/Local_tables/Percolate_table.md) |\n\n| tags | string | Строка с одним или несколькими тегами, разделёнными запятыми, которые могут использоваться для выборочного отображения/удаления сохранённых запросов |\n\nЛюбые другие имена полей не поддерживаются и вызовут ошибку.\n\n**Внимание:** Вставка/замена правил PQ в формате JSON через SQL не сработает. Другими словами, специализированные операторы JSON (`match` и др.) будут рассматриваться просто как части текста правила, с которыми должны совпадать документы. Если вы предпочитаете синтаксис JSON, используйте HTTP-эндпоинт вместо `INSERT`/`REPLACE`.\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON\n\n\n\nСуществует два способа добавить запрос percolate в таблицу percolate:\n\n* Запрос в формате JSON, совместимом с /search, описанном в [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON)\n\nCODE_BLOCK_2\n\n* Запрос в формате SQL, описанный в [синтаксисе поискового запроса](../../Searching/Filters.md#Queries-in-SQL-format)\n\nCODE_BLOCK_3\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_5\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_7\n\n\n\n##### java\n\n\n\nCODE_BLOCK_8\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\n## Автоматическое присвоение ID\n\nЕсли вы не укажете ID, он будет назначен автоматически. Подробнее об авто-ID можно прочитать [здесь](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### JSON\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### PHP\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Python\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python-asyncio\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### java\n\n\n\nCODE_BLOCK_23\n\n\n\n##### C#\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n## Отсутствие схемы в SQL\n\nЕсли схема в SQL-команде `INSERT` опущена, ожидаются следующие параметры:\n\n1. ID. Можно использовать `0` в качестве ID, чтобы инициировать автоматическую генерацию ID.\n\n2. Query — Полнотекстовый запрос.\n\n3. Tags — строка тегов правила PQ.\n\n4. Filters — дополнительные фильтры по атрибутам.\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n## Замена правил в таблице PQ\n\nДля замены существующего правила PQ на новое в SQL просто используйте обычную команду [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md). Существует особый синтаксис `?refresh=1` для замены правила PQ **определённого в JSON-режиме** через HTTP JSON интерфейс.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Data_creation_and_modification/Deleting_documents.md.json b/.translation-cache/Data_creation_and_modification/Deleting_documents.md.json index 900d0b4f9a..af761733b6 100644 --- a/.translation-cache/Data_creation_and_modification/Deleting_documents.md.json +++ b/.translation-cache/Data_creation_and_modification/Deleting_documents.md.json @@ -14,5 +14,21 @@ "russian": "# Удаление документов\n\nУдаление документов поддерживается только в [RT режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode) для следующих типов таблиц:\n\n* [RT](../Creating_a_table/Local_tables/Real-time_table.md) таблицы\n\n* [Percolate](../Creating_a_table/Local_tables/Percolate_table.md) таблицы\n\n* Распределённые таблицы, которые содержат только RT таблицы в качестве локальных или удалённых агентов.\n\nВы можете удалить существующие документы из таблицы, основываясь либо на их ID, либо на определённых условиях.\n\nТакже доступно [массовое удаление](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) для удаления нескольких документов.\n\nУдаление документов можно выполнить как через SQL, так и через JSON интерфейсы.\n\nДля SQL ответ о успешной операции будет содержать количество удалённых строк.\n\nДля JSON используется endpoint `json/delete`. Сервер ответит JSON объектом, указывающим, была ли операция успешной и сколько строк удалено.\n\nРекомендуется использовать [очистку таблицы](../Emptying_a_table.md) вместо удаления для удаления всех документов из таблицы, так как это гораздо более быстрая операция.\n\n\n\nВ этом примере мы удаляем все документы, которые соответствуют полнотекстовому запросу `test document` из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n* `query` для JSON содержит условие полнотекстового поиска; синтаксис такой же, как в [JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON).\n\n\n\nCODE_BLOCK_2\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n\n\nЗдесь — удаление документа с `id`, равным 1, из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n* `id` для JSON — это `id` строки, которую нужно удалить.\n\n\n\nCODE_BLOCK_23\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n\n\nЗдесь удаляются документы с `id`, совпадающими со значениями из таблицы с именем `test`:\n\nОбратите внимание, что формы удаления с `id=N` или `id IN (X,Y)` самые быстрые, так как они удаляют документы без выполнения поиска.\n\nТакже обратите внимание, что ответ содержит только id первого удалённого документа в соответствующем поле `_id`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nManticore SQL позволяет использовать сложные условия для оператора `DELETE`.\n\nНапример, здесь мы удаляем документы, которые соответствуют полнотекстовому запросу `test document` и имеют атрибут `mva1` со значением больше 206 или значения `mva1` равные 100 или 103 из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n\n\nВот пример удаления документов в таблице `test` кластера `cluster`. Обратите внимание, что необходимо указать свойство кластера вместе со свойством таблицы, чтобы удалить строку из таблицы внутри репликационного кластера:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n* `cluster` для JSON — это имя [репликационного кластера](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster), который содержит нужную таблицу\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n" }, "is_code_or_comment": false + }, + "e95ae87d8e137a42ae98c395b7b55f164babc34f158b4101281eaf20ec444b6c": { + "original": "\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n## Bulk deletion\n\n\n\nYou can also perform multiple delete operations in a single call using the `/bulk` endpoint. This endpoint only works with data that has `Content-Type` set to `application/x-ndjson`. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline `\\n` and, possibly, a `\\r`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n\n\n", + "translations": { + "chinese": "\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n## Bulk deletion\n\n\n\nYou can also perform multiple delete operations in a single call using the `/bulk` endpoint. This endpoint only works with data that has `Content-Type` set to `application/x-ndjson`. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline `\\n` and, possibly, a `\\r`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n\n\n", + "russian": "\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n## Bulk deletion\n\n\n\nYou can also perform multiple delete operations in a single call using the `/bulk` endpoint. This endpoint only works with data that has `Content-Type` set to `application/x-ndjson`. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline `\\n` and, possibly, a `\\r`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n\n\n" + }, + "is_code_or_comment": true + }, + "a111231b84be044eb819ac6eb22cdaa404f5a0abcac2cb91e91cb08ef4ea4283": { + "original": "# Deleting documents\n\nDeleting documents is only supported in [RT mode](../Read_this_first.md#Real-time-mode-vs-plain-mode) for the following table types:\n\n* [Real-time](../Creating_a_table/Local_tables/Real-time_table.md) tables\n\n* [Percolate](../Creating_a_table/Local_tables/Percolate_table.md) tables\n\n* Distributed tables that only contain RT tables as local or remote agents.\n\nYou can delete existing documents from a table based on either their ID or certain conditions.\n\nAlso, [bulk deletion](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) is available to delete multiple documents.\n\nDeletion of documents can be accomplished via both SQL and JSON interfaces.\n\nFor SQL, the response for a successful operation will indicate the number of rows deleted.\n\nFor JSON, the `json/delete` endpoint is used. The server will respond with a JSON object indicating whether the operation was successful and the number of rows deleted.\n\nIt is recommended to use [table truncation](../Emptying_a_table.md) instead of deletion to delete all documents from a table, as it is a much faster operation.\n\n\n\nIn this example we delete all documents that match full-text query `test document` from the table named `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n* `query` for JSON contains a clause for a full-text search; it has the same syntax as in the [JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON).\n\n\n\nCODE_BLOCK_2\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n\n\nHere - deleting a document with `id` equalling 1 from the table named `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n* `id` for JSON is the row `id` which should be deleted.\n\n\n\nCODE_BLOCK_23\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n\n\nHere, documents with `id` matching values from the table named `test` are deleted:\n\nNote that the delete forms with `id=N` or `id IN (X,Y)` are the fastest, as they delete documents without performing a search.\n\nAlso note that the response contains only the id of the first deleted document in the corresponding `_id` field.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nManticore SQL allows to use complex conditions for the `DELETE` statement.\n\nFor example here we are deleting documents that match full-text query `test document` and have attribute `mva1` with a value greater than 206 or `mva1` values 100 or 103 from table named `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\nHere is an example of deleting documents in cluster `cluster`'s table `test`. Note that we must provide the cluster name property along with table property to delete a row from a table within a replication cluster:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n* `cluster` for JSON is the name of the [replication cluster](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster). which contains the needed table\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### java:", + "translations": { + "chinese": "# 删除文档\n\n删除文档仅支持在[RT 模式](../Read_this_first.md#Real-time-mode-vs-plain-mode)下，对以下表类型进行：\n\n* [实时](../Creating_a_table/Local_tables/Real-time_table.md) 表\n\n* [Percolate](../Creating_a_table/Local_tables/Percolate_table.md) 表\n\n* 仅包含 RT 表作为本地或远程代理的分布式表。\n\n您可以根据文档的 ID 或某些条件从表中删除现有文档。\n\n另外，[批量删除](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) 可用于删除多个文档。\n\n文档的删除可以通过 SQL 和 JSON 接口来完成。\n\n对于 SQL，成功操作的响应将指示删除的行数。\n\n对于 JSON，使用 `json/delete` 端点。服务器将返回一个 JSON 对象，指示操作是否成功以及删除的行数。\n\n建议使用[表截断](../Emptying_a_table.md)来删除表中的所有文档，因为这是一种更快的操作。\n\n\n\n在此示例中，我们删除了名称为 `test` 的表中所有符合全文查询 `test document` 的文档：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n* JSON 的 `query` 包含全文搜索的条件；其语法与[JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON)中的相同。\n\n\n\nCODE_BLOCK_2\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n\n\n这里 - 删除表 `test` 中 `id` 等于 1 的文档：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n* JSON 的 `id` 是要删除的行的 `id`。\n\n\n\nCODE_BLOCK_23\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n\n\n这里，删除表 `test` 中 `id` 匹配指定值的文档：\n\n注意，形式为 `id=N` 或 `id IN (X,Y)` 的删除是最快的，因为它们在删除文档时不执行搜索。\n\n另外注意，响应中只包含第一个被删除文档的 id ，对应字段为 `_id`。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nManticore SQL 允许对 `DELETE` 语句使用复杂条件。\n\n例如，这里我们删除表 `test` 中符合全文查询 `test document` 且属性 `mva1` 大于 206，或 `mva1` 的值为 100 或 103 的文档：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n这是在集群 `cluster` 的表 `test` 中删除文档的示例。注意我们必须提供集群名称属性以及表属性，才能删除复制集群中的表中的行：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n* JSON 的 `cluster` 是包含所需表的[复制集群](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster)名称。\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### java:", + "russian": "# Удаление документов\n\nУдаление документов поддерживается только в [RT режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode) для следующих типов таблиц:\n\n* [Таблицы Real-time](../Creating_a_table/Local_tables/Real-time_table.md)\n\n* [Таблицы Percolate](../Creating_a_table/Local_tables/Percolate_table.md)\n\n* Распределённые таблицы, содержащие только RT таблицы в качестве локальных или удалённых агентов.\n\nВы можете удалить существующие документы из таблицы на основе их ID или определённых условий.\n\nТакже доступно [массовое удаление](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) для удаления нескольких документов.\n\nУдаление документов может быть выполнено как через SQL, так и через интерфейсы JSON.\n\nДля SQL ответ для успешной операции будет содержать количество удалённых строк.\n\nДля JSON используется endpoint `json/delete`. Сервер ответит JSON-объектом, указывающим, была ли операция успешной, и числом удалённых строк.\n\nРекомендуется использовать [очистку таблицы](../Emptying_a_table.md) вместо удаления для удаления всех документов из таблицы, так как это значительно более быстрая операция.\n\n\n\nВ этом примере мы удаляем все документы, которые соответствуют полнотекстовому запросу `test document` из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n* `query` для JSON содержит условие полнотекстового поиска; синтаксис совпадает с [JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON).\n\n\n\nCODE_BLOCK_2\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n\n\nЗдесь — удаление документа с `id`, равным 1, из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n* `id` для JSON — это ID строки, которую необходимо удалить.\n\n\n\nCODE_BLOCK_23\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n\n\nЗдесь удаляются документы с `id`, совпадающим со значениями из таблицы с именем `test`:\n\nОбратите внимание, что формы удаления с `id=N` или `id IN (X,Y)` являются самыми быстрыми, так как удаляют документы без выполнения поиска.\n\nТакже учтите, что в ответе содержится только id первого удалённого документа в соответствующем поле `_id`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nВ Manticore SQL разрешено использовать сложные условия для оператора `DELETE`.\n\nНапример, здесь мы удаляем документы, которые соответствуют полнотекстовому запросу `test document` и имеют атрибут `mva1` со значением больше 206 или значения `mva1` равны 100 или 103 из таблицы с именем `test`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\nПример удаления документов в таблице `test` кластера `cluster`. Обратите внимание, что необходимо указать свойство кластера вместе с таблицей для удаления строки из таблицы внутри репликационного кластера:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n* `cluster` для JSON — это имя [репликационного кластера](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster), содержащего нужную таблицу\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### java:" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Extensions/FEDERATED.md.json b/.translation-cache/Extensions/FEDERATED.md.json index 2d3818292b..85a1830a64 100644 --- a/.translation-cache/Extensions/FEDERATED.md.json +++ b/.translation-cache/Extensions/FEDERATED.md.json @@ -6,5 +6,13 @@ "russian": "# FEDERATED\n\nС помощью движка MySQL FEDERATED вы можете подключаться к локальному или удалённому экземпляру Manticore из MySQL/MariaDB и выполнять поисковые запросы.\n\n## Использование FEDERATED\n\nНепосредственно запрос Manticore нельзя использовать с движком FEDERATED из-за ограничений FEDERATED и того факта, что Manticore реализует собственный синтаксис, например, оператор [MATCH](../Searching/Full_text_matching/Basic_usage.md).\n\nДля поиска через `FEDERATED` сначала нужно создать таблицу с движком FEDERATED. Запрос Manticore будет включён в столбец `query` в операторе `SELECT`, выполняемом по таблице FEDERATED.\n\n\n\nСоздание таблицы MySQL, совместимой с FEDERATED:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n\n\nЗапрос к таблице, совместимой с FEDERATED:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nЕдинственное фиксированное сопоставление — это столбец `query`. Он обязателен и должен быть единственным столбцом, связанным с таблицей.\n\nТаблица Manticore, связанная через `FEDERATED`, **должна** быть физической таблицей (обычной или реального времени).\n\nТаблица FEDERATED должна иметь столбцы с такими же именами, как атрибуты удалённой таблицы Manticore, поскольку они будут связаны с атрибутами, предоставленными в наборе результатов Manticore по имени. Однако может быть сопоставлена только часть атрибутов, а не все.\n\nСервер Manticore идентифицирует запрос от клиента FEDERATED по имени пользователя \"FEDERATED\". Параметр строки `CONNECTION` используется для указания хоста Manticore, SQL-порта и таблиц для запросов, поступающих через соединение. Синтаксис строки соединения следующий:\n\nCODE_BLOCK_4\n\nПоскольку в Manticore нет понятия базы данных, строка `DB` может быть произвольной, так как она будет игнорироваться Manticore, но MySQL требует значение в определении строки `CONNECTION`. Как видно из примера, полный SQL-запрос `SELECT` должен быть помещён в условие WHERE по столбцу `query`.\n\nПоддерживается только оператор `SELECT`, не поддерживаются `INSERT`, `REPLACE`, `UPDATE` или `DELETE`.\n\n### Советы по FEDERATED\n\nОчень **важно** отметить, что гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и нарезку набора результатов, чем увеличивать максимальное количество совпадений и использовать условия WHERE, ORDER BY и LIMIT на стороне MySQL. Это по двум причинам. Во-первых, Manticore реализует ряд оптимизаций и работает лучше MySQL для этих задач. Во-вторых, меньше данных нужно упаковывать searchd, передавать и распаковывать между Manticore и MySQL.\n\n\n\nJOIN можно выполнять между таблицей FEDERATED и другими таблицами MySQL. Это можно использовать для получения информации, которая не хранится в таблице Manticore.\n\n\n\n##### SQL:\n\n\n\n##### Запрос для объединения таблицы MySQL с таблицей FEDERATED, обслуживаемой Manticore:\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n" }, "is_code_or_comment": false + }, + "e5a9a20abdde45c78a12b2e7e1ec46c111e8082f786df093f7b0dae86592e72a": { + "original": "# FEDERATED\n\nWith the MySQL FEDERATED engine, you can connect to a local or remote Manticore instance from MySQL/MariaDB and perform search queries.\n\n## Using FEDERATED\n\nAn actual Manticore query can't be used directly with the FEDERATED engine and must be \"proxied\" (sent as a string in a column) due to the FEDERATED engine's limitations and the fact that Manticore implements custom syntax like the [MATCH](../Searching/Full_text_matching/Basic_usage.md) clause.\n\nTo search via `FEDERATED`, you first need to create a FEDERATED engine table. The Manticore query will be included in a `query` column in the `SELECT` performed over the FEDERATED table.\n\n\n\nCreating a FEDERATED-compatible MySQL table:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nQuery FEDERATED compatible table:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nThe only fixed mapping is the `query` column. It is mandatory and must be the only column with a table attached.\n\nThe Manticore table linked via `FEDERATED` **must** be a physical table (plain or real-time).\n\nThe FEDERATED table should have columns with the same names as the remote Manticore table attributes since they will be bound to the attributes provided in the Manticore result set by name. However, it might map only some attributes, not all of them.\n\nManticore server identifies a query from a FEDERATED client by the user name \"FEDERATED\". The `CONNECTION` string parameter is used to specify the Manticore host, SQL port, and tables for queries coming through the connection. The connection string syntax is as follows:\n\nCODE_BLOCK_6\n\nSince Manticore doesn't have the concept of a database, the `DB` string can be random as it will be ignored by Manticore, but MySQL requires a value in the `CONNECTION` string definition. As seen in the example, the full `SELECT` SQL query should be placed in a WHERE clause against the `query` column.\n\nOnly the `SELECT` statement is supported, not `INSERT`, `REPLACE`, `UPDATE`, or `DELETE`.\n\n### FEDERATED tips\n\nOne **very important** note is that it is **much** more efficient to allow Manticore to perform sorting, filtering, and slicing the result set than to increase the max matches count and use WHERE, ORDER BY, and LIMIT clauses on the MySQL side. This is for two reasons. First, Manticore implements a number of optimizations and performs better than MySQL for these tasks. Second, less data needs to be packed by searchd, transferred, and unpacked between Manticore and MySQL.\n\n\n\nJOINs can be performed between a FEDERATED table and other MySQL tables. This can be used to retrieve information that is not stored in a Manticore table.\n\n\n\n##### SQL:\n\n\n\n##### Query to JOIN MySQL based table with FEDERATED table served by Manticore:\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n", + "translations": { + "chinese": "# FEDERATED\n\n通过 MySQL 的 FEDERATED 引擎，您可以从 MySQL/MariaDB 连接到本地或远程的 Manticore 实例，并执行搜索查询。\n\n## 使用 FEDERATED\n\n由于 FEDERATED 引擎的限制以及 Manticore 实现了自定义语法如 [MATCH](../Searching/Full_text_matching/Basic_usage.md) 子句，实际的 Manticore 查询不能直接用于 FEDERATED 引擎，必须“代理”（以字符串形式在列中发送）。\n\n要通过 `FEDERATED` 进行搜索，首先需要创建一个 FEDERATED 引擎表。Manticore 查询将作为 `query` 列中的字符串包含在对 FEDERATED 表执行的 `SELECT` 中。\n\n\n\n创建一个兼容 FEDERATED 的 MySQL 表：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\n查询兼容 FEDERATED 的表：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n唯一固定的映射是 `query` 列。它是必需的，并且必须是唯一附带表的列。\n\n通过 `FEDERATED` 关联的 Manticore 表 **必须** 是物理表（普通表或实时表）。\n\nFEDERATED 表应具有与远程 Manticore 表属性同名的列，因为它们将按名称绑定到 Manticore 结果集中提供的属性。但它可能只映射某些属性，而非全部。\n\nManticore 服务器通过用户名 \"FEDERATED\" 识别来自 FEDERATED 客户端的查询。`CONNECTION` 字符串参数用于指定通过该连接进行查询的 Manticore 主机、SQL 端口和表。连接字符串语法如下：\n\nCODE_BLOCK_6\n\n由于 Manticore 没有数据库的概念，`DB` 字符串可以是任意的，因为 Manticore 会忽略它，但 MySQL 需要在 `CONNECTION` 字符串定义中有一个值。如示例所示，完整的 `SELECT` SQL 查询应放置在对 `query` 列的 WHERE 子句中。\n\n仅支持 `SELECT` 语句，不支持 `INSERT`、`REPLACE`、`UPDATE` 或 `DELETE`。\n\n### FEDERATED 提示\n\n有一点 **非常重要**，就是让 Manticore 执行排序、过滤和结果集的切片要 **远** 比增加最大匹配数并在 MySQL 端使用 WHERE、ORDER BY 和 LIMIT 子句更高效。原因有两点。首先，Manticore 实现了多种优化，这些任务的性能优于 MySQL。其次，searchd 需要打包、传输及解包的数据更少，减少了 Manticore 与 MySQL 之间的数据传输。\n\n\n\n可以在 FEDERATED 表与其他 MySQL 表之间执行 JOIN。这可用于检索未存储在 Manticore 表中的信息。\n\n\n\n##### SQL:\n\n\n\n##### 对 MySQL 基础表与由 Manticore 提供服务的 FEDERATED 表执行 JOIN 的查询：\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n", + "russian": "# FEDERATED\n\nС помощью движка MySQL FEDERATED вы можете подключаться к локальному или удалённому экземпляру Manticore из MySQL/MariaDB и выполнять поисковые запросы.\n\n## Использование FEDERATED\n\nНепосредственно запрос Manticore нельзя использовать с движком FEDERATED, его нужно \"проксиировать\" (отправлять в виде строки в столбце) из-за ограничений движка FEDERATED и того, что Manticore использует нестандартный синтаксис, например, оператор [MATCH](../Searching/Full_text_matching/Basic_usage.md).\n\nЧтобы выполнять поиск через `FEDERATED`, сначала нужно создать таблицу с движком FEDERATED. Запрос Manticore будет включён в столбец `query` внутри оператора `SELECT`, выполняемого по таблице FEDERATED.\n\n\n\nСоздание совместимой с FEDERATED таблицы MySQL:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nЗапрос к таблице совместимой с FEDERATED:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nЕдинственное жёсткое сопоставление – это столбец `query`. Он обязателен и должен быть единственным столбцом, к которому привязана таблица.\n\nТаблица Manticore, связанная через `FEDERATED`, **должна** быть физической таблицей (обычной или в режиме реального времени).\n\nТаблица FEDERATED должна содержать столбцы с такими же именами, как атрибуты удалённой таблицы Manticore, так как они будут связаны с атрибутами из результата Manticore по именам. Однако может быть сопоставлена не вся таблица, а лишь некоторые атрибуты.\n\nСервер Manticore идентифицирует запросы от клиента FEDERATED по имени пользователя \"FEDERATED\". Параметр строки `CONNECTION` используется для указания хоста Manticore, SQL-порта и таблиц для запросов, поступающих через соединение. Синтаксис строки подключения следующий:\n\nCODE_BLOCK_6\n\nПоскольку в Manticore нет понятия базы данных, значение `DB` может быть произвольным, так как оно будет игнорироваться Manticore, но MySQL требует, чтобы в строке `CONNECTION` было указано значение. Как показано в примере, полный SQL-запрос `SELECT` должен быть помещён в условие WHERE к столбцу `query`.\n\nПоддерживается только оператор `SELECT`, а не `INSERT`, `REPLACE`, `UPDATE` или `DELETE`.\n\n### Советы по FEDERATED\n\nОчень **важно** понимать, что гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и выборку частей результата, чем увеличивать максимальное число совпадений и использовать WHERE, ORDER BY и LIMIT на стороне MySQL. Это связано с двумя причинами. Во-первых, Manticore реализует множество оптимизаций и работает лучше MySQL для этих задач. Во-вторых, меньше данных передаётся, упаковывается и распаковывается между searchd и MySQL.\n\n\n\nМожно выполнять операции JOIN между таблицей FEDERATED и другими таблицами MySQL. Это позволяет получать информацию, не хранящуюся в таблице Manticore.\n\n\n\n##### SQL:\n\n\n\n##### Запрос, который соединяет таблицу MySQL с таблицей FEDERATED, обслуживаемой Manticore:\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Extensions/SphinxSE.md.json b/.translation-cache/Extensions/SphinxSE.md.json index 1a7ff2c6ca..92bd1a88be 100644 --- a/.translation-cache/Extensions/SphinxSE.md.json +++ b/.translation-cache/Extensions/SphinxSE.md.json @@ -14,5 +14,21 @@ "russian": "# SphinxSE\n\nSphinxSE — это движок хранения MySQL, который можно скомпилировать в серверы MySQL/MariaDB, используя их модульную архитектуру.\n\nНесмотря на своё название, SphinxSE *не* хранит данные самостоятельно. Вместо этого он служит встроенным клиентом, который позволяет серверу MySQL взаимодействовать с `searchd`, выполнять поисковые запросы и получать результаты поиска. Вся индексация и поиск происходят вне MySQL.\n\nНекоторые распространённые применения SphinxSE включают:\n\n* Упрощение переноса приложений MySQL Full-Text Search (FTS) на Manticore;\n\n* Обеспечение использования Manticore с языками программирования, для которых нативные API ещё не доступны;\n\n* Предоставление оптимизаций, когда требуется дополнительная обработка результатов Manticore на стороне MySQL (например, JOIN с оригинальными таблицами документов или дополнительная фильтрация на стороне MySQL).\n\n## Установка SphinxSE\n\nВам потребуется получить исходники MySQL, подготовить их и затем перекомпилировать бинарный файл MySQL. Исходники MySQL (mysql-5.x.yy.tar.gz) можно получить с сайта .\n\n### Компиляция MySQL 5.0.x с SphinxSE\n\n1. скопируйте патч-файл `sphinx.5.0.yy.diff` в директорию с исходниками MySQL и выполните\n\nCODE_BLOCK_0\n\nЕсли нет .diff файла именно для нужной версии: сборки, попробуйте применить .diff с ближайшими номерами версий. Важно, чтобы патч применился без конфликтов.\n\n2. в директории с исходниками MySQL выполните\n\nCODE_BLOCK_1\n\n3. в директории с исходниками MySQL создайте каталог `sql/sphinx` и скопируйте туда все файлы из каталога `mysqlse` исходников Manticore. Пример:\n\nCODE_BLOCK_2\n\n4. настройте MySQL и включите новый движок:\n\nCODE_BLOCK_3\n\n5. соберите и установите MySQL:\n\nCODE_BLOCK_4\n\n### Компиляция MySQL 5.1.x с SphinxSE\n\n1. В директории с исходниками MySQL создайте каталог `storage/sphinx` и скопируйте все файлы из каталога `mysqlse` исходников Manticore в это новое место. Например:\n\nCODE_BLOCK_5\n\n2. В директории с исходниками MySQL выполните:\n\nCODE_BLOCK_6\n\n3. Настройте MySQL и включите движок Manticore:\n\nCODE_BLOCK_7\n\n4. Соберите и установите MySQL:\n\nCODE_BLOCK_8\n\n### Проверка установки SphinxSE\n\n\n\nЧтобы убедиться, что SphinxSE успешно скомпилирован в MySQL, запустите вновь собранный сервер, выполните клиент MySQL и выполните запрос `SHOW ENGINES`. Вы должны увидеть список всех доступных движков. Manticore должен присутствовать, а в столбце \"Support\" должно быть \"YES\":\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n## Использование SphinxSE\n\nДля поиска с помощью SphinxSE необходимо создать специальную \"поисковую таблицу\" с ENGINE=SPHINX, а затем использовать оператор `SELECT` с полнотекстовым запросом, помещённым в условие `WHERE` для колонки запроса.\n\nВот пример оператора создания и поискового запроса:\n\nCODE_BLOCK_11\n\nВ поисковой таблице первые три колонки *должны* иметь следующие типы: `INTEGER UNSIGNED` или `BIGINT` для первой колонки (ID документа), `INTEGER` или `BIGINT` для второй колонки (вес совпадения) и `VARCHAR` или `TEXT` для третьей колонки (ваш запрос). Это сопоставление фиксировано; нельзя пропускать какие-либо из этих трёх обязательных колонок, менять их порядок или типы. Кроме того, колонка запроса должна быть индексирована, а все остальные — не индексированы. Имена колонок игнорируются, поэтому можно использовать любые произвольные имена.\n\nДополнительные колонки должны быть одного из типов: `INTEGER`, `TIMESTAMP`, `BIGINT`, `VARCHAR` или `FLOAT`. Они будут связаны с атрибутами, предоставленными в наборе результатов Manticore по имени, поэтому их имена должны совпадать с именами атрибутов, указанными в `sphinx.conf`. Если в результатах поиска Manticore нет соответствующего имени атрибута, в колонке будут значения `NULL`.\n\nСпециальные \"виртуальные\" имена атрибутов также могут быть связаны с колонками SphinxSE. Для этого используйте `_sph_` вместо `@`. Например, чтобы получить значения виртуальных атрибутов `@groupby`, `@count` или `@distinct`, используйте имена колонок `_sph_groupby`, `_sph_count` или `_sph_distinct` соответственно.\n\nПараметр строки `CONNECTION` используется для указания хоста, порта и таблицы Manticore. Если в `CREATE TABLE` не указана строка подключения, предполагается имя таблицы `*` (т.е. поиск по всем таблицам) и `localhost:9312`. Синтаксис строки подключения следующий:\n\nCODE_BLOCK_12\n\nВы можете изменить строку подключения по умолчанию позже:\n\nCODE_BLOCK_13\n\nТакже эти параметры можно переопределить для каждого запроса.\n\nКак показано в примере, и текст запроса, и параметры поиска должны быть помещены в условие `WHERE` для колонки поискового запроса (т.е. третьей колонки). Опции разделяются точкой с запятой, а имена опций отделяются от значений знаком равенства. Можно указать любое количество опций. Доступные опции:\n\n* query - текст запроса;\n\n* mode - режим сопоставления. Должен быть одним из \"all\", \"any\", \"phrase\", \"boolean\" или \"extended\". По умолчанию \"all\";\n\n* sort - режим сортировки совпадений. Должен быть одним из \"relevance\", \"attr_desc\", \"attr_asc\", \"time_segments\" или \"extended\". Во всех режимах, кроме \"relevance\", после двоеточия требуется имя атрибута (или сортировочное выражение для \"extended\"):\n\nCODE_BLOCK_14\n\n* offset - смещение в наборе результатов; по умолчанию 0;\n\n* limit - количество совпадений для извлечения из набора результатов; по умолчанию 20;\n\n* index - имена таблиц для поиска:\n\nCODE_BLOCK_15\n\n* minid, maxid - минимальный и максимальный ID документа для совпадения;\n\n* weights - список весов, разделённых запятыми, которые будут назначены полнотекстовым полям Manticore:\n\nCODE_BLOCK_16\n\n* filter, !filter - имя атрибута и набор значений для фильтрации, разделённые запятыми:\n\nCODE_BLOCK_17\n\n* range, !range - имя атрибута Manticore (integer или bigint) и минимальное и максимальное значения для фильтрации, разделённые запятыми:\n\nCODE_BLOCK_18\n\n* floatrange, !floatrange - имя атрибута Manticore (с плавающей точкой) и минимальное и максимальное значения для фильтрации, разделённые запятыми:\n\nCODE_BLOCK_19\n\n* maxmatches - максимальное количество совпадений для запроса, как в [опции поиска max_matches](../Searching/Options.md#max_matches):\n\nCODE_BLOCK_20\n\n* cutoff - максимальное допустимое количество совпадений, как в [опции поиска cutoff](../Searching/Options.md#cutoff):\n\nCODE_BLOCK_21" }, "is_code_or_comment": false + }, + "64f6b512213a8174cb24b1d3bb596904fb4872f430dd894a55be0d79aec31699": { + "original": "* maxquerytime - maximum allowed query time (in milliseconds), as in [max_query_time search option](../Searching/Options.md#max_query_time):\n\nCODE_BLOCK_24\n\n* groupby - group-by function and attribute. Read [this](../Searching/Grouping.md#Just-Grouping) about grouping search results:\n\nCODE_BLOCK_25\n\n* groupsort - group-by sorting clause:\n\nCODE_BLOCK_26\n\n* distinct - an attribute to compute [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) for when doing group-by:\n\nCODE_BLOCK_27\n\n* indexweights - comma-separated list of table names and weights to use when searching through several tables:\n\nCODE_BLOCK_28\n\n* fieldweights - comma-separated list of per-field weights that can be used by the ranker:\n\nCODE_BLOCK_29\n\n* comment - a string to mark this query in query log, as in [comment search option](../Searching/Options.md#comment):\n\nCODE_BLOCK_30\n\n* select - a string with expressions to compute:\n\nCODE_BLOCK_31\n\n* host, port - remote `searchd` host name and TCP port, respectively:\n\nCODE_BLOCK_32\n\n* ranker - a ranking function to use with \"extended\" matching mode, as in [ranker](../Searching/Options.md#ranker). Known values are \"proximity_bm25\", \"bm25\", \"none\", \"wordcount\", \"proximity\", \"matchany\", \"fieldmask\", \"sph04\", \"expr:EXPRESSION\" syntax to support expression-based ranker (where EXPRESSION should be replaced with your specific ranking formula), and \"export:EXPRESSION\":\n\nCODE_BLOCK_33\n\nThe \"export\" ranker functions similarly to ranker=expr, but it retains the per-document factor values, while ranker=expr discards them after computing the final `WEIGHT()` value. Keep in mind that ranker=export is intended for occasional use, such as training a machine learning (ML) function or manually defining your own ranking function, and should not be used in actual production. When utilizing this ranker, you'll likely want to examine the output of the `RANKFACTORS()` function, which generates a string containing all the field-level factors for each document.\n\n\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n* geoanchor - geodistance anchor. Learn more about Geo-search [in this section](../Searching/Geo_search.md). Takes 4 parameters, which are the latitude and longitude attribute names, and anchor point coordinates, respectively:\n\nCODE_BLOCK_38\n\nOne **very important** note is that it is **much** more efficient to let Manticore handle sorting, filtering, and slicing the result set, rather than increasing the max matches count and using `WHERE`, `ORDER BY`, and `LIMIT` clauses on the MySQL side. This is due to two reasons. First, Manticore employs a variety of optimizations and performs these tasks better than MySQL. Second, less data would need to be packed by searchd, transferred, and unpacked by SphinxSE.\n\n### Important note about stored fields when using SphinxSE\n\nSince version 5.0.0, Manticore stores all fields by default. When Manticore is used together with MySQL or MariaDB via SphinxSE, storing all fields usually does not make sense because the originals are already stored in MySQL/MariaDB. In such setups it is recommended to explicitly disable stored fields for the involved Manticore table by setting:\n\nCODE_BLOCK_39\n\nSee the setting reference: [stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields).\n\nIf you keep the default (all fields stored) and then select a lot of documents at once through SphinxSE, an internal limit in the engine may be exceeded and you may receive an error like:\n\n\"bad searchd response length\"\n\nSetting `stored_fields =` avoids sending large stored payloads back to MySQL/MariaDB and prevents this error in typical SphinxSE integrations.\n\n### SHOW ENGINE SPHINX STATUS\n\n\n\nYou can obtain additional information related to the query results using the `SHOW ENGINE SPHINX STATUS` statement:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\nYou can also access this information through status variables. Keep in mind that using this method does not require super-user privileges.\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nSphinxSE search tables can be joined with tables using other engines. Here's an example using the \"documents\" table from example.sql:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n## Building snippets via MySQL\n\nSphinxSE also features a UDF function that allows you to create snippets using MySQL. This functionality is similar to [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting), but can be accessed through MySQL+SphinxSE.\n\nThe binary providing the UDF is called `sphinx.so` and should be automatically built and installed in the appropriate location along with SphinxSE. If it doesn't install automatically for some reason, locate `sphinx.so` in the build directory and copy it to your MySQL instance's plugins directory. Once done, register the UDF with the following statement:\n\nCODE_BLOCK_52\n\nThe function name *must* be sphinx_snippets; you cannot use an arbitrary name. The function arguments are as follows:\n\n**Prototype:** function sphinx_snippets ( document, table, words [, options] );\n\nThe document and words arguments can be either strings or table columns. Options must be specified like this: `'value' AS option_name`. For a list of supported options, refer to the [Highlighting section](../Searching/Highlighting.md). The only UDF-specific additional option is called `sphinx` and allows you to specify the searchd location (host and port).\n\nUsage examples:\n\nCODE_BLOCK_53\n\n", + "translations": { + "chinese": "* maxquerytime - 最大允许的查询时间（以毫秒为单位），如同 [max_query_time 搜索选项](../Searching/Options.md#max_query_time):\n\nCODE_BLOCK_24\n\n* groupby - 分组函数和属性。请阅读 [此处](../Searching/Grouping.md#Just-Grouping) 了解分组搜索结果：\n\nCODE_BLOCK_25\n\n* groupsort - 分组排序子句：\n\nCODE_BLOCK_26\n\n* distinct - 在执行分组时计算 [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) 的属性：\n\nCODE_BLOCK_27\n\n* indexweights - 逗号分隔的表名和权重列表，用于搜索多个表时：\n\nCODE_BLOCK_28\n\n* fieldweights - 逗号分隔的每字段权重列表，排名器可以使用：\n\nCODE_BLOCK_29\n\n* comment - 用于在查询日志中标记该查询的字符串，如同 [comment 搜索选项](../Searching/Options.md#comment):\n\nCODE_BLOCK_30\n\n* select - 要计算的表达式字符串：\n\nCODE_BLOCK_31\n\n* host, port - 远程 `searchd` 主机名和 TCP 端口，分别为：\n\nCODE_BLOCK_32\n\n* ranker - 用于“扩展”匹配模式的排名函数，如同 [ranker](../Searching/Options.md#ranker)。已知的值包括 \"proximity_bm25\"、\"bm25\"、\"none\"、\"wordcount\"、\"proximity\"、\"matchany\"、\"fieldmask\"、\"sph04\"、“expr:EXPRESSION” 语法用于支持基于表达式的排名器（其中 EXPRESSION 应替换为你的具体排名公式），以及 \"export:EXPRESSION\"：\n\nCODE_BLOCK_33\n\n\"export\" 排名器功能类似于 ranker=expr，但它保留每个文档的因子值，而 ranker=expr 在计算最终的 `WEIGHT()` 值后会丢弃它们。请记住，ranker=export 旨在偶尔使用，例如训练机器学习（ML）函数或手动定义自己的排名函数，不应在实际生产环境中使用。使用该排名器时，你可能希望检查 `RANKFACTORS()` 函数的输出，它生成包含每个文档所有字段级别因子的字符串。\n\n\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n* geoanchor - 地理距离锚点。请在[本节](../Searching/Geo_search.md)了解更多 Geo 搜索内容。接受四个参数，分别为纬度和经度属性名以及锚点坐标：\n\nCODE_BLOCK_38\n\n一个**非常重要**的注意事项是，让 Manticore 处理排序、过滤和结果集切片比增加最大匹配数并在 MySQL 端使用 `WHERE`、`ORDER BY` 和 `LIMIT` 子句要**高效得多**。原因有二：首先，Manticore 运用多种优化，并能比 MySQL 更好地完成这些任务。其次，searchd 需要打包的数据、传输的数据和 SphinxSE 需要解包的数据都会更少。\n\n### 使用 SphinxSE 时有关存储字段的重要说明\n\n从版本 5.0.0 起，Manticore 默认存储所有字段。当 Manticore 与 MySQL 或 MariaDB 一起通过 SphinxSE 使用时，存储所有字段通常没有意义，因为原始数据已存储在 MySQL/MariaDB 中。在这种配置下，建议通过设置显式禁用相关 Manticore 表的存储字段：\n\nCODE_BLOCK_39\n\n请参阅设置参考：[stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields)。\n\n如果保持默认（存储所有字段）且通过 SphinxSE 一次选择大量文档，可能会超过引擎的内部限制，出现如下错误：\n\n\"bad searchd response length\"\n\n设置 `stored_fields =` 可避免将大量存储的负载返回给 MySQL/MariaDB，并防止此错误在典型的 SphinxSE 集成中出现。\n\n### SHOW ENGINE SPHINX STATUS\n\n\n\n你可以使用 `SHOW ENGINE SPHINX STATUS` 语句获取与查询结果相关的更多信息：\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n你也可以通过状态变量访问这些信息。请注意，使用此方法无需超级用户权限。\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nSphinxSE 搜索表可以与使用其他引擎的表进行连接。以下示例使用 example.sql 中的 \"documents\" 表：\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n## 通过 MySQL 构建摘要片段\n\nSphinxSE 还提供了一个 UDF 函数，允许你通过 MySQL 创建摘要片段。此功能类似于 [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting)，但可通过 MySQL+SphinxSE 访问。\n\n提供此 UDF 的二进制文件名为 `sphinx.so`，应与 SphinxSE 一起自动构建并安装到相应位置。如果因某种原因未自动安装，请在构建目录中找到 `sphinx.so`，并复制到你的 MySQL 实例插件目录。完成后，使用以下语句注册 UDF：\n\nCODE_BLOCK_52\n\n函数名*必须*是 sphinx_snippets；不能使用任意名称。函数参数如下：\n\n**原型：** function sphinx_snippets ( document, table, words [, options] );\n\ndocument 和 words 参数可以是字符串或表列。options 必须以 `'value' AS option_name` 形式指定。支持的选项列表请参照[高亮部分](../Searching/Highlighting.md)。唯一特有的 UDF 额外选项为 `sphinx`，允许指定 searchd 位置（主机和端口）。\n\n使用示例：\n\nCODE_BLOCK_53\n\n", + "russian": "* maxquerytime - максимально допустимое время выполнения запроса (в миллисекундах), как в [опции поиска max_query_time](../Searching/Options.md#max_query_time):\n\nCODE_BLOCK_24\n\n* groupby - функция группировки и атрибут. Подробнее о группировке результатов поиска читайте [здесь](../Searching/Grouping.md#Just-Grouping):\n\nCODE_BLOCK_25\n\n* groupsort - параметр сортировки при группировке:\n\nCODE_BLOCK_26\n\n* distinct - атрибут для вычисления [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) при группировке:\n\nCODE_BLOCK_27\n\n* indexweights - список имён таблиц и весов через запятую для использования при поиске по нескольким таблицам:\n\nCODE_BLOCK_28\n\n* fieldweights - список весов по полям через запятую, которые может использовать ранкер:\n\nCODE_BLOCK_29\n\n* comment - строка для пометки запроса в журнале запросов, как в [опции поиска comment](../Searching/Options.md#comment):\n\nCODE_BLOCK_30\n\n* select - строка с выражениями для вычисления:\n\nCODE_BLOCK_31\n\n* host, port - имя удалённого хоста `searchd` и TCP-порт соответственно:\n\nCODE_BLOCK_32\n\n* ranker - функция ранжирования для использования в режиме \"extended\" соответствия, как в [ranker](../Searching/Options.md#ranker). Известные значения: \"proximity_bm25\", \"bm25\", \"none\", \"wordcount\", \"proximity\", \"matchany\", \"fieldmask\", \"sph04\", синтаксис \"expr:EXPRESSION\" для поддержки ранжирования на основе выражений (где EXPRESSION заменяется вашей конкретной формулой ранжирования), и \"export:EXPRESSION\":\n\nCODE_BLOCK_33\n\nРанкер \"export\" работает аналогично ranker=expr, но сохраняет значения факторов для каждого документа, тогда как ranker=expr отбрасывает их после вычисления итогового значения `WEIGHT()`. Имейте в виду, что ranker=export предназначен для случайного использования, например, для обучения функции машинного обучения (ML) или ручного определения собственной функции ранжирования, и не должен применяться в продакшене. При использовании этого ранкера обычно полезно изучать вывод функции `RANKFACTORS()`, которая генерирует строку со всеми значениями факторов по полям для каждого документа.\n\n\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n* geoanchor - якорь для георасстояния. Подробнее о геопоиске [в этом разделе](../Searching/Geo_search.md). Принимает 4 параметра: имена атрибутов широты и долготы, и координаты якорной точки соответственно:\n\nCODE_BLOCK_38\n\nОчень **важное** замечание: гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и нарезку результата, чем увеличивать количество максимальных совпадений и использовать в MySQL `WHERE`, `ORDER BY` и `LIMIT`. Это связано с двумя причинами. Во-первых, Manticore применяет множество оптимизаций и выполняет эти операции эффективнее, чем MySQL. Во-вторых, меньше данных нужно упаковывать searchd, передавать и распаковывать SphinxSE.\n\n### Важное замечание о сохранённых полях при использовании SphinxSE\n\nНачиная с версии 5.0.0, Manticore по умолчанию сохраняет все поля. Когда Manticore используется вместе с MySQL или MariaDB через SphinxSE, обычно сохранение всех полей не имеет смысла, потому что оригиналы уже хранятся в MySQL/MariaDB. В таких конфигурациях рекомендуется явно отключить сохранение полей для соответствующей таблицы Manticore, задав:\n\nCODE_BLOCK_39\n\nСмотрите справочник по настройке: [stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields).\n\nЕсли вы оставите настройку по умолчанию (сохранять все поля) и выберете много документов через SphinxSE, в движке может быть превышен внутренний лимит, и вы получите ошибку вида:\n\n\"bad searchd response length\"\n\nУстановка `stored_fields =` позволяет избежать передачи больших хранимых данных обратно в MySQL/MariaDB и предотвращает эту ошибку в типичных интеграциях SphinxSE.\n\n### SHOW ENGINE SPHINX STATUS\n\n\n\nВы можете получить дополнительную информацию по результатам запроса с помощью оператора `SHOW ENGINE SPHINX STATUS`:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\nТакже эти данные можно получить через переменные статуса. Учтите, что этот способ не требует привилегий суперпользователя.\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\nТаблицы поиска SphinxSE могут объединяться с таблицами, использующими другие движки. Вот пример с таблицей \"documents\" из example.sql:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n## Создание сниппетов через MySQL\n\nSphinxSE также поддерживает UDF-функцию, которая позволяет создавать сниппеты через MySQL. Эта функциональность похожа на [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting), но доступна через связку MySQL+SphinxSE.\n\nБинарный файл UDF называется `sphinx.so` и должен автоматически собираться и устанавливаться в соответствующем месте вместе с SphinxSE. Если по какой-то причине он не установился автоматически, найдите `sphinx.so` в каталоге сборки и скопируйте его в директорию плагинов вашего MySQL. Затем зарегистрируйте UDF следующей командой:\n\nCODE_BLOCK_52\n\nИмя функции *должно* быть sphinx_snippets; нельзя использовать произвольное имя. Аргументы функции:\n\n**Прототип:** function sphinx_snippets ( document, table, words [, options] );\n\nАргументы document и words могут быть строками или столбцами таблицы. Опции задаются так: `'value' AS option_name`. Список поддерживаемых опций смотрите в [разделе Highlighting](../Searching/Highlighting.md). Единственная дополнительная опция, специфичная для UDF, называется `sphinx` и позволяет указать расположение searchd (хост и порт).\n\nПримеры использования:\n\nCODE_BLOCK_53\n\n" + }, + "is_code_or_comment": false + }, + "b94cc33558e1d665ca20241f44a7ebacd739ec32379e1099993b000c9147ba8a": { + "original": "# SphinxSE\n\nSphinxSE is a MySQL storage engine that can be compiled into MySQL/MariaDB servers using their pluggable architecture.\n\nDespite its name, SphinxSE does *not* actually store any data itself. Instead, it serves as a built-in client that enables the MySQL server to communicate with `searchd`, execute search queries, and retrieve search results. All indexing and searching take place outside MySQL.\n\nSome common SphinxSE applications include:\n\n* Simplifying the porting of MySQL Full-Text Search (FTS) applications to Manticore;\n\n* Enabling Manticore use with programming languages for which native APIs are not yet available;\n\n* Offering optimizations when additional Manticore result set processing is needed on the MySQL side (e.g., JOINs with original document tables or additional MySQL-side filtering).\n\n## Installing SphinxSE\n\nYou will need to obtain a copy of MySQL sources, prepare those, and then recompile MySQL binary. MySQL sources (mysql-5.x.yy.tar.gz) could be obtained from website.\n\n### Compiling MySQL 5.0.x with SphinxSE\n\n1. copy `sphinx.5.0.yy.diff` patch file into MySQL sources directory and run\n\nCODE_BLOCK_0\n\nIf there's no .diff file exactly for the specific version you need to: build, try applying .diff with closest version numbers. It is important that the patch should apply with no rejects.\n\n2. in MySQL sources directory, run\n\nCODE_BLOCK_1\n\n3. in MySQL sources directory, create `sql/sphinx` directory in and copy all files in `mysqlse` directory from Manticore sources there. Example:\n\nCODE_BLOCK_2\n\n4. configure MySQL and enable the new engine:\n\nCODE_BLOCK_3\n\n5. build and install MySQL:\n\nCODE_BLOCK_4\n\n### Compiling MySQL 5.1.x with SphinxSE\n\n1. In the MySQL sources directory, create a `storage/sphinx` directory and copy all files from the `mysqlse` directory in the Manticore sources to this new location. For example:\n\nCODE_BLOCK_5\n\n2. In the MySQL source directory, run:\n\nCODE_BLOCK_6\n\n3. Configure MySQL and enable the Manticore engine:\n\nCODE_BLOCK_7\n\n4. Build and install MySQL:\n\nCODE_BLOCK_8\n\n### Checking SphinxSE installation\n\n\n\nTo verify that SphinxSE has been successfully compiled into MySQL, start the newly built server, run the MySQL client, and issue the `SHOW ENGINES` query. You should see a list of all available engines. Manticore should be present, and the \"Support\" column should display \"YES\":\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n## Using SphinxSE\n\nTo search using SphinxSE, you'll need to create a special ENGINE=SPHINX \"search table\" and then use a `SELECT` statement with the full-text query placed in the `WHERE` clause for the query column.\n\nHere's an example create statement and search query:\n\nCODE_BLOCK_13\n\nIn a search table, the first three columns *must* have the following types: `INTEGER UNSIGNED` or `BIGINT` for the 1st column (document ID), `INTEGER` or `BIGINT` for the 2nd column (match weight), and `VARCHAR` or `TEXT` for the 3rd column (your query). This mapping is fixed; you cannot omit any of these three required columns, move them around, or change their types. Additionally, the query column must be indexed, while all others should remain unindexed. Column names are ignored, so you can use any arbitrary names.\n\nAdditional columns must be either `INTEGER`, `TIMESTAMP`, `BIGINT`, `VARCHAR`, or `FLOAT`. They will be bound to attributes provided in the Manticore result set by name, so their names must match the attribute names specified in `sphinx.conf`. If there's no matching attribute name in the Manticore search results, the column will have `NULL` values.\n\nSpecial \"virtual\" attribute names can also be bound to SphinxSE columns. Use `_sph_` instead of `@` for that purpose. For example, to obtain the values of `@groupby`, `@count`, or `@distinct` virtual attributes, use `_sph_groupby`, `_sph_count`, or `_sph_distinct` column names, respectively.\n\nThe `CONNECTION` string parameter is used to specify the Manticore host, port, and table. If no connection string is specified in `CREATE TABLE`, the table name `*` (i.e., search all tables) and `localhost:9312` are assumed. The connection string syntax is as follows:\n\nCODE_BLOCK_14\n\nYou can change the default connection string later:\n\nCODE_BLOCK_15\n\nYou can also override these parameters on a per-query basis.\n\nAs shown in the example, both the query text and search options should be placed in the `WHERE` clause on the search query column (i.e., the 3rd column). Options are separated by semicolons and their names from values by an equality sign. Any number of options can be specified. The available options are:\n\n* query - query text;\n\n* mode - matching mode. Must be one of \"all\", \"any\", \"phrase\", \"boolean\", or \"extended\". Default is \"all\";\n\n* sort - match sorting mode. Must be one of \"relevance\", \"attr_desc\", \"attr_asc\", \"time_segments\", or \"extended\". In all modes besides \"relevance\", the attribute name (or sorting clause for \"extended\") is also required after a colon:\n\nCODE_BLOCK_16\n\n* offset - offset into the result set; default is 0;\n\n* limit - number of matches to retrieve from the result set; default is 20;\n\n* index - names of the tables to search:\n\nCODE_BLOCK_17\n\n* minid, maxid - min and max document ID to match;\n\n* weights - comma-separated list of weights to be assigned to Manticore full-text fields:\n\nCODE_BLOCK_18\n\n* filter, !filter - comma-separated attribute name and a set of values to match:\n\nCODE_BLOCK_19\n\n* range, !range - comma-separated (integer or bigint) Manticore attribute name, and min and max values to match:\n\nCODE_BLOCK_20\n\n* floatrange, !floatrange - comma-separated (floating point) Manticore attribute name, and min and max values to match:\n\nCODE_BLOCK_21\n\n* maxmatches - maxmatches - per-query max matches value, as in [max_matches search option](../Searching/Options.md#max_matches):\n\nCODE_BLOCK_22\n\n* cutoff - maximum allowed matches, as in [cutoff search option](../Searching/Options.md#cutoff):\n\nCODE_BLOCK_23", + "translations": { + "chinese": "# SphinxSE\n\nSphinxSE 是一种 MySQL 存储引擎，可以通过 MySQL/MariaDB 服务器的可插拔架构编译进去。\n\n尽管名字叫 SphinxSE，但它*并不*实际存储任何数据。它充当内置客户端，使 MySQL 服务器能够与 `searchd` 通信，执行搜索查询并检索搜索结果。所有索引和搜索都发生在 MySQL 之外。\n\n一些常见的 SphinxSE 应用包括：\n\n* 简化将 MySQL 全文搜索 (FTS) 应用移植到 Manticore 的过程；\n\n* 使尚无原生 API 的编程语言能够使用 Manticore；\n\n* 在 MySQL 端需要额外的 Manticore 结果集处理（例如与原始文档表 JOIN 或额外的 MySQL 端过滤）时提供优化。\n\n## 安装 SphinxSE\n\n你需要获得 MySQL 源代码，准备好后重新编译 MySQL 二进制文件。MySQL 源代码（mysql-5.x.yy.tar.gz）可以从 网站下载。\n\n### 使用 SphinxSE 编译 MySQL 5.0.x\n\n1. 将 `sphinx.5.0.yy.diff` 补丁文件复制到 MySQL 源代码目录并运行\n\nCODE_BLOCK_0\n\n如果没有针对特定版本的 .diff 文件，尝试应用版本号最接近的 .diff 文件。补丁必须无拒绝地应用成功。\n\n2. 在 MySQL 源代码目录运行\n\nCODE_BLOCK_1\n\n3. 在 MySQL 源代码目录中，创建 `sql/sphinx` 目录并将 Manticore 源代码中的 `mysqlse` 目录所有文件复制到该目录。示例：\n\nCODE_BLOCK_2\n\n4. 配置 MySQL 并启用新引擎：\n\nCODE_BLOCK_3\n\n5. 编译并安装 MySQL：\n\nCODE_BLOCK_4\n\n### 使用 SphinxSE 编译 MySQL 5.1.x\n\n1. 在 MySQL 源代码目录中创建 `storage/sphinx` 目录，并将 Manticore 源代码的 `mysqlse` 目录里所有文件复制到此新位置。例如：\n\nCODE_BLOCK_5\n\n2. 在 MySQL 源代码目录运行：\n\nCODE_BLOCK_6\n\n3. 配置 MySQL 并启用 Manticore 引擎：\n\nCODE_BLOCK_7\n\n4. 编译并安装 MySQL：\n\nCODE_BLOCK_8\n\n### 检查 SphinxSE 安装\n\n\n\n要验证 SphinxSE 是否成功编译进 MySQL，启动新构建的服务器，运行 MySQL 客户端，发出 `SHOW ENGINES` 查询。你应该看到所有可用引擎的列表。Manticore 应该在其中，且 \"Support\" 列显示为 \"YES\"：\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n## 使用 SphinxSE\n\n要使用 SphinxSE 进行搜索，需要创建一个特殊的 ENGINE=SPHINX “搜索表”，然后对查询列使用带全文查询的 `WHERE` 子句的 `SELECT` 语句。\n\n以下是示例建表语句和搜索查询：\n\nCODE_BLOCK_13\n\n在搜索表中，前三列*必须*具有以下类型：第1列（文档ID）为 `INTEGER UNSIGNED` 或 `BIGINT`，第2列（匹配权重）为 `INTEGER` 或 `BIGINT`，第3列（查询文本）为 `VARCHAR` 或 `TEXT`。此映射固定；不能省略这三列中的任何一列，不能调整顺序，也不能更改类型。此外，查询列必须被索引，其它列应保持未索引。列名被忽略，因此可以使用任意名称。\n\n额外的列必须是 `INTEGER`、`TIMESTAMP`、`BIGINT`、`VARCHAR` 或 `FLOAT`。它们将按照名称绑定到 Manticore 结果集中提供的属性，因此它们的名称必须与 `sphinx.conf` 中指定的属性名称匹配。如果 Manticore 搜索结果中没有匹配的属性名称，该列的值为 `NULL`。\n\n特殊的“虚拟”属性名称也可以绑定到 SphinxSE 列。为此使用 `_sph_` 代替 `@`。例如，要获取 `@groupby`、`@count` 或 `@distinct` 虚拟属性的值，分别使用 `_sph_groupby`、`_sph_count` 或 `_sph_distinct` 列名。\n\n`CONNECTION` 字符串参数用于指定 Manticore 的主机、端口和表名。如果 `CREATE TABLE` 中未指定连接字符串，则假定表名为 `*`（即搜索所有表）且连接到 `localhost:9312`。连接字符串语法如下：\n\nCODE_BLOCK_14\n\n你可以稍后更改默认连接字符串：\n\nCODE_BLOCK_15\n\n你也可以针对每次查询覆盖这些参数。\n\n如示例所示，查询文本和搜索选项均应放在搜索查询列（即第3列）的 `WHERE` 子句中。选项用分号分隔，名称和值用等号分隔。可指定任意多个选项。可用选项有：\n\n* query - 查询文本；\n\n* mode - 匹配模式。必须是 \"all\"、\"any\"、\"phrase\"、\"boolean\" 或 \"extended\" 之一。默认是 \"all\"；\n\n* sort - 匹配排序模式。必须是 \"relevance\"、\"attr_desc\"、\"attr_asc\"、\"time_segments\" 或 \"extended\" 之一。除 \"relevance\" 外，其他模式需要在冒号后指定属性名称（或 \"extended\" 的排序子句）：\n\nCODE_BLOCK_16\n\n* offset - 结果集偏移，默认是 0；\n\n* limit - 从结果集中检索的匹配数，默认是 20；\n\n* index - 要搜索的表名列表：\n\nCODE_BLOCK_17\n\n* minid, maxid - 要匹配的最小和最大文档ID；\n\n* weights - 分配给 Manticore 全文字段的权重逗号列表：\n\nCODE_BLOCK_18\n\n* filter, !filter - 逗号分隔的属性名及匹配值集合：\n\nCODE_BLOCK_19\n\n* range, !range - 逗号分隔的（整数或 bigint）Manticore 属性名，以及最小和最大匹配值：\n\nCODE_BLOCK_20\n\n* floatrange, !floatrange - 逗号分隔的（浮点）Manticore 属性名，以及最小和最大匹配值：\n\nCODE_BLOCK_21\n\n* maxmatches - 每次查询的最大匹配数，详见 [max_matches 搜索选项](../Searching/Options.md#max_matches)：\n\nCODE_BLOCK_22\n\n* cutoff - 最大允许匹配数，详见 [cutoff 搜索选项](../Searching/Options.md#cutoff)：\n\nCODE_BLOCK_23", + "russian": "# SphinxSE\n\nSphinxSE — это движок хранения MySQL, который можно скомпилировать в серверы MySQL/MariaDB с использованием их архитектуры с плагинами.\n\nНесмотря на своё название, SphinxSE *не* хранит данные самостоятельно. Вместо этого он служит встроенным клиентом, позволяющим серверу MySQL взаимодействовать с `searchd`, выполнять поисковые запросы и получать результаты поиска. Всё индексирование и поиск происходят вне MySQL.\n\nНекоторые типичные применения SphinxSE включают:\n\n* Упрощение переноса приложений MySQL Full-Text Search (FTS) на Manticore;\n\n* Возможность использования Manticore с языками программирования, для которых нативные API ещё не доступны;\n\n* Предоставление оптимизаций при необходимости дополнительной обработки результатов Manticore на стороне MySQL (например, JOIN с таблицами оригинальных документов или дополнительная фильтрация на стороне MySQL).\n\n## Установка SphinxSE\n\nВам потребуется получить исходники MySQL, подготовить их и затем перекомпилировать бинарный файл MySQL. Исходники MySQL (mysql-5.x.yy.tar.gz) можно получить с сайта .\n\n### Компиляция MySQL 5.0.x с SphinxSE\n\n1. скопируйте патч `sphinx.5.0.yy.diff` в директорию с исходниками MySQL и выполните\n\nCODE_BLOCK_0\n\nЕсли нет .diff файла именно для версии, которую нужно собрать, попробуйте применить .diff для самой близкой версии. Важно, чтобы патч применился без отклонённых изменений.\n\n2. в директории с исходниками MySQL запустите\n\nCODE_BLOCK_1\n\n3. в директории с исходниками MySQL создайте папку `sql/sphinx` и скопируйте туда все файлы из папки `mysqlse` из исходников Manticore. Пример:\n\nCODE_BLOCK_2\n\n4. настройте MySQL и включите новый движок:\n\nCODE_BLOCK_3\n\n5. соберите и установите MySQL:\n\nCODE_BLOCK_4\n\n### Компиляция MySQL 5.1.x с SphinxSE\n\n1. В директории с исходниками MySQL создайте каталог `storage/sphinx` и скопируйте туда все файлы из каталога `mysqlse` исходников Manticore. Например:\n\nCODE_BLOCK_5\n\n2. В директории с исходниками MySQL выполните:\n\nCODE_BLOCK_6\n\n3. Настройте MySQL и включите движок Manticore:\n\nCODE_BLOCK_7\n\n4. Соберите и установите MySQL:\n\nCODE_BLOCK_8\n\n### Проверка установки SphinxSE\n\n\n\nЧтобы убедиться, что SphinxSE успешно собран в MySQL, запустите недавно собранный сервер, выполните клиент MySQL и выполните запрос `SHOW ENGINES`. Вы увидите список всех доступных движков. В списке должен присутствовать Manticore с указанным \"Support\" значением \"YES\":\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n## Использование SphinxSE\n\nДля поиска с помощью SphinxSE необходимо создать специальную \"таблицу поиска\" с ENGINE=SPHINX, а затем выполнить `SELECT` с полным текстовым запросом, размещённым в условии `WHERE` для колонки запроса.\n\nПример CREATE-запроса и поискового запроса:\n\nCODE_BLOCK_13\n\nВ таблице поиска первые три столбца *должны* иметь следующие типы: `INTEGER UNSIGNED` или `BIGINT` для первого столбца (id документа), `INTEGER` или `BIGINT` для второго (вес совпадения), и `VARCHAR` или `TEXT` для третьего (текст запроса). Это сопоставление фиксированное; вы не можете пропустить ни один из этих трёх обязательных столбцов, изменять их порядок или типы. Кроме того, колонка с запросом должна быть проиндексирована, а остальные — без индекса. Имена столбцов игнорируются, можно использовать любые имена.\n\nДополнительные столбцы должны иметь типы `INTEGER`, `TIMESTAMP`, `BIGINT`, `VARCHAR` или `FLOAT`. Они будут соответствовать атрибутам из результата Manticore по имени, поэтому их имена должны совпадать с именами атрибутов, указанными в `sphinx.conf`. Если для конкретного столбца нет подходящего атрибута в результатах поиска Manticore, в этом столбце будут `NULL` значения.\n\nСпециальные \"виртуальные\" имена атрибутов также могут быть связаны с колонками SphinxSE. Для этого используйте вместо `@` префикс `_sph_`. Например, чтобы получить значения виртуальных атрибутов `@groupby`, `@count` или `@distinct`, используйте названия колонок `_sph_groupby`, `_sph_count` и `_sph_distinct` соответственно.\n\nПараметр строки `CONNECTION` используется для указания хоста, порта и таблицы Manticore. Если в `CREATE TABLE` параметр соединения не задан, используется имя таблицы `*` (т.е. поиск по всем таблицам) и `localhost:9312`. Синтаксис строки соединения следующий:\n\nCODE_BLOCK_14\n\nПозже строку соединения можно изменить:\n\nCODE_BLOCK_15\n\nТакже эти параметры можно переопределять в каждом конкретном запросе.\n\nКак показано в примере, и текст запроса, и опции поиска должны располагаться в условии `WHERE` по колонке запроса (т.е. третьей колонке). Опции разделяются точкой с запятой, а имя опции и её значение — знаком равенства. Можно указать любое количество опций. Доступные опции:\n\n* query - текст запроса;\n\n* mode - режим сопоставления. Должен быть одним из: \"all\", \"any\", \"phrase\", \"boolean\", или \"extended\". По умолчанию \"all\";\n\n* sort - режим сортировки совпадений. Должен быть одним из: \"relevance\", \"attr_desc\", \"attr_asc\", \"time_segments\" или \"extended\". Во всех режимах кроме \"relevance\" после двоеточия нужно указать имя атрибута (или выражение сортировки для \"extended\"):\n\nCODE_BLOCK_16\n\n* offset - смещение в наборе результатов; по умолчанию 0;\n\n* limit - число совпадений для извлечения из набора; по умолчанию 20;\n\n* index - имена таблиц для поиска:\n\nCODE_BLOCK_17\n\n* minid, maxid - минимальный и максимальный id документа для поиска;\n\n* weights - список весов через запятую для полей полнотекстового анализа Manticore:\n\nCODE_BLOCK_18\n\n* filter, !filter - имя атрибута и набор значений для фильтрации через запятую:\n\nCODE_BLOCK_19\n\n* range, !range - имя атрибута (integer или bigint) и минимальное и максимальное значения для диапазона:\n\nCODE_BLOCK_20\n\n* floatrange, !floatrange - имя атрибута с плавающей точкой и минимальное и максимальное значения для диапазона:\n\nCODE_BLOCK_21\n\n* maxmatches - максимальное число совпадений на запрос, как в [max_matches опции поиска](../Searching/Options.md#max_matches):\n\nCODE_BLOCK_22\n\n* cutoff - максимальное допустимое число совпадений, как в [cutoff опции поиска](../Searching/Options.md#cutoff):\n\nCODE_BLOCK_23" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md.json b/.translation-cache/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md.json index 20177a699d..af93b0b5de 100644 --- a/.translation-cache/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md.json +++ b/.translation-cache/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md.json @@ -6,5 +6,13 @@ "russian": "# Включение и отключение плагинов Buddy\n\nДля упрощения управления плагинами Buddy, особенно при разработке нового или изменении существующего, предоставлены команды включения и отключения плагинов Buddy. Эти команды действуют временно во время выполнения и сбрасываются к значениям по умолчанию после перезапуска демона или выполнения сброса Buddy. Для постоянного отключения плагина его необходимо удалить.\n\nДля включения или отключения плагина требуется полное квалифицированное имя пакета плагина. Чтобы его найти, можно выполнить запрос `SHOW BUDDY PLUGINS` и посмотреть полное квалифицированное имя в поле `package`. Например, плагин `SHOW` имеет полное квалифицированное имя `manticoresoftware/buddy-plugin-show`.\n\n\n\n## ENABLE BUDDY PLUGIN\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `ENABLE BUDDY PLUGIN` требует [Manticore Buddy](../../../Installation/Manticore_Buddy.md). Если команда не работает, убедитесь, что Buddy установлен.\n\nЭта команда повторно активирует ранее отключённый плагин Buddy, позволяя ему снова обрабатывать ваши запросы.\n\n\n\n### Пример\n\n\n\nCODE_BLOCK_1\n\n\n\n\n\n## DISABLE BUDDY PLUGIN\n\nCODE_BLOCK_2\n\nЭта команда деактивирует активный плагин Buddy, предотвращая его обработку дальнейших запросов.\n\n\n\n### Пример\n\n\n\nCODE_BLOCK_3\n\nПосле отключения, если вы попробуете выполнить команду `SHOW QUERIES`, вы получите ошибку, так как плагин отключён.\n\n" }, "is_code_or_comment": false + }, + "e3b949bf825af10dd21af1e6d8b4c0ef5877b2c55633078cfa0b1b58c3fcf59a": { + "original": "# Enabling and disabling Buddy plugins\n\nTo simplify the control of Buddy plugins, especially when developing a new one or modifying an existing one, the enable and disable Buddy plugin commands are provided. These commands act temporarily during runtime and will reset to their defaults after restarting the daemon or performing a Buddy reset. To permanently disable a plugin, it must be removed.\n\nYou need the fully qualified package name of the plugin to enable or disable it. To find it, you can run the `SHOW BUDDY PLUGINS` query and look for the full qualified name in the `package` field. For example, the `SHOW` plugin has the fully qualified name `manticoresoftware/buddy-plugin-show`.\n\n\n\n## ENABLE BUDDY PLUGIN\n\nCODE_BLOCK_0\n\n> NOTE: `ENABLE BUDDY PLUGIN` requires [Manticore Buddy](../../../Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\nThis command reactivates a previously disabled Buddy plugin, allowing it to process your requests again.\n\n\n\n### SQL Example\n\n\n\nCODE_BLOCK_1\n\n\n\n### JSON Example\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\n## DISABLE BUDDY PLUGIN\n\nCODE_BLOCK_3\n\nThis command deactivates an active Buddy plugin, preventing it from processing any further requests.\n\n\n\n### SQL Example\n\n\n\nCODE_BLOCK_4\n\n\n\n### JSON Example\n\n\n\nCODE_BLOCK_5\n\nAfter disabling, if you try the `SHOW QUERIES` command, you'll encounter an error because the plugin is disabled.\n\n", + "translations": { + "chinese": "# 启用和禁用 Buddy 插件\n\n为了简化对 Buddy 插件的控制，特别是在开发新插件或修改现有插件时，提供了启用和禁用 Buddy 插件的命令。这些命令在运行时临时生效，重新启动守护进程或执行 Buddy 重置后将恢复默认。要永久禁用插件，必须将其删除。\n\n您需要插件的完全限定包名才能启用或禁用它。要查找它，可以运行 `SHOW BUDDY PLUGINS` 查询，并在 `package` 字段中查找完整限定名称。例如，`SHOW` 插件的完全限定名称是 `manticoresoftware/buddy-plugin-show`。\n\n\n\n## ENABLE BUDDY PLUGIN\n\nCODE_BLOCK_0\n\n> 注意：`ENABLE BUDDY PLUGIN` 需要 [Manticore Buddy](../../../Installation/Manticore_Buddy.md)。如果命令无法执行，请确保已安装 Buddy。\n\n此命令重新激活先前禁用的 Buddy 插件，使其再次处理您的请求。\n\n\n\n### SQL 示例\n\n\n\nCODE_BLOCK_1\n\n\n\n### JSON 示例\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\n## DISABLE BUDDY PLUGIN\n\nCODE_BLOCK_3\n\n此命令停用一个活动的 Buddy 插件，防止其进一步处理任何请求。\n\n\n\n### SQL 示例\n\n\n\nCODE_BLOCK_4\n\n\n\n### JSON 示例\n\n\n\nCODE_BLOCK_5\n\n禁用后，如果尝试执行 `SHOW QUERIES` 命令，将会遇到错误，因为插件已被禁用。\n\n", + "russian": "# Включение и отключение плагинов Buddy\n\nДля упрощения управления плагинами Buddy, особенно при разработке нового или изменении существующего, предоставлены команды включения и отключения плагинов Buddy. Эти команды действуют временно во время выполнения и сбрасываются до настроек по умолчанию после перезапуска демона или выполнения сброса Buddy. Для постоянного отключения плагина его необходимо удалить.\n\nДля включения или отключения плагина требуется полное квалифицированное имя пакета плагина. Чтобы его найти, можно выполнить запрос `SHOW BUDDY PLUGINS` и посмотреть полное квалифицированное имя в поле `package`. Например, плагин `SHOW` имеет полное квалифицированное имя `manticoresoftware/buddy-plugin-show`.\n\n\n\n## ENABLE BUDDY PLUGIN\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `ENABLE BUDDY PLUGIN` требует [Manticore Buddy](../../../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\nЭта команда повторно активирует ранее отключенный плагин Buddy, позволяя ему снова обрабатывать ваши запросы.\n\n\n\n### Пример SQL\n\n\n\nCODE_BLOCK_1\n\n\n\n### Пример JSON\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\n## DISABLE BUDDY PLUGIN\n\nCODE_BLOCK_3\n\nЭта команда деактивирует активный плагин Buddy, препятствуя его дальнейшей обработке запросов.\n\n\n\n### Пример SQL\n\n\n\nCODE_BLOCK_4\n\n\n\n### Пример JSON\n\n\n\nCODE_BLOCK_5\n\nПосле отключения при попытке выполнить команду `SHOW QUERIES` возникнет ошибка, так как плагин отключен.\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Functions/Date_and_time_functions.md.json b/.translation-cache/Functions/Date_and_time_functions.md.json index c30931eea1..7f587f7c56 100644 --- a/.translation-cache/Functions/Date_and_time_functions.md.json +++ b/.translation-cache/Functions/Date_and_time_functions.md.json @@ -14,5 +14,21 @@ "russian": "# Функции даты и времени\n\nОбратите внимание, что `CURTIME()`, `UTC_TIME()`, `UTC_TIMESTAMP()`, и `TIMEDIFF()` могут быть преобразованы в числовые типы с помощью произвольных функций преобразования, таких как `BIGINT()`, `DOUBLE()` и т.д.\n\n### NOW()\n\n\n\nВозвращает текущую метку времени в виде INTEGER.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n### CURTIME()\n\n\n\nВозвращает текущее время в локальном часовом поясе в формате `hh:ii:ss`.\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n### CURDATE()\n\n\n\nВозвращает текущую дату в локальном часовом поясе в формате `YYYY-MM-DD`.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n### UTC_TIME()\n\n\n\nВозвращает текущее время в часовом поясе UTC в формате `hh:ii:ss`.\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n### UTC_TIMESTAMP()\n\n\n\nВозвращает текущее время в часовом поясе UTC в формате `YYYY-MM-DD hh:ii:ss`.\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\n### SECOND()\n\n\n\nВозвращает целочисленное значение секунд (в диапазоне 0..59) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n### MINUTE()\n\n\n\nВозвращает целочисленное значение минут (в диапазоне 0..59) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n### HOUR()\n\n\n\nВозвращает целочисленное значение часов (в диапазоне 0..23) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n### DAY()\n\n\n\nВозвращает целочисленное значение дня месяца (в диапазоне 1..31) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n### MONTH()\n\n\n\nВозвращает целочисленное значение месяца (в диапазоне 1..12) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n### QUARTER()\n\n\n\nВозвращает целочисленное значение квартала года (в диапазоне 1..4) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n### YEAR()\n\n\n\nВозвращает целочисленное значение года (в диапазоне 1969..2038) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n### DAYNAME()\n\n\n\nВозвращает название дня недели для заданного аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n### MONTHNAME()\n\n\n\nВозвращает название месяца для заданного аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n### DAYOFWEEK()\n\n\n\nВозвращает целочисленный индекс дня недели (в диапазоне 1..7) для заданного аргумента метки времени, согласно текущему часовому поясу.\n\nОбратите внимание, что неделя начинается с воскресенья.\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n### DAYOFYEAR()\n\n\n\nВозвращает целочисленное значение дня года (в диапазоне 1..366) для заданного аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### YEARWEEK()\n\n\n\nВозвращает целочисленное значение года и код дня первого дня текущей недели (в диапазоне 1969001..2038366) для заданного аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n### YEARMONTH()\n\n\n\nВозвращает целочисленное значение года и месяца (в диапазоне 196912..203801) из аргумента метки времени, согласно текущему часовому поясу.\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### YEARMONTHDAY()\n\n\n\nВозвращает целочисленное значение года, месяца и дня (в диапазоне от 19691231 до 20380119) на основе текущего часового пояса.\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n### TIMEDIFF()\n\n\n\nВычисляет разницу между двумя метками времени в формате `hh:ii:ss`.\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n### DATEDIFF()\n\n\n\nВычисляет количество дней между двумя заданными метками времени.\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n### DATE()\n\n\n\nФорматирует часть даты из аргумента метки времени в строку в формате `YYYY-MM-DD`.\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n### TIME()\n\n\n\nФорматирует часть времени из аргумента метки времени в строку в формате `HH:MM:SS`.\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n### DATE_FORMAT()\n\n\n\nВозвращает отформатированную строку на основе предоставленных аргументов даты и формата. Аргумент формата использует те же спецификаторы, что и функция [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html). Для удобства, вот некоторые распространённые спецификаторы формата:\n\n- `%Y` - Год из четырёх цифр\n\n- `%m` - Двухзначный месяц (01-12)\n\n- `%d` - Двухзначный день месяца (01-31)\n\n- `%H` - Двухзначный час (00-23)\n\n- `%M` - Двухзначная минута (00-59)\n\n- `%S` - Двухзначная секунда (00-59)\n\n- `%T` - Время в 24-часовом формате (`%H:%M:%S`)" }, "is_code_or_comment": false + }, + "ce6372165ce562b0876d72484c6e5ba78a235cbd0dc705fe764a0a43a93c77e2": { + "original": "\n\nCalculates the difference between two timestamps in the format `hh:ii:ss`.\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n### DATEDIFF()\n\n\n\nCalculates the number of days between two given timestamps.\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n### DATE()\n\n\n\nFormats the date part from a timestamp argument as a string in `YYYY-MM-DD` format.\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n### TIME()\n\n\n\nFormats the time part from a timestamp argument as a string in `HH:MM:SS` format.\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n### DATE_FORMAT()\n\n\n\nReturns a formatted string based on the provided date and format arguments. The format argument uses the same specifiers as the [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) function. For convenience, here are some common format specifiers:\n\n- `%Y` - Four-digit year\n\n- `%m` - Two-digit month (01-12)\n\n- `%d` - Two-digit day of the month (01-31)\n\n- `%H` - Two-digit hour (00-23)\n\n- `%M` - Two-digit minute (00-59)\n\n- `%S` - Two-digit second (00-59)\n\n- `%T` - Time in 24-hour format (`%H:%M:%S`)\n\nNote that this is not a complete list of the specifiers. Please consult the documentation for `strftime()` for your operating system to get the full list.\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nThis example formats the current date and time, displaying the four-digit year and the time in 24-hour format.\n\n### DATE_HISTOGRAM()\n\n\n\n`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` Takes a bucket size as a unit name and returns the bucket number for the value. Values are rounded to the closest bucket. The key function is:\n\nCODE_BLOCK_96\n\nIntervals can be specified using a unit name, like `week`, or as a single unit, such as `1M`. However, multiple units, like `2d`, are not supported with `calendar_interval` but are allowed with `fixed_interval`.\n\nThe valid intervals for `calendar_interval` are:\n\n- `minute`, `1m`\n\n- `hour`, `1h`\n\n- `day`, `1d`\n\n- `week`, `1w` (a week is the interval between the start day of the week, hour, minute, second and the next week but the same day and time of the week)\n\n- `month`, `1M`\n\n- `year`, `1y` (a year is the interval between the start day of the month, time and the next year but the same day of the month, time)\n\nThe valid intervals for `fixed_interval` are:\n\n- `minute`, `2m`\n\n- `hour`, `3h`\n\n- `day`, `5d`\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_97\n\n### DATE_RANGE()\n\n\n\n`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` takes a set of ranges and returns the bucket number for the value.\n\nThe expression includes the `range_from` value and excludes the `range_to` value for each range. The range can be open - having only the `range_from` or only the `range_to` value.\n\nThe difference between this and the [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) function is that the `range_from` and `range_to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions.\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_98\n\n##### Date math\n\nDate math lets you work with dates and times directly in your searches. It's especially useful for handling data that changes over time. With date math, you can easily do things like find entries from a certain period, analyze data trends, or manage when information should be removed. It simplifies working with dates by letting you add or subtract time from a given date, round dates to the nearest time unit, and more, all within your search queries.\n\nTo use date math, you start with a base date, which can be:\n\n- `now` for the current date and time,\n\n- or a specific date string ending with `||`.\n\nThen, you can modify this date with operations like:\n\n- `+1y` to add one year,\n\n- `-1h` to subtract one hour,\n\n- `/m` to round to the nearest month.\n\nYou can use these units in your operations:\n\n- `s` for seconds,\n\n- `m` for minutes,\n\n- `h` (or `H`) for hours,\n\n- `d` for days,\n\n- `w` for weeks,\n\n- `M` for months,\n\n- `y` for years.\n\nHere are some examples of how you might use date math:\n\n- `now+4h` means four hours from now.\n\n- `now-2d/d` is the time two days ago, rounded to the nearest day.\n\n- `2010-04-20||+2M/d` is June 20, 2010, rounded to the nearest day.\n\n", + "translations": { + "chinese": "\n\nCalculates the difference between two timestamps in the format `hh:ii:ss`.\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n### DATEDIFF()\n\n\n\nCalculates the number of days between two given timestamps.\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n### DATE()\n\n\n\nFormats the date part from a timestamp argument as a string in `YYYY-MM-DD` format.\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n### TIME()\n\n\n\nFormats the time part from a timestamp argument as a string in `HH:MM:SS` format.\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n### DATE_FORMAT()\n\n\n\nReturns a formatted string based on the provided date and format arguments. The format argument uses the same specifiers as the [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) function. For convenience, here are some common format specifiers:\n\n- `%Y` - Four-digit year\n\n- `%m` - Two-digit month (01-12)\n\n- `%d` - Two-digit day of the month (01-31)\n\n- `%H` - Two-digit hour (00-23)\n\n- `%M` - Two-digit minute (00-59)\n\n- `%S` - Two-digit second (00-59)\n\n- `%T` - Time in 24-hour format (`%H:%M:%S`)\n\nNote that this is not a complete list of the specifiers. Please consult the documentation for `strftime()` for your operating system to get the full list.\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nThis example formats the current date and time, displaying the four-digit year and the time in 24-hour format.\n\n### DATE_HISTOGRAM()\n\n\n\n`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` Takes a bucket size as a unit name and returns the bucket number for the value. Values are rounded to the closest bucket. The key function is:\n\nCODE_BLOCK_96\n\nIntervals can be specified using a unit name, like `week`, or as a single unit, such as `1M`. However, multiple units, like `2d`, are not supported with `calendar_interval` but are allowed with `fixed_interval`.\n\nThe valid intervals for `calendar_interval` are:\n\n- `minute`, `1m`\n\n- `hour`, `1h`\n\n- `day`, `1d`\n\n- `week`, `1w` (a week is the interval between the start day of the week, hour, minute, second and the next week but the same day and time of the week)\n\n- `month`, `1M`\n\n- `year`, `1y` (a year is the interval between the start day of the month, time and the next year but the same day of the month, time)\n\nThe valid intervals for `fixed_interval` are:\n\n- `minute`, `2m`\n\n- `hour`, `3h`\n\n- `day`, `5d`\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_97\n\n### DATE_RANGE()\n\n\n\n`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` takes a set of ranges and returns the bucket number for the value.\n\nThe expression includes the `range_from` value and excludes the `range_to` value for each range. The range can be open - having only the `range_from` or only the `range_to` value.\n\nThe difference between this and the [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) function is that the `range_from` and `range_to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions.\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_98\n\n##### Date math\n\nDate math lets you work with dates and times directly in your searches. It's especially useful for handling data that changes over time. With date math, you can easily do things like find entries from a certain period, analyze data trends, or manage when information should be removed. It simplifies working with dates by letting you add or subtract time from a given date, round dates to the nearest time unit, and more, all within your search queries.\n\nTo use date math, you start with a base date, which can be:\n\n- `now` for the current date and time,\n\n- or a specific date string ending with `||`.\n\nThen, you can modify this date with operations like:\n\n- `+1y` to add one year,\n\n- `-1h` to subtract one hour,\n\n- `/m` to round to the nearest month.\n\nYou can use these units in your operations:\n\n- `s` for seconds,\n\n- `m` for minutes,\n\n- `h` (or `H`) for hours,\n\n- `d` for days,\n\n- `w` for weeks,\n\n- `M` for months,\n\n- `y` for years.\n\nHere are some examples of how you might use date math:\n\n- `now+4h` means four hours from now.\n\n- `now-2d/d` is the time two days ago, rounded to the nearest day.\n\n- `2010-04-20||+2M/d` is June 20, 2010, rounded to the nearest day.\n\n", + "russian": "\n\nCalculates the difference between two timestamps in the format `hh:ii:ss`.\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n### DATEDIFF()\n\n\n\nCalculates the number of days between two given timestamps.\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n### DATE()\n\n\n\nFormats the date part from a timestamp argument as a string in `YYYY-MM-DD` format.\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n### TIME()\n\n\n\nFormats the time part from a timestamp argument as a string in `HH:MM:SS` format.\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n### DATE_FORMAT()\n\n\n\nReturns a formatted string based on the provided date and format arguments. The format argument uses the same specifiers as the [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) function. For convenience, here are some common format specifiers:\n\n- `%Y` - Four-digit year\n\n- `%m` - Two-digit month (01-12)\n\n- `%d` - Two-digit day of the month (01-31)\n\n- `%H` - Two-digit hour (00-23)\n\n- `%M` - Two-digit minute (00-59)\n\n- `%S` - Two-digit second (00-59)\n\n- `%T` - Time in 24-hour format (`%H:%M:%S`)\n\nNote that this is not a complete list of the specifiers. Please consult the documentation for `strftime()` for your operating system to get the full list.\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nThis example formats the current date and time, displaying the four-digit year and the time in 24-hour format.\n\n### DATE_HISTOGRAM()\n\n\n\n`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` Takes a bucket size as a unit name and returns the bucket number for the value. Values are rounded to the closest bucket. The key function is:\n\nCODE_BLOCK_96\n\nIntervals can be specified using a unit name, like `week`, or as a single unit, such as `1M`. However, multiple units, like `2d`, are not supported with `calendar_interval` but are allowed with `fixed_interval`.\n\nThe valid intervals for `calendar_interval` are:\n\n- `minute`, `1m`\n\n- `hour`, `1h`\n\n- `day`, `1d`\n\n- `week`, `1w` (a week is the interval between the start day of the week, hour, minute, second and the next week but the same day and time of the week)\n\n- `month`, `1M`\n\n- `year`, `1y` (a year is the interval between the start day of the month, time and the next year but the same day of the month, time)\n\nThe valid intervals for `fixed_interval` are:\n\n- `minute`, `2m`\n\n- `hour`, `3h`\n\n- `day`, `5d`\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_97\n\n### DATE_RANGE()\n\n\n\n`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` takes a set of ranges and returns the bucket number for the value.\n\nThe expression includes the `range_from` value and excludes the `range_to` value for each range. The range can be open - having only the `range_from` or only the `range_to` value.\n\nThe difference between this and the [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) function is that the `range_from` and `range_to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions.\n\nUsed in aggregation, `FACET`, and grouping.\n\nExample:\n\nCODE_BLOCK_98\n\n##### Date math\n\nDate math lets you work with dates and times directly in your searches. It's especially useful for handling data that changes over time. With date math, you can easily do things like find entries from a certain period, analyze data trends, or manage when information should be removed. It simplifies working with dates by letting you add or subtract time from a given date, round dates to the nearest time unit, and more, all within your search queries.\n\nTo use date math, you start with a base date, which can be:\n\n- `now` for the current date and time,\n\n- or a specific date string ending with `||`.\n\nThen, you can modify this date with operations like:\n\n- `+1y` to add one year,\n\n- `-1h` to subtract one hour,\n\n- `/m` to round to the nearest month.\n\nYou can use these units in your operations:\n\n- `s` for seconds,\n\n- `m` for minutes,\n\n- `h` (or `H`) for hours,\n\n- `d` for days,\n\n- `w` for weeks,\n\n- `M` for months,\n\n- `y` for years.\n\nHere are some examples of how you might use date math:\n\n- `now+4h` means four hours from now.\n\n- `now-2d/d` is the time two days ago, rounded to the nearest day.\n\n- `2010-04-20||+2M/d` is June 20, 2010, rounded to the nearest day.\n\n" + }, + "is_code_or_comment": true + }, + "0ece6e873b33370c26256c9167fefbeb1bab039cd43cfb1ed151e95966512580": { + "original": "# Date and time functions\n\nNote, that `CURTIME()`, `UTC_TIME()`, `UTC_TIMESTAMP()`, and `TIMEDIFF()` can be promoted to numeric types using arbitrary conversion functions such as `BIGINT()`, `DOUBLE()`, etc.\n\n### NOW()\n\n\n\nReturns the current timestamp as an INTEGER.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n### CURTIME()\n\n\n\nReturns the current time in the local timezone in `hh:ii:ss` format.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n### CURDATE()\n\n\n\nReturns the current date in the local timezone in `YYYY-MM-DD` format.\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n### UTC_TIME()\n\n\n\nReturns the current time in UTC timezone in `hh:ii:ss` format.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n### UTC_TIMESTAMP()\n\n\n\nReturns the current time in UTC timezone in `YYYY-MM-DD hh:ii:ss` format.\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n### SECOND()\n\n\n\nReturns the integer second (in 0..59 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n### MINUTE()\n\n\n\nReturns the integer minute (in 0..59 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n### HOUR()\n\n\n\nReturns the integer hour (in 0..23 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### DAY()\n\n\n\nReturns the integer day of the month (in 1..31 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### MONTH()\n\n\n\nReturns the integer month (in 1..12 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n### QUARTER()\n\n\n\nReturns the integer quarter of the year (in 1..4 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n### YEAR()\n\n\n\nReturns the integer year (in 1969..2038 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n### DAYNAME()\n\n\n\nReturns the weekday name for a given timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n### MONTHNAME()\n\n\n\nReturns the name of the month for a given timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n### DAYOFWEEK()\n\n\n\nReturns the integer weekday index (in 1..7 range) for a given timestamp argument, according to the current timezone.\n\nNote that the week starts on Sunday.\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n### DAYOFYEAR()\n\n\n\nReturns the integer day of the year (in 1..366 range) for a given timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n### YEARWEEK()\n\n\n\nReturns the integer year and the day code of the first day of current week (in 1969001..2038366 range) for a given timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n### YEARMONTH()\n\n\n\nReturns the integer year and month code (in 196912..203801 range) from a timestamp argument, according to the current timezone.\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n### YEARMONTHDAY()\n\n\n\nReturns the integer year, month, and date code (ranging from 19691231 to 20380119) based on the current timezone.\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n### TIMEDIFF()", + "translations": { + "chinese": "# 日期和时间函数\n\n注意，`CURTIME()`、`UTC_TIME()`、`UTC_TIMESTAMP()` 和 `TIMEDIFF()` 可以使用任意转换函数如 `BIGINT()`、`DOUBLE()` 等提升为数值类型。\n\n### NOW()\n\n\n\n返回当前时间戳，格式为 INTEGER。\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n### CURTIME()\n\n\n\n返回本地时区当前时间，格式为 `hh:ii:ss`。\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n### CURDATE()\n\n\n\n返回本地时区当前日期，格式为 `YYYY-MM-DD`。\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n### UTC_TIME()\n\n\n\n返回 UTC 时区当前时间，格式为 `hh:ii:ss`。\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n### UTC_TIMESTAMP()\n\n\n\n返回 UTC 时区当前时间，格式为 `YYYY-MM-DD hh:ii:ss`。\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n### SECOND()\n\n\n\n根据当前时区，从时间戳参数中返回秒整数（范围 0..59）。\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n### MINUTE()\n\n\n\n根据当前时区，从时间戳参数中返回分钟整数（范围 0..59）。\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n### HOUR()\n\n\n\n根据当前时区，从时间戳参数中返回小时整数（范围 0..23）。\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### DAY()\n\n\n\n根据当前时区，从时间戳参数中返回月份中某日的整数（范围 1..31）。\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### MONTH()\n\n\n\n根据当前时区，从时间戳参数中返回月份整数（范围 1..12）。\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n### QUARTER()\n\n\n\n根据当前时区，从时间戳参数中返回年第几季度的整数（范围 1..4）。\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n### YEAR()\n\n\n\n根据当前时区，从时间戳参数中返回年份整数（范围 1969..2038）。\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n### DAYNAME()\n\n\n\n根据当前时区，返回给定时间戳参数对应的星期几名称。\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n### MONTHNAME()\n\n\n\n根据当前时区，返回给定时间戳参数对应的月份名称。\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n### DAYOFWEEK()\n\n\n\n根据当前时区，返回给定时间戳参数对应的星期几索引（范围 1..7）。\n\n注意，周日为一周的第一天。\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n### DAYOFYEAR()\n\n\n\n根据当前时区，返回给定时间戳参数对应的年度中的第几天整数（范围 1..366）。\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n### YEARWEEK()\n\n\n\n根据当前时区，返回给定时间戳参数对应的当前周第一天的年及日代码整数（范围 1969001..2038366）。\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n### YEARMONTH()\n\n\n\n根据当前时区，从时间戳参数返回年和月份代码整数（范围 196912..203801）。\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n### YEARMONTHDAY()\n\n\n\n根据当前时区，返回整数年、月和日代码（范围从 19691231 到 20380119）。\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n### TIMEDIFF()", + "russian": "# Функции даты и времени\n\nОбратите внимание, что `CURTIME()`, `UTC_TIME()`, `UTC_TIMESTAMP()`, и `TIMEDIFF()` могут быть приведены к числовым типам с помощью произвольных функций преобразования, таких как `BIGINT()`, `DOUBLE()` и других.\n\n### NOW()\n\n\n\nВозвращает текущую метку времени в виде INTEGER.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n### CURTIME()\n\n\n\nВозвращает текущее время в локальном часовом поясе в формате `hh:ii:ss`.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n### CURDATE()\n\n\n\nВозвращает текущую дату в локальном часовом поясе в формате `YYYY-MM-DD`.\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n### UTC_TIME()\n\n\n\nВозвращает текущее время в часовом поясе UTC в формате `hh:ii:ss`.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n### UTC_TIMESTAMP()\n\n\n\nВозвращает текущее время в часовом поясе UTC в формате `YYYY-MM-DD hh:ii:ss`.\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n### SECOND()\n\n\n\nВозвращает целую секунду (в диапазоне от 0 до 59) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n### MINUTE()\n\n\n\nВозвращает целую минуту (в диапазоне от 0 до 59) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n### HOUR()\n\n\n\nВозвращает целый час (в диапазоне от 0 до 23) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### DAY()\n\n\n\nВозвращает целый день месяца (в диапазоне от 1 до 31) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### MONTH()\n\n\n\nВозвращает целый месяц (в диапазоне от 1 до 12) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n### QUARTER()\n\n\n\nВозвращает целый квартал года (в диапазоне от 1 до 4) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n### YEAR()\n\n\n\nВозвращает целый год (в диапазоне от 1969 до 2038) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n### DAYNAME()\n\n\n\nВозвращает название дня недели для заданного аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n### MONTHNAME()\n\n\n\nВозвращает название месяца для заданного аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n### DAYOFWEEK()\n\n\n\nВозвращает целочисленный индекс дня недели (в диапазоне от 1 до 7) для заданного аргумента метки времени, в соответствии с текущим часовым поясом.\n\nОбратите внимание, что неделя начинается с воскресенья.\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n### DAYOFYEAR()\n\n\n\nВозвращает целочисленный день года (в диапазоне от 1 до 366) для заданного аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n### YEARWEEK()\n\n\n\nВозвращает целочисленное значение года и кода дня первого дня текущей недели (в диапазоне от 1969001 до 2038366) для заданного аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n### YEARMONTH()\n\n\n\nВозвращает целочисленное значение года и месяца (в диапазоне от 196912 до 203801) из аргумента метки времени, в соответствии с текущим часовым поясом.\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n### YEARMONTHDAY()\n\n\n\nВозвращает целочисленный код года, месяца и дня (в диапазоне от 19691231 до 20380119) на основе текущего часового пояса.\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n### TIMEDIFF()" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Integration/Kafka.md.json b/.translation-cache/Integration/Kafka.md.json index dba7fae7d8..ef7da3e0e3 100644 --- a/.translation-cache/Integration/Kafka.md.json +++ b/.translation-cache/Integration/Kafka.md.json @@ -14,5 +14,21 @@ "russian": "# Синхронизация из Kafka\n\n> ПРИМЕЧАНИЕ: эта функциональность требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\nManticore поддерживает интеграцию с [Apache Kafka](https://kafka.apache.org/) для потокового приема данных в реальном времени через источники Kafka и материализованные представления, что позволяет индексировать и искать данные в реальном времени. В настоящее время поддерживаются и протестированы версии **apache/kafka 3.7.0-4.1.0**.\n\nЧтобы начать, необходимо:\n\n1. **Определить источник:** Указать тему Kafka, из которой Manticore Search будет читать сообщения. Эта настройка включает детали, такие как хост брокера, порт и имя темы.\n\n2. **Настроить таблицу назначения:** Выбрать таблицу реального времени Manticore для хранения входящих данных из Kafka.\n\n3. **Создать материализованное представление:** Настроить материализованное представление (`mv`) для обработки преобразования данных и сопоставления из Kafka в таблицу назначения Manticore Search. Здесь вы определите сопоставления полей, преобразования данных и любые фильтры или условия для входящего потока данных.\n\n## Источник\n\n\n\nКонфигурация `source` позволяет определить `broker`, `topic list`, `consumer group` и структуру сообщений.\n\n#### Схема\n\nОпределите схему, используя типы полей Manticore, такие как `int`, `float`, `text`, `json` и т.д.\n\nCODE_BLOCK_0\n\nВсе ключи схемы нечувствительны к регистру, то есть `Products`, `products` и `PrOdUcTs` считаются одинаковыми. Все они преобразуются в нижний регистр.\n\nЕсли имена ваших полей не соответствуют [синтаксису имен полей](../Creating_a_table/Data_types.md#Field-name-syntax), разрешенному в Manticore Search (например, содержат специальные символы или начинаются с цифр), необходимо определить сопоставление схемы. Например, `$keyName` или `123field` являются допустимыми ключами в JSON, но недопустимыми именами полей в Manticore Search. Если попытаться использовать недопустимые имена полей без правильного сопоставления, Manticore вернет ошибку, и создание источника не удастся.\n\nДля таких случаев используйте следующий синтаксис схемы для сопоставления недопустимых имен полей с допустимыми:\n\nCODE_BLOCK_1\n\nНапример:\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n#### Опции\n\n| Опция | Допустимые значения | Описание |\n\n|-|----------------|---------------------------------------------------------------------------------------------------------------------|\n\n| `type` | `kafka` | Устанавливает тип источника. В настоящее время поддерживается только `kafka` |\n\n| `broker_list` | `host:port [, ...]` | Указывает URL брокеров Kafka |\n\n| `topic_list` | `string [, ...]` | Список тем Kafka для потребления |\n\n| `consumer_group`| `string` | Определяет группу потребителей Kafka, по умолчанию `manticore`. |\n\n| `num_consumers` | `int` | Количество потребителей для обработки сообщений. |\n\n| `partition_list` | `int [, ...]` | Список партиций для чтения [подробнее](../Integration/Kafka.md#Sharding-with-Kafka). |\n\n| `batch` | `int` | Количество сообщений для обработки перед переходом к следующей партии. По умолчанию `100`; в противном случае обрабатывает оставшиеся сообщения по таймауту |\n\n### Таблица назначения\n\n\n\nТаблица назначения — это обычная таблица реального времени, в которой хранятся результаты обработки сообщений Kafka. Эта таблица должна быть определена в соответствии с требованиями схемы входящих данных и оптимизирована для производительности запросов вашего приложения. Подробнее о создании таблиц реального времени читайте [здесь](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n### Материализованное представление\n\n\n\nМатериализованное представление позволяет преобразовывать данные из сообщений Kafka. Вы можете переименовывать поля, применять функции Manticore Search, выполнять сортировку, группировку и другие операции с данными.\n\nМатериализованное представление действует как запрос, который перемещает данные из источника Kafka в таблицу назначения, позволяя использовать синтаксис Manticore Search для настройки этих запросов. Убедитесь, что поля в `select` соответствуют полям источника.\n\nCODE_BLOCK_7\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nДанные передаются из Kafka в Manticore Search партиями, которые очищаются после каждого запуска. Для вычислений по партиям, таких как AVG, будьте осторожны, так как они могут работать не так, как ожидается, из-за обработки по партиям.\n\n### Сопоставление полей\n\nВот таблица сопоставления на основе приведенных выше примеров:\n\n| Kafka | Источник | Буфер | MV | Назначение |\n\n|-----------------|----------|----------|-----------------------------------|-------------|\n\n| `id` | `id` | `id` | `id` | `id` |\n\n| `term` | `term` | `term` | `term as name` | `name` |\n\n| `unnecessary_key`, который нас не интересует | - | - | | |\n\n| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name` |\n\n| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at` |\n\n| `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` |\n\n### Просмотр\n\n\n\nДля просмотра источников и материализованных представлений в Manticore Search используйте следующие команды:\n\n- `SHOW SOURCES`: Показывает все настроенные источники.\n\n- `SHOW MVS`: Показывает все материализованные представления." }, "is_code_or_comment": false + }, + "fb9bb2680a266c49890945c928fa34de860abb8665acb9896f18b4d1000a3c4b": { + "original": "| `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` |\n\n### Listing\n\n\n\nTo view sources and materialized views in Manticore Search, use these commands:\n\n- `SHOW SOURCES`: Lists all configured sources.\n\n- `SHOW MVS`: Lists all materialized views.\n\n- `SHOW MV view_table`: Shows detailed information on a specific materialized view.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### Altering materialized views\n\n\n\nYou can suspend data consumption by altering materialized views.\n\nIf you remove the `source` without deleting the MV, it automatically suspends. After recreating the source, unsuspend the MV manually using the `ALTER` command.\n\nCurrently, only materialized views can be altered. To change `source` parameters, drop and recreate the source.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### Sharding with Kafka\n\nYou can also specify a `partition_list` for each Kafka topic.\n\nOne of the main benefits of this approach is the ability to implement `sharding` for your table via Kafka.\n\nTo achieve this, you should create a separate chain of `source` → `materialized view` → `destination table` for each shard:\n\n**Sources:**\n\nCODE_BLOCK_36\n\n**Destination Tables:**\n\nCODE_BLOCK_37\n\n**Materialized Views:**\n\nCODE_BLOCK_38\n\n#### ⚠️ Important Notes:\n\n* In this setup, rebalancing must be managed manually.\n\n* Kafka does not distribute messages using a round-robin strategy by default.\n\n* To achieve round-robin-like distribution when sending data, make sure your Kafka producer is configured with:\n\n * `parse.key=true`\n\n * `key.separator={your_delimiter}`\n\nOtherwise, Kafka will distribute messages based on its own internal rules, which may lead to uneven partitioning.\n\n### Troubleshooting\n\n#### Duplicate entries\n\nKafka offsets commit after each batch or when processing times out. If the process stops unexpectedly during a materialized view query, you may see duplicate entries. To avoid this, include an `id` field in your schema, allowing Manticore Search to prevent duplicates in the table.\n\n### How it works internally\n\n- **Worker initialization:** After configuring a source and materialized view, Manticore Search sets up a dedicated worker to handle data ingestion from Kafka.\n\n- **Message mapping:** Messages are mapped according to the source configuration schema, transforming them into a structured format.\n\n- **Batching:** Messages are grouped into batches for efficient processing. Batch size can be adjusted to suit your performance and latency needs.\n\n- **Buffering:** Mapped data batches are stored in a buffer table for efficient bulk operations.\n\n- **Materialized view processing:** The view logic is applied to data in the buffer table, performing any transformations or filtering.\n\n- **Data transfer:** Processed data is then transferred to the destination real-time table.\n\n- **Cleanup:** The buffer table is cleared after each batch, ensuring it’s ready for the next set of data.\n\n", + "translations": { + "chinese": "| `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` |\n\n### 列表\n\n\n\n要查看 Manticore Search 中的源和物化视图，请使用以下命令：\n\n- `SHOW SOURCES`：列出所有配置的源。\n\n- `SHOW MVS`：列出所有物化视图。\n\n- `SHOW MV view_table`：显示特定物化视图的详细信息。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### 修改物化视图\n\n\n\n您可以通过修改物化视图来暂停数据消费。\n\n如果您移除 `source` 而不删除物化视图，物化视图会自动暂停。重新创建源后，使用 `ALTER` 命令手动取消暂停物化视图。\n\n目前，只能修改物化视图。要更改 `source` 参数，需要删除并重新创建源。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### Kafka 分片\n\n您也可以为每个 Kafka 主题指定一个 `partition_list`。\n\n这种方法的主要优点之一是可以通过 Kafka 来实现表的 `分片`。\n\n要实现这一点，您应该为每个分片创建一条独立的 `source` → `materialized view` → `destination table` 的链：\n\n**源：**\n\nCODE_BLOCK_36\n\n**目标表：**\n\nCODE_BLOCK_37\n\n**物化视图：**\n\nCODE_BLOCK_38\n\n#### ⚠️ 重要注意事项：\n\n* 在此设置中，必须手动管理重平衡。\n\n* Kafka 默认不使用轮询（round-robin）策略分发消息。\n\n* 要在发送数据时实现类似轮询的分发，请确保您的 Kafka 生产者配置了：\n\n * `parse.key=true`\n\n * `key.separator={your_delimiter}`\n\n否则，Kafka 将根据其内部规则分发消息，可能导致分区不均。\n\n### 故障排查\n\n#### 重复条目\n\nKafka 会在每个批次后或处理超时后提交 offset。如果物化视图查询过程中进程意外停止，可能会看到重复条目。为避免此情况，请在方案中包含 `id` 字段，允许 Manticore Search 防止表中出现重复数据。\n\n### 内部工作原理\n\n- **工作线程初始化：** 在配置好源和物化视图后，Manticore Search 会设置专用工作线程来处理来自 Kafka 的数据摄取。\n\n- **消息映射：** 根据源配置方案映射消息，将其转换为结构化格式。\n\n- **批处理：** 将消息分组为批次以提高处理效率。批次大小可根据性能和延迟需求进行调整。\n\n- **缓冲：** 映射后的数据批次存储在缓冲表中，以支持高效的批量操作。\n\n- **物化视图处理：** 将视图逻辑应用于缓冲表中的数据，执行转换或过滤。\n\n- **数据传输：** 处理后的数据传输到目标实时表。\n\n- **清理：** 每批处理完成后清空缓冲表，准备接收下一批数据。\n\n", + "russian": "| `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` |\n\n### Список\n\n\n\nДля просмотра источников и материализованных представлений в Manticore Search используйте следующие команды:\n\n- `SHOW SOURCES`: Показывает все настроенные источники.\n\n- `SHOW MVS`: Показывает все материализованные представления.\n\n- `SHOW MV view_table`: Показывает подробную информацию о конкретном материализованном представлении.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n### Изменение материализованных представлений\n\n\n\nВы можете приостановить потребление данных, изменив материализованные представления.\n\nЕсли удалить `source`, не удаляя MV, оно автоматически приостанавливается. После воссоздания источника отмените приостановку MV вручную с помощью команды `ALTER`.\n\nВ настоящее время изменять можно только материализованные представления. Чтобы изменить параметры `source`, удалите и создайте источник заново.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n### Шардинг с Kafka\n\nВы также можете указать `partition_list` для каждой темы Kafka.\n\nОдним из основных преимуществ такого подхода является возможность реализовать `sharding` для вашей таблицы через Kafka.\n\nДля этого вы должны создать отдельную цепочку `source` → `materialized view` → `destination table` для каждого шарда:\n\n**Источники:**\n\nCODE_BLOCK_36\n\n**Таблицы назначения:**\n\nCODE_BLOCK_37\n\n**Материализованные представления:**\n\nCODE_BLOCK_38\n\n#### ⚠️ Важные замечания:\n\n* В этой конфигурации балансировка нагрузки должна выполняться вручную.\n\n* Kafka по умолчанию не распределяет сообщения по круговой (round-robin) стратегии.\n\n* Чтобы добиться распределения, похожего на round-robin, при отправке данных, убедитесь, что ваш Kafka producer настроен с:\n\n * `parse.key=true`\n\n * `key.separator={your_delimiter}`\n\nИначе Kafka будет распределять сообщения по своим внутренним правилам, что может привести к неравномерному разбиению по партициям.\n\n### Устранение неполадок\n\n#### Дублирование записей\n\nФиксация offset’ов Kafka происходит после каждой партии или при таймауте обработки. Если процесс прервался неожиданно во время запроса к материализованному представлению, могут появиться дублирующиеся записи. Чтобы избежать этого, добавьте поле `id` в схему, что позволит Manticore Search предотвращать дубликаты в таблице.\n\n### Как это работает внутренне\n\n- **Инициализация рабочего процесса:** После настройки источника и материализованного представления Manticore Search запускает выделенного рабочего для обработки приема данных из Kafka.\n\n- **Отображение сообщений:** Сообщения сопоставляются согласно схеме конфигурации источника, преобразуясь в структурированный формат.\n\n- **Формирование партий:** Сообщения группируются в партии для эффективной обработки. Размер партии можно настраивать в зависимости от требований к производительности и задержке.\n\n- **Буферизация:** Партии отображенных данных сохраняются в буферной таблице для эффективных операций пакетной обработки.\n\n- **Обработка материализованного представления:** К данным в буферной таблице применяется логика представления, выполняются необходимые преобразования и фильтрация.\n\n- **Передача данных:** Обработанные данные передаются в целевую таблицу реального времени.\n\n- **Очистка:** Буферная таблица очищается после каждой партии, готовясь к обработке следующего набора данных.\n\n" + }, + "is_code_or_comment": false + }, + "a898ccb14ec46fb560502ba0fb419a4cf39e07439db7863c7cbb8b7b6f027189": { + "original": "# Syncing from Kafka\n\n> NOTE: this functionality requires [Manticore Buddy](../Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\nManticore supports integration with [Apache Kafka](https://kafka.apache.org/) real-time data ingestion through Kafka sources and materialized views, allowing for real-time data indexing and search. Currently, **apache/kafka versions 3.7.0-4.1.0** are tested and supported.\n\nTo get started, you need to:\n\n1. **Define the source:** Specify the Kafka topic from which Manticore Search will read messages. This setup includes details like the broker’s host, port, and topic name.\n\n2. **Set up the destination table:** Choose a Manticore real-time table to store the incoming Kafka data.\n\n3. **Create a materialized view:** Set up a materialized view (`mv`) to handle data transformation and mapping from Kafka to the destination table in Manticore Search. Here, you’ll define field mappings, data transformations, and any filters or conditions for the incoming data stream.\n\n## Source\n\n\n\nThe `source` configuration allows you to define the `broker`, `topic list`, `consumer group`, and the message structure.\n\n#### Schema\n\nDefine the schema using Manticore field types like `int`, `float`, `text`, `json`, etc.\n\nCODE_BLOCK_0\n\nAll schema keys are case-insensitive, meaning `Products`, `products`, and `PrOdUcTs` are treated the same. They are all converted to lowercase.\n\nIf your field names don't match the [field name syntax](../Creating_a_table/Data_types.md#Field-name-syntax) allowed in Manticore Search (for example, if they contain special characters or start with numbers), you must define a schema mapping. For instance, `$keyName` or `123field` are valid keys in JSON but not valid field names in Manticore Search. If you try to use invalid field names without proper mapping, Manticore will return an error and the source creation will fail.\n\nTo handle such cases, use the following schema syntax to map invalid field names to valid ones:\n\nCODE_BLOCK_1\n\nFor example:\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n#### Options\n\n| Option | Accepted Values | Description |\n\n|-|----------------|---------------------------------------------------------------------------------------------------------------------|\n\n| `type` | `kafka` | Sets the source type. Currently, only `kafka` is supported |\n\n| `broker_list` | `host:port [, ...]` | Specifies Kafka broker URLs |\n\n| `topic_list` | `string [, ...]` | Lists Kafka topics to consume from |\n\n| `consumer_group`| `string` | Defines the Kafka consumer group, defaulting to `manticore`. |\n\n| `num_consumers` | `int` | Number of consumers to handle messages. |\n\n| `partition_list` | `int [, ...]` | List of partitions for reading [more](../Integration/Kafka.md#Sharding-with-Kafka). |\n\n| `batch` | `int` | Number of messages to process before moving on. Default is `100`; processes remaining messages on timeout otherwise |\n\n### Destination table\n\n\n\nThe destination table is a regular real-time table where the results of Kafka message processing are stored. This table should be defined to match the schema requirements of the incoming data and optimized for the query performance needs of your application. Read more about creating real-time tables [here](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### Materialized view\n\n\n\nA materialized view enables data transformation from Kafka messages. You can rename fields, apply Manticore Search functions, and perform sorting, grouping, and other data operations.\n\nA materialized view acts as a query that moves data from the Kafka source to the destination table, letting you use Manticore Search syntax to customize these queries. Make sure that fields in the `select` match those in the source.\n\nCODE_BLOCK_11\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nData is transferred from Kafka to Manticore Search in batches, which are cleared after each run. For calculations across batches, such as AVG, use caution, as these may not work as expected due to batch-by-batch processing.\n\n### Field Mapping\n\nHere's a mapping table based on the examples above:\n\n| Kafka | Source | Buffer | MV | Destination |\n\n|-----------------|----------|----------|-----------------------------------|-------------|\n\n| `id` | `id` | `id` | `id` | `id` |\n\n| `term` | `term` | `term` | `term as name` | `name` |\n\n| `unnecessary_key` which we're not interested in | - | - | | |\n\n| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name` |\n\n| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at` |", + "translations": { + "chinese": "# 从 Kafka 同步\n\n> 注意：此功能需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果不起作用，请确保已安装 Buddy。\n\nManticore 支持通过 Kafka 源和物化视图与 [Apache Kafka](https://kafka.apache.org/) 实时数据摄取集成，实现实时数据索引和搜索。目前，**apache/kafka 版本 3.7.0-4.1.0** 已测试并支持。\n\n开始时，您需要：\n\n1. **定义源：** 指定 Manticore Search 将读取消息的 Kafka 主题。此设置包括代理主机、端口和主题名称等详细信息。\n\n2. **设置目标表：** 选择一个 Manticore 实时表用于存储接收到的 Kafka 数据。\n\n3. **创建物化视图：** 设置一个物化视图（`mv`）来处理 Kafka 到 Manticore Search 目标表的数据转换和映射。在这里，您将定义字段映射、数据转换及任何传入数据流的过滤器或条件。\n\n## 源\n\n\n\n`source` 配置允许您定义 `broker`、`topic list`、`consumer group` 以及消息结构。\n\n#### 架构\n\n使用 Manticore 字段类型如 `int`、`float`、`text`、`json` 等定义架构。\n\nCODE_BLOCK_0\n\n所有架构键不区分大小写，这意味着 `Products`、`products` 和 `PrOdUcTs` 被视为相同。它们都会被转换为小写。\n\n如果您的字段名称与 Manticore Search 允许的[字段名称语法](../Creating_a_table/Data_types.md#Field-name-syntax)不匹配（例如，包含特殊字符或以数字开头），您必须定义架构映射。例如，`$keyName` 或 `123field` 是 JSON 中有效的键，但在 Manticore Search 中不是有效的字段名称。如果尝试使用无效字段名称且没有适当映射，则 Manticore 会返回错误并且源创建会失败。\n\n为处理此类情况，请使用以下架构语法将无效字段名称映射为有效名称：\n\nCODE_BLOCK_1\n\n例如：\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n#### 选项\n\n| 选项 | 接受值 | 描述 |\n\n|-|----------------|-------------------------------------------------------------------------------------------------------------|\n\n| `type` | `kafka` | 设置源类型。目前仅支持 `kafka` |\n\n| `broker_list` | `host:port [, ...]`| 指定 Kafka 代理 URL |\n\n| `topic_list` | `string [, ...]` | 列出要消费的 Kafka 主题 |\n\n| `consumer_group` | `string` | 定义 Kafka 消费组，默认为 `manticore`。 |\n\n| `num_consumers` | `int` | 处理消息的消费者数量。 |\n\n| `partition_list` | `int [, ...]` | 读取的分区列表，详见[更多](../Integration/Kafka.md#Sharding-with-Kafka)。 |\n\n| `batch` | `int` | 处理消息数目阈值，处理完后才继续。默认是 `100`；超时则处理剩余消息。 |\n\n### 目标表\n\n\n\n目标表是一个常规的实时表，用于存储 Kafka 消息处理的结果。该表应根据传入数据的架构需求定义，并针对应用查询性能需求进行优化。关于创建实时表请阅读[这里](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:)。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### 物化视图\n\n\n\n物化视图支持对 Kafka 消息进行数据转换。您可以重命名字段，应用 Manticore Search 函数，执行排序、分组及其他数据操作。\n\n物化视图作为从 Kafka 源到目标表的数据转移查询，允许您使用 Manticore Search 语法自定义这些查询。请确保 `select` 中的字段与源中的字段匹配。\n\nCODE_BLOCK_11\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n数据以批处理方式从 Kafka 传输到 Manticore Search，批次在每次运行后被清空。进行跨批次计算（如 AVG）时请谨慎，因为批次逐批处理可能导致结果不符合预期。\n\n### 字段映射\n\n以下是基于上述示例的映射表：\n\n| Kafka | 源 | 缓冲区 | 物化视图 | 目标表 |\n\n|------------------------|--------------|----------------|---------------------------------|--------------|\n\n| `id` | `id` | `id` | `id` | `id` |\n\n| `term` | `term` | `term` | `term as name` | `name` |\n\n| `unnecessary_key`（我们不感兴趣的字段） | - | - | | |\n\n| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name` |\n\n| - | - | - | `UTC_TIMESTAMP() as received_at`| `received_at`|", + "russian": "# Синхронизация из Kafka\n\n> ПРИМЕЧАНИЕ: эта функциональность требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\nManticore поддерживает интеграцию с [Apache Kafka](https://kafka.apache.org/) для потокового сбора данных через Kafka источники и материализованные представления, позволяя индексировать и искать данные в реальном времени. В настоящее время тестируются и поддерживаются версии **apache/kafka 3.7.0-4.1.0**.\n\nЧтобы начать, вам нужно:\n\n1. **Определить источник:** Указать Kafka-топик, из которого Manticore Search будет считывать сообщения. В настройках указываются такие параметры, как хост брокера, порт и имя топика.\n\n2. **Настроить целевую таблицу:** Выбрать таблицу типа real-time Manticore для хранения данных, поступающих из Kafka.\n\n3. **Создать материализованное представление:** Настроить материализованное представление (`mv`) для обработки трансформации данных и сопоставления из Kafka в целевую таблицу Manticore Search. Здесь вы определяете поля, преобразования данных и любые фильтры или условия для входящего потока данных.\n\n## Источник\n\n\n\nКонфигурация `source` позволяет определить `broker`, `topic list`, `consumer group` и структуру сообщений.\n\n#### Схема\n\nОпределите схему, используя типы полей Manticore, такие как `int`, `float`, `text`, `json` и т.д.\n\nCODE_BLOCK_0\n\nВсе ключи схемы нечувствительны к регистру, то есть `Products`, `products` и `PrOdUcTs` считаются одинаковыми. Они все преобразуются в нижний регистр.\n\nЕсли имена полей не соответствуют [синтаксису имён полей](../Creating_a_table/Data_types.md#Field-name-syntax), допустимому в Manticore Search (например, содержат специальные символы или начинаются с цифр), необходимо определить маппинг схемы. Например, `$keyName` или `123field` являются допустимыми ключами в JSON, но недопустимыми именами полей в Manticore Search. Если попытаться использовать недопустимые имена без корректного маппинга, Manticore выдаст ошибку, и создание источника не удастся.\n\nДля таких случаев используйте следующий синтаксис схемы для сопоставления недопустимых имён с валидными:\n\nCODE_BLOCK_1\n\nНапример:\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n#### Опции\n\n| Опция | Допустимые значения | Описание |\n\n|-|----------------|---------------------------------------------------------------------------------------------------------------------|\n\n| `type` | `kafka` | Устанавливает тип источника. В настоящее время поддерживается только `kafka`. |\n\n| `broker_list` | `host:port [, ...]` | Указывает URL брокеров Kafka |\n\n| `topic_list` | `string [, ...]` | Список топиков Kafka для чтения |\n\n| `consumer_group`| `string` | Определяет группу потребителей Kafka, по умолчанию `manticore`. |\n\n| `num_consumers` | `int` | Количество потребителей для обработки сообщений. |\n\n| `partition_list` | `int [, ...]` | Список разделов для чтения [подробнее](../Integration/Kafka.md#Sharding-with-Kafka). |\n\n| `batch` | `int` | Количество сообщений для обработки перед переходом дальше. По умолчанию `100`; по таймауту обрабатывает оставшиеся сообщения. |\n\n### Целевая таблица\n\n\n\nЦелевая таблица — обычная таблица real-time, в которую записываются результаты обработки сообщений из Kafka. Эта таблица должна быть определена в соответствии с требованиями схемы поступающих данных и оптимизирована под нужды производительности запросов вашего приложения. Подробнее о создании real-time таблиц читайте [здесь](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### Материализованное представление\n\n\n\nМатериализованное представление позволяет трансформировать данные из сообщений Kafka. Вы можете переименовывать поля, применять функции Manticore Search, выполнять сортировку, группировку и другие операции с данными.\n\nМатериализованное представление выступает в роли запроса, который перемещает данные из Kafka-источника в целевую таблицу, позволяя использовать синтаксис Manticore Search для настройки таких запросов. Убедитесь, что поля в `select` соответствуют полям источника.\n\nCODE_BLOCK_11\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nДанные передаются из Kafka в Manticore Search пакетами, которые очищаются после каждого запуска. Для вычислений на основе нескольких пакетов, например AVG, будьте осторожны, так как такие операции могут некорректно работать из-за обработки по пакетам.\n\n### Сопоставление полей\n\nВот таблица сопоставлений на основе вышеуказанных примеров:\n\n| Kafka | Источник | Буфер | MV | Целевой пункт |\n\n|-------------------------------------|----------|----------|----------------------------------------|---------------|\n\n| `id` | `id` | `id` | `id` | `id` |\n\n| `term` | `term` | `term` | `term as name` | `name` |\n\n| `unnecessary_key`, который нас не интересует | - | - | | |\n\n| `$abbrev` | `abbrev` | `abbrev` | `abbrev as short_name` | `short_name` |\n\n| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at` |" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Listing_tables.md.json b/.translation-cache/Listing_tables.md.json index 6792c6aaf2..9304a1e994 100644 --- a/.translation-cache/Listing_tables.md.json +++ b/.translation-cache/Listing_tables.md.json @@ -6,5 +6,13 @@ "russian": "# Listing tables\n\nManticore Search имеет один уровень иерархии для таблиц.\n\nВ отличие от других СУБД, в Manticore нет концепции группировки таблиц в базы данных. Однако, для совместимости с диалектами SQL, Manticore принимает операторы `SHOW DATABASES` для совместимости с диалектом SQL, но оператор не возвращает никаких результатов.\n\n\n\n## SHOW TABLES\n\nОбщий синтаксис:\n\nCODE_BLOCK_0\n\nОператор `SHOW TABLES` выводит список всех активных в данный момент таблиц вместе с их типами. Существующие типы таблиц: `local`, `distributed`, `rt`, `percolate` и `template`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n\n\nПоддерживается необязательный оператор LIKE для фильтрации таблиц по имени.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n## DESCRIBE\n\nCODE_BLOCK_33\n\nОператор `DESCRIBE` выводит столбцы таблицы и их соответствующие типы. Столбцы включают ID документа, полнотекстовые поля и атрибуты. Порядок соответствует порядку, в котором поля и атрибуты ожидаются в операторах `INSERT` и `REPLACE`. Типы столбцов включают `field`, `integer`, `timestamp`, `ordinal`, `bool`, `float`, `bigint`, `string` и `mva`. Столбец ID будет иметь тип `bigint`. Пример:\n\nCODE_BLOCK_34\n\nПоддерживается необязательный оператор LIKE. Обратитесь к\n\n[SHOW META](Node_info_and_management/SHOW_META.md) для деталей синтаксиса.\n\n### SELECT FROM name.@table\n\n\n\nВы также можете просмотреть схему таблицы, выполнив запрос `select * from .@table`. Преимущество этого метода в том, что вы можете использовать оператор `WHERE` для фильтрации:\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\n\n\nВы также можете выполнять многие другие действия с `.@table`, рассматривая её как обычную таблицу Manticore с колонками, состоящими из целочисленных и строковых атрибутов.\n\n\n\nCODE_BLOCK_37\n\n\n\n## SHOW CREATE TABLE\n\n\n\nCODE_BLOCK_38\n\nВыводит оператор `CREATE TABLE`, использованный для создания указанной таблицы.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\n### Схемы таблиц Percolate\n\nЕсли вы используете оператор `DESC` для таблицы percolate, он отобразит схему внешней таблицы, которая является схемой сохранённых запросов. Эта схема статична и одинакова для всех локальных таблиц percolate:\n\nCODE_BLOCK_41\n\nЕсли вы хотите просмотреть ожидаемую схему документа, используйте следующую команду:\n\n`DESC table`:\n\nCODE_BLOCK_42\n\nТакже поддерживается `desc pq table like ...` и работает следующим образом:\n\nCODE_BLOCK_43" }, "is_code_or_comment": false + }, + "39cadf789ffd6ca7a9d687e682ebd27aeb2c149bfceba360cb2e3c6ac0f4b146": { + "original": "# Listing tables\n\nManticore Search has a single level of hierarchy for tables.\n\nUnlike other DBMS, there is no concept of grouping tables into databases in Manticore. However, for interoperability with SQL dialects, Manticore accepts `SHOW DATABASES` statements for interoperability with SQL dialect, statements, but the statement does not return any results.\n\n\n\n## SHOW TABLES\n\nGeneral syntax:\n\nCODE_BLOCK_0\n\nThe `SHOW TABLES`statement lists all currently active tables along with their types. The existing table types are `local`, `distributed`, `rt`, `percolate` and `template`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n\n\nOptional LIKE clause is supported for filtering tables by name.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\n## DESCRIBE\n\nCODE_BLOCK_37\n\nThe `DESCRIBE` statement lists the table columns and their associated types. The columns are document ID, full-text fields, and attributes. The order matches the order in which fields and attributes are expected by `INSERT` and `REPLACE` statements. Column types include `field`, `integer`, `timestamp`, `ordinal`, `bool`, `float`, `bigint`, `string`, and `mva`. ID column will be typed as `bigint`. Example:\n\nCODE_BLOCK_38\n\nAn optional LIKE clause is supported. Refer to\n\n[SHOW META](Node_info_and_management/SHOW_META.md) for its syntax details.\n\n### SELECT FROM name.@table\n\n\n\nYou can also view the table schema by executing the query `select * from .@table`. The benefit of this method is that you can use the `WHERE` clause for filtering:\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\n\n\nYou can also perform many other actions on `.@table` considering it as a regular Manticore table with columns consisting of integer and string attributes.\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\n## SHOW CREATE TABLE\n\n\n\nCODE_BLOCK_45\n\nPrints the `CREATE TABLE` statement used to create the specified table.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n### Percolate table schemas\n\nIf you use the `DESC` statement on a percolate table, it will display the outer table schema, which is the schema of stored queries. This schema is static and the same for all local percolate tables:\n\nCODE_BLOCK_50\n\nIf you want to view the expected document schema, use the following command:\n\n`DESC table`:\n\nCODE_BLOCK_51\n\nAlso `desc pq table like ...` is supported and works as follows:\n\nCODE_BLOCK_52", + "translations": { + "chinese": "# 列出表格\n\nManticore Search 对表格只有单级层级结构。\n\n与其他数据库管理系统不同，Manticore 中没有将表格分组到数据库中的概念。然而，为了与 SQL 方言兼容，Manticore 接受 `SHOW DATABASES` 语句，但该语句不会返回任何结果。\n\n\n\n## SHOW TABLES\n\n通用语法：\n\nCODE_BLOCK_0\n\n`SHOW TABLES` 语句列出所有当前活动的表及其类型。现有的表类型有 `local`、`distributed`、`rt`、`percolate` 和 `template`。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n\n\n支持可选的 LIKE 子句，用于按名称过滤表格。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\n## DESCRIBE\n\nCODE_BLOCK_37\n\n`DESCRIBE` 语句列出表的列及其关联类型。列包括文档 ID、全文字段和属性。顺序与 `INSERT` 和 `REPLACE` 语句中字段和属性的顺序一致。列类型包括 `field`、`integer`、`timestamp`、`ordinal`、`bool`、`float`、`bigint`、`string` 和 `mva`。ID 列的类型为 `bigint`。示例：\n\nCODE_BLOCK_38\n\n支持可选的 LIKE 子句。语法详情请参阅\n\n[SHOW META](Node_info_and_management/SHOW_META.md)。\n\n### SELECT FROM name.@table\n\n\n\n你也可以通过执行查询 `select * from .@table` 查看表结构。此方法的好处是可以使用 `WHERE` 子句进行过滤：\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\n\n\n你也可以对 `.@table` 执行许多其他操作，将其视为包含整数和字符串属性列的常规 Manticore 表。\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\n## SHOW CREATE TABLE\n\n\n\nCODE_BLOCK_45\n\n打印用于创建指定表的 `CREATE TABLE` 语句。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n### Percolate 表结构\n\n如果你对 percolate 表执行 `DESC` 语句，它将显示外部表结构，也就是存储查询的结构。该结构是静态的，所有本地 percolate 表都相同：\n\nCODE_BLOCK_50\n\n如果你想查看期望的文档结构，请使用以下命令：\n\n`DESC table`：\n\nCODE_BLOCK_51\n\n同时支持 `desc pq table like ...`，行为如下：\n\nCODE_BLOCK_52", + "russian": "# Listing tables\n\nManticore Search имеет один уровень иерархии для таблиц.\n\nВ отличие от других СУБД, в Manticore отсутствует концепция группировки таблиц в базы данных. Тем не менее, для совместимости с диалектами SQL, Manticore принимает операторы `SHOW DATABASES`, но оператор не возвращает никаких результатов.\n\n\n\n## SHOW TABLES\n\nОбщий синтаксис:\n\nCODE_BLOCK_0\n\nОператор `SHOW TABLES` выводит все текущие активные таблицы вместе с их типами. Существующие типы таблиц: `local`, `distributed`, `rt`, `percolate` и `template`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n\n\nОпциональное условие LIKE поддерживается для фильтрации таблиц по имени.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\n## DESCRIBE\n\nCODE_BLOCK_37\n\nОператор `DESCRIBE` выводит столбцы таблицы и их сопутствующие типы. Столбцы — это идентификатор документа, полнотекстовые поля и атрибуты. Порядок совпадает с порядком, в котором поля и атрибуты ожидаются в операторах `INSERT` и `REPLACE`. Типы столбцов включают `field`, `integer`, `timestamp`, `ordinal`, `bool`, `float`, `bigint`, `string` и `mva`. Столбец ID будет иметь тип `bigint`. Пример:\n\nCODE_BLOCK_38\n\nОпциональное условие LIKE поддерживается. Обратитесь к\n\n[SHOW META](Node_info_and_management/SHOW_META.md) для деталей синтаксиса.\n\n### SELECT FROM name.@table\n\n\n\nВы также можете просмотреть схему таблицы, выполнив запрос `select * from .@table`. Преимущество этого метода в том, что вы можете использовать условие `WHERE` для фильтрации:\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\n\n\nВы также можете выполнять многие другие действия с `.@table`, рассматривая его как обычную таблицу Manticore с колонками, состоящими из целочисленных и строковых атрибутов.\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\n## SHOW CREATE TABLE\n\n\n\nCODE_BLOCK_45\n\nВыводит оператор `CREATE TABLE`, использованный для создания указанной таблицы.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n### Схемы таблиц Percolate\n\nЕсли использовать оператор `DESC` для percolate-таблицы, будет показана схема внешней таблицы, которая представляет собой схему сохранённых запросов. Эта схема статична и одинакова для всех локальных percolate-таблиц:\n\nCODE_BLOCK_50\n\nЕсли вы хотите посмотреть ожидаемую схему документа, используйте следующую команду:\n\n`DESC table`:\n\nCODE_BLOCK_51\n\nТакже поддерживается `desc pq table like ...` и работает следующим образом:\n\nCODE_BLOCK_52" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/KILL.md.json b/.translation-cache/Node_info_and_management/KILL.md.json index 7cc8ce6ff1..2b84e85894 100644 --- a/.translation-cache/Node_info_and_management/KILL.md.json +++ b/.translation-cache/Node_info_and_management/KILL.md.json @@ -6,5 +6,13 @@ "russian": "# KILL\n\n\n\nCODE_BLOCK_0\n\n`KILL` завершает выполнение запроса по его ID, который вы можете найти в [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES).\n\n\n\nCODE_BLOCK_1\n\n\n\n" }, "is_code_or_comment": false + }, + "6cf17343665ad572264723e7a8b83d596df7dae37ca2637319b2f5ade44359cf": { + "original": "# KILL\n\n\n\nCODE_BLOCK_0\n\n`KILL` terminates the execution of a query by its ID, which you can find in [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES).\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n", + "translations": { + "chinese": "# KILL\n\n\n\nCODE_BLOCK_0\n\n`KILL` 通过查询的 ID 终止该查询的执行，您可以在 [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES) 中找到该 ID。\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n", + "russian": "# KILL\n\n\n\nCODE_BLOCK_0\n\n`KILL` завершает выполнение запроса по его ID, который вы можете найти в [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES).\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/Node_status.md.json b/.translation-cache/Node_info_and_management/Node_status.md.json index 1c8d7c5ac2..5e4ed31977 100644 --- a/.translation-cache/Node_info_and_management/Node_status.md.json +++ b/.translation-cache/Node_info_and_management/Node_status.md.json @@ -14,5 +14,21 @@ "russian": "# Статус узла\n\n## STATUS\n\n\n\nСамый простой способ получить общую информацию о вашем узле Manticore — выполнить команду `status` в клиенте MySQL. Она отобразит информацию о различных аспектах, таких как:\n\n* Текущая версия\n\n* Используется ли SSL или нет\n\n* Текущий TCP порт/Unix сокет\n\n* Время работы\n\n* Количество [потоков](../Server_settings/Searchd.md#threads)\n\n* Количество [заданий в очереди](../Server_settings/Searchd.md#jobs_queue_size)\n\n* Количество подключений (`clients`)\n\n* Количество задач, обрабатываемых в данный момент\n\n* Количество выполненных запросов с момента запуска\n\n* Количество заданий в очереди и количество задач, нормализованное по количеству потоков\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n## SHOW STATUS\n\nCODE_BLOCK_2\n\n\n\n`SHOW STATUS` — это SQL-запрос, который показывает различные полезные счетчики производительности. Счетчики ввода-вывода и CPU будут доступны только если `searchd` был запущен с ключами `--iostats` и `--cpustats` соответственно (или если они были включены через `SET GLOBAL iostats/cpustats=1`).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\nПоддерживается необязательный оператор `LIKE`, позволяющий выбрать только переменные, соответствующие определенному шаблону. Синтаксис шаблона соответствует стандартным SQL-джокерам, где `%` означает любое количество любых символов, а `_` — один символ.\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n### Статистика времени запросов\n\n\n\nКоманда `SHOW STATUS` предоставляет подробный отчет о различных показателях производительности в Manticore, включая статистику времени запросов для insert/replace, search и update запросов. Эти статистики рассчитываются за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили времени запросов.\n\nЭти метрики помогают отслеживать производительность за определенные интервалы времени, что облегчает выявление тенденций в времени отклика запросов и поиск возможных узких мест.\n\nСледующие метрики входят в вывод `SHOW STATUS`:\n\n- `*_avg`: Среднее время запроса для каждого типа запросов за последние 1, 5 и 15 минут.\n\n- `*_min`: Самое короткое время запроса, зафиксированное для каждого типа запросов.\n\n- `*_max`: Самое длинное время запроса, зафиксированное для каждого типа запросов.\n\n- `*_pct95`: Время, в течение которого выполняются 95% запросов.\n\n- `*_pct99`: Время, в течение которого выполняются 99% запросов.\n\nЭти статистики предоставляются отдельно для insert/replace (`insert_replace_stats_*`), search (`search_stats_*`) и update (`update_stats_*`) запросов, что дает детальное представление о производительности различных операций.\n\nЕсли в течение контролируемого интервала запросы не выполнялись, система отобразит `N/A`.\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n## SHOW SETTINGS\n\n\n\n`SHOW SETTINGS` — это SQL-запрос, который отображает текущие настройки из вашего конфигурационного файла. Имена настроек представлены в формате: `'config_section_name'.'setting_name'`\n\nРезультат также включает два дополнительных значения:\n\n- `configuration_file` — путь к конфигурационному файлу\n\n- `worker_pid` — идентификатор процесса запущенного экземпляра `searchd`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n## SHOW AGENT STATUS\n\nCODE_BLOCK_13\n\n\n\n`SHOW AGENT STATUS` отображает статистику [удаленных агентов](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) или распределенной таблицы. Включает такие значения, как время с последнего запроса, последнего ответа, количество различных типов ошибок и успешных операций и т.д. Статистика отображается для каждого агента за последние интервалы 1, 5 и 15, каждый из которых состоит из [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) секунд.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\nПоддерживается необязательный оператор `LIKE`, синтаксис которого такой же, как в `SHOW STATUS`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n##### C#:" }, "is_code_or_comment": false + }, + "2ee74280ea484752d3a3b228bff8a57dd7218f4ac6158185265c1ed7b8e7bb83": { + "original": "\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n\n\nYou can specify a particular agent by its address. In this case, only that agent's data will be displayed. Additionally, the `agent_` prefix will be used instead of `ag_N_`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n\n\nFinally, you can check the status of the agents in a specific distributed table using the `SHOW AGENT table_name STATUS` statement. This statement displays the table's HA status (i.e., whether or not it uses agent mirrors at all) and provides information on the mirrors, including: address, blackhole and persistent flags, and the mirror selection probability used when one of the [weighted probability strategies](../Creating_a_cluster/Remote_nodes/Load_balancing.md) is in effect.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n## Prometheus Exporter\n\n\n\nManticore Search has a built-in Prometheus exporter.\n\nTo request metrics, make sure the HTTP port is exposed and simply call the /metrics endpoint.\n\n**Note:** The exporter requires **Buddy** to be enabled.\n\n\n\n##### HTTP:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n", + "translations": { + "chinese": "\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n\n\nYou can specify a particular agent by its address. In this case, only that agent's data will be displayed. Additionally, the `agent_` prefix will be used instead of `ag_N_`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n\n\nFinally, you can check the status of the agents in a specific distributed table using the `SHOW AGENT table_name STATUS` statement. This statement displays the table's HA status (i.e., whether or not it uses agent mirrors at all) and provides information on the mirrors, including: address, blackhole and persistent flags, and the mirror selection probability used when one of the [weighted probability strategies](../Creating_a_cluster/Remote_nodes/Load_balancing.md) is in effect.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n## Prometheus Exporter\n\n\n\nManticore Search has a built-in Prometheus exporter.\n\nTo request metrics, make sure the HTTP port is exposed and simply call the /metrics endpoint.\n\n**Note:** The exporter requires **Buddy** to be enabled.\n\n\n\n##### HTTP:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n", + "russian": "\n\n##### JSON:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\n\n\nYou can specify a particular agent by its address. In this case, only that agent's data will be displayed. Additionally, the `agent_` prefix will be used instead of `ag_N_`:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\n\n\nFinally, you can check the status of the agents in a specific distributed table using the `SHOW AGENT table_name STATUS` statement. This statement displays the table's HA status (i.e., whether or not it uses agent mirrors at all) and provides information on the mirrors, including: address, blackhole and persistent flags, and the mirror selection probability used when one of the [weighted probability strategies](../Creating_a_cluster/Remote_nodes/Load_balancing.md) is in effect.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n## Prometheus Exporter\n\n\n\nManticore Search has a built-in Prometheus exporter.\n\nTo request metrics, make sure the HTTP port is exposed and simply call the /metrics endpoint.\n\n**Note:** The exporter requires **Buddy** to be enabled.\n\n\n\n##### HTTP:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n" + }, + "is_code_or_comment": true + }, + "66354cec429c6b4e0dce962c94857c828dd4bc0081f10f42b7bf849d51f42d5b": { + "original": "# Node status\n\n## STATUS\n\n\n\nThe easiest way to view high-level information about your Manticore node is by running `status` in the MySQL client. It will display information about various aspects, such as:\n\n* Current version\n\n* Whether SSL is in effect or not\n\n* Current TCP port/Unix socket\n\n* Uptime\n\n* Number of [threads](../Server_settings/Searchd.md#threads)\n\n* Number of [jobs in queue](../Server_settings/Searchd.md#jobs_queue_size)\n\n* Number of connections (`clients`)\n\n* Number of tasks being processed currently\n\n* Number of queries executed since the start\n\n* Number of jobs in queue and number of tasks, normalized by the number of threads\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n## SHOW STATUS\n\nCODE_BLOCK_2\n\n\n\n`SHOW STATUS` is an SQL statement that presents various helpful performance counters. IO and CPU counters will only be available if `searchd` was started with the `--iostats` and `--cpustats` switches, respectively (or if they were enabled via `SET GLOBAL iostats/cpustats=1`).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n\n\nAn optional `LIKE` clause is supported, allowing you to select only the variables that match a specific pattern. The pattern syntax follows standard SQL wildcards, where `%` represents any number of any characters, and `_` represents a single character.\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n### Query Time Statistics\n\n\n\nThe `SHOW STATUS` command gives a detailed report on various performance metrics in Manticore, including query time statistics for insert/replace, search, and update queries. These stats are calculated over sliding windows of 1, 5, and 15 minutes, showing average, minimum, maximum, and 95th/99th percentile values for query times.\n\nThese metrics help track performance over specific time intervals, making it easier to spot trends in query response times and find possible bottlenecks.\n\nThe following metrics are part of the `SHOW STATUS` output:\n\n- `*_avg`: The average query time for each type of query over the last 1, 5, and 15 minutes.\n\n- `*_min`: The shortest query time recorded for each query type.\n\n- `*_max`: The longest query time recorded for each query type.\n\n- `*_pct95`: The time under which 95% of queries are completed.\n\n- `*_pct99`: The time under which 99% of queries are completed.\n\nThese statistics are provided separately for insert/replace (`insert_replace_stats_*`), search (`search_stats_*`), and update (`update_stats_*`) queries, offering detailed insights into the performance of different operations.\n\nIf no queries are executed during the monitored interval, the system will display `N/A`.\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n## SHOW SETTINGS\n\n\n\n`SHOW SETTINGS` is an SQL statement that displays the current settings from your configuration file. The setting names are represented in the following format: `'config_section_name'.'setting_name'`\n\nThe result also includes two additional values:\n\n- `configuration_file` - The path to the configuration file\n\n- `worker_pid` - The process ID of the running `searchd` instance\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n## SHOW AGENT STATUS\n\nCODE_BLOCK_23\n\n\n\n`SHOW AGENT STATUS` displays the statistics of [remote agents](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) or a distributed table. It includes values such as the age of the last request, last answer, the number of various types of errors and successes, and so on. Statistics are displayed for every agent for the last 1, 5, and 15 intervals, each consisting of [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) seconds.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n\n\nAn optional `LIKE` clause is supported, with the syntax being the same as in `SHOW STATUS`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47", + "translations": { + "chinese": "# 节点状态\n\n## 状态\n\n\n\n查看 Manticore 节点高级信息的最简单方法是在 MySQL 客户端中运行 `status`。它将显示有关各个方面的信息，例如：\n\n* 当前版本\n\n* 是否启用了 SSL\n\n* 当前的 TCP 端口/Unix 套接字\n\n* 运行时间\n\n* 线程数 ([threads](../Server_settings/Searchd.md#threads))\n\n* 队列中的作业数 ([jobs_queue_size](../Server_settings/Searchd.md#jobs_queue_size))\n\n* 连接数 (`clients`)\n\n* 当前正在处理的任务数\n\n* 自启动以来执行的查询数\n\n* 按线程数归一化的队列中作业数和任务数\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n## SHOW STATUS\n\nCODE_BLOCK_2\n\n\n\n`SHOW STATUS` 是一个 SQL 语句，展示各种有用的性能计数器。IO 和 CPU 计数器仅在 `searchd` 使用 `--iostats` 和 `--cpustats` 开关启动时可用（或通过 `SET GLOBAL iostats/cpustats=1` 启用）。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n\n\n支持可选的 `LIKE` 子句，允许仅选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符规则，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n### 查询时间统计\n\n\n\n`SHOW STATUS` 命令详细报告了 Manticore 中各种性能指标，包括插入/替换、搜索和更新查询的查询时间统计。这些统计是在 1、5 和 15 分钟的滑动窗口内计算的，显示查询时间的平均值、最小值、最大值以及第 95 和 99 百分位值。\n\n这些指标有助于跟踪特定时间区间内的性能，更易识别查询响应时间的趋势和潜在瓶颈。\n\n以下指标包含在 `SHOW STATUS` 的输出中：\n\n- `*_avg`：每种查询类型在最近 1、5 和 15 分钟内的平均查询时间。\n\n- `*_min`：每种查询类型记录的最短查询时间。\n\n- `*_max`：每种查询类型记录的最长查询时间。\n\n- `*_pct95`：95% 查询完成时间的上限。\n\n- `*_pct99`：99% 查询完成时间的上限。\n\n这些统计分别针对插入/替换 (`insert_replace_stats_*`)、搜索 (`search_stats_*`) 和更新 (`update_stats_*`) 查询提供，详尽洞察不同操作的性能。\n\n如果监控间隔内未执行查询，系统将显示 `N/A`。\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n## SHOW SETTINGS\n\n\n\n`SHOW SETTINGS` 是一个 SQL 语句，显示配置文件中的当前设置。设置名称格式为：`'config_section_name'.'setting_name'`\n\n结果还包括两个额外值：\n\n- `configuration_file` - 配置文件路径\n\n- `worker_pid` - 运行中的 `searchd` 实例的进程 ID\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n## SHOW AGENT STATUS\n\nCODE_BLOCK_23\n\n\n\n`SHOW AGENT STATUS` 显示[远程代理](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent)或分布式表的统计信息。包括上次请求和回答的时间间隔，各类错误和成功次数等。统计信息分别用于过去的 1、5、15 个由 [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) 秒组成的时间段内的每个代理。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n\n\n支持可选的 `LIKE` 子句，其语法与 `SHOW STATUS` 中相同。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47", + "russian": "# Статус узла\n\n## STATUS\n\n\n\nСамый простой способ просмотреть основную информацию о вашем узле Manticore — выполнить команду `status` в клиенте MySQL. Она отобразит информацию о различных аспектах, таких как:\n\n* Текущая версия\n\n* Используется ли SSL или нет\n\n* Текущий TCP порт/Unix сокет\n\n* Время работы\n\n* Количество [потоков](../Server_settings/Searchd.md#threads)\n\n* Количество [заданий в очереди](../Server_settings/Searchd.md#jobs_queue_size)\n\n* Количество подключений (`clients`)\n\n* Количество задач, обрабатываемых в данный момент\n\n* Количество выполненных запросов с момента запуска\n\n* Количество заданий в очереди и количество задач, нормализованных по количеству потоков\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n## SHOW STATUS\n\nCODE_BLOCK_2\n\n\n\n`SHOW STATUS` — это SQL-запрос, который отображает различные полезные счетчики производительности. Счетчики ввода-вывода и процессора будут доступны только если `searchd` был запущен с переключателями `--iostats` и `--cpustats` соответственно (или если они были включены через `SET GLOBAL iostats/cpustats=1`).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n\n\nПоддерживается необязательный оператор `LIKE`, который позволяет выбрать только переменные, соответствующие определенному шаблону. Синтаксис шаблона соответствует стандартным SQL-символам подстановки, где `%` обозначает любое количество любых символов, а `_` — один символ.\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n### Статистика времени выполнения запросов\n\n\n\nКоманда `SHOW STATUS` предоставляет детальный отчет о различных показателях производительности в Manticore, включая статистику времени выполнения для запросов insert/replace, search и update. Эти статистики рассчитываются за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95%/99%-ные перцентили времени выполнения запросов.\n\nЭти метрики помогают отслеживать производительность за определенные интервалы времени, что облегчает выявление тенденций в времени отклика запросов и поиск возможных узких мест.\n\nСледующие метрики входят в вывод `SHOW STATUS`:\n\n- `*_avg`: Среднее время выполнения запроса для каждого типа запросов за последние 1, 5 и 15 минут.\n\n- `*_min`: Самое короткое время выполнения запроса для каждого типа запросов.\n\n- `*_max`: Самое долгое время выполнения запроса для каждого типа запросов.\n\n- `*_pct95`: Время, в течение которого выполнено 95% запросов.\n\n- `*_pct99`: Время, в течение которого выполнено 99% запросов.\n\nЭти статистики предоставляются отдельно для insert/replace (`insert_replace_stats_*`), search (`search_stats_*`) и update (`update_stats_*`) запросов, предоставляя исчерпывающую информацию о производительности различных операций.\n\nЕсли в течение контролируемого интервала не выполняются запросы, система отобразит `N/A`.\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n## SHOW SETTINGS\n\n\n\n`SHOW SETTINGS` — это SQL-запрос, который выводит текущие настройки из вашего конфигурационного файла. Имена настроек представлены в формате: `'config_section_name'.'setting_name'`\n\nРезультат также включает два дополнительных значения:\n\n- `configuration_file` — путь к конфигурационному файлу\n\n- `worker_pid` — идентификатор процесса запущенного экземпляра `searchd`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n## SHOW AGENT STATUS\n\nCODE_BLOCK_23\n\n\n\n`SHOW AGENT STATUS` отображает статистику [удаленных агентов](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) или распределенной таблицы. Включает такие значения, как возраст последнего запроса, последний ответ, количество различных типов ошибок и успешных ответов и так далее. Статистика отображается для каждого агента за последние интервалы в 1, 5 и 15, каждый из которых состоит из [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) секунд.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\n\n\nПоддерживается необязательный оператор `LIKE` с синтаксисом, аналогичным `SHOW STATUS`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/SHOW_META.md.json b/.translation-cache/Node_info_and_management/SHOW_META.md.json index 51bb13d11d..804c8bacea 100644 --- a/.translation-cache/Node_info_and_management/SHOW_META.md.json +++ b/.translation-cache/Node_info_and_management/SHOW_META.md.json @@ -14,5 +14,21 @@ "russian": "# SHOW META\n\nCODE_BLOCK_0\n\n\n\n`SHOW META` — это SQL-запрос, который отображает дополнительную метаинформацию о выполненном запросе, включая время выполнения запроса, статистику по ключевым словам и информацию о используемых вторичных индексах. Синтаксис:\n\nВключённые элементы:\n\n* `total`: Количество совпадений, которые фактически были извлечены и отправлены клиенту. Это значение обычно ограничивается опцией поиска [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results).\n\n* `total_found`:\n\n - Оценочное общее количество совпадений для запроса в индексе. Если вам нужно точное количество совпадений, используйте `SELECT COUNT(*)` вместо опоры на это значение.\n\n - Для запросов с `GROUP BY` `total_found` представляет количество групп, а не отдельных совпадений.\n\n - Для запросов [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) `total_found` по-прежнему представляет количество групп, независимо от значения `N`.\n\n* `total_relation`: Указывает, является ли значение `total_found` точным или оценочным.\n\n - Если Manticore не может определить точное значение `total_found`, в этом поле будет отображено `total_relation: gte`, что означает, что фактическое количество совпадений **больше или равно** указанному `total_found`.\n\n - Если значение `total_found` точное, будет отображено `total_relation: eq`.\n\n* `time`: Время (в секундах), затраченное на обработку поискового запроса.\n\n* `keyword[N]`: n-й ключевой запрос, использованный в поисковом запросе. Обратите внимание, что ключевое слово может быть представлено с использованием подстановочного знака, например, `abc*`.\n\n* `docs[N]`: Общее количество документов (или записей), содержащих n-й ключевой запрос из поискового запроса. Если ключевое слово представлено с подстановочным знаком, это значение представляет сумму документов для всех расширенных подзапросов, что может превышать фактическое количество совпавших документов.\n\n* `hits[N]`: Общее количество вхождений (или попаданий) n-го ключевого слова во всех документах.\n\n* `index`: Информация об используемом индексе (например, вторичном индексе).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\n`SHOW META` может отображать счётчики ввода-вывода и CPU, но они будут доступны только если searchd был запущен с переключателями `--iostats` и `--cpustats` соответственно.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\nДополнительные значения, такие как `predicted_time`, `dist_predicted_time`, `local_fetched_docs`, `local_fetched_hits`, `local_fetched_skips` и их соответствующие аналоги `dist_fetched_*`, будут доступны только если `searchd` был настроен с [предсказанными затратами времени](../Server_settings/Searchd.md#predicted_time_costs) и запрос включал `predicted_time` в опции `OPTION`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n\n\n`SHOW META` должен выполняться сразу после запроса в **той же** сессии. Поскольку некоторые MySQL-коннекторы/библиотеки используют пулы соединений, выполнение `SHOW META` в отдельном запросе может привести к неожиданным результатам, например, получению метаданных другого запроса. В таких случаях (и в общем случае рекомендуется) выполняйте множественный запрос, содержащий и сам запрос, и `SHOW META`. Некоторые коннекторы/библиотеки поддерживают мультизапросы в одном методе для одного запроса, в то время как другие могут требовать использования специального метода для мультизапросов или установки определённых опций при настройке соединения.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\nВы также можете использовать необязательное выражение LIKE, которое позволяет выбрать только переменные, соответствующие определённому шаблону. Синтаксис шаблона соответствует стандартным SQL-подстановочным знакам, где `%` обозначает любое количество любых символов, а `_` — один символ.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n## SHOW META и фасеты\n\n\n\nПри использовании [фасетного поиска](../Searching/Faceted_search.md) вы можете проверить поле `multiplier` в выводе `SHOW META`, чтобы определить, сколько запросов было выполнено в оптимизированной группе.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n## SHOW META и оптимизатор запросов\n\n\n\nКогда [оптимизатор запросов на основе стоимости](../Searching/Cost_based_optimizer.md) выбирает использование `DocidIndex`, `ColumnarScan` или `SecondaryIndex` вместо простого фильтра, это отражается в команде `SHOW META`.\n\nПеременная `index` отображает имена и типы вторичных индексов, использованных во время выполнения запроса. Процент указывает, сколько дисковых чанков (в случае RT-таблицы) или псевдо-шард (в случае простой таблицы) использовали вторичный индекс.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n## SHOW META для PQ таблиц\n\n\n\n`SHOW META` можно использовать после выполнения [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ), в этом случае он выдаёт другой вывод.\n\n`SHOW META` после выполнения `CALL PQ` включает:\n\n* `total` — Общее время, затраченное на сопоставление документа(ов)\n\n* `queries_matched` — Количество сохранённых запросов, которые совпали с документом(ами)\n\n* `document_matches` — Количество документов, которые совпали с запросами, сохранёнными в таблице\n\n* `total_queries_stored` — Общее количество запросов, сохранённых в таблице\n\n* `term_only_queries` — Количество запросов в таблице, которые содержат термы; остальные запросы используют расширенный синтаксис запросов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n\n\nИспользование `CALL PQ` с опцией `verbose` предоставляет более подробный вывод." }, "is_code_or_comment": false + }, + "ec5562375af2320902b544432a32eb2bd91770bac4cd76cf6d69d0240609f489": { + "original": "`SHOW META` can be used after executing a [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ) statement, in which case it provides different output.\n\n`SHOW META` following a `CALL PQ` statement includes:\n\n* `total` - Total time spent on matching the document(s)\n\n* `queries_matched` - Number of stored queries that match the document(s)\n\n* `document_matches` - Number of documents that matched the queries stored in the table\n\n* `total_queries_stored` - Total number of queries stored in the table\n\n* `term_only_queries` - Number of queries in the table that have terms; the remaining queries use extended query syntax.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n\n\nUsing `CALL PQ` with a `verbose` option provides more detailed output.\n\nIt includes the following additional entries:\n\n* `Setup` - Time spent on the initial setup of the matching process, such as parsing docs and setting options\n\n* `Queries failed` - Number of queries that failed\n\n* `Fast rejected queries` - Number of queries that were not fully evaluated but quickly matched and rejected using filters or other conditions\n\n* `Time per query` - Detailed time for each query\n\n* `Time of matched queries` - Total time spent on queries that matched any documents\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n", + "translations": { + "chinese": "`SHOW META` 可在执行 [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ) 语句后使用，此时它提供不同的输出。\n\n紧跟 `CALL PQ` 语句之后的 `SHOW META` 包括：\n\n* `total` - 匹配文档所花费的总时间\n\n* `queries_matched` - 匹配文档的存储查询数量\n\n* `document_matches` - 匹配表中存储查询的文档数量\n\n* `total_queries_stored` - 表中存储的查询总数\n\n* `term_only_queries` - 表中包含词条的查询数量；其余查询使用扩展查询语法。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n\n\n使用带有 `verbose` 选项的 `CALL PQ` 可提供更详细的输出。\n\n它包括以下附加条目：\n\n* `Setup` - 匹配过程初始设置所花时间，如解析文档和设置选项\n\n* `Queries failed` - 失败的查询数量\n\n* `Fast rejected queries` - 使用过滤器或其他条件快速匹配并拒绝的查询数量，这些查询未被完全评估\n\n* `Time per query` - 每个查询的详细时间\n\n* `Time of matched queries` - 匹配任何文档的查询所花费的总时间\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n", + "russian": "`SHOW META` может использоваться после выполнения оператора [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ), при этом он выводит другую информацию.\n\n`SHOW META` после оператора `CALL PQ` включает:\n\n* `total` - Общее время, затраченное на сопоставление документа(ов)\n\n* `queries_matched` - Количество сохранённых запросов, которые совпали с документом(ами)\n\n* `document_matches` - Количество документов, которые совпали с запросами, сохранёнными в таблице\n\n* `total_queries_stored` - Общее количество запросов, сохранённых в таблице\n\n* `term_only_queries` - Количество запросов в таблице, которые содержат термы; остальные запросы используют расширенный синтаксис запросов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n\n\nИспользование `CALL PQ` с опцией `verbose` даёт более подробный вывод.\n\nОн включает следующие дополнительные поля:\n\n* `Setup` - Время, затраченное на начальную настройку процесса сопоставления, например, разбор документов и установку параметров\n\n* `Queries failed` - Количество запросов, которые завершились ошибкой\n\n* `Fast rejected queries` - Количество запросов, которые не были полностью оценены, но быстро сопоставлены и отброшены с использованием фильтров или других условий\n\n* `Time per query` - Подробное время для каждого запроса\n\n* `Time of matched queries` - Общее время, затраченное на запросы, которые совпали с любыми документами\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n" + }, + "is_code_or_comment": false + }, + "d1ee1a830ff2de48f06e3e56f7c3862168de6178454968fcf1cc282186d27c6f": { + "original": "# SHOW META\n\nCODE_BLOCK_0\n\n\n\n`SHOW META` is an SQL statement that displays additional meta-information about the processed query, including the query time, keyword statistics, and information about the secondary indexes used. The syntax is:\n\nThe included items are:\n\n* `total`: The number of matches that were actually retrieved and sent to the client. This value is typically limited by the [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results) search option.\n\n* `total_found`:\n\n - The estimated total number of matches for the query in the index. If you need the exact number of matches, use `SELECT COUNT(*)` instead of relying on this value.\n\n - For queries with `GROUP BY`, `total_found` represents the number of groups instead of individual matches.\n\n - For [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) queries, `total_found` still represents the number of groups, regardless of the value of `N`.\n\n* `total_relation`: Indicates whether the `total_found` value is exact or an estimate.\n\n - If Manticore cannot determine the precise `total_found` value, this field will display `total_relation: gte`, meaning the actual number of matches is **Greater Than or Equal** to the reported `total_found`.\n\n - If the `total_found` value is exact, `total_relation: eq` will be displayed.\n\n* `time`: The duration (in seconds) it took to process the search query.\n\n* `keyword[N]`: The n-th keyword used in the search query. Note that the keyword can be presented as a wildcard, e.g., `abc*`.\n\n* `docs[N]`: The total number of documents (or records) containing the n-th keyword from the search query. If the keyword is presented as a wildcard, this value represents the sum of documents for all expanded sub-keywords, potentially exceeding the actual number of matched documents.\n\n* `hits[N]`: The total number of occurrences (or hits) of the n-th keyword across all documents.\n\n* `index`: Information about the utilized index (e.g., secondary index).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n`SHOW META` can display I/O and CPU counters, but they will only be available if searchd was started with the `--iostats` and `--cpustats` switches, respectively.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\nAdditional values, such as `predicted_time`, `dist_predicted_time`, `local_fetched_docs`, `local_fetched_hits`, `local_fetched_skips`, and their respective `dist_fetched_*` counterparts, will only be available if `searchd` was configured with [predicted time costs](../Server_settings/Searchd.md#predicted_time_costs) and the query included `predicted_time` in the `OPTION` clause.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\n`SHOW META` must be executed immediately after the query in the **same** session. Since some MySQL connectors/libraries use connection pools, running `SHOW META` in a separate statement can lead to unexpected results, such as retrieving metadata from another query. In these cases (and generally recommended), run a multiple statement containing both the query and `SHOW META`. Some connectors/libraries support multi-queries within the same method for a single statement, while others may require the use of a dedicated method for multi-queries or setting specific options during connection setup.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n\n\nYou can also use the optional LIKE clause, which allows you to select only the variables that match a specific pattern. The pattern syntax follows standard SQL wildcards, where `%` represents any number of any characters, and `_` represents a single character.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n## SHOW META and facets\n\n\n\nWhen utilizing [faceted search](../Searching/Faceted_search.md), you can examine the `multiplier` field in the `SHOW META` output to determine how many queries were executed in an optimized group.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n## SHOW META and query optimizer\n\n\n\nWhen the [cost-based query optimizer](../Searching/Cost_based_optimizer.md) chooses to use `DocidIndex`, `ColumnarScan`, or `SecondaryIndex` instead of a plain filter, this is reflected in the `SHOW META` command.\n\nThe `index` variable displays the names and types of secondary indexes used during query execution. The percentage indicates how many disk chunks (in the case of an RT table) or pseudo shards (in the case of a plain table) utilized the secondary index.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n## SHOW META for PQ tables\n\n", + "translations": { + "chinese": "# SHOW META\n\nCODE_BLOCK_0\n\n\n\n`SHOW META` 是一个 SQL 语句，用于显示有关处理查询的附加元信息，包括查询时间、关键词统计以及所用二级索引的信息。语法为：\n\n所包含的项目有：\n\n* `total`：实际检索并发送给客户端的匹配数。此值通常受 [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results) 搜索选项限制。\n\n* `total_found`：\n\n - 索引中查询的估计总匹配数。如果需要精确匹配数，请使用 `SELECT COUNT(*)`，而不要依赖此值。\n\n - 对于带有 `GROUP BY` 的查询，`total_found` 表示分组数量，而非单个匹配。\n\n - 对于 [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) 查询，`total_found` 仍然表示分组数，而不管 `N` 的值。\n\n* `total_relation`：指示 `total_found` 值是精确还是估计。\n\n - 如果 Manticore 无法确定精确的 `total_found` 值，该字段将显示 `total_relation: gte`，表示实际匹配数 **大于等于** 报告的 `total_found`。\n\n - 如果 `total_found` 值是精确的，将显示 `total_relation: eq`。\n\n* `time`：处理搜索查询花费的时长（秒）。\n\n* `keyword[N]`：搜索查询中使用的第 n 个关键词。注意关键词可以是通配符形式，例如 `abc*`。\n\n* `docs[N]`：包含搜索查询中第 n 个关键词的文档（或记录）总数。如果关键词是通配符形式，此值表示所有扩展子关键词对应文档的总和，可能大于实际匹配文档数。\n\n* `hits[N]`：所有文档中第 n 个关键词的总出现次数（或命中数）。\n\n* `index`：有关使用的索引（例如二级索引）的信息。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n`SHOW META` 可以显示 I/O 和 CPU 计数器，但只有当 searchd 启动时分别包含 `--iostats` 和 `--cpustats` 开关时，这些信息才可用。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\n附加值，如 `predicted_time`、`dist_predicted_time`、`local_fetched_docs`、`local_fetched_hits`、`local_fetched_skips` 及其相应的 `dist_fetched_*` 对应项，只有在 `searchd` 配置了[预测时间成本](../Server_settings/Searchd.md#predicted_time_costs)并且查询的 `OPTION` 子句中包含 `predicted_time` 时才会提供。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\n`SHOW META` 必须在**同一**会话中紧接着查询立即执行。由于某些 MySQL 连接器/库使用连接池，在单独语句中执行 `SHOW META` 可能造成意外结果，例如检索到其他查询的元数据。在这些情况下（并且通常推荐），请执行包含查询和 `SHOW META` 的多语句操作。有些连接器/库支持单个方法中的多查询，而有些则可能需要使用专门的方法或在连接设置时启用特定选项来支持多查询。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n\n\n你也可以使用可选的 LIKE 子句，允许你仅选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n## SHOW META 与 facets\n\n\n\n当使用[分面搜索](../Searching/Faceted_search.md)时，你可以通过 `SHOW META` 输出中的 `multiplier` 字段，了解优化分组内执行了多少查询。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n## SHOW META 与查询优化器\n\n\n\n当[基于成本的查询优化器](../Searching/Cost_based_optimizer.md)选择使用 `DocidIndex`、`ColumnarScan` 或 `SecondaryIndex` 替代普通过滤时，`SHOW META` 命令会有所反映。\n\n`index` 变量显示查询执行期间所用二级索引的名称和类型。百分比表示利用二级索引的磁盘块数量（对于 RT 表）或伪分片数量（对于普通表）。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n## SHOW META 针对 PQ 表\n\n", + "russian": "# SHOW META\n\nCODE_BLOCK_0\n\n\n\n`SHOW META` — это SQL-оператор, который отображает дополнительную мета-информацию о выполненном запросе, включая время выполнения запроса, статистику по ключевым словам и информацию о вторичных индексах, использованных в запросе. Синтаксис:\n\nВключённые элементы:\n\n* `total`: Количество совпадений, которые были фактически извлечены и отправлены клиенту. Обычно это значение ограничивается опцией поиска [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results).\n\n* `total_found`:\n\n - Оценочное общее количество совпадений для запроса в индексе. Если требуется точное количество совпадений, используйте `SELECT COUNT(*)`, вместо того чтобы полагаться на это значение.\n\n - Для запросов с `GROUP BY`, `total_found` представляет количество групп, а не отдельных совпадений.\n\n - Для запросов типа [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) `total_found` всё равно представляет количество групп, независимо от значения `N`.\n\n* `total_relation`: Показывает, является ли значение `total_found` точным или оценочным.\n\n - Если Manticore не может определить точное значение `total_found`, в этом поле будет отображено `total_relation: gte`, что означает, что фактическое количество совпадений **больше или равно** указанному `total_found`.\n\n - Если значение `total_found` точно, будет отображено `total_relation: eq`.\n\n* `time`: Время (в секундах), затраченное на обработку поискового запроса.\n\n* `keyword[N]`: n-й ключевой запрос, использованный в поиске. Обратите внимание, что ключевое слово может быть представлено с использованием подстановочного знака, например, `abc*`.\n\n* `docs[N]`: Общее количество документов (или записей), содержащих n-ое ключевое слово из поискового запроса. Если ключевое слово представлено подстановочным знаком, это значение представляет сумму документов для всех расширенных подключей, что может превышать фактическое количество совпадающих документов.\n\n* `hits[N]`: Общее количество вхождений (или попаданий) n-го ключевого слова во всех документах.\n\n* `index`: Информация об используемом индексе (например, вторичном индексе).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n`SHOW META` может показывать счётчики ввода/вывода и процессора, но они будут доступны только, если searchd был запущен с переключателями `--iostats` и `--cpustats` соответственно.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\nДополнительные значения, такие как `predicted_time`, `dist_predicted_time`, `local_fetched_docs`, `local_fetched_hits`, `local_fetched_skips` и соответствующие им `dist_fetched_*` значения будут доступны только если `searchd` был сконфигурирован с [предсказанными временными затратами](../Server_settings/Searchd.md#predicted_time_costs) и запрос включал `predicted_time` в разделе `OPTION`.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n\n\n`SHOW META` должен выполняться сразу после запроса в **той же** сессии. Поскольку некоторые MySQL-коннекторы/библиотеки используют пулы соединений, выполнение `SHOW META` в отдельном операторе может привести к непредвиденным результатам, таким как получение метаданных другого запроса. В таких случаях (и вообще рекомендуется) выполняйте многооператорный запрос, содержащий и запрос, и `SHOW META`. Некоторые коннекторы/библиотеки поддерживают мультизапросы в пределах одного вызова метода, в то время как другим может потребоваться использовать специализированный метод для мультизапросов или настроить определённые параметры при установке соединения.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n\n\nВы также можете использовать необязательный оператор LIKE, который позволяет выбирать только переменные, соответствующие определённому шаблону. Синтаксис шаблона выполняется по стандартным SQL-подстановочным знакам, где `%` означает любое количество любых символов, а `_` соответствует одному символу.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n## SHOW META и фасеты\n\n\n\nПри использовании [фасетного поиска](../Searching/Faceted_search.md) в выводе `SHOW META` вы можете посмотреть поле `multiplier`, чтобы узнать, сколько запросов было выполнено в оптимизированной группе.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n## SHOW META и оптимизатор запросов\n\n\n\nКогда [оптимизатор запросов на основе стоимости](../Searching/Cost_based_optimizer.md) выбирает использовать `DocidIndex`, `ColumnarScan` или `SecondaryIndex` вместо простого фильтра, это отображается в команде `SHOW META`.\n\nПеременная `index` показывает имена и типы вторичных индексов, использованных при выполнении запроса. Процент указывает, сколько дисковых чанков (для RT-таблицы) или псевдо-шард (для простой таблицы) использовали вторичный индекс.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n## SHOW META для PQ таблиц\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/SHOW_QUERIES.md.json b/.translation-cache/Node_info_and_management/SHOW_QUERIES.md.json index 06367699ad..9ad343f006 100644 --- a/.translation-cache/Node_info_and_management/SHOW_QUERIES.md.json +++ b/.translation-cache/Node_info_and_management/SHOW_QUERIES.md.json @@ -6,5 +6,13 @@ "russian": "# SHOW QUERIES\n\n\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `SHOW QUERIES` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.\n\n`SHOW QUERIES` возвращает информацию обо всех текущих выполняющихся запросах. Вывод представляет собой таблицу со следующей структурой:\n\n- `id`: ID запроса, который можно использовать в [KILL](../Node_info_and_management/KILL.md) для завершения запроса\n\n- `query`: Текст запроса или его часть\n\n- `time`: Время выполнения команды или сколько времени назад был выполнен запрос (в этом случае значение будет содержать `ago`)\n\n- `protocol`: [Протокол соединения](../Server_settings/Searchd.md#listen), возможные значения: `sphinx`, `mysql`, `http`, `ssl`, `compressed`, `replication` или их комбинации (например, `http,ssl` или `compressed,mysql`)\n\n- `host`: `ip:port` клиента\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nОбратитесь к [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md), если хотите получить информацию с точки зрения самих потоков.\n\n" }, "is_code_or_comment": false + }, + "dbbba81e4c62dd7416bfa607eeb141e273736a6711cf9f825d307b4edc1a80f5": { + "original": "# SHOW QUERIES\n\n\n\nCODE_BLOCK_0\n\n> NOTE: `SHOW QUERIES` requires [Manticore Buddy](../Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\n`SHOW QUERIES` returns information about all currently running queries. The output is a table with the following structure:\n\n- `id`: Query ID that can be used in [KILL](../Node_info_and_management/KILL.md) to terminate the query\n\n- `query`: Query statement or a portion of it\n\n- `time`: Time taken on command execution or how long ago the query was performed (in this case, the value will include `ago`)\n\n- `protocol`: [Connection protocol](../Server_settings/Searchd.md#listen), with possible values being `sphinx`, `mysql`, `http`, `ssl`, `compressed`, `replication`, or a combination (e.g., `http,ssl` or `compressed,mysql`)\n\n- `host`: Client's `ip:port`\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nRefer to [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md) if you'd like to gain insight from the perspective of the threads themselves.\n\n", + "translations": { + "chinese": "# SHOW QUERIES\n\n\n\nCODE_BLOCK_0\n\n> 注意：`SHOW QUERIES` 需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法工作，请确保 Buddy 已安装。\n\n`SHOW QUERIES` 返回所有当前正在运行的查询的信息。输出是一个结构如下的表：\n\n- `id`：查询 ID，可用于 [KILL](../Node_info_and_management/KILL.md) 中终止查询\n\n- `query`：查询语句或其部分内容\n\n- `time`：命令执行所用时间或距查询执行的时间（此情况下，值将包含 `ago`）\n\n- `protocol`： [连接协议](../Server_settings/Searchd.md#listen)，可能的值有 `sphinx`、`mysql`、`http`、`ssl`、`compressed`、`replication`，或组合形式（例如 `http,ssl` 或 `compressed,mysql`）\n\n- `host`：客户端的 `ip:port`\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n如果您想从线程本身的角度了解情况，请参考 [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md)。\n\n", + "russian": "# ПОКАЗАТЬ ЗАПРОСЫ\n\n\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `SHOW QUERIES` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если это не работает, убедитесь, что Buddy установлен.\n\n`SHOW QUERIES` возвращает информацию обо всех в данный момент выполняющихся запросах. Вывод представляет собой таблицу со следующей структурой:\n\n- `id`: ID запроса, который можно использовать в [KILL](../Node_info_and_management/KILL.md) для завершения запроса\n\n- `query`: Текст запроса или его часть\n\n- `time`: Время выполнения команды или как давно был выполнен запрос (в этом случае значение будет содержать `ago`)\n\n- `protocol`: [Протокол соединения](../Server_settings/Searchd.md#listen), возможные значения — `sphinx`, `mysql`, `http`, `ssl`, `compressed`, `replication` или их комбинации (например, `http,ssl` или `compressed,mysql`)\n\n- `host`: `ip:port` клиента\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nОбратитесь к [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md), если хотите получить информацию с точки зрения самих потоков.\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/SHOW_VERSION.md.json b/.translation-cache/Node_info_and_management/SHOW_VERSION.md.json index 291639e928..567f09140b 100644 --- a/.translation-cache/Node_info_and_management/SHOW_VERSION.md.json +++ b/.translation-cache/Node_info_and_management/SHOW_VERSION.md.json @@ -6,5 +6,13 @@ "russian": "# SHOW VERSION\n\n\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `SHOW VERSION` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если команда не работает, убедитесь, что Buddy установлен.\n\n`SHOW VERSION` предоставляет подробную информацию о версиях различных компонентов экземпляра Manticore Search. Эта команда особенно полезна администраторам и разработчикам, которым необходимо проверить версию Manticore Search, которую они используют, а также версии связанных компонентов.\n\nВ таблице вывода две колонки:\n\n- `Component`: В этой колонке указано название конкретного компонента Manticore Search.\n\n- `Version`: В этой колонке отображается информация о версии соответствующего компонента.\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n" }, "is_code_or_comment": false + }, + "2318403e2c8f61ef878bb2a2d3bb45349db08c5620c6461d8b9662b0e0c72672": { + "original": "# SHOW VERSION\n\n\n\nCODE_BLOCK_0\n\n> NOTE: `SHOW VERSION` requires [Manticore Buddy](../Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\n`SHOW VERSION` provides detailed version information of various components of the Manticore Search instance. This command is particularly useful for administrators and developers who need to verify the version of Manticore Search they are running, along with the versions of its associated components.\n\nThe output table includes two columns:\n\n- `Component`: This column names the specific component of Manticore Search.\n\n- `Version`: This column displays the version information for the respective component.\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "translations": { + "chinese": "# SHOW VERSION\n\n\n\nCODE_BLOCK_0\n\n> 注意：`SHOW VERSION` 需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。\n\n`SHOW VERSION` 提供 Manticore Search 实例各个组件的详细版本信息。此命令对于需要验证正在运行的 Manticore Search 版本及其相关组件版本的管理员和开发人员尤其有用。\n\n输出表包含两列：\n\n- `Component`：此列显示 Manticore Search 的具体组件名称。\n\n- `Version`：此列显示相应组件的版本信息。\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "russian": "# SHOW VERSION\n\n\n\nCODE_BLOCK_0\n\n> ПРИМЕЧАНИЕ: `SHOW VERSION` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если команда не работает, убедитесь, что Buddy установлен.\n\n`SHOW VERSION` предоставляет подробную информацию о версиях различных компонентов экземпляра Manticore Search. Эта команда особенно полезна администраторам и разработчикам, которым нужно проверить версию Manticore Search, которую они используют, а также версии связанных компонентов.\n\nВыходная таблица включает две колонки:\n\n- `Component`: В этой колонке указано название конкретного компонента Manticore Search.\n\n- `Version`: В этой колонке отображается информация о версии соответствующего компонента.\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md.json b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md.json index 69f1e37510..1c5ee5b061 100644 --- a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md.json +++ b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md.json @@ -6,5 +6,13 @@ "russian": "# SHOW TABLE INDEXES\n\n\n\nОператор SQL `SHOW TABLE INDEXES` отображает доступные вторичные индексы для указанной таблицы вместе с их свойствами. [Вторичные индексы](../../Server_settings/Searchd.md#secondary_indexes) улучшают производительность запросов, создавая дополнительные структуры данных, которые ускоряют поиск по определённым столбцам.\n\nСинтаксис:\n\nCODE_BLOCK_0\n\nОтображаемые свойства включают следующие столбцы:\n\n* **Name**: Имя вторичного индекса. Может использоваться в [подсказках оптимизатора запросов](../../Searching/Options.md#Query-optimizer-hints).\n\n* **Type**: Тип данных, хранящихся во вторичном индексе. Для простых атрибутов он совпадает с типом исходного атрибута. Для вторичных индексов, созданных из JSON-атрибутов, тип определяется путём сканирования всех документов и определения типов всех JSON-свойств.\n\n* **Enabled**: Указывает, включён ли индекс в данный момент и может ли использоваться для ускорения поиска. Когда атрибут обновляется, вторичный индекс для этого атрибута временно отключается до тех пор, пока индекс не будет перестроен. Вы можете перестроить отключённые индексы с помощью команды [ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index).\n\n* **Percent**: В RT-таблице разные дисковые чанки могут содержать разные вторичные индексы, особенно при использовании JSON-атрибутов. Этот процент показывает, сколько чанков имеют индекс с одинаковым именем, типом и состоянием включения.\n\n> **Примечание:** Для RT-таблиц вторичные индексы создаются только для дисковых чанков, а не для данных в RAM-сегментах. Когда вы впервые вставляете данные в RT-таблицу, они остаются в RAM, и вторичные индексы не отображаются. Индексы становятся видимыми только после сброса данных в дисковые чанки, что по умолчанию происходит автоматически, когда таблица становится активной (получает и вставки, и поисковые запросы).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n" }, "is_code_or_comment": false + }, + "d324812729d37e29901ccd63bf17e46a2294734fa4799819a74023c86e510c75": { + "original": "# SHOW TABLE INDEXES\n\n\n\nThe `SHOW TABLE INDEXES` SQL statement displays the secondary indexes available for a specified table, along with their properties. [Secondary indexes](../../Server_settings/Searchd.md#secondary_indexes) improve query performance by creating additional data structures that speed up searches on specific columns.\n\nThe syntax is:\n\nCODE_BLOCK_0\n\nThe displayed properties include the following columns:\n\n* **Name**: The name of the secondary index. Can be used in [query optimizer hints](../../Searching/Options.md#Query-optimizer-hints).\n\n* **Type**: The type of data stored in the secondary index. For plain attributes, it matches the type of the original attribute. For secondary indexes generated from JSON attributes, the type is deduced by scanning all documents and determining the types of all JSON properties.\n\n* **Enabled**: Indicates whether the index is currently enabled and can be used to improve search speed. When an attribute is updated, the secondary index for that attribute is temporarily disabled until the index is rebuilt. You can rebuild disabled indexes using the [ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index) command.\n\n* **Percent**: In an RT table, different disk chunks may contain different secondary indexes especially when JSON attributes are used. This percentage shows how many chunks have an index with the same name, type, and enabled state.\n\n> **Note:** For RT tables, secondary indexes are only created for disk chunks, not for data in RAM segments. When you first insert data into an RT table, it stays in RAM and no secondary indexes will be shown. The indexes become visible only after the data is flushed to disk chunks, which by default happens automatically when the table becomes active (receives both inserts and searches).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n", + "translations": { + "chinese": "# SHOW TABLE INDEXES\n\n\n\n`SHOW TABLE INDEXES` SQL 语句显示指定表可用的二级索引及其属性。[二级索引](../../Server_settings/Searchd.md#secondary_indexes)通过创建额外的数据结构来加速对特定列的搜索，从而提高查询性能。\n\n语法为：\n\nCODE_BLOCK_0\n\n显示的属性包括以下列：\n\n* **Name**：二级索引的名称。可以在[查询优化器提示](../../Searching/Options.md#Query-optimizer-hints)中使用。\n\n* **Type**：二级索引中存储的数据类型。对于普通属性，类型与原始属性的类型相匹配。对于由 JSON 属性生成的二级索引，类型通过扫描所有文档并确定所有 JSON 属性的类型来推断。\n\n* **Enabled**：指示索引当前是否启用且可用于提升搜索速度。当属性更新时，该属性的二级索引会暂时被禁用，直到索引被重建。您可以使用[ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index)命令重建被禁用的索引。\n\n* **Percent**：在 RT 表中，不同的磁盘块可能包含不同的二级索引，特别是在使用 JSON 属性时。此百分比显示有多少块包含相同名称、类型和启用状态的索引。\n\n> **注意：** 对于 RT 表，二级索引仅为磁盘块创建，而不为 RAM 分段中的数据创建。当您首次将数据插入 RT 表时，数据保留在 RAM 中，且不会显示二级索引。只有在数据被刷新到磁盘块后索引才可见，默认情况下，这会在表变为活动状态（同时接收插入和搜索）时自动发生。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n", + "russian": "# ПОКАЗАТЬ ИНДЕКСЫ ТАБЛИЦЫ\n\n\n\nОператор SQL `SHOW TABLE INDEXES` отображает вторичные индексы, доступные для указанной таблицы, вместе с их свойствами. [Вторичные индексы](../../Server_settings/Searchd.md#secondary_indexes) улучшают производительность запросов, создавая дополнительные структуры данных, которые ускоряют поиск по определённым столбцам.\n\nСинтаксис:\n\nCODE_BLOCK_0\n\nОтображаемые свойства включают в себя следующие столбцы:\n\n* **Name**: Имя вторичного индекса. Может использоваться в [подсказках оптимизатора запросов](../../Searching/Options.md#Query-optimizer-hints).\n\n* **Type**: Тип данных, хранящихся во вторичном индексе. Для простых атрибутов он соответствует типу исходного атрибута. Для вторичных индексов, сгенерированных из JSON-атрибутов, тип определяется сканированием всех документов и определением типов всех свойств JSON.\n\n* **Enabled**: Указывает, включён ли индекс в данный момент и может ли использоваться для ускорения поиска. Когда атрибут обновляется, вторичный индекс для этого атрибута временно отключается до тех пор, пока индекс не будет перестроен. Вы можете перестроить отключённые индексы с помощью команды [ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index).\n\n* **Percent**: В RT-таблице разные дисковые чанки могут содержать разные вторичные индексы, особенно при использовании JSON-атрибутов. Этот процент показывает, в каком количестве чанков имеется индекс с одинаковым именем, типом и состоянием включения.\n\n> **Примечание:** Для RT-таблиц вторичные индексы создаются только для дисковых чанков, а не для данных в RAM-сегментах. При первом добавлении данных в RT-таблицу они остаются в RAM, и вторичные индексы отображаться не будут. Индексы становятся видимыми только после сброса данных в дисковые чанки, что по умолчанию происходит автоматически, когда таблица становится активной (получает как вставки, так и запросы).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md.json b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md.json index fecb8dde53..c001ff53c3 100644 --- a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md.json +++ b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md.json @@ -6,5 +6,13 @@ "russian": "# SHOW TABLE SETTINGS\n\n\n\n`SHOW TABLE SETTINGS` — это SQL-запрос, который отображает настройки для каждой таблицы в формате, совместимом с конфигурационным файлом.\n\nСинтаксис:\n\nCODE_BLOCK_0\n\nВывод похож на опцию [--dumpconfig](../../Miscellaneous_tools.md#indextool) утилиты [indextool](../../Miscellaneous_tools.md#indextool). Отчет предоставляет подробный разбор всех настроек таблицы, включая параметры токенизатора и словаря.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\nВы также можете указать номер конкретного чанка, чтобы просмотреть настройки определенного чанка в RT-таблице. Нумерация начинается с 0.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n" }, "is_code_or_comment": false + }, + "0aeff153ef9a5567952d4c1d1b520ece44ef37b62aff29cef10aba51c32a4e4b": { + "original": "# SHOW TABLE SETTINGS\n\n\n\n`SHOW TABLE SETTINGS` is an SQL statement that displays per-table settings in a format compatible with the config file.\n\nThe syntax is:\n\nCODE_BLOCK_0\n\nThe output resembles the [--dumpconfig](../../Miscellaneous_tools.md#indextool) option of the [indextool](../../Miscellaneous_tools.md#indextool) utility. The report provides a breakdown of all table settings, including tokenizer and dictionary options.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\nYou can also specify a particular chunk number to view the settings of a specific chunk in an RT table. The numbering is 0-based.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n", + "translations": { + "chinese": "# SHOW TABLE SETTINGS\n\n\n\n`SHOW TABLE SETTINGS` 是一个 SQL 语句，用于以与配置文件兼容的格式显示每个表的设置。\n\n语法如下：\n\nCODE_BLOCK_0\n\n输出类似于 [indextool](../../Miscellaneous_tools.md#indextool) 工具的 [--dumpconfig](../../Miscellaneous_tools.md#indextool) 选项。报告提供了所有表设置的详细分解，包括分词器和字典选项。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n您还可以指定特定的块编号，以查看 RT 表中特定块的设置。编号从 0 开始。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n", + "russian": "# SHOW TABLE SETTINGS\n\n\n\n`SHOW TABLE SETTINGS` — это SQL-запрос, который отображает настройки для каждой таблицы в формате, совместимом с конфигурационным файлом.\n\nСинтаксис:\n\nCODE_BLOCK_0\n\nВывод похож на опцию [--dumpconfig](../../Miscellaneous_tools.md#indextool) утилиты [indextool](../../Miscellaneous_tools.md#indextool). В отчёте приводится разбивка всех настроек таблицы, включая опции токенизатора и словаря.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\nТакже можно указать номер конкретного чанка, чтобы просмотреть настройки определённого чанка в RT-таблице. Нумерация начинается с 0.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md.json b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md.json index b277508035..4d00f669b0 100644 --- a/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md.json +++ b/.translation-cache/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md.json @@ -14,5 +14,13 @@ "russian": "# SHOW TABLE STATUS\n\n\n\n`SHOW TABLE STATUS` — это SQL-запрос, который отображает различные статистические данные по каждой таблице.\n\nСинтаксис:\n\nCODE_BLOCK_0\n\nВ зависимости от типа индекса отображаемая статистика включает разный набор строк:\n\n* **template**: `index_type`.\n\n* **distributed**: `index_type`, `query_time_1min`, `query_time_5min`,`query_time_15min`,`query_time_total`, `exact_query_time_1min`, `exact_query_time_5min`, `exact_query_time_15min`, `exact_query_time_total`, `found_rows_1min`, `found_rows_5min`, `found_rows_15min`, `found_rows_total`.\n\n* **percolate**: `index_type`, `stored_queries`, `ram_bytes`, `disk_bytes`, `max_stack_need`, `average_stack_base`, `\n\n desired_thread_stack`, `tid`, `tid_saved`, `query_time_1min`, `query_time_5min`,`query_time_15min`,`query_time_total`, `exact_query_time_1min`, `exact_query_time_5min`, `exact_query_time_15min`, `exact_query_time_total`, `found_rows_1min`, `found_rows_5min`, `found_rows_15min`, `found_rows_total`.\n\n* **plain**: `index_type`, `indexed_documents`, `indexed_bytes`, может быть набор `field_tokens_*` и `total_tokens`, `ram_bytes`, `disk_bytes`, `disk_mapped`, `disk_mapped_cached`, `disk_mapped_doclists`, `disk_mapped_cached_doclists`, `disk_mapped_hitlists`, `disk_mapped_cached_hitlists`, `killed_documents`, `killed_rate`, `query_time_1min`, `query_time_5min`,`query_time_15min`,`query_time_total`, `exact_query_time_1min`, `exact_query_time_5min`, `exact_query_time_15min`, `exact_query_time_total`, `found_rows_1min`, `found_rows_5min`, `found_rows_15min`, `found_rows_total`.\n\n* **rt**: `index_type`, `indexed_documents`, `indexed_bytes`, может быть набор `field_tokens_*` и `total_tokens`, `ram_bytes`, `disk_bytes`, `disk_mapped`, `disk_mapped_cached`, `disk_mapped_doclists`, `disk_mapped_cached_doclists`, `disk_mapped_hitlists`, `disk_mapped_cached_hitlists`, `killed_documents`, `killed_rate`, `ram_chunk`, `ram_chunk_segments_count`, `disk_chunks`, `mem_limit`, `mem_limit_rate`, `ram_bytes_retired`, `optimizing`, `locked`, `tid`, `tid_saved`, `query_time_1min`, `query_time_5min`,`query_time_15min`,`query_time_total`, `exact_query_time_1min`, `exact_query_time_5min`, `exact_query_time_15min`, `exact_query_time_total`, `found_rows_1min`, `found_rows_5min`, `found_rows_15min`, `found_rows_total`.\n\nЗначения означают следующее:\n\n* `index_type`: в настоящее время один из `disk`, `rt`, `percolate`, `template` и `distributed`.\n\n* `indexed_documents`: количество проиндексированных документов.\n\n* `indexed_bytes`: общий размер проиндексированного текста. Обратите внимание, что это значение не строгое, так как в полнотекстовом индексе невозможно строго восстановить исходный текст для измерения.\n\n* `stored_queries`: количество перколяторных запросов, сохранённых в таблице.\n\n* `field_tokens_XXX`: опционально, общая длина по полям (в токенах) по всей таблице (используется внутренне для функций ранжирования `BM25A` и `BM25F`). Доступно только для таблиц, созданных с `index_field_lengths=1`.\n\n* `total_tokens`: опционально, общая сумма всех `field_tokens_XXX`.\n\n* `ram_bytes`: общий объём оперативной памяти, занимаемый таблицей.\n\n* `disk_bytes`: общий объём дискового пространства, занимаемый таблицей.\n\n* `disk_mapped`: общий размер отображений файлов.\n\n* `disk_mapped_cached`: общий размер отображений файлов, фактически кэшируемых в ОЗУ.\n\n* `disk_mapped_doclists` и `disk_mapped_cached_doclists`: часть общих и кэшируемых отображений, относящаяся к спискам документов.\n\n* `disk_mapped_hitlists` и `disk_mapped_cached_hitlists`: часть общих и кэшируемых отображений, относящаяся к спискам попаданий. Значения doclists и hitlists показаны отдельно, так как они обычно занимают большой объём (например, около 90% от размера всей таблицы).\n\n* `killed_documents` и `killed_rate`: первое указывает количество удалённых документов, второе — отношение удалённых к проиндексированным. Технически удаление документа означает подавление его в результатах поиска, но он физически остаётся в таблице и будет удалён только после слияния/оптимизации таблицы.\n\n* `ram_chunk`: размер блока оперативной памяти в таблице реального времени или перколяторной таблице.\n\n* `ram_chunk_segments_count`: блок оперативной памяти внутренне состоит из сегментов, обычно не более 32. Эта строка показывает текущее количество.\n\n* `disk_chunks`: количество дисковых блоков в таблице реального времени.\n\n* `mem_limit`: фактическое значение `rt_mem_limit` для таблицы.\n\n* `mem_limit_rate`: коэффициент, при котором блок оперативной памяти будет сброшен как дисковый блок, например, если `rt_mem_limit` равен 128M и коэффициент 50%, новый дисковый блок будет сохранён, когда блок оперативной памяти превысит 64M.\n\n* `ram_bytes_retired`: размер мусора в блоках оперативной памяти (например, удалённые или заменённые документы, ещё не окончательно удалённые).\n\n* `optimizing`: значение больше 0 указывает, что таблица в данный момент оптимизируется (т.е. сейчас происходит слияние некоторых дисковых блоков).\n\n* `locked`: значение больше 0 указывает, что таблица в данный момент заблокирована с помощью [FREEZE](../../Securing_and_compacting_a_table/Freezing_a_table.md#Freezing-a-table). Число показывает, сколько раз таблица была заморожена. Например, таблица может быть заморожена `manticore-backup`, а затем снова заморожена репликацией. Полностью разморожена она должна быть только тогда, когда ни один другой процесс не требует её заморозки.\n\n* `max_stack_need`: объём стека, необходимый для вычисления самой сложной из сохранённых перколяторных запросов. Это динамическое значение, зависящее от деталей сборки, таких как компилятор, оптимизация, оборудование и т.д.\n\n* `average_stack_base`: объём стека, обычно занимаемый в начале вычисления перколяторного запроса.\n\n* `desired_thread_stack`: сумма вышеуказанных значений, округлённая до ближайшего значения, кратного 128 байтам. Если это значение больше `thread_stack`, выполнение `call pq` по этой таблице может быть невозможно, так как некоторые сохранённые запросы завершатся с ошибкой. Значение `thread_stack` по умолчанию — 1M (1048576); другие значения должны быть настроены." }, "is_code_or_comment": false + }, + "e2cd2a5f5b4a5f440e6ee749b43872cd770312673bd3cc59480a5fb1ec9a5bb4": { + "original": "* `tid` and `tid_saved`: represent the state of saving the table. `tid` increases with each change (transaction). `tid_saved` shows the max `tid` of the state saved in a RAM chunk in `.ram` file. When the numbers differ, some changes exist only in RAM and are also backed by binlog (if enabled). Performing `FLUSH TABLE` or scheduling periodic flushing saves these changes. After flushing, the binlog is cleared, and `tid_saved` represents the new actual state.\n\n* `query_time_*`, `exact_query_time_*`: query execution time statistics for the last 1 minute, 5 minutes, 15 minutes, and total since server start; data is encapsulated as a JSON object, including the number of queries and min, max, avg, 95, and 99 percentile values.\n\n* `found_rows_*`: statistics of rows found by queries; provided for the last 1 minute, 5 minutes, 15 minutes, and total since server start; data is encapsulated as a JSON object, including the number of queries and min, max, avg, 95, and 99 percentile values.\n\n* `command_*`: counters for the total number of times a specific command has been successfully executed against this table.\n\n* `search_stats_ms_*`: statistics on the execution time (in milliseconds) for search queries. The * indicates the time window (e.g., 1min, 5min, 15min, total). These stats are calculated over sliding windows of 1, 5, and 15 minutes, showing average, minimum, maximum, and 95th/99th percentile values for query times.\n\n* `insert_replace_stats_ms_*`: statistics on the execution time (in milliseconds) for insert and replace queries. The * indicates the time window (e.g., 1min, 5min, 15min, total). These stats are calculated over sliding windows of 1, 5, and 15 minutes, showing average, minimum, maximum, and 95th/99th percentile values for query times.\n\n* `update_stats_ms_*`: statistics on the execution time (in milliseconds) for update queries. The * indicates the time window (e.g., 1min, 5min, 15min, total). These stats are calculated over sliding windows of 1, 5, and 15 minutes, showing average, minimum, maximum, and 95th/99th percentile values for query times.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n", + "translations": { + "chinese": "* `tid` 和 `tid_saved`：表示表的保存状态。`tid` 随每次更改（事务）递增。`tid_saved` 显示保存在 `
.ram` 文件的 RAM 块中的状态的最大 `tid`。当两者数字不同时，表示有些更改只存在于 RAM 中，同时也由 binlog 备份（如果已启用）。执行 `FLUSH TABLE` 或定期刷新保存这些更改。刷新后，binlog 被清除，`tid_saved` 表示新的实际状态。\n\n* `query_time_*`、`exact_query_time_*`：查询执行时间统计，涵盖最近 1 分钟、5 分钟、15 分钟及自服务器启动以来的总计；数据封装为 JSON 对象，包括查询数量及最小、最大、平均、95 和 99 百分位值。\n\n* `found_rows_*`：查询找到的行数统计，提供最近 1 分钟、5 分钟、15 分钟及自服务器启动以来的总计；数据封装为 JSON 对象，包括查询数量及最小、最大、平均、95 和 99 百分位值。\n\n* `command_*`：针对该表成功执行特定命令的总次数计数器。\n\n* `search_stats_ms_*`：搜索查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。\n\n* `insert_replace_stats_ms_*`：插入和替换查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。\n\n* `update_stats_ms_*`：更新查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n", + "russian": "* `tid` и `tid_saved`: представляют состояние сохранения таблицы. `tid` увеличивается с каждой изменением (транзакцией). `tid_saved` показывает максимальный `tid` состояния, сохранённого в RAM-чанке в файле `
.ram`. Когда значения отличаются, некоторые изменения существуют только в RAM и также поддерживаются binlog (если он включён). Выполнение `FLUSH TABLE` или планирование периодической очистки сохраняет эти изменения. После очистки binlog очищается, и `tid_saved` представляет новое фактическое состояние.\n\n* `query_time_*`, `exact_query_time_*`: статистика времени выполнения запросов за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные представлены в виде JSON-объекта, включающего количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентили.\n\n* `found_rows_*`: статистика найденных строк по запросам; предоставляется за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные представлены в виде JSON-объекта, включающего количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентили.\n\n* `command_*`: счётчики общего количества успешных выполнений определённой команды для этой таблицы.\n\n* `search_stats_ms_*`: статистика времени выполнения (в миллисекундах) поисковых запросов. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов.\n\n* `insert_replace_stats_ms_*`: статистика времени выполнения (в миллисекундах) вставки и замены записей. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов.\n\n* `update_stats_ms_*`: статистика времени выполнения (в миллисекундах) обновляющих запросов. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### TypeScript:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Faceted_search.md.json b/.translation-cache/Searching/Faceted_search.md.json index 81fce95451..b8526f5bce 100644 --- a/.translation-cache/Searching/Faceted_search.md.json +++ b/.translation-cache/Searching/Faceted_search.md.json @@ -22,5 +22,29 @@ "russian": "# Фасетный поиск\n\nФасетный поиск так же важен для современного поискового приложения, как [автозаполнение](../Searching/Autocomplete.md), [исправление опечаток](../Searching/Spell_correction.md) и подсветка поисковых ключевых слов [highlighting](../Searching/Highlighting.md), особенно в продуктах электронной коммерции.\n\n![Faceted search](faceted.png)\n\nФасетный поиск полезен при работе с большими объемами данных и различными взаимосвязанными свойствами, такими как размер, цвет, производитель или другие факторы. При запросе больших объемов данных результаты поиска часто включают множество записей, которые не соответствуют ожиданиям пользователя. Фасетный поиск позволяет конечному пользователю явно определить критерии, которым должны удовлетворять результаты поиска.\n\nВ Manticore Search есть оптимизация, которая сохраняет набор результатов исходного запроса и повторно использует его для каждого вычисления фасета. Поскольку агрегации применяются к уже вычисленному подмножеству документов, они выполняются быстро, и общее время выполнения часто может быть лишь немного дольше, чем у первоначального запроса. Фасеты можно добавлять к любому запросу, и фасет может быть любым атрибутом или выражением. Результат фасета включает значения фасета и количество по фасету. К фасетам можно получить доступ с помощью SQL-запроса `SELECT`, объявляя их в самом конце запроса.\n\n## Агрегации\n\n\n\n### SQL\n\nЗначения фасета могут исходить из атрибута, свойства JSON внутри JSON-атрибута или выражения. Значения фасета также могут иметь псевдонимы, но **псевдоним должен быть уникальным** во всех наборах результатов (основной набор результатов запроса и другие наборы результатов фасетов). Значение фасета выводится из агрегированного атрибута/выражения, но также может исходить из другого атрибута/выражения.\n\nCODE_BLOCK_0\n\nНесколько объявлений фасетов должны разделяться пробелом.\n\n### HTTP JSON\n\nФасеты можно определить в узле `aggs`:\n\nCODE_BLOCK_1\n\nгде:\n\n* `group name` — это псевдоним, присвоенный агрегации\n\n* значение `field` должно содержать имя атрибута или выражения, по которому выполняется фасетирование\n\n* необязательный параметр `size` указывает максимальное количество бакетов, включаемых в результат. Если не указан, наследует лимит основного запроса. Подробнее см. в разделе [Размер результата фасета](../Searching/Faceted_search.md#Size-of-facet-result).\n\n* необязательный параметр `sort` задает массив атрибутов и/или дополнительных свойств с использованием того же синтаксиса, что и [\"параметр sort в основном запросе\"](../Searching/Sorting_and_ranking.md#Sorting-via-JSON).\n\nНабор результатов будет содержать узел `aggregations` с возвращенными фасетами, где `key` — агрегированное значение, а `doc_count` — количество в агрегации.\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n\n\n### Фасетирование по агрегации другого атрибута\n\nДанные можно фасетировать, агрегируя другой атрибут или выражение. Например, если документы содержат как идентификатор бренда, так и его название, можно вернуть в фасете названия брендов, но агрегировать идентификаторы брендов. Это можно сделать с помощью `FACET {expr1} BY {expr2}`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\n\n\n### Фасетирование без дубликатов\n\nЕсли нужно удалить дубликаты из бакетов, возвращаемых FACET, можно использовать `DISTINCT field_name`, где `field_name` — поле, по которому нужно выполнить дедупликацию. Это также может быть `id` (что является значением по умолчанию), если вы выполняете FACET-запрос к распределенной таблице и не уверены, что у вас уникальные идентификаторы в таблицах (таблицы должны быть локальными и иметь одинаковую схему).\n\nЕсли в вашем запросе несколько объявлений FACET, `field_name` должен быть одинаковым во всех них.\n\n`DISTINCT` возвращает дополнительный столбец `count(distinct ...)` перед столбцом `count(*)`, что позволяет получить оба результата без необходимости делать дополнительный запрос.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n\n\n### Фасет по выражениям\n\nФасеты могут агрегировать по выражениям. Классический пример — сегментация цен по определенным диапазонам:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48" }, "is_code_or_comment": false + }, + "38d7b321c4263e225b72e875da6c40c814f8670820efd756478145798d5d6d29": { + "original": "\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n### Returned result set\n\nWhen using SQL, a search with facets returns multiple result sets. The MySQL client/library/connector used **must** support multiple result sets in order to access the facet result sets.\n\n\n\n### Performance\n\nInternally, the `FACET` is a shorthand for executing a multi-query where the first query contains the main search query and the rest of the queries in the batch have each a clustering. As in the case of multi-query, the common query optimization can kick in for a faceted search, meaning the search query is executed only once, and the facets operate on the search query result, with each facet adding only a fraction of time to the total query time.\n\nTo check if the faceted search ran in an optimized mode, you can look in the [query log](../Logging/Query_logging.md), where all logged queries will contain an `xN` string, where `N` is the number of queries that ran in the optimized group. Alternatively, you can check the output of the [SHOW META](../Node_info_and_management/SHOW_META.md) statement, which will display a `multiplier` metric:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\n", + "translations": { + "chinese": "\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n### Returned result set\n\nWhen using SQL, a search with facets returns multiple result sets. The MySQL client/library/connector used **must** support multiple result sets in order to access the facet result sets.\n\n\n\n### Performance\n\nInternally, the `FACET` is a shorthand for executing a multi-query where the first query contains the main search query and the rest of the queries in the batch have each a clustering. As in the case of multi-query, the common query optimization can kick in for a faceted search, meaning the search query is executed only once, and the facets operate on the search query result, with each facet adding only a fraction of time to the total query time.\n\nTo check if the faceted search ran in an optimized mode, you can look in the [query log](../Logging/Query_logging.md), where all logged queries will contain an `xN` string, where `N` is the number of queries that ran in the optimized group. Alternatively, you can check the output of the [SHOW META](../Node_info_and_management/SHOW_META.md) statement, which will display a `multiplier` metric:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\n", + "russian": "\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n### Returned result set\n\nWhen using SQL, a search with facets returns multiple result sets. The MySQL client/library/connector used **must** support multiple result sets in order to access the facet result sets.\n\n\n\n### Performance\n\nInternally, the `FACET` is a shorthand for executing a multi-query where the first query contains the main search query and the rest of the queries in the batch have each a clustering. As in the case of multi-query, the common query optimization can kick in for a faceted search, meaning the search query is executed only once, and the facets operate on the search query result, with each facet adding only a fraction of time to the total query time.\n\nTo check if the faceted search ran in an optimized mode, you can look in the [query log](../Logging/Query_logging.md), where all logged queries will contain an `xN` string, where `N` is the number of queries that ran in the optimized group. Alternatively, you can check the output of the [SHOW META](../Node_info_and_management/SHOW_META.md) statement, which will display a `multiplier` metric:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\n" + }, + "is_code_or_comment": true + }, + "b188ed3649053ef92c8fe405b39e92b4ddb2f7f69b7643b4027db08e148a2850": { + "original": "CODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\n\n\n### Facet over multi-level grouping\n\nFacets can aggregate over multi-level grouping, with the result set being the same as if the query performed a multi-level grouping:\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\n\n\n### Facet over histogram values\n\nFacets can aggregate over histogram values by constructing fixed-size buckets over the values.\n\nThe key function is:\n\nCODE_BLOCK_59\n\nThe histogram argument `interval` must be positive, and the histogram argument `offset` must be positive and less than `interval`. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys.\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n### Facet over histogram date values\n\nFacets can aggregate over histogram date values, which is similar to the normal histogram. The difference is that the interval is specified using a date or time expression. Such expressions require special support because the intervals are not always of fixed length. Values are rounded to the closest bucket using the following key function:\n\nCODE_BLOCK_66\n\nThe histogram parameter `calendar_interval` understands months to have different amounts of days.\n\nUnlike `calendar_interval`, the `fixed_interval` parameter uses a fixed number of units and does not deviate, regardless of where it falls on the calendar. However `fixed_interval` cannot process units such as months because a month is not a fixed quantity. Attempting to specify units like weeks or months for `fixed_interval` will result in an error.\n\nThe accepted intervals are described in the [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29) expression. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys.\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\n\n\n### Facet over set of ranges\n\nFacets can aggregate over a set of ranges. The values are checked against the bucket range, where each bucket includes the `from` value and excludes the `to` value from the range.\n\nSetting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array.\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\n\n\n### Facet over set of date ranges\n\nFacets can aggregate over a set of date ranges, which is similar to the normal range. The difference is that the `from` and `to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions. This aggregation includes the `from` value and excludes the `to` value for each range. Setting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array.\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\n\n\n### Ordering in facet result\n\nFacets support the `ORDER BY` clause just like a standard query. Each facet can have its own ordering, and the facet ordering doesn't affect the main result set's ordering, which is determined by the main query's `ORDER BY`. Sorting can be done on attribute name, count (using `COUNT(*)`, `COUNT(DISTINCT attribute_name)`), or the special `FACET()` function, which provides the aggregated data values. By default, a query with `ORDER BY COUNT(*)` will sort in descending order.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n\n\n### Size of facet result\n\nBy default, each facet result set is limited to 20 values. The number of facet values can be controlled with the `LIMIT` clause individually for each facet by providing either a number of values to return in the format `LIMIT count` or with an offset as `LIMIT offset, count`.\n\nThe maximum facet values that can be returned is limited by the query's `max_matches` setting. If you want to implement dynamic `max_matches` (limiting `max_matches` to offset + per page for better performance), it must be taken into account that a too low `max_matches` value can affect the number of facet values. In this case, a minimum `max_matches` value should be used that is sufficient to cover the number of facet values.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101", + "translations": { + "chinese": "CODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\n\n\n### 多层分组的 Facet\n\nFacet 可以对多层分组进行聚合，结果集与查询执行多层分组的结果相同：\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\n\n\n### 基于直方图值的 Facet\n\nFacet 能够通过在值上构建固定大小的桶对直方图值进行聚合。\n\n关键函数为：\n\nCODE_BLOCK_59\n\n直方图参数 `interval` 必须为正数，直方图参数 `offset` 必须为正数且小于 `interval`。默认情况下，桶作为数组返回。直方图参数 `keyed` 将响应变为带有桶键的字典。\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n### 基于直方图日期值的 Facet\n\nFacet 可以对直方图日期值进行聚合，这与普通直方图类似。区别在于间隔使用日期或时间表达式指定。此类表达式需要特殊支持，因为间隔长度并不总是固定的。值使用以下关键函数四舍五入至最近的桶：\n\nCODE_BLOCK_66\n\n直方图参数 `calendar_interval` 理解月份天数不同。\n\n与 `calendar_interval` 不同，`fixed_interval` 参数使用固定数量的单位，且不会偏移，无论其在日历中的位置如何。然而，`fixed_interval` 无法处理诸如月份之类的单位，因为月份不是固定的数量。尝试为 `fixed_interval` 指定诸如周或月的单位将导致错误。\n\n接受的间隔在 [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29) 表达式中有描述。默认情况下，桶作为数组返回。直方图参数 `keyed` 将响应变为带有桶键的字典。\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\n\n\n### 基于一组范围的 Facet\n\nFacet 可以对一组范围进行聚合。值会与桶区间进行对比，每个桶包含 `from` 值，但不包含 `to` 值。\n\n将 `keyed` 属性设置为 `true` 会使响应变成以桶键为键的字典，而不是数组。\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\n\n\n### 基于一组日期范围的 Facet\n\nFacet 可以对一组日期范围进行聚合，这与普通的范围类似。区别在于 `from` 和 `to` 值可以用[日期数学](../Functions/Date_and_time_functions.md#Date-math)表达式表示。此聚合包含每个范围的 `from` 值，但不包含 `to` 值。将 `keyed` 属性设置为 `true` 会使响应变成以桶键为键的字典，而不是数组。\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\n\n\n### Facet 结果中的排序\n\nFacet 支持 `ORDER BY` 子句，就像标准查询一样。每个 Facet 可以有自己的排序，Facet 的排序不会影响主结果集的排序，主结果的排序由主查询中的 `ORDER BY` 决定。排序可以基于属性名、计数（使用 `COUNT(*)`，`COUNT(DISTINCT attribute_name)`），或特殊的 `FACET()` 函数，它提供聚合的数据值。默认情况下，使用 `ORDER BY COUNT(*)` 的查询将按降序排序。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n\n\n### Facet 结果的大小\n\n默认情况下，每个 Facet 结果集限制为 20 个值。每个 Facet 的返回值数量可以通过 `LIMIT` 子句单独控制，格式为 `LIMIT count` 返回指定数量的值，或 `LIMIT offset, count` 以偏移量和数量返回。\n\n返回的最大 Facet 值受查询的 `max_matches` 设置限制。如果你想实现动态的 `max_matches`（将 `max_matches` 限制为偏移量加每页数量以提高性能），必须考虑到过低的 `max_matches` 可能会影响 Facet 值的数量。在这种情况下，应使用足以涵盖 Facet 值数量的最小 `max_matches` 值。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101", + "russian": "CODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\n\n\n### Фасет по многоуровневой группировке\n\nФасеты могут агрегировать по многоуровневой группировке, при этом результирующий набор будет таким же, как если бы запрос выполнял многоуровневую группировку:\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\n\n\n### Фасет по значениям гистограммы\n\nФасеты могут агрегировать по значениям гистограммы, создавая фиксированные интервалы (баки) по значениям.\n\nКлючевая функция:\n\nCODE_BLOCK_59\n\nАргумент `interval` гистограммы должен быть положительным, а аргумент `offset` должен быть положительным и меньше `interval`. По умолчанию баки возвращаются в виде массива. Аргумент гистограммы `keyed` делает ответ словарём с ключами баков.\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n### Фасет по значениям гистограммы даты\n\nФасеты могут агрегировать по значениям гистограммы даты, что похоже на обычную гистограмму. Разница в том, что интервал указывается с помощью выражения даты или времени. Такие выражения требуют специальной поддержки, так как интервалы не всегда имеют фиксированную длину. Значения округляются до ближайшего бака с помощью следующей ключевой функции:\n\nCODE_BLOCK_66\n\nПараметр гистограммы `calendar_interval` учитывает, что в месяцах разное количество дней.\n\nВ отличие от `calendar_interval`, параметр `fixed_interval` использует фиксированное количество единиц и не отклоняется, независимо от положения в календаре. Однако `fixed_interval` не может обрабатывать такие единицы, как месяцы, поскольку месяц — это не фиксированный период. Попытка указать такие единицы, как недели или месяцы для `fixed_interval`, приведёт к ошибке.\n\nДопустимые интервалы описаны в выражении [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29). По умолчанию баки возвращаются в виде массива. Аргумент гистограммы `keyed` делает ответ словарём с ключами баков.\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\n\n\n### Фасет по набору диапазонов\n\nФасеты могут агрегировать по набору диапазонов. Значения проверяются на принадлежность диапазону бака, при этом каждый бак включает значение `from` и исключает значение `to` из диапазона.\n\nУстановка свойства `keyed` в `true` делает ответ словарём с ключами баков вместо массива.\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\n\n\n### Фасет по набору диапазонов дат\n\nФасеты могут агрегировать по набору диапазонов дат, что похоже на обычный диапазон. Разница в том, что значения `from` и `to` могут быть выражены с помощью выражений [Date math](../Functions/Date_and_time_functions.md#Date-math). Эта агрегация включает значение `from` и исключает значение `to` для каждого диапазона. Установка свойства `keyed` в `true` делает ответ словарём с ключами баков вместо массива.\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\n\n\n### Сортировка в результате фасета\n\nФасеты поддерживают предложение `ORDER BY`, как и стандартный запрос. Каждый фасет может иметь свою собственную сортировку, и сортировка фасета не влияет на сортировку основного набора результатов, которая определяется `ORDER BY` основного запроса. Сортировка может осуществляться по имени атрибута, количеству (с помощью `COUNT(*)`, `COUNT(DISTINCT attribute_name)`) или специальной функции `FACET()`, которая предоставляет агрегированные значения. По умолчанию запрос с `ORDER BY COUNT(*)` сортирует результаты по убыванию.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n\n\n### Размер результата фасета\n\nПо умолчанию каждый результат фасета ограничен 20 значениями. Количество значений фасета можно контролировать с помощью предложения `LIMIT` отдельно для каждого фасета, указав либо количество возвращаемых значений в формате `LIMIT count`, либо с оффсетом в формате `LIMIT offset, count`.\n\nМаксимальное количество значений фасета ограничено настройкой `max_matches` запроса. Если вы хотите реализовать динамическое управление `max_matches` (ограничение `max_matches` значением offset + количество на страницу для лучшей производительности), необходимо учитывать, что слишком маленькое `max_matches` может повлиять на количество значений фасета. В этом случае следует использовать минимальное значение `max_matches`, достаточное для покрытия количества значений фасета.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101" + }, + "is_code_or_comment": false + }, + "7b6d505591cefe878ba6f57c47d9d5457d4dd366baebea6654a3c63bad50056f": { + "original": "# Faceted search\n\nFaceted search is as crucial to a modern search application as [autocomplete](../Searching/Autocomplete.md), [spell correction](../Searching/Spell_correction.md), and search keywords [highlighting](../Searching/Highlighting.md), especially in e-commerce products.\n\n![Faceted search](faceted.png)\n\nFaceted search comes in handy when dealing with large quantities of data and various interconnected properties, such as size, color, manufacturer, or other factors. When querying vast amounts of data, search results frequently include numerous entries that don't match the user's expectations. Faceted search enables the end user to explicitly define the criteria they want their search results to satisfy.\n\nIn Manticore Search, there's an optimization that maintains the result set of the original query and reuses it for each facet calculation. Since the aggregations are applied to an already calculated subset of documents, they're fast, and the total execution time can often be only slightly longer than the initial query. Facets can be added to any query, and the facet can be any attribute or expression. A facet result includes the facet values and the facet counts. Facets can be accessed using the SQL `SELECT` statement by declaring them at the very end of the query.\n\n## Aggregations\n\n\n\n### SQL\n\nThe facet values can originate from an attribute, a JSON property within a JSON attribute, or an expression. Facet values can also be aliased, but the **alias must be unique** across all result sets (main query result set and other facets result sets). The facet value is derived from the aggregated attribute/expression, but it can also come from another attribute/expression.\n\nCODE_BLOCK_0\n\nMultiple facet declarations must be separated by a whitespace.\n\n### HTTP JSON\n\nFacets can be defined in the `aggs` node:\n\nCODE_BLOCK_1\n\nwhere:\n\n* `group name` is an alias assigned to the aggregation\n\n* `field` value must contain the name of the attribute or expression being faceted\n\n* optional `size` specifies the maximum number of buckets to include in the result. When not specified, it inherits the main query's limit. More details can be found in the [Size of facet result](../Searching/Faceted_search.md#Size-of-facet-result) section.\n\n* optional `sort` specifies an array of attributes and/or additional properties using the same syntax as the [\"sort\" parameter in the main query](../Searching/Sorting_and_ranking.md#Sorting-via-JSON).\n\nThe result set will contain an `aggregations` node with the returned facets, where `key` is the aggregated value and `doc_count` is the aggregation count.\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n\n\n### Faceting by aggregation over another attribute\n\nData can be faceted by aggregating another attribute or expression. For example if the documents contain both the brand id and name, we can return in facet the brand names, but aggregate the brand ids. This can be done by using `FACET {expr1} BY {expr2}`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n\n\n### Faceting without duplicates\n\nIf you need to remove duplicates from the buckets returned by FACET, you can use `DISTINCT field_name`, where `field_name` is the field by which you want to perform deduplication. It can also be `id` (which is the default) if you make a FACET query against a distributed table and are not sure whether you have unique ids in the tables (the tables should be local and have the same schema).\n\nIf you have multiple FACET declarations in your query, `field_name` should be the same in all of them.\n\n`DISTINCT` returns an additional column `count(distinct ...)` before the column `count(*)`, allowing you to obtain both results without needing to make another query.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n\n\n### Facet over expressions\n\nFacets can aggregate over expressions. A classic example is the segmentation of prices by specific ranges:\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n", + "translations": { + "chinese": "# 分面搜索\n\n分面搜索对于现代搜索应用程序而言，与[自动完成](../Searching/Autocomplete.md)、[拼写纠正](../Searching/Spell_correction.md)和搜索关键词[高亮显示](../Searching/Highlighting.md)一样重要，特别是在电子商务产品中。\n\n![分面搜索](faceted.png)\n\n在处理大量数据和各种相互关联的属性（如尺寸、颜色、制造商或其他因素）时，分面搜索非常有用。在查询大量数据时，搜索结果通常包含许多不符合用户期望的条目。分面搜索使最终用户能够明确指定他们希望搜索结果满足的条件。\n\n在 Manticore Search 中，有一种优化方法保持原始查询的结果集，并将其重用于每个分面计算。由于聚合应用于已经计算好的文档子集，因此它们执行得很快，总执行时间通常只比初始查询稍长。分面可以添加到任何查询中，分面可以是任何属性或表达式。分面结果包括分面值和分面计数。可以通过 SQL 的 `SELECT` 语句在查询末尾声明来访问分面。\n\n## 聚合\n\n\n\n### SQL\n\n分面值可以来自属性、JSON 属性中的 JSON 属性，或表达式。分面值也可以被别名，但**别名必须在所有结果集中唯一**（包括主查询结果集和其他分面结果集）。分面值来源于聚合的属性/表达式，但也可以来自另一个属性/表达式。\n\nCODE_BLOCK_0\n\n多个分面声明必须用空格分隔。\n\n### HTTP JSON\n\n分面可以在 `aggs` 节点中定义：\n\nCODE_BLOCK_1\n\n其中：\n\n* `group name` 是分配给聚合的别名\n\n* `field` 的值必须包含被分面的属性或表达式名称\n\n* 可选的 `size` 指定结果中包含桶的最大数量。如果未指定，则继承主查询的限制。更多细节可参见[分面结果的大小](../Searching/Faceted_search.md#Size-of-facet-result)部分。\n\n* 可选的 `sort` 指定一个属性和/或附加属性的数组，使用与[主查询中的“sort”参数](../Searching/Sorting_and_ranking.md#Sorting-via-JSON)相同的语法。\n\n结果集将包含一个 `aggregations` 节点及返回的分面，其中 `key` 是聚合值，`doc_count` 是聚合计数。\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n\n\n### 通过另一个属性的聚合进行分面\n\n数据可以通过聚合另一个属性或表达式进行分面。例如，如果文档同时包含品牌 id 和名称，我们可以在分面中返回品牌名称，但以品牌 id 进行聚合。这可以通过使用 `FACET {expr1} BY {expr2}` 来实现。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n\n\n### 分面去重\n\n如果需要从 FACET 返回的桶中去重，可以使用 `DISTINCT field_name`，其中 `field_name` 是用于去重的字段。如果对分布式表进行 FACET 查询而不确定表中是否有唯一 id（表应为本地且具有相同的模式），那么 `field_name` 可以是 `id`（默认）。\n\n如果查询中有多个 FACET 声明，`field_name` 应该在所有声明中保持一致。\n\n`DISTINCT` 会在 `count(*)` 列之前返回额外的 `count(distinct ...)` 列，允许你在不需要另一个查询的情况下获取这两种结果。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n\n\n### 基于表达式的分面\n\n分面可以对表达式进行聚合。一个经典的例子是按特定区间对价格进行分段：\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n", + "russian": "# Многофакторный поиск\n\nМногофакторный поиск так же важен для современного поискового приложения, как [автодополнение](../Searching/Autocomplete.md), [исправление орфографии](../Searching/Spell_correction.md) и подсветка поисковых ключевых слов [highlighting](../Searching/Highlighting.md), особенно в продуктах электронной коммерции.\n\n![Многофакторный поиск](faceted.png)\n\nМногофакторный поиск полезен при работе с большим объемом данных и различными взаимосвязанными свойствами, такими как размер, цвет, производитель или другие факторы. При запросе больших объемов данных результаты поиска часто содержат множество записей, которые не соответствуют ожиданиям пользователя. Многофакторный поиск позволяет конечному пользователю явно определить критерии, которым должны удовлетворять результаты его поиска.\n\nВ Manticore Search есть оптимизация, которая сохраняет результат исходного запроса и повторно использует его для каждого расчета фактора. Поскольку агрегации применяются к уже вычисленному подмножеству документов, они работают быстро, и общее время выполнения часто бывает лишь немного больше времени первичного запроса. Факторы можно добавлять к любому запросу, и фактором может быть любой атрибут или выражение. Результат фактора включает значения фактора и количество по фактору. К факторам можно получить доступ, используя SQL-оператор `SELECT`, объявляя их в самом конце запроса.\n\n## Агрегации\n\n\n\n### SQL\n\nЗначения фактора могут исходить из атрибута, свойства JSON внутри JSON-атрибута или выражения. Значения фактора также могут иметь псевдонимы, но **псевдоним должен быть уникальным** во всех наборах результатов (основной набор результатов запроса и другие наборы результатов факторов). Значение фактора получается из агрегированного атрибута/выражения, но также может браться из другого атрибута/выражения.\n\nCODE_BLOCK_0\n\nНесколько объявлений факторов должны быть разделены пробелом.\n\n### HTTP JSON\n\nФакторы могут быть определены в узле `aggs`:\n\nCODE_BLOCK_1\n\nгде:\n\n* `group name` — псевдоним, присвоенный агрегации\n\n* значение `field` должно содержать имя атрибута или выражения, по которому происходит факторинг\n\n* необязательный `size` указывает максимальное количество корзин, включаемых в результат. Если не указано, наследует лимит основного запроса. Подробнее см. в разделе [Размер результата фактора](../Searching/Faceted_search.md#Size-of-facet-result).\n\n* необязательный `sort` задает массив атрибутов и/или дополнительных свойств, используя такой же синтаксис, как параметр [\"sort\" в основном запросе](../Searching/Sorting_and_ranking.md#Sorting-via-JSON).\n\nНабор результатов будет содержать узел `aggregations` с возвращаемыми факторами, где `key` — агрегированное значение, а `doc_count` — количество в агрегации.\n\nCODE_BLOCK_2\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\n\n\n### Факторинг по агрегации другого атрибута\n\nДанные могут быть факторированы путем агрегации другого атрибута или выражения. Например, если в документах содержатся и id бренда, и название, мы можем вернуть в факторе названия брендов, но агрегировать id брендов. Это можно сделать с помощью конструкции `FACET {expr1} BY {expr2}`\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n\n\n### Факторинг без дубликатов\n\nЕсли необходимо удалить дубликаты из корзин, возвращаемых FACET, можно использовать `DISTINCT field_name`, где `field_name` — поле, по которому требуется выполнить дедупликацию. Это также может быть `id` (который является значением по умолчанию), если выполняется FACET-запрос к распределенной таблице и не уверены, есть ли уникальные идентификаторы в таблицах (таблицы должны быть локальными и иметь одинаковую схему).\n\nЕсли в вашем запросе несколько объявлений FACET, `field_name` должен быть одинаковым во всех из них.\n\n`DISTINCT` возвращает дополнительный столбец `count(distinct ...)` перед столбцом `count(*)`, что позволяет получить оба результата без необходимости делать еще один запрос.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\n\n\n### Факторинг по выражениям\n\nФакторы могут агрегировать по выражениям. Классический пример — сегментация цен по определенным диапазонам:\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Full_text_matching/Basic_usage.md.json b/.translation-cache/Searching/Full_text_matching/Basic_usage.md.json index 020540e8b8..d4c9b41e95 100644 --- a/.translation-cache/Searching/Full_text_matching/Basic_usage.md.json +++ b/.translation-cache/Searching/Full_text_matching/Basic_usage.md.json @@ -6,5 +6,13 @@ "russian": "# MATCH\n\nКлауза `MATCH` позволяет выполнять полнотекстовый поиск в текстовых полях. Входная строка запроса [токенизируется](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md) с использованием тех же настроек, которые применялись к тексту при индексировании. Помимо токенизации входного текста, строка запроса поддерживает ряд [операторов полнотекстового поиска](../../Searching/Full_text_matching/Operators.md), которые задают различные правила того, как ключевые слова должны обеспечивать валидное совпадение.\n\nКлаузы полнотекстового поиска могут комбинироваться с атрибутными [фильтрами](../../Searching/Filters.md) как логическое И. **Логические ИЛИ между полнотекстовыми совпадениями и атрибутными фильтрами не поддерживаются**.\n\nЗапрос с match всегда выполняется первым в процессе фильтрации, за ним следуют [атрибутные фильтры](../../Searching/Filters.md). Атрибутные фильтры применяются к результату запроса match. Запрос без клаузы match называется fullscan.\n\nВ `SELECT` должно быть не более одного `MATCH()`.\n\nИспользуя [синтаксис полнотекстового запроса](../../Searching/Full_text_matching/Operators.md), поиск выполняется по всем индексированным текстовым полям документа, если выражение не требует совпадения внутри поля (например, поиск фразы) или не ограничено операторами поля.\n\nПри использовании запросов с [JOIN](../../Searching/Joining.md), `MATCH()` может принимать необязательный второй параметр, который указывает, к какой таблице должен применяться полнотекстовый поиск. По умолчанию полнотекстовый запрос применяется к левой таблице в операции `JOIN`:\n\nCODE_BLOCK_0\n\nЭто позволяет выполнять полнотекстовый поиск по конкретным таблицам в операции соединения. Для получения дополнительной информации о использовании MATCH с JOIN смотрите раздел [Joining tables](../../Searching/Joining.md).\n\n## SQL\n\n\n\nCODE_BLOCK_1\n\n- `'search query'`: Строка полнотекстового поискового запроса, которая может включать различные [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md).\n\n- `table_name`: (Опционально) Имя таблицы, к которой применяется полнотекстовый поиск, используется в запросах с `JOIN` для указания таблицы, отличной от левой по умолчанию.\n\nОператор [SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) использует клаузу [MATCH](../../Searching/Full_text_matching/Basic_usage.md), которая должна идти после WHERE, для выполнения полнотекстового поиска. `MATCH()` принимает входную строку, в которой доступны все [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nПример более сложного запроса с использованием MATCH и фильтров WHERE.\n\nCODE_BLOCK_4\n\n\n\n## HTTP JSON\n\n\n\nПолнотекстовый поиск доступен в эндпоинте `/search` и в HTTP-клиентах. Для выполнения полнотекстового поиска можно использовать следующие клаузы:\n\n### match\n\n\"match\" — это простой запрос, который ищет указанные ключевые слова в указанных полях.\n\nCODE_BLOCK_5\n\nВы можете указать список полей:\n\nCODE_BLOCK_6\n\nИли использовать `_all` или `*` для поиска по всем полям.\n\nВы можете искать по всем полям, кроме одного, используя \"!field\":\n\nCODE_BLOCK_7\n\nПо умолчанию ключевые слова объединяются оператором OR. Однако вы можете изменить это поведение с помощью клаузы \"operator\":\n\nCODE_BLOCK_8\n\n\"operator\" может быть установлен в \"or\" или \"and\".\n\nТакже можно применить модификатор `boost`. Он повышает значение [IDF](../../Searching/Options.md#idf)_score слова на указанный коэффициент в рейтинговых оценках, которые учитывают IDF в своих вычислениях. Это не влияет на процесс сопоставления.\n\nCODE_BLOCK_9\n\n### match_phrase\n\n\"match_phrase\" — это запрос, который ищет полную фразу. Он похож на оператор фразы в SQL. Пример:\n\nCODE_BLOCK_10\n\n### query_string\n\n\"query_string\" принимает входную строку в синтаксисе `MATCH()` для полнотекстового запроса.\n\nCODE_BLOCK_11\n\n### match_all\n\n\"match_all\" принимает пустой объект и возвращает документы из таблицы без применения атрибутных фильтров или полнотекстового поиска. Альтернативно, можно просто опустить клаузу `query` в запросе, что даст тот же эффект.\n\nCODE_BLOCK_12\n\n### Комбинирование полнотекстовой фильтрации с другими фильтрами\n\nВсе клаузы полнотекстового поиска могут комбинироваться с операторами [must](../../Searching/Filters.md#must), [must_not](../../Searching/Filters.md#must_not) и [should](../../Searching/Filters.md#should) в [JSON `bool` запросе](../../Searching/Filters.md#bool-query).\n\n\n\nПримеры:\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nPython\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\njavascript\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\njava\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nC#\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nRust\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nGo\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\n" }, "is_code_or_comment": false + }, + "c7f0792a7297dba4a252e47110803e3d0c43f2bcf25730ca0aa609f59b0f5ed2": { + "original": "# MATCH\n\nThe `MATCH` clause allows for full-text searches in text fields. The input query string is [tokenized](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md) using the same settings applied to the text during indexing. In addition to the tokenization of input text, the query string supports a number of [full-text operators](../../Searching/Full_text_matching/Operators.md) that enforce various rules on how keywords should provide a valid match.\n\nFull-text match clauses can be combined with attribute [filters](../../Searching/Filters.md) as an AND boolean. **OR relations between full-text matches and attribute filters are not supported**.\n\nThe match query is always executed first in the filtering process, followed by the [attribute filters](../../Searching/Filters.md). The attribute filters are applied to the result set of the match query. A query without a match clause is called a fullscan.\n\nThere must be at most one `MATCH()` in the `SELECT` clause.\n\nUsing the [full-text query syntax](../../Searching/Full_text_matching/Operators.md), matching is performed across all indexed text fields of a document, unless the expression requires a match within a field (like phrase search) or is limited by field operators.\n\nWhen using [JOIN](../../Searching/Joining.md) queries, `MATCH()` can accept an optional second parameter that specifies which table the full-text search should be applied to. By default, the full-text query is applied to the left table in the `JOIN` operation:\n\nCODE_BLOCK_0\n\nThis allows you to perform full-text searches on specific tables in a join operation. For more details on using MATCH with JOINs, see the [Joining tables](../../Searching/Joining.md) section.\n\n## SQL\n\n\n\nCODE_BLOCK_1\n\n- `'search query'`: The full-text search query string, which can include various [full-text operators](../../Searching/Full_text_matching/Operators.md).\n\n- `table_name`: (Optional) The name of the table to apply the full-text search to, used in `JOIN` queries to specify a different table than the default left table.\n\nThe [SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) statement uses a [MATCH](../../Searching/Full_text_matching/Basic_usage.md) clause, which must come after WHERE, for performing full-text searches. `MATCH()` accepts an input string in which all [full-text operators](../../Searching/Full_text_matching/Operators.md) are available.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nAn example of a more complex query using MATCH with WHERE filters.\n\nCODE_BLOCK_6\n\n\n\n## HTTP JSON\n\n\n\nFull-text matching is available in the `/search` endpoint and in HTTP-based clients. The following clauses can be used for performing full-text matches:\n\n### match\n\n\"match\" is a simple query that matches the specified keywords in the specified fields.\n\nCODE_BLOCK_7\n\nYou can specify a list of fields:\n\nCODE_BLOCK_8\n\nOr you can use `_all` or `*` to search all fields.\n\nYou can search all fields except one using \"!field\":\n\nCODE_BLOCK_9\n\nBy default, keywords are combined using the OR operator. However, you can change that behavior using the \"operator\" clause:\n\nCODE_BLOCK_10\n\n\"operator\" can be set to \"or\" or \"and\".\n\nThe `boost` modifier can also be applied. It raises the word [IDF](../../Searching/Options.md#idf)_score by the indicated factor in ranking scores that incorporate IDF into their calculations. It does not impact the matching process in any manner.\n\nCODE_BLOCK_11\n\n### match_phrase\n\n\"match_phrase\" is a query that matches the entire phrase. It is similar to a phrase operator in SQL. Here's an example:\n\nCODE_BLOCK_12\n\n### query_string\n\n\"query_string\" accepts an input string as a full-text query in `MATCH()` syntax.\n\nCODE_BLOCK_13\n\n### match_all\n\n\"match_all\" accepts an empty object and returns documents from the table without performing any attribute filtering or full-text matching. Alternatively, you can just omit the `query` clause in the request which will have the same effect.\n\nCODE_BLOCK_14\n\n### Combining full-text filtering with other filters\n\nAll full-text match clauses can be combined with [must](../../Searching/Filters.md#must), [must_not](../../Searching/Filters.md#must_not), and [should](../../Searching/Filters.md#should) operators of a [JSON `bool` query](../../Searching/Filters.md#bool-query).\n\n\n\nExamples:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nPython\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\njavascript\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\njava\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nC#\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nRust\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nGo\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\n", + "translations": { + "chinese": "# MATCH\n\n`MATCH` 子句允许在文本字段中进行全文搜索。输入的查询字符串会使用与索引期间应用于文本的相同设置进行[分词](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md)。除了对输入文本的分词外，查询字符串还支持许多[全文操作符](../../Searching/Full_text_matching/Operators.md)，用于规定关键字应如何提供有效匹配的各种规则。\n\n全文匹配子句可以与属性[过滤器](../../Searching/Filters.md)组合，作为 AND 布尔关系。**全文匹配与属性过滤器之间不支持 OR 关系**。\n\n匹配查询总是在过滤过程中首先执行，随后是[属性过滤器](../../Searching/Filters.md)。属性过滤器应用于匹配查询的结果集。没有 MATCH 子句的查询称为全表扫描（fullscan）。\n\n`SELECT` 子句中最多只能有一个 `MATCH()`。\n\n使用[全文查询语法](../../Searching/Full_text_matching/Operators.md)时，匹配会跨文档的所有已索引文本字段执行，除非表达式要求在某字段内匹配（如短语搜索）或受字段操作符所限制。\n\n在使用[JOIN](../../Searching/Joining.md)查询时，`MATCH()` 可以接受一个可选的第二个参数，指定全文搜索应应用于哪个表。默认情况下，全文查询应用于 `JOIN` 操作中的左表：\n\nCODE_BLOCK_0\n\n这允许你在连接操作中针对特定表执行全文搜索。有关在 JOIN 中使用 MATCH 的更多详细信息，请参见[连接表](../../Searching/Joining.md)部分。\n\n## SQL\n\n\n\nCODE_BLOCK_1\n\n- `'search query'`：全文搜索查询字符串，可以包含各种[全文操作符](../../Searching/Full_text_matching/Operators.md)。\n\n- `table_name`：（可选）要应用全文搜索的表名，用于 `JOIN` 查询中指定不同于默认左表的表。\n\n[SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) 语句使用 [MATCH](../../Searching/Full_text_matching/Basic_usage.md) 子句，必须放在 WHERE 之后，用于执行全文搜索。`MATCH()` 接受输入字符串，其中所有[全文操作符](../../Searching/Full_text_matching/Operators.md)都可用。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n一个使用 MATCH 和 WHERE 过滤器进行更复杂查询的示例。\n\nCODE_BLOCK_6\n\n\n\n## HTTP JSON\n\n\n\n全文匹配功能可在 `/search` 端点及 HTTP 客户端中使用。以下子句可用于执行全文匹配：\n\n### match\n\n\"match\" 是简单查询，在指定字段中匹配指定的关键字。\n\nCODE_BLOCK_7\n\n你可以指定字段列表：\n\nCODE_BLOCK_8\n\n或者使用 `_all` 或 `*` 来搜索所有字段。\n\n你也可以使用 \"!field\" 搜索除某字段外的所有字段：\n\nCODE_BLOCK_9\n\n默认情况下，关键字通过 OR 运算符组合。但你可以通过 \"operator\" 子句更改此行为：\n\nCODE_BLOCK_10\n\n\"operator\" 可设置为 \"or\" 或 \"and\"。\n\n也可以应用 `boost` 修改符。它通过指定的因子提升词的 [IDF](../../Searching/Options.md#idf) 分数（在评分中结合 IDF 的排名分数中体现）。它不会以任何方式影响匹配过程。\n\nCODE_BLOCK_11\n\n### match_phrase\n\n\"match_phrase\" 是匹配整个短语的查询，类似于 SQL 的短语操作符，示例：\n\nCODE_BLOCK_12\n\n### query_string\n\n\"query_string\" 接受一个作为 `MATCH()` 语法的全文查询的输入字符串。\n\nCODE_BLOCK_13\n\n### match_all\n\n\"match_all\" 接受一个空对象，返回表中的文档，不执行任何属性过滤或全文匹配。或者，直接省略请求中的 `query` 子句也有同样效果。\n\nCODE_BLOCK_14\n\n### 结合全文过滤和其他过滤器\n\n所有全文匹配子句都可以结合 [must](../../Searching/Filters.md#must)、[must_not](../../Searching/Filters.md#must_not) 和 [should](../../Searching/Filters.md#should) 操作符使用 [JSON `bool` 查询](../../Searching/Filters.md#bool-query)。\n\n\n\n示例：\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nPython\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\njavascript\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\njava\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nC#\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nRust\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nGo\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\n", + "russian": "# MATCH\n\nКлауза `MATCH` позволяет выполнять полнотекстовый поиск в текстовых полях. Входящая строка запроса [токенизируется](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md) с использованием тех же настроек, которые применялись к тексту при индексировании. Помимо токенизации входного текста, строка запроса поддерживает ряд [операторов полнотекстового поиска](../../Searching/Full_text_matching/Operators.md), которые задают различные правила, с помощью которых ключевые слова должны обеспечивать валидное совпадение.\n\nКлаузы полнотекстового сопоставления могут комбинироваться с [фильтрами](../../Searching/Filters.md) по атрибутам, используя логическое И (AND). **Отношения ИЛИ между полнотекстовыми совпадениями и атрибутными фильтрами не поддерживаются**.\n\nЗапрос сопоставления всегда выполняется первым на этапе фильтрации, а затем применяются [фильтры атрибутов](../../Searching/Filters.md). Фильтры атрибутов применяются к результату запроса сопоставления. Запрос без клаузы match называется fullscan.\n\nВ клауза `SELECT` может присутствовать не более одной `MATCH()`.\n\nИспользуя [синтаксис полнотекстовых запросов](../../Searching/Full_text_matching/Operators.md), сопоставление выполняется по всем проиндексированным текстовым полям документа, если только выражение не требует совпадения в определённом поле (например, поиск фразы) или не ограничено операторами полей.\n\nПри использовании запросов с [JOIN](../../Searching/Joining.md), `MATCH()` может принимать необязательный второй параметр, который указывает таблицу, к которой следует применить полнотекстовый поиск. По умолчанию полнотекстовый запрос применяется к левой таблице в операции `JOIN`:\n\nCODE_BLOCK_0\n\nЭто позволяет выполнять полнотекстовый поиск по конкретным таблицам в операции объединения. Для подробностей использования MATCH с JOIN смотрите раздел [Объединение таблиц](../../Searching/Joining.md).\n\n## SQL\n\n\n\nCODE_BLOCK_1\n\n- `'search query'`: Строка полнотекстового поискового запроса, которая может включать различные [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md).\n\n- `table_name`: (необязательно) Имя таблицы, к которой применяется полнотекстовый поиск, используется в запросах с `JOIN` для указания таблицы, отличной от левой по умолчанию.\n\nОператор [SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) использует клауза [MATCH](../../Searching/Full_text_matching/Basic_usage.md), который должен идти после WHERE, для выполнения полнотекстовых поисков. `MATCH()` принимает входную строку, в которой доступны все [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nПример более сложного запроса с использованием MATCH и фильтров WHERE.\n\nCODE_BLOCK_6\n\n\n\n## HTTP JSON\n\n\n\nПолнотекстовое сопоставление доступно через эндпоинт `/search` и в HTTP-клиентах. Для полнотекстовых сопоставлений можно использовать следующие клаузы:\n\n### match\n\n\"match\" — простой запрос, который сопоставляет указанные ключевые слова в заданных полях.\n\nCODE_BLOCK_7\n\nМожно указать список полей:\n\nCODE_BLOCK_8\n\nИли использовать `_all` или `*` для поиска по всем полям.\n\nМожно искать по всем полям, кроме одного, используя \"!field\":\n\nCODE_BLOCK_9\n\nПо умолчанию ключевые слова объединяются оператором OR. Однако это поведение можно изменить с помощью клаузы \"operator\":\n\nCODE_BLOCK_10\n\n\"operator\" может быть установлен в \"or\" или \"and\".\n\nТакже можно использовать модификатор `boost`. Он увеличивает значение [IDF](../../Searching/Options.md#idf)_оценки слова на указанный коэффициент в ранжировочных оценках, которые учитывают IDF при вычислениях. Это не влияет на процесс сопоставления.\n\nCODE_BLOCK_11\n\n### match_phrase\n\n\"match_phrase\" — запрос, который сопоставляет всю фразу целиком. Это похоже на оператор фразы в SQL. Пример:\n\nCODE_BLOCK_12\n\n### query_string\n\n\"query_string\" принимает входную строку в синтаксисе `MATCH()` и использует ее как полнотекстовый запрос.\n\nCODE_BLOCK_13\n\n### match_all\n\n\"match_all\" принимает пустой объект и возвращает документы из таблицы без применения фильтров по атрибутам или полнотекстового сопоставления. Альтернативно можно просто опустить клауза `query` в запросе — эффект будет тот же.\n\nCODE_BLOCK_14\n\n### Комбинирование полнотекстового фильтра с другими фильтрами\n\nВсе клаузы полнотекстового сопоставления можно комбинировать с операторами [must](../../Searching/Filters.md#must), [must_not](../../Searching/Filters.md#must_not) и [should](../../Searching/Filters.md#should) JSON `bool` запроса [bool](../../Searching/Filters.md#bool-query).\n\n\n\nПримеры:\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nPython\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\njavascript\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\njava\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nC#\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nRust\n\n\n\nCODE_BLOCK_33\n\n\n\nCODE_BLOCK_34\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nGo\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Full_text_matching/Profiling.md.json b/.translation-cache/Searching/Full_text_matching/Profiling.md.json index ca879e7355..236829fbed 100644 --- a/.translation-cache/Searching/Full_text_matching/Profiling.md.json +++ b/.translation-cache/Searching/Full_text_matching/Profiling.md.json @@ -14,5 +14,21 @@ "russian": "# Поиск с профилированием\n\n## Как интерпретируется запрос\n\nРассмотрим этот пример сложного запроса:\n\nCODE_BLOCK_0\n\nПолное значение этого поиска:\n\n* Найти слова 'hello' и 'world' рядом друг с другом в любом поле документа;\n\n* Кроме того, в том же документе должны содержаться слова 'example' и 'program' в поле заголовка, с не более чем 5 словами между ними (не включая 5); (например, \"example PHP program\" подойдет, а \"example script to introduce outside data into the correct context for your program\" — нет, так как между двумя терминами 5 или более слов)\n\n* Более того, в том же документе должно быть слово 'python' в поле body, при этом исключая 'php' или 'perl';\n\n* Наконец, в том же документе должно содержаться слово 'code' в любом поле.\n\nОператор OR имеет приоритет над AND, поэтому \"looking for cat | dog | mouse\" означает \"looking for (cat | dog | mouse)\", а не \"(looking for cat) | dog | mouse\".\n\nЧтобы понять, как будет выполняться запрос, Manticore Search предоставляет инструменты профилирования запросов для изучения дерева запроса, сгенерированного выражением запроса.\n\n\n\n## Профилирование дерева запроса в SQL\n\nЧтобы включить профилирование полнотекстового запроса с помощью SQL-запроса, необходимо активировать его перед выполнением нужного запроса:\n\nCODE_BLOCK_1\n\nЧтобы просмотреть дерево запроса, выполните команду `SHOW PLAN` сразу после выполнения запроса:\n\nCODE_BLOCK_2\n\nЭта команда вернет структуру выполненного запроса. Имейте в виду, что 3 оператора — SET profiling, сам запрос и SHOW — должны выполняться в одной сессии.\n\n## Профилирование запроса в HTTP JSON\n\nПри использовании протокола HTTP JSON можно просто включить `\"profile\":true`, чтобы получить в ответе структуру дерева полнотекстового запроса.\n\nCODE_BLOCK_3\n\nВ ответе будет объект `profile`, содержащий член `query`.\n\nСвойство `query` содержит преобразованное дерево полнотекстового запроса. Каждый узел состоит из:\n\n* `type`: тип узла, который может быть AND, OR, PHRASE, KEYWORD и т.д.\n\n* `description`: поддерево запроса для этого узла, представленное в виде строки (в формате `SHOW PLAN`)\n\n* `children`: дочерние узлы, если есть\n\n* `max_field_pos`: максимальная позиция в поле\n\nУ узла ключевого слова дополнительно будут:\n\n* `word`: преобразованное ключевое слово.\n\n* `querypos`: позиция этого ключевого слова в запросе.\n\n* `excluded`: ключевое слово исключено из запроса.\n\n* `expanded`: ключевое слово добавлено расширением префикса.\n\n* `field_start`: ключевое слово должно появиться в начале поля.\n\n* `field_end`: ключевое слово должно появиться в конце поля.\n\n* `boost`: IDF ключевого слова будет умножен на это значение.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nPython\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\njavascript\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\njava\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nC#\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nRust\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nGo\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\nВ некоторых случаях оцениваемое дерево запроса может значительно отличаться от исходного из-за расширений и других преобразований.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nPython\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\njavascript\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\njava\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nC#\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nRust\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nGo\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n## Профилирование без выполнения запроса\n\n\n\nSQL-оператор `EXPLAIN QUERY` позволяет отобразить дерево выполнения для заданного полнотекстового запроса без фактического выполнения поискового запроса по таблице.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\n\n\n`EXPLAIN QUERY ... option format=dot` позволяет отобразить дерево выполнения заданного полнотекстового запроса в иерархическом формате, подходящем для визуализации с помощью существующих инструментов, таких как https://dreampuf.github.io/GraphvizOnline:\n\n![EXPLAIN QUERY graphviz example](graphviz.png)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n## Просмотр значений факторов совпадения\n\n\n\nПри использовании ранжировщика выражений можно вывести значения вычисленных факторов с помощью функции [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29).\n\nФункция возвращает:" }, "is_code_or_comment": false + }, + "0686def7c0fc93a6b31b69fa324b21d9b5333dc35e22e51c0d57a21fd8a85e52": { + "original": "When using an expression ranker, it's possible to reveal the values of the calculated factors with the [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29) function.\n\nThe function returns:\n\n* The values of document-level factors (such as bm25, field_mask, doc_word_count)\n\n* A list of each field that generated a hit (including lcs, hit_count, word_count, sum_idf, min_hit_pos, etc.)\n\n* A list of each keyword from the query along with their tf and idf values\n\nThese values can be utilized to understand why certain documents receive lower or higher scores in a search or to refine the existing ranking expression.\n\n\n\nExample:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n", + "translations": { + "chinese": "当使用表达式排序器时，可以通过[PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29)函数揭示计算因子的值。\n\n该函数返回：\n\n* 文档级别因子的值（例如 bm25、field_mask、doc_word_count）\n\n* 生成命中的每个字段的列表（包括 lcs、hit_count、word_count、sum_idf、min_hit_pos 等）\n\n* 查询中的每个关键字及其 tf 和 idf 值的列表\n\n这些值可用于了解为什么某些文档在搜索中得分较低或较高，或者用于完善现有的排序表达式。\n\n\n\n示例：\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n", + "russian": "При использовании ранжировщика выражений возможно получить значения вычисленных факторов с помощью функции [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29).\n\nФункция возвращает:\n\n* Значения факторов на уровне документа (таких как bm25, field_mask, doc_word_count)\n\n* Список каждого поля, сгенерировавшего совпадение (включая lcs, hit_count, word_count, sum_idf, min_hit_pos и др.)\n\n* Список каждого ключевого слова из запроса вместе с их значениями tf и idf\n\nЭти значения могут быть использованы для понимания причин, по которым определённые документы получают более низкие или высокие оценки в поиске, или для уточнения существующего выражения ранжирования.\n\n\n\nПример:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n" + }, + "is_code_or_comment": false + }, + "510ecffdcaa6d93a4c475ba0ab8db70808085c100220a9a0c0c97e23ea83fd1a": { + "original": "# Search profiling\n\n## How a query is interpreted\n\nConsider this complex query example:\n\nCODE_BLOCK_0\n\nThe full meaning of this search is:\n\n* Locate the words 'hello' and 'world' adjacently in any field within a document;\n\n* Additionally, the same document must also contain the words 'example' and 'program' in the title field, with up to, but not including, 5 words between them; (For instance, \"example PHP program\" would match, but \"example script to introduce outside data into the correct context for your program\" would not, as there are 5 or more words between the two terms)\n\n* Furthermore, the same document must have the word 'python' in the body field, while excluding 'php' or 'perl';\n\n* Finally, the same document must include the word 'code' in any field.\n\nThe OR operator takes precedence over AND, so \"looking for cat | dog | mouse\" means \"looking for (cat | dog | mouse)\" rather than \"(looking for cat) | dog | mouse\".\n\nTo comprehend how a query will be executed, Manticore Search provides query profiling tools to examine the query tree generated by a query expression.\n\n\n\n## Profiling the query tree in SQL\n\nTo enable full-text query profiling with an SQL statement, you must activate it before executing the desired query:\n\nCODE_BLOCK_1\n\nTo view the query tree, execute the `SHOW PLAN` command immediately after running the query:\n\nCODE_BLOCK_2\n\nThis command will return the structure of the executed query. Keep in mind that the 3 statements - SET profiling, the query, and SHOW - must be executed within the same session.\n\n## Profiling the query in HTTP JSON\n\nWhen using the HTTP JSON protocol we can just enable `\"profile\":true` to get in response the full-text query tree structure.\n\nCODE_BLOCK_3\n\nThe response will include a `profile` object containing a `query` member.\n\nThe `query` property holds the transformed full-text query tree. Each node consists of:\n\n* `type`: node type, which can be AND, OR, PHRASE, KEYWORD, etc.\n\n* `description`: query subtree for this node represented as a string (in `SHOW PLAN` format)\n\n* `children`: any child nodes, if present\n\n* `max_field_pos`: maximum position within a field\n\n A keyword node will additionally include:\n\n* `word`: the transformed keyword.\n\n* `querypos`: position of this keyword in the query.\n\n* `excluded`: keyword excluded from the query.\n\n* `expanded`: keyword added by prefix expansion.\n\n* `field_start`: keyword must appear at the beginning of the field.\n\n* `field_end`: keyword must appear at the end of the field.\n\n* `boost`: the keyword's IDF will be multiplied by this value.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nPython\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\njavascript\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\njava\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nC#\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nRust\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nGo\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\nIn some instances, the evaluated query tree may significantly differ from the original one due to expansions and other transformations.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nPython\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\njavascript\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\njava\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nC#\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nRust\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nGo\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n## Profiling without running a query\n\n\n\nThe SQL statement `EXPLAIN QUERY` enables the display of the execution tree for a given full-text query without performing an actual search query on the table.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n`EXPLAIN QUERY ... option format=dot` allows displaying the execution tree of a provided full-text query in a hierarchical format suitable for visualization by existing tools, such as https://dreampuf.github.io/GraphvizOnline:\n\n![EXPLAIN QUERY graphviz example](graphviz.png)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n## Viewing the match factors values\n\n", + "translations": { + "chinese": "# 搜索分析\n\n## 查询的解析方式\n\n考虑下面这个复杂的查询示例：\n\nCODE_BLOCK_0\n\n此搜索的完整含义是：\n\n* 在文档的任意字段中定位相邻的单词 'hello' 和 'world'；\n\n* 此外，同一文档的标题字段中必须包含单词 'example' 和 'program'，这两个词之间最多（但不包括）有 5 个单词；（例如，“example PHP program”会匹配，但“example script to introduce outside data into the correct context for your program”不会，因为这两个词之间有 5 个或更多单词）\n\n* 此外，同一文档中正文字段必须包含词 'python'，同时排除 'php' 或 'perl'；\n\n* 最后，同一文档中任意字段必须包含单词 'code'。\n\nOR 运算符优先于 AND，因此“looking for cat | dog | mouse”意味着“looking for (cat | dog | mouse)”，而不是“(looking for cat) | dog | mouse”。\n\n为了理解查询将如何执行，Manticore Search 提供了查询分析工具来检查由查询表达式生成的查询树。\n\n\n\n## 使用 SQL 进行查询树分析\n\n要用 SQL 语句启用全文查询分析，必须在执行所需查询之前激活它：\n\nCODE_BLOCK_1\n\n执行查询后，立即运行 `SHOW PLAN` 命令以查看查询树：\n\nCODE_BLOCK_2\n\n此命令将返回执行查询的结构。请记住，3 条语句——SET profiling、查询和 SHOW——必须在同一会话中执行。\n\n## 在 HTTP JSON 中进行查询分析\n\n使用 HTTP JSON 协议时，只需启用 `\"profile\":true`，即可在响应中获得全文查询树结构。\n\nCODE_BLOCK_3\n\n响应将包含一个 `profile` 对象，其中包含 `query` 成员。\n\n`query` 属性包含转换后的全文查询树。每个节点包括：\n\n* `type`：节点类型，可以是 AND、OR、PHRASE、KEYWORD 等。\n\n* `description`：该节点表示的查询子树字符串（以 `SHOW PLAN` 格式）\n\n* `children`：如果有，则为子节点\n\n* `max_field_pos`：字段内的最大位置\n\n 关键字节点还将包含：\n\n* `word`：转换后的关键字。\n\n* `querypos`：该关键字在查询中的位置。\n\n* `excluded`：关键字被排除在查询之外。\n\n* `expanded`：关键字由前缀扩展添加。\n\n* `field_start`：关键字必须出现在字段开头。\n\n* `field_end`：关键字必须出现在字段末尾。\n\n* `boost`：关键字的 IDF 将乘以此值。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nPython\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\njavascript\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\njava\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nC#\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nRust\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nGo\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n在某些情况下，由于扩展和其他转换，评估后的查询树可能与原始查询树有显著差异。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nPython\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\njavascript\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\njava\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nC#\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nRust\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nGo\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n## 在不执行查询的情况下分析查询\n\n\n\nSQL 语句 `EXPLAIN QUERY` 允许显示给定全文查询的执行树，而不会真正对表进行搜索查询。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n`EXPLAIN QUERY ... option format=dot` 允许以分层格式显示提供的全文查询的执行树，适合用现有工具如 https://dreampuf.github.io/GraphvizOnline 做可视化：\n\n![EXPLAIN QUERY graphviz example](graphviz.png)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n## 查看匹配因子值\n\n", + "russian": "# Профилирование поиска\n\n## Как интерпретируется запрос\n\nРассмотрим этот сложный пример запроса:\n\nCODE_BLOCK_0\n\nПолное значение этого поиска:\n\n* Найти слова «hello» и «world» рядом в любом поле внутри документа;\n\n* Кроме того, в том же документе должны также содержаться слова «example» и «program» в поле заголовка, с не более чем 5 словами между ними, не включая эти слова; (Например, «example PHP program» будет подходить, но «example script to introduce outside data into the correct context for your program» — нет, поскольку между двумя терминами 5 или более слов)\n\n* Более того, в том же документе должно быть слово «python» в поле body, при этом исключая «php» или «perl»;\n\n* Наконец, тот же документ должен содержать слово «code» в любом поле.\n\nОператор OR имеет приоритет над AND, поэтому «looking for cat | dog | mouse» означает «looking for (cat | dog | mouse)», а не «(looking for cat) | dog | mouse».\n\nЧтобы понять, как будет выполняться запрос, Manticore Search предоставляет инструменты профилирования запросов для изучения дерева запроса, сгенерированного выражением запроса.\n\n\n\n## Профилирование дерева запроса в SQL\n\nЧтобы включить профилирование полнотекстового запроса с помощью SQL-запроса, необходимо активировать его до выполнения нужного запроса:\n\nCODE_BLOCK_1\n\nЧтобы посмотреть дерево запроса, выполните команду `SHOW PLAN` сразу после выполнения запроса:\n\nCODE_BLOCK_2\n\nЭта команда вернёт структуру выполненного запроса. Учтите, что 3 оператора — SET profiling, запрос и SHOW — должны выполняться в одной сессии.\n\n## Профилирование запроса через HTTP JSON\n\nПри использовании протокола HTTP JSON можно просто включить `\"profile\":true`, чтобы в ответе получить структуру дерева полнотекстового запроса.\n\nCODE_BLOCK_3\n\nВ ответе будет объект `profile`, содержащий элемент `query`.\n\nСвойство `query` содержит преобразованное дерево полнотекстового запроса. Каждый узел состоит из:\n\n* `type`: тип узла, который может быть AND, OR, PHRASE, KEYWORD и т.д.\n\n* `description`: поддерево запроса для этого узла, представленное строкой (в формате `SHOW PLAN`)\n\n* `children`: дочерние узлы, если они есть\n\n* `max_field_pos`: максимальная позиция в поле\n\nУ узла ключевого слова дополнительно есть:\n\n* `word`: преобразованное ключевое слово.\n\n* `querypos`: позиция этого ключевого слова в запросе.\n\n* `excluded`: ключевое слово исключено из запроса.\n\n* `expanded`: ключевое слово добавлено с помощью расширения префикса.\n\n* `field_start`: ключевое слово должно появиться в начале поля.\n\n* `field_end`: ключевое слово должно появиться в конце поля.\n\n* `boost`: ИДФ ключевого слова будет умножен на это значение.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nPython\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\njavascript\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\njava\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nC#\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nRust\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nGo\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\nВ некоторых случаях оцениваемое дерево запроса может существенно отличаться от исходного из-за расширений и других преобразований.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nPython\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\njavascript\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\njava\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nC#\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nRust\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nGo\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n## Профилирование без выполнения запроса\n\n\n\nSQL оператор `EXPLAIN QUERY` позволяет показать дерево выполнения для данного полнотекстового запроса без фактического выполнения поискового запроса по таблице.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n`EXPLAIN QUERY ... option format=dot` позволяет вывести дерево выполнения переданного полнотекстового запроса в иерархическом формате, подходящем для визуализации с помощью существующих инструментов, таких как https://dreampuf.github.io/GraphvizOnline:\n\n![EXPLAIN QUERY graphviz example](graphviz.png)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n## Просмотр значений факторов совпадения\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Grouping.md.json b/.translation-cache/Searching/Grouping.md.json index 28d80ddf39..ce642bc1ef 100644 --- a/.translation-cache/Searching/Grouping.md.json +++ b/.translation-cache/Searching/Grouping.md.json @@ -30,5 +30,37 @@ "russian": "# Группировка результатов поиска\n\n\n\nГруппировка результатов поиска часто полезна для получения количества совпадений по группам или других агрегатов. Например, это удобно для построения графика, иллюстрирующего количество совпадающих публикаций в блогах по месяцам, или для группировки результатов веб-поиска по сайту, сообщений форума по автору и т.д.\n\nManticore поддерживает группировку результатов поиска по одному или нескольким столбцам и вычисляемым выражениям. Результаты могут:\n\n* Быть отсортированы внутри группы\n\n* Возвращать более одной строки на группу\n\n* Фильтровать группы\n\n* Сортировать группы\n\n* Агрегироваться с помощью [функций агрегации](../Searching/Grouping.md#Aggregation-functions)\n\n\n\nОбщий синтаксис:\n\n\n\nОбщий синтаксис\n\nCODE_BLOCK_0\n\n\n\nФормат JSON-запроса в настоящее время поддерживает базовую группировку, которая может получать агрегатные значения и их count(*).\n\nCODE_BLOCK_1\n\nСтандартный вывод запроса возвращает набор результатов без группировки, который можно скрыть с помощью `limit` (или `size`).\n\nДля агрегации необходимо установить `size` для размера результирующего набора групп.\n\n\n\n\n\n### Просто группировка\n\nГруппировка довольно проста — просто добавьте \"GROUP BY smth\" в конец вашего `SELECT` запроса. Что-то может быть:\n\n* Любым нефулл-текстовым полем из таблицы: integer, float, string, MVA (атрибут с множественным значением)\n\n* Или, если вы использовали псевдоним в списке `SELECT`, вы также можете использовать GROUP BY по нему\n\nВы можете опустить любые [функции агрегации](../Searching/Grouping.md#Aggregation-functions) в списке `SELECT`, и это все равно будет работать:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nВ большинстве случаев, однако, вы захотите получить некоторую агрегированную информацию для каждой группы, например:\n\n* `COUNT(*)` просто чтобы получить количество элементов в каждой группе\n\n* или `AVG(field)`, чтобы вычислить среднее значение поля внутри группы\n\nДля HTTP JSON-запросов использование одного бакета `aggs` с `limit=0` на уровне основного запроса работает аналогично SQL-запросу с `GROUP BY` и `COUNT(*)`, обеспечивая эквивалентное поведение и производительность.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n\n\n##### Сортировка групп\n\nПо умолчанию группы не сортируются, и следующим обычно желаемым действием является их упорядочивание по чему-то, например, по полю, по которому происходит группировка:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\nВ качестве альтернативы, вы можете сортировать по агрегату:\n\n* по `count(*)`, чтобы сначала показать группы с наибольшим количеством элементов\n\n* по `avg(rental_rate)`, чтобы сначала показать фильмы с наивысшим рейтингом. Обратите внимание, что в примере это делается через псевдоним: `avg(rental_rate)` сначала сопоставлен с `avg` в списке `SELECT`, а затем мы просто делаем `ORDER BY avg`\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\n##### GROUP BY по нескольким полям одновременно\n\nВ некоторых случаях вы можете захотеть группировать не только по одному полю, но по нескольким сразу, например, по категории фильма и году:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\n##### Дайте мне N строк\n\nИногда полезно видеть не только один элемент на группу, но и несколько. Это легко достигается с помощью `GROUP N BY`. Например, в следующем случае мы получаем два фильма для каждого года вместо одного, который вернул бы простой `GROUP BY release_year`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\n##### Сортировка внутри группы\n\nЕще одно важное требование для аналитики — сортировка элементов внутри группы. Для этого используйте конструкцию `WITHIN GROUP ORDER BY ... {ASC|DESC}`. Например, получим фильм с наивысшим рейтингом для каждого года. Обратите внимание, что это работает параллельно с обычным `ORDER BY`:\n\n* `WITHIN GROUP ORDER BY` сортирует результаты **внутри группы**\n\n* а простой `GROUP BY` **сортирует сами группы**\n\nЭти два работают полностью независимо.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n\n\n##### Фильтрация групп\n\n`HAVING expression` — полезная конструкция для фильтрации групп. В то время как `WHERE` применяется до группировки, `HAVING` работает с уже сгруппированными данными. Например, оставим только те года, когда средний рейтинг аренды фильмов за этот год был выше 3. В итоге мы получаем только четыре года:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### GROUPBY()" }, "is_code_or_comment": false + }, + "e7208864ffb1c2cc0588fbaa1ea4285aa03b26c182e2acd247ff6e721ca02b7f": { + "original": "Manticore will try to increase `max_matches` up to [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold) if it detects that groupby may return inaccurate results. Detection is based on the number of unique values of the groupby attribute, which is retrieved from secondary indexes (if present).\n\nTo ensure accurate aggregates and/or group counts when using RT tables or `pseudo_sharding`, `accurate_aggregation` can be enabled. This will try to increase `max_matches` up to the threshold, and if the threshold is not high enough, Manticore will disable parallel processing for the query.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\n", + "translations": { + "chinese": "Manticore 将尝试将 `max_matches` 增加到 [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold)，如果它检测到 groupby 可能返回不准确的结果。检测基于 groupby 属性的唯一值数量，这些值是从二级索引（如果存在）中检索的。\n\n为了确保在使用 RT 表或 `pseudo_sharding` 时聚合和/或组计数的准确性，可以启用 `accurate_aggregation`。这将尝试将 `max_matches` 增加到阈值，如果阈值不够高，Manticore 将禁用该查询的并行处理。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\n", + "russian": "Manticore попробует увеличить `max_matches` до [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold), если обнаружит, что groupby может возвращать неточные результаты. Обнаружение основывается на количестве уникальных значений атрибута groupby, которые извлекаются из вторичных индексов (если они присутствуют).\n\nДля обеспечения точных агрегатов и/или подсчёта групп при использовании RT таблиц или `pseudo_sharding` можно включить `accurate_aggregation`. Это попытается увеличить `max_matches` до порога, а если порог недостаточно высок, Manticore отключит параллельную обработку для запроса.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\n" + }, + "is_code_or_comment": false + }, + "aa4599aa8618029ed698b5dbd78eec3880845ccf8f539bc14906a479cd20ab1b": { + "original": "# Grouping search results\n\n\n\nGrouping search results is often helpful for obtaining per-group match counts or other aggregations. For example, it's useful for creating a graph illustrating the number of matching blog posts per month or grouping web search results by site or forum posts by author, etc.\n\nManticore supports the grouping of search results by single or multiple columns and computed expressions. The results can:\n\n* Be sorted within a group\n\n* Return more than one row per group\n\n* Have groups filtered\n\n* Have groups sorted\n\n* Be aggregated using the [aggregation functions](../Searching/Grouping.md#Aggregation-functions)\n\n\n\nThe general syntax is:\n\n\n\nGeneral syntax\n\nCODE_BLOCK_0\n\n\n\nJSON query format currently supports a basic grouping that can retrieve aggregate values and their count(*).\n\nCODE_BLOCK_1\n\nThe standard query output returns the result set without grouping, which can be hidden using `limit` (or `size`).\n\nThe aggregation requires setting a `size` for the group's result set size.\n\n\n\n\n\n### Just Grouping\n\nGrouping is quite simple - just add \"GROUP BY smth\" to the end of your `SELECT` query. The something can be:\n\n* Any non-full-text field from the table: integer, float, string, MVA (multi-value attribute)\n\n* Or, if you used an alias in the `SELECT` list, you can GROUP BY it too\n\nYou can omit any [aggregation functions](../Searching/Grouping.md#Aggregation-functions) in the `SELECT` list and it will still work:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n\n\nIn most cases, however, you'll want to obtain some aggregated data for each group, such as:\n\n* `COUNT(*)` to simply get the number of elements in each group\n\n* or `AVG(field)` to calculate the average value of the field within the group\n\nFor HTTP JSON requests, using a single `aggs` bucket with `limit=0` at the main query level works similarly to a SQL query with `GROUP BY` and `COUNT(*)`, providing equivalent behavior and performance.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n##### Sorting groups\n\nBy default, groups are not sorted, and the next thing you typically want to do is order them by something, like the field you're grouping by:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\nAlternatively, you can sort by the aggregation:\n\n* by `count(*)` to display groups with the most elements first\n\n* by `avg(rental_rate)` to show the highest-rated movies first. Note that in the example, it's done via an alias: `avg(rental_rate)` is first mapped to `avg` in the `SELECT` list, and then we simply do `ORDER BY avg`\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\n##### GROUP BY multiple fields at once\n\nIn some cases, you might want to group not just by a single field, but by multiple fields at once, such as a movie's category and year:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### Give me N rows\n\nSometimes it's useful to see not just a single element per group, but multiple. This can be easily achieved with the help of `GROUP N BY`. For example, in the following case, we get two movies for each year rather than just one, which a simple `GROUP BY release_year` would have returned.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\n##### Sorting inside a group\n\nAnother crucial analytics requirement is to sort elements within a group. To achieve this, use the `WITHIN GROUP ORDER BY ... {ASC|DESC}` clause. For example, let's get the highest-rated film for each year. Note that it works in parallel with just `ORDER BY`:\n\n* `WITHIN GROUP ORDER BY` sorts results **inside a group**\n\n* while just `GROUP BY` **sorts the groups themselves**\n\nThese two work entirely independently.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n##### Filter groups", + "translations": { + "chinese": "# 分组搜索结果\n\n\n\n分组搜索结果通常有助于获得每个组的匹配计数或其他聚合。例如，它对于创建显示每月匹配博客文章数量的图表，或者按网站对网络搜索结果分组，或按作者对论坛帖子分组等非常有用。\n\nManticore 支持按单列或多列以及计算表达式对搜索结果进行分组。结果可以：\n\n* 在组内排序\n\n* 每组返回多行\n\n* 过滤组\n\n* 对组排序\n\n* 使用[聚合函数](../Searching/Grouping.md#Aggregation-functions)进行聚合\n\n\n\n一般语法是：\n\n\n\n通用语法\n\nCODE_BLOCK_0\n\n\n\nJSON 查询格式当前支持基本分组，可以检索聚合值及其 count(*)。\n\nCODE_BLOCK_1\n\n标准查询输出返回未分组的结果集，可以使用 `limit`（或 `size`）将其隐藏。\n\n聚合需要设置组结果集大小的 `size`。\n\n\n\n\n\n### 仅分组\n\n分组非常简单——只需在 `SELECT` 查询末尾添加 \"GROUP BY smth\"。这里的某物可以是：\n\n* 表中的任何非全文字段：整数、浮点数、字符串、多值属性（MVA）\n\n* 或者，如果你在 `SELECT` 列表中使用了别名，也可以按该别名分组\n\n你可以在 `SELECT` 列表中省略任何[聚合函数](../Searching/Grouping.md#Aggregation-functions)，它仍然可以工作：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n\n\n不过在大多数情况下，你会想获得每个组的一些聚合数据，比如：\n\n* `COUNT(*)` 仅获取每组元素数量\n\n* 或 `AVG(field)` 计算组内字段的平均值\n\n对于 HTTP JSON 请求，主查询层使用单个带 `limit=0` 的 `aggs` bucket，效果类似于 SQL 查询中的 `GROUP BY` 和 `COUNT(*)`，提供等效的行为和性能。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n##### 分组排序\n\n默认情况下，组不排序，通常接下来你会想按某个字段排序，比如你分组的字段：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\n或者，你可以按聚合排序：\n\n* 按 `count(*)` 显示元素最多的组优先\n\n* 按 `avg(rental_rate)` 显示评分最高的电影优先。注意在示例中是通过别名完成的：`avg(rental_rate)` 首先映射为 `avg`，然后直接使用 `ORDER BY avg`\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\n##### 同时按多个字段 GROUP BY\n\n有时，你可能想不仅按单个字段分组，而是同时按多个字段，比如电影的类别和年份：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### 每组返回 N 行\n\n有时不仅想查看每组一个元素，而是多个，这可以通过 `GROUP N BY` 轻松实现。例如，下面的情况我们每年获取两部电影，而不是简单的 `GROUP BY release_year` 只返回一部。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\n##### 组内排序\n\n另一个关键的分析需求是对组内元素排序。为此，使用 `WITHIN GROUP ORDER BY ... {ASC|DESC}` 子句。例如，我们想获取每年评分最高的电影。注意它与简单的 `ORDER BY` 并行工作：\n\n* `WITHIN GROUP ORDER BY` 用于排序**组内结果**\n\n* 而简单的 `GROUP BY` **排序的是组本身**\n\n两者彼此完全独立。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n##### 过滤组", + "russian": "# Группировка результатов поиска\n\n\n\nГруппировка результатов поиска часто полезна для получения количества совпадений по каждой группе или других агрегатов. Например, это удобно для создания графика с количеством подходящих блог-постов по месяцам или группировки результатов веб-поиска по сайтам, форумных сообщений по авторам и т.д.\n\nManticore поддерживает группировку результатов поиска по одному или нескольким столбцам и вычисляемым выражениям. Результаты могут:\n\n* Быть отсортированы внутри группы\n\n* Возвращать более одной строки на группу\n\n* Фильтровать группы\n\n* Сортировать группы\n\n* Агрегироваться с использованием [функций агрегации](../Searching/Grouping.md#Aggregation-functions)\n\n\n\nОбщий синтаксис:\n\n\n\nОбщий синтаксис\n\nCODE_BLOCK_0\n\n\n\nФормат JSON-запроса на данный момент поддерживает базовую группировку, которая может извлекать агрегированные значения и их count(*).\n\nCODE_BLOCK_1\n\nСтандартный результат запроса возвращает набор без группировки, который можно скрыть с помощью `limit` (или `size`).\n\nДля агрегации необходимо задать `size` в размере набора результатов для группы.\n\n\n\n\n\n### Просто группировка\n\nГруппировка достаточно проста - просто добавьте \"GROUP BY smth\" в конец вашего `SELECT` запроса. Что-то может быть:\n\n* Любым не полнотекстовым полем из таблицы: integer, float, string, MVA (мульти-значение атрибута)\n\n* Или, если вы использовали псевдоним в списке `SELECT`, вы также можете группировать по нему\n\nВы можете опустить любые [функции агрегации](../Searching/Grouping.md#Aggregation-functions) в списке `SELECT`, и это продолжит работать:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n\n\nВ большинстве случаев, однако, вы захотите получить некоторые агрегированные данные для каждой группы, такие как:\n\n* `COUNT(*)`, чтобы просто получить количество элементов в каждой группе\n\n* или `AVG(field)`, чтобы вычислить среднее значение поля внутри группы\n\nДля HTTP JSON-запросов использование одного `aggs` bucket с `limit=0` на основном уровне запроса работает аналогично SQL запросу с `GROUP BY` и `COUNT(*)`, обеспечивая эквивалентное поведение и производительность.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n##### Сортировка групп\n\nПо умолчанию группы не сортируются, и следующая типичная операция — отсортировать их по чему-либо, например, по полю, по которому ведется группировка:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\nИли же можно сортировать по агрегату:\n\n* по `count(*)`, чтобы показывать группы с наибольшим количеством элементов первыми\n\n* по `avg(rental_rate)`, чтобы показывать фильмы с самым высоким рейтингом первыми. Обратите внимание, что в примере это сделано через псевдоним: `avg(rental_rate)` сначала отображается в `avg` в списке `SELECT`, а потом мы просто делаем `ORDER BY avg`\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n\n\n##### GROUP BY по нескольким полям одновременно\n\nВ некоторых случаях вы можете захотеть группировать не только по одному полю, но и по нескольким сразу, например, по категории фильма и году:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### Дайте мне N строк\n\nИногда полезно видеть не только один элемент на группу, а несколько. Это легко достигается с помощью `GROUP N BY`. Например, в следующем случае мы получаем два фильма для каждого года вместо одного, что вернул бы простой `GROUP BY release_year`.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\n\n\n##### Сортировка внутри группы\n\nЕще одно важное требование аналитики — сортировать элементы внутри группы. Для этого используйте конструкцию `WITHIN GROUP ORDER BY ... {ASC|DESC}`. Например, получим фильм с наивысшим рейтингом за каждый год. Обратите внимание, что это работает параллельно с обычным `ORDER BY`:\n\n* `WITHIN GROUP ORDER BY` сортирует результаты **внутри группы**\n\n* в то время как просто `GROUP BY` **сортирует сами группы**\n\nЭти два работают полностью независимо.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\n\n\n##### Фильтрация групп" + }, + "is_code_or_comment": false + }, + "d21ec20dc8e7de7851bc025b62f9df7d8ab74014dbf499b677c37f462ff1c756": { + "original": "`HAVING expression` is a helpful clause for filtering groups. While `WHERE` is applied before grouping, `HAVING` works with the groups. For example, let's keep only those years when the average rental rate of the films for that year was higher than 3. We get only four years:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n\n\n##### GROUPBY()\n\nThere is a function `GROUPBY()` which returns the key of the current group. It's useful in many cases, especially when you [GROUP BY an MVA](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29) or a [JSON value](../Searching/Grouping.md#Grouping-by-a-JSON-node).\n\nIt can also be used in `HAVING`, for example, to keep only years 2000 and 2002.\n\nNote that `GROUPBY()`is not recommended for use when you GROUP BY multiple fields at once. It will still work, but since the group key in this case is a compound of field values, it may not appear the way you expect.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n\n\n##### Grouping by MVA (multi-value attributes)\n\nManticore supports grouping by [MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29). To demonstrate how it works, let's create a table \"shoes\" with MVA \"sizes\" and insert a few documents into it:\n\nCODE_BLOCK_60\n\nso we have:\n\nCODE_BLOCK_61\n\nIf we now GROUP BY \"sizes\", it will process all our multi-value attributes and return an aggregation for each, in this case just the count:\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\nres = await searchApi.search({\n\n index: 'test',\n\n aggs: {\n\n mva_agg: {\n\n terms: { field: \"mva_field\", size: 2 }\n\n }\n\n }\n\n});\n\nCODE_BLOCK_81\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":4,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_82\n\nquery := map[string]interface{} {};\n\nsearchRequest.SetQuery(query);\n\naggTerms := manticoreclient.NewAggregationTerms()\n\naggTerms.SetField(\"mva_field\")\n\naggTerms.SetSize(2)\n\naggregation := manticoreclient.NewAggregation()\n\naggregation.setTerms(aggTerms)\n\nsearchRequest.SetAggregation(aggregation)\n\nres, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*searchRequest).Execute()\n\nCODE_BLOCK_83\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":5,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_84\n\ncreate table products(title text, meta json);\n\ninsert into products values(0,'nike','{\"color\":\"red\"}'),(0,'adidas','{\"color\":\"red\"}'),(0,'puma','{\"color\":\"green\"}');\n\nCODE_BLOCK_85\n\nSELECT * FROM products;\n\n+---------------------+-------------------+--------+\n\n| id | meta | title |\n\n+---------------------+-------------------+--------+\n\n| 1657851069130080268 | {\"color\":\"red\"} | nike |\n\n| 1657851069130080269 | {\"color\":\"red\"} | adidas |\n\n| 1657851069130080270 | {\"color\":\"green\"} | puma |\n\n+---------------------+-------------------+--------+\n\nCODE_BLOCK_86\n\nSELECT groupby() color, count(*) from products GROUP BY meta.color;\n\nCODE_BLOCK_87\n\n+-------+----------+\n\n| color | count(*) |\n\n+-------+----------+\n\n| red | 2 |\n\n| green | 1 |\n\n+-------+----------+\n\nCODE_BLOCK_88\n\nPOST /search -d '\n\n {\n\n \"table\" : \"products\",\n\n \"limit\": 0,\n\n \"aggs\" :\n\n {\n\n \"color\" :\n\n {\n\n \"terms\" :\n\n {\n\n \"field\":\"meta.color\",\n\n \"size\":100\n\n }\n\n }\n\n }\n\n }\n\n'\n\nCODE_BLOCK_89\n\n{\n\n \"took\": 0,\n\n \"timed_out\": false,\n\n \"hits\": {\n\n \"total\": 3,\n\n \"hits\": [\n\n ]\n\n },\n\n \"aggregations\": {\n\n \"color\": {\n\n \"buckets\": [\n\n {\n\n \"key\": \"green\",\n\n \"doc_count\": 1\n\n },\n\n {\n\n \"key\": \"red\",\n\n \"doc_count\": 2\n\n }\n\n ]\n\n }\n\n }\n\n}\n\nCODE_BLOCK_90\n\n$index->setName('products');\n\n$search = $index->search('');\n\n$search->limit(0);\n\n$search->facet('meta.color','color',100);\n\n$results = $search->get();\n\nprint_r($results->getFacets());\n\nCODE_BLOCK_91\n\nArray\n\n(\n\n [color] => Array\n\n (\n\n [buckets] => Array\n\n (\n\n [0] => Array\n\n (\n\n [key] => green\n\n [doc_count] => 1\n\n )\n\n [1] => Array\n\n (\n\n [key] => red\n\n [doc_count] => 2\n\n )\n\n )\n\n )\n\n)\n\nCODE_BLOCK_92\n\nres =searchApi.search({\"table\":\"products\",\"limit\":0,\"aggs\":{\"color\":{\"terms\":{\"field\":\"meta.color\",\"size\":100}}}})\n\nCODE_BLOCK_93\n\n{'aggregations': {u'color': {u'buckets': [{u'doc_count': 1,\n\n u'key': u'green'},\n\n {u'doc_count': 2, u'key': u'red'}]}},", + "translations": { + "chinese": "`HAVING expression` 是一个用于过滤分组的有用子句。虽然 `WHERE` 在分组之前应用，`HAVING` 则作用于分组。例如，我们只保留那些该年份电影的平均租赁费率高于 3 的年份。结果只剩下四个年份：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n\n\n##### GROUPBY()\n\n有一个函数 `GROUPBY()`，它返回当前分组的键。在很多情况下非常有用，特别是当你[对 MVA 进行 GROUP BY](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29)或对[JSON 值进行 GROUP BY](../Searching/Grouping.md#Grouping-by-a-JSON-node)时。\n\n它也可以在 `HAVING` 中使用，例如，只保留年份 2000 和 2002。\n\n注意，当你同时对多个字段进行 GROUP BY 时，不推荐使用 `GROUPBY()`。它仍然可以工作，但由于此时分组键是字段值的复合，可能不会按你预期的方式显示。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n\n\n##### 按 MVA（多值属性）分组\n\nManticore 支持按[MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29)分组。为演示其工作方式，我们创建一个带有 MVA “sizes” 的表 \"shoes\"，并插入几条文档：\n\nCODE_BLOCK_60\n\n所以我们有：\n\nCODE_BLOCK_61\n\n如果我们现在对 \"sizes\" 进行 GROUP BY，它会处理所有的多值属性，并为每个值返回一个聚合，在此例中只是计数：\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\nres = await searchApi.search({\n\n index: 'test',\n\n aggs: {\n\n mva_agg: {\n\n terms: { field: \"mva_field\", size: 2 }\n\n }\n\n }\n\n});\n\nCODE_BLOCK_81\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":4,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_82\n\nquery := map[string]interface{} {};\n\nsearchRequest.SetQuery(query);\n\naggTerms := manticoreclient.NewAggregationTerms()\n\naggTerms.SetField(\"mva_field\")\n\naggTerms.SetSize(2)\n\naggregation := manticoreclient.NewAggregation()\n\naggregation.setTerms(aggTerms)\n\nsearchRequest.SetAggregation(aggregation)\n\nres, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*searchRequest).Execute()\n\nCODE_BLOCK_83\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":5,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_84\n\ncreate table products(title text, meta json);\n\ninsert into products values(0,'nike','{\"color\":\"red\"}'),(0,'adidas','{\"color\":\"red\"}'),(0,'puma','{\"color\":\"green\"}');\n\nCODE_BLOCK_85\n\nSELECT * FROM products;\n\n+---------------------+-------------------+--------+\n\n| id | meta | title |\n\n+---------------------+-------------------+--------+\n\n| 1657851069130080268 | {\"color\":\"red\"} | nike |\n\n| 1657851069130080269 | {\"color\":\"red\"} | adidas |\n\n| 1657851069130080270 | {\"color\":\"green\"} | puma |\n\n+---------------------+-------------------+--------+\n\nCODE_BLOCK_86\n\nSELECT groupby() color, count(*) from products GROUP BY meta.color;\n\nCODE_BLOCK_87\n\n+-------+----------+\n\n| color | count(*) |\n\n+-------+----------+\n\n| red | 2 |\n\n| green | 1 |\n\n+-------+----------+\n\nCODE_BLOCK_88\n\nPOST /search -d '\n\n {\n\n \"table\" : \"products\",\n\n \"limit\": 0,\n\n \"aggs\" :\n\n {\n\n \"color\" :\n\n {\n\n \"terms\" :\n\n {\n\n \"field\":\"meta.color\",\n\n \"size\":100\n\n }\n\n }\n\n }\n\n }\n\n'\n\nCODE_BLOCK_89\n\n{\n\n \"took\": 0,\n\n \"timed_out\": false,\n\n \"hits\": {\n\n \"total\": 3,\n\n \"hits\": [\n\n ]\n\n },\n\n \"aggregations\": {\n\n \"color\": {\n\n \"buckets\": [\n\n {\n\n \"key\": \"green\",\n\n \"doc_count\": 1\n\n },\n\n {\n\n \"key\": \"red\",\n\n \"doc_count\": 2\n\n }\n\n ]\n\n }\n\n }\n\n}\n\nCODE_BLOCK_90\n\n$index->setName('products');\n\n$search = $index->search('');\n\n$search->limit(0);\n\n$search->facet('meta.color','color',100);\n\n$results = $search->get();\n\nprint_r($results->getFacets());\n\nCODE_BLOCK_91\n\nArray\n\n(\n\n [color] => Array\n\n (\n\n [buckets] => Array\n\n (\n\n [0] => Array\n\n (\n\n [key] => green\n\n [doc_count] => 1\n\n )\n\n [1] => Array\n\n (\n\n [key] => red\n\n [doc_count] => 2\n\n )\n\n )\n\n )\n\n)\n\nCODE_BLOCK_92\n\nres =searchApi.search({\"table\":\"products\",\"limit\":0,\"aggs\":{\"color\":{\"terms\":{\"field\":\"meta.color\",\"size\":100}}}})\n\nCODE_BLOCK_93\n\n{'aggregations': {u'color': {u'buckets': [{u'doc_count': 1,\n\n u'key': u'green'},\n\n {u'doc_count': 2, u'key': u'red'}]}},", + "russian": "`HAVING expression` — полезный оператор для фильтрации групп. В то время как `WHERE` применяется до группировки, `HAVING` работает с группами. Например, оставим только те годы, когда средняя арендная ставка фильмов за этот год была выше 3. Мы получим только четыре года:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\n\n\n##### GROUPBY()\n\nСуществует функция `GROUPBY()`, которая возвращает ключ текущей группы. Она полезна во многих случаях, особенно когда вы [GROUP BY по MVA](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29) или по [JSON значению](../Searching/Grouping.md#Grouping-by-a-JSON-node).\n\nЕё также можно использовать в `HAVING`, например, чтобы оставить только годы 2000 и 2002.\n\nОбратите внимание, что `GROUPBY()` не рекомендуется использовать, когда вы группируете по нескольким полям одновременно. Она всё ещё будет работать, но поскольку ключ группы в этом случае является составным из значений полей, он может не отображаться так, как вы ожидаете.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\n\n\n##### Группировка по MVA (многозначные атрибуты)\n\nManticore поддерживает группировку по [MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29). Чтобы показать, как это работает, создадим таблицу \"shoes\" с MVA \"sizes\" и вставим в неё несколько документов:\n\nCODE_BLOCK_60\n\nтаким образом у нас есть:\n\nCODE_BLOCK_61\n\nЕсли теперь мы сделаем GROUP BY по \"sizes\", будут обработаны все наши многозначные атрибуты и возвращена агрегация для каждого, в данном случае просто количество:\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\nres = await searchApi.search({\n\n index: 'test',\n\n aggs: {\n\n mva_agg: {\n\n terms: { field: \"mva_field\", size: 2 }\n\n }\n\n }\n\n});\n\nCODE_BLOCK_81\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":4,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_82\n\nquery := map[string]interface{} {};\n\nsearchRequest.SetQuery(query);\n\naggTerms := manticoreclient.NewAggregationTerms()\n\naggTerms.SetField(\"mva_field\")\n\naggTerms.SetSize(2)\n\naggregation := manticoreclient.NewAggregation()\n\naggregation.setTerms(aggTerms)\n\nsearchRequest.SetAggregation(aggregation)\n\nres, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*searchRequest).Execute()\n\nCODE_BLOCK_83\n\n{\n\n\t\"took\":0,\n\n\t\"timed_out\":false,\n\n\t\"aggregations\":\n\n\t{\n\n\t\t\"mva_agg\":\n\n\t\t{\n\n\t\t\t\"buckets\":\n\n\t\t\t[{\n\n\t\t\t\t\"key\":1,\n\n\t\t\t\t\"doc_count\":4\n\n\t\t\t},\n\n\t\t\t{\n\n\t\t\t\t\"key\":2,\n\n\t\t\t\t\"doc_count\":2\n\n\t\t\t}]\n\n\t\t}\n\n\t},\n\n\t\"hits\":\n\n\t{\n\n\t\t\"total\":5,\n\n\t\t\"hits\":[]\n\n\t}\n\n}\n\nCODE_BLOCK_84\n\ncreate table products(title text, meta json);\n\ninsert into products values(0,'nike','{\"color\":\"red\"}'),(0,'adidas','{\"color\":\"red\"}'),(0,'puma','{\"color\":\"green\"}');\n\nCODE_BLOCK_85\n\nSELECT * FROM products;\n\n+---------------------+-------------------+--------+\n\n| id | meta | title |\n\n+---------------------+-------------------+--------+\n\n| 1657851069130080268 | {\"color\":\"red\"} | nike |\n\n| 1657851069130080269 | {\"color\":\"red\"} | adidas |\n\n| 1657851069130080270 | {\"color\":\"green\"} | puma |\n\n+---------------------+-------------------+--------+\n\nCODE_BLOCK_86\n\nSELECT groupby() color, count(*) from products GROUP BY meta.color;\n\nCODE_BLOCK_87\n\n+-------+----------+\n\n| color | count(*) |\n\n+-------+----------+\n\n| red | 2 |\n\n| green | 1 |\n\n+-------+----------+\n\nCODE_BLOCK_88\n\nPOST /search -d '\n\n {\n\n \"table\" : \"products\",\n\n \"limit\": 0,\n\n \"aggs\" :\n\n {\n\n \"color\" :\n\n {\n\n \"terms\" :\n\n {\n\n \"field\":\"meta.color\",\n\n \"size\":100\n\n }\n\n }\n\n }\n\n }\n\n'\n\nCODE_BLOCK_89\n\n{\n\n \"took\": 0,\n\n \"timed_out\": false,\n\n \"hits\": {\n\n \"total\": 3,\n\n \"hits\": [\n\n ]\n\n },\n\n \"aggregations\": {\n\n \"color\": {\n\n \"buckets\": [\n\n {\n\n \"key\": \"green\",\n\n \"doc_count\": 1\n\n },\n\n {\n\n \"key\": \"red\",\n\n \"doc_count\": 2\n\n }\n\n ]\n\n }\n\n }\n\n}\n\nCODE_BLOCK_90\n\n$index->setName('products');\n\n$search = $index->search('');\n\n$search->limit(0);\n\n$search->facet('meta.color','color',100);\n\n$results = $search->get();\n\nprint_r($results->getFacets());\n\nCODE_BLOCK_91\n\nArray\n\n(\n\n [color] => Array\n\n (\n\n [buckets] => Array\n\n (\n\n [0] => Array\n\n (\n\n [key] => green\n\n [doc_count] => 1\n\n )\n\n [1] => Array\n\n (\n\n [key] => red\n\n [doc_count] => 2\n\n )\n\n )\n\n )\n\n)\n\nCODE_BLOCK_92\n\nres =searchApi.search({\"table\":\"products\",\"limit\":0,\"aggs\":{\"color\":{\"terms\":{\"field\":\"meta.color\",\"size\":100}}}})\n\nCODE_BLOCK_93\n\n{'aggregations': {u'color': {u'buckets': [{u'doc_count': 1,\n\n u'key': u'green'},\n\n {u'doc_count': 2, u'key': u'red'}]}}," + }, + "is_code_or_comment": false + }, + "ce6b9c226a0862422e9f41cc030a4bf17e4affd4875f0d241309982eba72ad0b": { + "original": " 'hits': {'hits': [], 'max_score': None, 'total': 3},\n\n 'profile': None,\n\n 'timed_out': False,\n\n 'took': 0}\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\n## Aggregation functions\n\nBesides `COUNT(*)`, which returns the number of elements in each group, you can use various other aggregation functions:\n\n\n\n##### COUNT(DISTINCT field)\n\nWhile `COUNT(*)` returns the number of all elements in the group, `COUNT(DISTINCT field)` returns the number of unique values of the field in the group, which may be completely different from the total count. For instance, you can have 100 elements in the group, but all with the same value for a certain field. `COUNT(DISTINCT field)` helps to determine that. To demonstrate this, let's create a table \"students\" with the student's name, age, and major:\n\nCODE_BLOCK_109\n\nso we have:\n\nCODE_BLOCK_110\n\nIn the example, you can see that if we GROUP BY major and display both `COUNT(*)` and `COUNT(DISTINCT age)`, it becomes clear that there are two students who chose the major \"cs\" with two unique ages, but for the major \"arts\", there are also two students, yet only one unique age.\n\nThere can be at most one `COUNT(DISTINCT)` per query.\n\n** By default, counts are approximate **\n\nActually, some of them are exact, while others are approximate. More on that below.\n\nManticore supports two algorithms for computing counts of distinct values. One is a legacy algorithm that uses a lot of memory and is usually slow. It collects `{group; value}` pairs, sorts them, and periodically discards duplicates. The benefit of this approach is that it guarantees exact counts within a plain table. You can enable it by setting the [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option to `0`.\n\nThe other algorithm (enabled by default) loads counts into a hash table and returns its size. If the hash table becomes too large, its contents are moved into a `HyperLogLog`. This is where the counts become approximate since `HyperLogLog` is a probabilistic algorithm. The advantage is that the maximum memory usage per group is fixed and depends on the accuracy of the `HyperLogLog`. The overall memory usage also depends on the [max_matches](../Searching/Options.md#max_matches) setting, which reflects the number of groups.\n\nThe [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option sets the threshold below which counts are guaranteed to be exact. The `HyperLogLog` accuracy setting and the threshold for the \"hash table to HyperLogLog\" conversion are derived from this setting. It's important to use this option with caution because doubling it will double the maximum memory required for count calculations. The maximum memory usage can be roughly estimated using this formula: `64 * max_matches * distinct_precision_threshold`. Note that this is the worst-case scenario, and in most cases, count calculations will use significantly less RAM.\n\n**`COUNT(DISTINCT)` against a distributed table or a real-time table consisting of multiple disk chunks may return inaccurate results**, but the result should be accurate for a distributed table consisting of local plain or real-time tables with the same schema (identical set/order of fields, but may have different tokenization settings).\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\nCODE_BLOCK_114\n\n\n\n\n\n##### GROUP_CONCAT(field)\n\nOften, you want to better understand the contents of each group. You can use [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) for that, but it would return additional rows you might not want in the output. `GROUP_CONCAT()` enriches your grouping by concatenating values of a specific field in the group. Let's take the previous example and improve it by displaying all the ages in each group.\n\n`GROUP_CONCAT(field)` returns the list as comma-separated values.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\n\n\n##### SUM(), MIN(), MAX(), AVG()\n\nOf course, you can also obtain the sum, average, minimum, and maximum values within a group.\n\n\n\n##### Example:\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\n\n\n## Grouping accuracy\n\nGrouping is done in fixed memory, which depends on the [max_matches](../Searching/Options.md#max_matches) setting. If `max_matches` allows for storage of all found groups, the results will be 100% accurate. However, if the value of `max_matches` is lower, the results will be less accurate.\n\nWhen parallel processing is involved, it can become more complicated. When `pseudo_sharding` is enabled and/or when using an RT table with several disk chunks, each chunk or pseudo shard gets a result set that is no larger than `max_matches`. This can lead to inaccuracies in aggregates and group counts when the result sets from different threads are merged. To fix this, either a larger `max_matches` value or disabling parallel processing can be used.", + "translations": { + "chinese": " 'hits': {'hits': [], 'max_score': None, 'total': 3},\n\n 'profile': None,\n\n 'timed_out': False,\n\n 'took': 0}\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\n## 聚合函数\n\n除了返回每组元素数量的 `COUNT(*)` 外，你还可以使用各种其他聚合函数：\n\n\n\n##### COUNT(DISTINCT 字段)\n\n虽然 `COUNT(*)` 返回组中所有元素的数量，但 `COUNT(DISTINCT 字段)` 返回该字段在组中唯一值的数量，这可能与总数完全不同。例如，你可以有 100 个元素在组中，但它们某个字段的值都是相同的。`COUNT(DISTINCT 字段)` 有助于判断这一点。为演示此功能，创建一个包含学生姓名、年龄和专业的表 \"students\"：\n\nCODE_BLOCK_109\n\n所以我们有：\n\nCODE_BLOCK_110\n\n在示例中，你可以看到如果我们按专业进行 GROUP BY 并同时显示 `COUNT(*)` 和 `COUNT(DISTINCT age)`，很明显专业为 \"cs\" 的有两名学生，他们的年龄各不相同，而专业为 \"arts\" 的同样有两名学生，但是只有一个唯一年龄。\n\n每个查询最多只能有一个 `COUNT(DISTINCT)`。\n\n** 默认情况下，计数是近似的 **\n\n实际上，有些计数是精确的，有些是近似的。下面会详细说明。\n\nManticore 支持两种计算不同值计数的算法。一种是传统算法，使用大量内存且通常速度较慢。它收集 `{group; value}` 对，排序并定期剔除重复项。这种方法的好处是能保证在纯表中计数的精确。你可以通过将 [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) 选项设置为 `0` 来启用它。\n\n另一种算法（默认启用）将计数加载到哈希表中并返回其大小。如果哈希表变得过大，其内容会被移动至 `HyperLogLog`。这时计数成为近似值，因为 `HyperLogLog` 是概率算法。优点是每组最大内存使用固定，且依赖于 `HyperLogLog` 的精度。整体内存消耗也受 [max_matches](../Searching/Options.md#max_matches) 设置影响，该设置反映了组的数量。\n\n[distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) 选项设置了计数保证精确的阈值。`HyperLogLog` 的精度设置以及从哈希表转换到 `HyperLogLog` 的阈值都来源于该设置。使用此选项需谨慎，因为阈值加倍将使计算计数所需的最大内存加倍。最大内存使用可粗略估算为：`64 * max_matches * distinct_precision_threshold`。请注意这是最坏情况，大多数情况下计数计算会使用明显更少的内存。\n\n** 对分布式表或包含多个磁盘块的实时表执行 `COUNT(DISTINCT)` 可能返回不准确结果，**但对于由本地纯表或实时表（结构相同）组成的分布式表，结果应当准确（字段集合/顺序一致，但可能有不同的分词设置）。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\nCODE_BLOCK_114\n\n\n\n\n\n##### GROUP_CONCAT(字段)\n\n通常，你想更好地了解每个分组的内容。你可以使用 [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) 来实现，但它会返回你可能不想要的额外行。`GROUP_CONCAT()` 通过将组中特定字段的值连接起来丰富你的分组。让我们用之前的例子来改进，通过显示每个组中所有年龄。\n\n`GROUP_CONCAT(字段)` 返回逗号分隔的值列表。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\n\n\n##### SUM(), MIN(), MAX(), AVG()\n\n当然，你也可以获得组内的总和、平均值、最小值和最大值。\n\n\n\n##### 示例：\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\n\n\n## 分组精度\n\n分组是在固定内存中完成的，内存大小取决于 [max_matches](../Searching/Options.md#max_matches) 设置。如果 `max_matches` 允许存储所有找到的组，结果将是 100% 精确的。然而，如果 `max_matches` 的值较小，则结果会降低准确性。\n\n当涉及并行处理时，情况会更复杂。启用 `pseudo_sharding` 和/或使用带有多个磁盘块的 RT 表时，每个块或伪分片获得的结果集大小不超过 `max_matches`。这可能在不同线程的结果集合并时导致聚合和分组计数不准确。为解决此问题，可以使用更大的 `max_matches` 值或禁用并行处理。", + "russian": " 'hits': {'hits': [], 'max_score': None, 'total': 3},\n\n 'profile': None,\n\n 'timed_out': False,\n\n 'took': 0}\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\n## Функции агрегации\n\nКроме `COUNT(*)`, который возвращает количество элементов в каждой группе, вы можете использовать различные другие функции агрегации:\n\n\n\n##### COUNT(DISTINCT field)\n\nВ то время как `COUNT(*)` возвращает количество всех элементов в группе, `COUNT(DISTINCT field)` возвращает количество уникальных значений поля в группе, что может существенно отличаться от общего количества. Например, в группе может быть 100 элементов, но все с одинаковым значением определённого поля. `COUNT(DISTINCT field)` помогает это определить. Для демонстрации создадим таблицу \"students\" с именем студента, возрастом и специальностью:\n\nCODE_BLOCK_109\n\nтак что у нас есть:\n\nCODE_BLOCK_110\n\nВ примере видно, что если мы делаем GROUP BY по major и показываем одновременно `COUNT(*)` и `COUNT(DISTINCT age)`, становится ясно, что среди студентов, выбравших специальность \"cs\", двое и у них два уникальных возраста, а для специальности \"arts\" также двое студентов, но только один уникальный возраст.\n\nВ одном запросе может быть не более одного `COUNT(DISTINCT)`.\n\n**По умолчанию подсчёты приблизительные**\n\nНа самом деле, некоторые из них точные, а другие — приблизительные. Подробнее об этом ниже.\n\nManticore поддерживает два алгоритма подсчёта количества уникальных значений. Один — устаревший алгоритм, который использует много памяти и обычно медленный. Он собирает пары `{group; value}`, сортирует их и периодически удаляет дубликаты. Преимущество этого подхода в том, что он гарантирует точный подсчёт для простой таблицы. Его можно включить, установив опцию [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) в значение `0`.\n\nДругой алгоритм (включён по умолчанию) загружает подсчёты в хеш-таблицу и возвращает её размер. Если хеш-таблица становится слишком большой, её содержимое переносится в `HyperLogLog`. Здесь подсчёты становятся приблизительными, поскольку `HyperLogLog` — вероятностный алгоритм. Преимущество в том, что максимальное использование памяти на группу фиксировано и зависит от точности `HyperLogLog`. Общее потребление памяти также зависит от настройки [max_matches](../Searching/Options.md#max_matches), отражающей количество групп.\n\nОпция [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) задаёт порог, ниже которого подсчёты гарантированно точные. Настройки точности `HyperLogLog` и порог конверсии \"хеш-таблица в HyperLogLog\" выводятся из этой настройки. Важно с осторожностью использовать эту опцию, поскольку её удвоение приведёт к удвоению максимального объёма памяти, требуемой для подсчётов. Максимальное использование памяти примерно можно оценить формулой: `64 * max_matches * distinct_precision_threshold`. Учтите, что это наихудший сценарий, в большинстве случаев подсчёты используют существенно меньше оперативной памяти.\n\n**`COUNT(DISTINCT)` для распределённой таблицы или таблицы реального времени, состоящей из нескольких дисковых чанк, может возвращать неточные результаты**, но результат должен быть точным для распределённой таблицы, состоящей из локальных простых или таблиц реального времени с одинаковой схемой (идентичный набор/порядок полей, но настройки токенизации могут отличаться).\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\nCODE_BLOCK_114\n\n\n\n\n\n##### GROUP_CONCAT(field)\n\nЧасто хочется лучше понять содержимое каждой группы. Для этого можно использовать [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows), но он вернёт дополнительные строки, которых может не быть в выводе. `GROUP_CONCAT()` обогащает группировку, объединяя значения конкретного поля в группе. Возьмём предыдущий пример и улучшим его, отобразив все возраста в каждой группе.\n\n`GROUP_CONCAT(field)` возвращает список через запятую.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\n\n\n##### SUM(), MIN(), MAX(), AVG()\n\nРазумеется, можно получить сумму, среднее, минимальное и максимальное значения в группе.\n\n\n\n##### Пример:\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\n\n\n## Точность группировки\n\nГруппировка выполняется в фиксированной памяти, которая зависит от настройки [max_matches](../Searching/Options.md#max_matches). Если `max_matches` позволяет сохранить все найденные группы, результаты будут 100% точными. Однако, если значение `max_matches` меньше, результаты будут менее точными.\n\nПри использовании параллельной обработки ситуация усложняется. При включённом `pseudo_sharding` и/или при использовании RT-таблицы с несколькими дисковыми чанками каждая часть или псевдо-шард получает набор результатов не больше чем `max_matches`. Это может привести к неточностям в агрегатах и подсчётах групп при объединении результатов из разных потоков. Чтобы исправить это, можно либо увеличить значение `max_matches`, либо отключить параллельную обработку." + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Highlighting.md.json b/.translation-cache/Searching/Highlighting.md.json index 179db306db..29e2c1e7ce 100644 --- a/.translation-cache/Searching/Highlighting.md.json +++ b/.translation-cache/Searching/Highlighting.md.json @@ -38,5 +38,37 @@ "russian": "`order` задаёт порядок сортировки извлечённых фрагментов. Если установлено значение `\"score\"`, фрагменты сортируются по релевантности. Это опционально и работает аналогично опции `weight_order`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nCODE_BLOCK_151\n\n\n\nCODE_BLOCK_152\n\n\n\nCODE_BLOCK_153\n\n\n\nCODE_BLOCK_154\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_155\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_156\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nCODE_BLOCK_159\n\n\n\nCODE_BLOCK_160\n\n\n\nCODE_BLOCK_161\n\n\n\n\n\n#### fragment_size\n\n`fragment_size` задаёт максимальный размер фрагмента в символах. Может быть глобальным или для каждого поля отдельно. Опции для поля переопределяют глобальные. Это опционально, значение по умолчанию — 256. Работает аналогично опции `limit`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_162\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nCODE_BLOCK_165\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nCODE_BLOCK_168\n\n\n\nCODE_BLOCK_169\n\n\n\nCODE_BLOCK_170\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_171\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_172\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_173\n\n\n\nCODE_BLOCK_174\n\n\n\nCODE_BLOCK_175\n\n\n\nCODE_BLOCK_176\n\n\n\nCODE_BLOCK_177\n\n\n\n\n\n#### number_of_fragments\n\n`number_of_fragments` ограничивает максимальное количество фрагментов в результате. Как и `fragment_size`, может быть глобальным или для каждого поля. Опционально, значение по умолчанию — 0 (без ограничений). Работает аналогично опции `limit_snippets`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_178\n\n\n\nCODE_BLOCK_179\n\n\n\nCODE_BLOCK_180\n\n\n\nCODE_BLOCK_181\n\n\n\nCODE_BLOCK_182\n\n\n\nCODE_BLOCK_183\n\n\n\nCODE_BLOCK_184\n\n\n\nCODE_BLOCK_185\n\n\n\nCODE_BLOCK_186\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_187\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_188\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_189\n\n\n\nCODE_BLOCK_190\n\n\n\nCODE_BLOCK_191\n\n\n\nCODE_BLOCK_192\n\n\n\nCODE_BLOCK_193\n\n\n\n\n\n#### limit, limit_words, limit_snippets\n\nОпции `limit`, `limit_words` и `limit_snippets` могут задаваться глобально или для каждого поля. Глобальные опции используются как лимиты для полей, если не переопределены опциями для конкретного поля. В примере поле `title` подсвечивается с настройками по умолчанию, а поле `content` использует другие лимиты.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_194\n\n\n\nCODE_BLOCK_195\n\n\n\nCODE_BLOCK_196\n\n\n\nCODE_BLOCK_197\n\n\n\nCODE_BLOCK_198\n\n\n\nCODE_BLOCK_199\n\n\n\nCODE_BLOCK_200\n\n\n\nCODE_BLOCK_201\n\n\n\nCODE_BLOCK_202\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_203\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_204\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_205\n\n\n\nCODE_BLOCK_206\n\n\n\nCODE_BLOCK_207\n\n\n\nCODE_BLOCK_208\n\n\n\nCODE_BLOCK_209\n\n\n\n\n\n#### limits_per_field\n\nГлобальные лимиты также можно задать, указав `limits_per_field=0`. Эта опция означает, что все объединённые результаты подсветки должны укладываться в заданные лимиты. Недостаток в том, что в одном поле может быть несколько подсвеченных фрагментов, а в другом — ни одного, если движок подсветки решит, что они более релевантны.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_210\n\n\n\nCODE_BLOCK_211\n\n\n\nCODE_BLOCK_212\n\n\n\nCODE_BLOCK_213\n\n\n\nCODE_BLOCK_214\n\n\n\nCODE_BLOCK_215\n\n\n\nCODE_BLOCK_216\n\n\n\nCODE_BLOCK_217\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_219\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_220\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_221\n\n\n\nCODE_BLOCK_222\n\n\n\nCODE_BLOCK_223\n\n\n\n## CALL SNIPPETS\n\n\n\nОператор `CALL SNIPPETS` формирует фрагмент из предоставленных данных и запроса с использованием настроек указанной таблицы. Он не может получить доступ к встроенному хранилищу документов, поэтому рекомендуется использовать функцию [HIGHLIGHT()](../Searching/Highlighting.md).\n\nСинтаксис:\n\nCODE_BLOCK_224\n\n#### data\n\n`data` — источник, из которого извлекается фрагмент. Это может быть одна строка или список строк в фигурных скобках.\n\n#### table\n\n`table` — имя таблицы, которая задаёт настройки обработки текста для генерации фрагмента.\n\n#### query" }, "is_code_or_comment": false + }, + "bc45203e81e71677302ae9b2a76b71a17260c314c490c462619d854515ac4b64": { + "original": "\n\nCODE_BLOCK_152\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_153\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_154\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nCODE_BLOCK_159\n\n\n\n\n\n#### order\n\n`order` sets the sorting order of extracted snippets. If set to `\"score\"`, it sorts the extracted snippets in order of relevance. This is optional and works similarly to the `weight_order` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_160\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nCODE_BLOCK_165\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nCODE_BLOCK_168\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_169\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_170\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_171\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\nCODE_BLOCK_174\n\n\n\nCODE_BLOCK_175\n\n\n\n\n\n#### fragment_size\n\n`fragment_size` sets the maximum snippet size in symbols. It can be global or per-field. Per-field options override global options. This is optional, with a default value of 256. It works similarly to the `limit` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_176\n\n\n\nCODE_BLOCK_177\n\n\n\nCODE_BLOCK_178\n\n\n\nCODE_BLOCK_179\n\n\n\nCODE_BLOCK_180\n\n\n\nCODE_BLOCK_181\n\n\n\nCODE_BLOCK_182\n\n\n\nCODE_BLOCK_183\n\n\n\nCODE_BLOCK_184\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_185\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_186\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_187\n\n\n\nCODE_BLOCK_188\n\n\n\nCODE_BLOCK_189\n\n\n\nCODE_BLOCK_190\n\n\n\nCODE_BLOCK_191\n\n\n\n\n\n#### number_of_fragments\n\n`number_of_fragments` limits the maximum number of snippets in the result. Like `fragment_size`, it can be global or per-field. This is optional, with a default value of 0 (no limit). It works similarly to the `limit_snippets` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_192\n\n\n\nCODE_BLOCK_193\n\n\n\nCODE_BLOCK_194\n\n\n\nCODE_BLOCK_195\n\n\n\nCODE_BLOCK_196\n\n\n\nCODE_BLOCK_197\n\n\n\nCODE_BLOCK_198\n\n\n\nCODE_BLOCK_199\n\n\n\nCODE_BLOCK_200\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_201\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_202\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_203\n\n\n\nCODE_BLOCK_204\n\n\n\nCODE_BLOCK_205\n\n\n\nCODE_BLOCK_206\n\n\n\nCODE_BLOCK_207\n\n\n\n\n\n#### limit, limit_words, limit_snippets\n\nOptions like `limit`, `limit_words`, and `limit_snippets` can be set as global or per-field options. Global options are used as per-field limits unless per-field options override them. In the example, the `title` field is highlighted with default limit settings, while the `content` field uses a different limit.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_208\n\n\n\nCODE_BLOCK_209\n\n\n\nCODE_BLOCK_210\n\n\n\nCODE_BLOCK_211\n\n\n\nCODE_BLOCK_212\n\n\n\nCODE_BLOCK_213\n\n\n\nCODE_BLOCK_214\n\n\n\nCODE_BLOCK_215\n\n\n\nCODE_BLOCK_216\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_219\n\n\n\nCODE_BLOCK_220\n\n\n\nCODE_BLOCK_221\n\n\n\nCODE_BLOCK_222\n\n\n\nCODE_BLOCK_223\n\n\n\n\n\n#### limits_per_field\n\nGlobal limits can also be enforced by specifying `limits_per_field=0`. Setting this option means that all combined highlighting results must be within the specified limits. The downside is that you may get several snippets highlighted in one field and none in another if the highlighting engine decides that they are more relevant.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_224\n\n\n\nCODE_BLOCK_225\n\n\n\nCODE_BLOCK_226\n\n\n\nCODE_BLOCK_227\n\n\n\nCODE_BLOCK_228\n\n\n\nCODE_BLOCK_229\n\n\n\nCODE_BLOCK_230\n\n\n\nCODE_BLOCK_231\n\n\n\nCODE_BLOCK_232\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_234\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_235\n\n\n\nCODE_BLOCK_236\n\n\n\nCODE_BLOCK_237\n\n\n\n## CALL SNIPPETS\n\n", + "translations": { + "chinese": "\n\nCODE_BLOCK_152\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_153\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_154\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nCODE_BLOCK_159\n\n\n\n\n\n#### order\n\n`order` sets the sorting order of extracted snippets. If set to `\"score\"`, it sorts the extracted snippets in order of relevance. This is optional and works similarly to the `weight_order` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_160\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nCODE_BLOCK_165\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nCODE_BLOCK_168\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_169\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_170\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_171\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\nCODE_BLOCK_174\n\n\n\nCODE_BLOCK_175\n\n\n\n\n\n#### fragment_size\n\n`fragment_size` sets the maximum snippet size in symbols. It can be global or per-field. Per-field options override global options. This is optional, with a default value of 256. It works similarly to the `limit` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_176\n\n\n\nCODE_BLOCK_177\n\n\n\nCODE_BLOCK_178\n\n\n\nCODE_BLOCK_179\n\n\n\nCODE_BLOCK_180\n\n\n\nCODE_BLOCK_181\n\n\n\nCODE_BLOCK_182\n\n\n\nCODE_BLOCK_183\n\n\n\nCODE_BLOCK_184\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_185\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_186\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_187\n\n\n\nCODE_BLOCK_188\n\n\n\nCODE_BLOCK_189\n\n\n\nCODE_BLOCK_190\n\n\n\nCODE_BLOCK_191\n\n\n\n\n\n#### number_of_fragments\n\n`number_of_fragments` limits the maximum number of snippets in the result. Like `fragment_size`, it can be global or per-field. This is optional, with a default value of 0 (no limit). It works similarly to the `limit_snippets` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_192\n\n\n\nCODE_BLOCK_193\n\n\n\nCODE_BLOCK_194\n\n\n\nCODE_BLOCK_195\n\n\n\nCODE_BLOCK_196\n\n\n\nCODE_BLOCK_197\n\n\n\nCODE_BLOCK_198\n\n\n\nCODE_BLOCK_199\n\n\n\nCODE_BLOCK_200\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_201\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_202\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_203\n\n\n\nCODE_BLOCK_204\n\n\n\nCODE_BLOCK_205\n\n\n\nCODE_BLOCK_206\n\n\n\nCODE_BLOCK_207\n\n\n\n\n\n#### limit, limit_words, limit_snippets\n\nOptions like `limit`, `limit_words`, and `limit_snippets` can be set as global or per-field options. Global options are used as per-field limits unless per-field options override them. In the example, the `title` field is highlighted with default limit settings, while the `content` field uses a different limit.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_208\n\n\n\nCODE_BLOCK_209\n\n\n\nCODE_BLOCK_210\n\n\n\nCODE_BLOCK_211\n\n\n\nCODE_BLOCK_212\n\n\n\nCODE_BLOCK_213\n\n\n\nCODE_BLOCK_214\n\n\n\nCODE_BLOCK_215\n\n\n\nCODE_BLOCK_216\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_219\n\n\n\nCODE_BLOCK_220\n\n\n\nCODE_BLOCK_221\n\n\n\nCODE_BLOCK_222\n\n\n\nCODE_BLOCK_223\n\n\n\n\n\n#### limits_per_field\n\nGlobal limits can also be enforced by specifying `limits_per_field=0`. Setting this option means that all combined highlighting results must be within the specified limits. The downside is that you may get several snippets highlighted in one field and none in another if the highlighting engine decides that they are more relevant.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_224\n\n\n\nCODE_BLOCK_225\n\n\n\nCODE_BLOCK_226\n\n\n\nCODE_BLOCK_227\n\n\n\nCODE_BLOCK_228\n\n\n\nCODE_BLOCK_229\n\n\n\nCODE_BLOCK_230\n\n\n\nCODE_BLOCK_231\n\n\n\nCODE_BLOCK_232\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_234\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_235\n\n\n\nCODE_BLOCK_236\n\n\n\nCODE_BLOCK_237\n\n\n\n## CALL SNIPPETS\n\n", + "russian": "\n\nCODE_BLOCK_152\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_153\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_154\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nCODE_BLOCK_159\n\n\n\n\n\n#### order\n\n`order` sets the sorting order of extracted snippets. If set to `\"score\"`, it sorts the extracted snippets in order of relevance. This is optional and works similarly to the `weight_order` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_160\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nCODE_BLOCK_165\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nCODE_BLOCK_168\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_169\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_170\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_171\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\nCODE_BLOCK_174\n\n\n\nCODE_BLOCK_175\n\n\n\n\n\n#### fragment_size\n\n`fragment_size` sets the maximum snippet size in symbols. It can be global or per-field. Per-field options override global options. This is optional, with a default value of 256. It works similarly to the `limit` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_176\n\n\n\nCODE_BLOCK_177\n\n\n\nCODE_BLOCK_178\n\n\n\nCODE_BLOCK_179\n\n\n\nCODE_BLOCK_180\n\n\n\nCODE_BLOCK_181\n\n\n\nCODE_BLOCK_182\n\n\n\nCODE_BLOCK_183\n\n\n\nCODE_BLOCK_184\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_185\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_186\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_187\n\n\n\nCODE_BLOCK_188\n\n\n\nCODE_BLOCK_189\n\n\n\nCODE_BLOCK_190\n\n\n\nCODE_BLOCK_191\n\n\n\n\n\n#### number_of_fragments\n\n`number_of_fragments` limits the maximum number of snippets in the result. Like `fragment_size`, it can be global or per-field. This is optional, with a default value of 0 (no limit). It works similarly to the `limit_snippets` option.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_192\n\n\n\nCODE_BLOCK_193\n\n\n\nCODE_BLOCK_194\n\n\n\nCODE_BLOCK_195\n\n\n\nCODE_BLOCK_196\n\n\n\nCODE_BLOCK_197\n\n\n\nCODE_BLOCK_198\n\n\n\nCODE_BLOCK_199\n\n\n\nCODE_BLOCK_200\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_201\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_202\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_203\n\n\n\nCODE_BLOCK_204\n\n\n\nCODE_BLOCK_205\n\n\n\nCODE_BLOCK_206\n\n\n\nCODE_BLOCK_207\n\n\n\n\n\n#### limit, limit_words, limit_snippets\n\nOptions like `limit`, `limit_words`, and `limit_snippets` can be set as global or per-field options. Global options are used as per-field limits unless per-field options override them. In the example, the `title` field is highlighted with default limit settings, while the `content` field uses a different limit.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_208\n\n\n\nCODE_BLOCK_209\n\n\n\nCODE_BLOCK_210\n\n\n\nCODE_BLOCK_211\n\n\n\nCODE_BLOCK_212\n\n\n\nCODE_BLOCK_213\n\n\n\nCODE_BLOCK_214\n\n\n\nCODE_BLOCK_215\n\n\n\nCODE_BLOCK_216\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_217\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_218\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_219\n\n\n\nCODE_BLOCK_220\n\n\n\nCODE_BLOCK_221\n\n\n\nCODE_BLOCK_222\n\n\n\nCODE_BLOCK_223\n\n\n\n\n\n#### limits_per_field\n\nGlobal limits can also be enforced by specifying `limits_per_field=0`. Setting this option means that all combined highlighting results must be within the specified limits. The downside is that you may get several snippets highlighted in one field and none in another if the highlighting engine decides that they are more relevant.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_224\n\n\n\nCODE_BLOCK_225\n\n\n\nCODE_BLOCK_226\n\n\n\nCODE_BLOCK_227\n\n\n\nCODE_BLOCK_228\n\n\n\nCODE_BLOCK_229\n\n\n\nCODE_BLOCK_230\n\n\n\nCODE_BLOCK_231\n\n\n\nCODE_BLOCK_232\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_233\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_234\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_235\n\n\n\nCODE_BLOCK_236\n\n\n\nCODE_BLOCK_237\n\n\n\n## CALL SNIPPETS\n\n" + }, + "is_code_or_comment": true + }, + "a229da3d8c1b9ebb1399c7d721ac63f6dbaa300c2bf98b9345569dc027fa5875": { + "original": "The `CALL SNIPPETS` statement builds a snippet from provided data and query using specified table settings. It can't access built-in document storage, which is why it's recommended to use the [HIGHLIGHT() function](../Searching/Highlighting.md) instead.\n\nThe syntax is:\n\nCODE_BLOCK_238\n\n#### data\n\n`data` serves as the source from which a snippet is extracted. It can either be a single string or a list of strings enclosed in curly brackets.\n\n#### table\n\n`table` refers to the name of the table that provides the text processing settings for snippet generation.\n\n#### query\n\n`query` is the full-text query used to build the snippets.\n\n#### opt_value and opt_name\n\n`opt_value` and `opt_name` represent the [snippet generation options](../Searching/Highlighting.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_239\n\n\n\nCODE_BLOCK_240\n\n\n\nCODE_BLOCK_241\n\n\n\nCODE_BLOCK_242\n\n\n\nMost options are the same as in the [HIGHLIGHT() function](../Searching/Highlighting.md). There are, however, several options that can only be used with `CALL SNIPPETS`.\n\n\n\nThe following options can be used to highlight text stored in separate files:\n\n#### load_files\n\nThis option, when enabled, treats the first argument as file names instead of data to extract snippets from. The specified files on the server side will be loaded for data. Up to [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) worker threads per request will be used to parallelize the work when this flag is enabled. Default is 0 (no limit). To distribute snippet generation between remote agents, invoke snippets generation in a distributed table containing only one(!) local agent and several remotes. The [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) option is used to generate the final file name. For example, when searchd is configured with `snippets_file_prefix = /var/data_` and `text.txt` is provided as a file name, snippets will be generated from the content of `/var/data_text.txt`.\n\n#### load_files_scattered\n\nThis option only works with distributed snippets generation with remote agents. Source files for snippet generation can be distributed among different agents, and the main server will merge all non-erroneous results. For example, if one agent of the distributed table has `file1.txt`, another agent has `file2.txt`, and you use `CALL SNIPPETS` with both of these files, searchd will merge agent results, so you will get results from both `file1.txt` and `file2.txt`. Default is 0.\n\nIf the `load_files` option is also enabled, the request will return an error if any of the files is not available anywhere. Otherwise (if `load_files` is not enabled), it will return empty strings for all absent files. Searchd does not pass this flag to agents, so agents do not generate a critical error if the file does not exist. If you want to be sure that all source files are loaded, set both `load_files_scattered` and `load_files` to 1. If the absence of some source files on some agent is not critical, set only `load_files_scattered` to 1.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_243\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\nCODE_BLOCK_246\n\n\n\n", + "translations": { + "chinese": "`CALL SNIPPETS` 语句使用指定的表设置根据提供的数据和查询构建摘要片段。它无法访问内置的文档存储，因此建议改用 [HIGHLIGHT() 函数](../Searching/Highlighting.md)。\n\n语法如下：\n\nCODE_BLOCK_238\n\n#### data\n\n`data` 用作提取摘要片段的来源。它可以是单个字符串，也可以是用大括号括起来的字符串列表。\n\n#### table\n\n`table` 指提供文本处理设置以生成摘要片段的表名。\n\n#### query\n\n`query` 是用于构建摘要片段的全文查询。\n\n#### opt_value 和 opt_name\n\n`opt_value` 和 `opt_name` 表示 [摘要片段生成选项](../Searching/Highlighting.md)。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_239\n\n\n\nCODE_BLOCK_240\n\n\n\nCODE_BLOCK_241\n\n\n\nCODE_BLOCK_242\n\n\n\n大多数选项与 [HIGHLIGHT() 函数](../Searching/Highlighting.md) 中相同。然而，有几个选项只可用于 `CALL SNIPPETS`。\n\n\n\n以下选项可用于高亮显示存储在独立文件中的文本：\n\n#### load_files\n\n启用此选项时，会将第一个参数视为文件名，而非用于提取摘要片段的数据。服务器端将加载指定的文件作为数据。启用此标志时，每个请求将使用最多 [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) 个工作线程以实现并行处理。默认值为 0（无上限）。要在远程代理之间分发摘要片段生成，可以在包含一个（！）本地代理和多个远程代理的分布式表中调用摘要片段生成。选项 [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) 用于生成最终文件名。例如，当 searchd 配置为 `snippets_file_prefix = /var/data_` 并提供 `text.txt` 作为文件名时，摘要片段将由 `/var/data_text.txt` 的内容生成。\n\n#### load_files_scattered\n\n此选项仅适用于带远程代理的分布式摘要片段生成。摘要片段生成的源文件可以分布在不同代理中，主服务器将合并所有无错误的结果。例如，如果分布式表的一个代理有 `file1.txt`，另一个代理有 `file2.txt`，并且你使用包含这两个文件的 `CALL SNIPPETS`，searchd 将合并代理结果，因此你将获得来自 `file1.txt` 和 `file2.txt` 的结果。默认值为 0。\n\n如果 `load_files` 选项也启用，当任一文件不可用时，请求会返回错误。否则（如果未启用 `load_files`），对于所有缺失文件返回空字符串。Searchd 不会将此标志传递给代理，因此文件不存在时代理不会生成严重错误。如果你想确保所有源文件都被加载，请将 `load_files_scattered` 和 `load_files` 都设置为 1。如果某些代理缺失源文件不影响结果，则只设置 `load_files_scattered` 为 1。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_243\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\nCODE_BLOCK_246\n\n\n\n", + "russian": "Оператор `CALL SNIPPETS` формирует сниппет из предоставленных данных и запроса с использованием заданных настроек таблицы. Он не может получить доступ к встроенному хранилищу документов, поэтому рекомендуется использовать функцию [HIGHLIGHT()](../Searching/Highlighting.md).\n\nСинтаксис:\n\nCODE_BLOCK_238\n\n#### data\n\n`data` служит источником, из которого извлекается сниппет. Это может быть либо одна строка, либо список строк, заключённых в фигурные скобки.\n\n#### table\n\n`table` — имя таблицы, которая задаёт настройки обработки текста для генерации сниппетов.\n\n#### query\n\n`query` — полнотекстовый запрос, используемый для построения сниппетов.\n\n#### opt_value и opt_name\n\n`opt_value` и `opt_name` представляют собой [опции генерации сниппетов](../Searching/Highlighting.md).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_239\n\n\n\nCODE_BLOCK_240\n\n\n\nCODE_BLOCK_241\n\n\n\nCODE_BLOCK_242\n\n\n\nБольшинство опций идентичны опциям функции [HIGHLIGHT()](../Searching/Highlighting.md). Однако существуют несколько опций, которые можно использовать только с `CALL SNIPPETS`.\n\n\n\nСледующие опции могут использоваться для подсветки текста, хранящегося в отдельных файлах:\n\n#### load_files\n\nПри включении этой опции первый аргумент рассматривается как имена файлов, а не как данные для извлечения сниппетов. Указанные файлы на стороне сервера будут загружены для получения данных. Для параллелизации работы при включённом этом флаге на запрос будет выделено до [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) рабочих потоков. Значение по умолчанию — 0 (без ограничения). Чтобы распределить генерацию сниппетов между удалёнными агентами, вызовите генерацию сниппетов в распределённой таблице, содержащей только одного(!) локального агента и нескольких удалённых. Опция [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) используется для формирования конечного имени файла. Например, если searchd настроен с `snippets_file_prefix = /var/data_` и в качестве имени файла передаётся `text.txt`, сниппеты будут сгенерированы из содержимого файла `/var/data_text.txt`.\n\n#### load_files_scattered\n\nЭта опция работает только при распределённой генерации сниппетов с удалёнными агентами. Исходные файлы для генерации сниппетов могут быть распределены между разными агентами, а основной сервер объединит все корректные результаты. Например, если у одного агента распределённой таблицы есть `file1.txt`, у другого — `file2.txt`, и вы используете `CALL SNIPPETS` с обоими этими файлами, searchd объединит результаты агентов, и вы получите результаты как из `file1.txt`, так и из `file2.txt`. Значение по умолчанию — 0.\n\nЕсли опция `load_files` также включена, запрос вернёт ошибку, если какой-либо из файлов отсутствует везде. В противном случае (если `load_files` не включена) будет возвращена пустая строка для всех отсутствующих файлов. Searchd не передаёт этот флаг агентам, поэтому агенты не генерируют критическую ошибку, если файл не существует. Если вы хотите быть уверены, что все исходные файлы загружены, установите обе опции `load_files_scattered` и `load_files` в 1. Если отсутствие некоторых исходных файлов у некоторых агентов не критично, установите только `load_files_scattered` в 1.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_243\n\n\n\nCODE_BLOCK_244\n\n\n\nCODE_BLOCK_245\n\n\n\nCODE_BLOCK_246\n\n\n\n" + }, + "is_code_or_comment": false + }, + "8b252e54bbddaf30aec9d24e3141f91dc0076eabc2cd9dd4b0c1cd72cc6308f0": { + "original": "## Highlighting via HTTP\n\n\n\nTo highlight full-text search results in JSON queries via HTTP, field contents must be stored in document storage (enabled by default). In the example, full-text fields `content` and `title` are fetched from document storage and highlighted against the query specified in the `query` clause.\n\nHighlighted snippets are returned in the `highlight` property of the `hits` array.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\n\n\nTo highlight all possible fields, pass an empty object as the `highlight` property.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\nIn addition to common highlighting options, several synonyms are available for JSON queries via HTTP:\n\n#### fields\n\nThe `fields` object contains attribute names with options. It can also be an array of field names (without any options).\n\nNote that by default, highlighting attempts to highlight the results following the full-text query. In a general case, when you don't specify fields to highlight, the highlight is based on your full-text query. However, if you specify fields to highlight, it highlights only if the full-text query matches the selected fields.\n\n#### encoder\n\nThe `encoder` can be set to `default` or `html`. When set to `html`, it retains HTML markup when highlighting. This works similarly to the `html_strip_mode=retain` option.\n\n\n\n#### highlight_query\n\nThe `highlight_query` option allows you to highlight against a query other than your search query. The syntax is the same as in the main `query`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_113\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_121\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_122\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nCODE_BLOCK_127\n\n\n\n\n\n#### pre_tags and post_tags\n\n`pre_tags` and `post_tags` set the opening and closing tags for highlighted text snippets. They function similarly to the `before_match` and `after_match` options. These are optional, with default values of `` and ``.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_128\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_137\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_138\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\nCODE_BLOCK_143\n\n\n\n\n\n#### no_match_size\n\n`no_match_size` functions similarly to the `allow_empty` option. If set to 0, it acts as `allow_empty=1`, allowing an empty string to be returned as a highlighting result when a snippet could not be generated. Otherwise, the beginning of the field will be returned. This is optional, with a default value of 1.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_144\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nCODE_BLOCK_151", + "translations": { + "chinese": "## 通过 HTTP 进行高亮\n\n\n\n要通过 HTTP 在 JSON 查询中高亮全文搜索结果，字段内容必须存储在文档存储中（默认启用）。在示例中，全文字段 `content` 和 `title` 从文档存储中获取，并根据在 `query` 子句中指定的查询进行高亮。\n\n高亮片段在 `hits` 数组的 `highlight` 属性中返回。\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\n\n\n要高亮所有可能的字段，将一个空对象作为 `highlight` 属性传递。\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\n除了常见的高亮选项外，JSON 查询通过 HTTP 还支持几个同义词：\n\n#### fields\n\n`fields` 对象包含带有选项的属性名。它也可以是字段名的数组（不包含任何选项）。\n\n注意，默认情况下，高亮尝试根据全文查询结果进行高亮。在一般情况下，当您未指定要高亮的字段时，高亮基于全文查询。然而，如果您指定了要高亮的字段，只有当全文查询匹配选定字段时才进行高亮。\n\n#### encoder\n\n`encoder` 可以设置为 `default` 或 `html`。设置为 `html` 时，高亮时保留 HTML 标记。这与 `html_strip_mode=retain` 选项类似。\n\n\n\n#### highlight_query\n\n`highlight_query` 选项允许您使用与搜索查询不同的查询进行高亮。语法与主查询的 `query` 相同。\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_113\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_121\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_122\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nCODE_BLOCK_127\n\n\n\n\n\n#### pre_tags 和 post_tags\n\n`pre_tags` 和 `post_tags` 设置高亮文本片段的起始和结束标签。它们的功能类似于 `before_match` 和 `after_match` 选项。这些是可选项，默认值分别为 `` 和 ``。\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_128\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_137\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_138\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\nCODE_BLOCK_143\n\n\n\n\n\n#### no_match_size\n\n`no_match_size` 的功能类似于 `allow_empty` 选项。如果设置为 0，则等同于 `allow_empty=1`，当无法生成高亮片段时允许返回空字符串作为高亮结果。否则，将返回字段的开头。此项是可选的，默认值为 1。\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_144\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nCODE_BLOCK_151", + "russian": "## Выделение через HTTP\n\n\n\nДля выделения результатов полнотекстового поиска в JSON-запросах через HTTP содержимое полей должно храниться в хранилище документов (включено по умолчанию). В примере полнотекстовые поля `content` и `title` извлекаются из хранилища документов и подсвечиваются по запросу, указанному в условии `query`.\n\nПодсвеченные фрагменты возвращаются в свойстве `highlight` массива `hits`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_73\n\n\n\nCODE_BLOCK_74\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_75\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nCODE_BLOCK_82\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_83\n\n\n\nCODE_BLOCK_84\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_85\n\n\n\nCODE_BLOCK_86\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_87\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nCODE_BLOCK_92\n\n\n\n\n\nДля выделения всех возможных полей передайте пустой объект в свойстве `highlight`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_93\n\n\n\nCODE_BLOCK_94\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_95\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nCODE_BLOCK_102\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_103\n\n\n\nCODE_BLOCK_104\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_105\n\n\n\nCODE_BLOCK_106\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_107\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\nCODE_BLOCK_112\n\n\n\nКроме общих опций выделения, несколько синонимов доступны для JSON-запросов через HTTP:\n\n#### fields\n\nОбъект `fields` содержит имена атрибутов с опциями. Также может быть массивом имен полей (без опций).\n\nОбратите внимание, что по умолчанию выделение пытается подсветить результаты согласно полнотекстовому запросу. В общем случае, если вы не указываете поля для выделения, подсветка основана на вашем полнотекстовом запросе. Однако, если вы указываете поля для выделения, подсветка происходит только если полнотекстовый запрос совпадает с выбранными полями.\n\n#### encoder\n\n`encoder` может быть установлен в `default` или `html`. При установке в `html` сохраняется HTML-разметка при выделении. Это работает аналогично опции `html_strip_mode=retain`.\n\n\n\n#### highlight_query\n\nОпция `highlight_query` позволяет подсвечивать по запросу, отличному от вашего поискового. Синтаксис такой же, как в основном запросе `query`.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_113\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\nCODE_BLOCK_118\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_121\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_122\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nCODE_BLOCK_127\n\n\n\n\n\n#### pre_tags и post_tags\n\n`pre_tags` и `post_tags` задают открывающие и закрывающие теги для подсвечиваемых фрагментов текста. Они функционируют аналогично опциям `before_match` и `after_match`. Эти опции необязательны, значения по умолчанию — `` и ``.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_128\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_137\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_138\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\nCODE_BLOCK_143\n\n\n\n\n\n#### no_match_size\n\n`no_match_size` работает аналогично опции `allow_empty`. Если установлено в 0, действует как `allow_empty=1`, позволяя возвращать пустую строку как результат подсветки, когда фрагмент не может быть сгенерирован. Иначе возвращается начало поля. Опционально, значение по умолчанию — 1.\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_144\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nCODE_BLOCK_151" + }, + "is_code_or_comment": false + }, + "e24fddf44cdae67fedf38b62d45cd13486c84fc6fca9f8eba3389705540af49f": { + "original": "Defines the HTML stripping mode setting. Defaults to `index`, meaning that table settings will be used. Other values include `none` and `strip`, which forcibly skip or apply stripping regardless of table settings; and `retain`, which retains HTML markup and protects it from highlighting. The `retain` mode can only be used when highlighting full documents and therefore requires that no snippet size limits are set. The allowed string values are `none`, `strip`, `index`, and `retain`.\n\n#### allow_empty\n\nPermits an empty string to be returned as the highlighting result when no snippets could be generated in the current field (no keyword match or no snippets fit the limit). By default, the beginning of the original text would be returned instead of an empty string. The default is 0 (don't allow an empty result).\n\n#### snippet_boundary\n\nEnsures that snippets do not cross a sentence, paragraph, or zone boundary (when used with a table that has the respective indexing settings enabled). The allowed values are `sentence`, `paragraph`, and `zone`.\n\n#### emit_zones\n\nEmits an HTML tag with the enclosing zone name before each snippet. The default is 0 (don't emit zone names).\n\n#### force_snippets\n\nDetermines whether to force snippet generation even if limits allow highlighting the entire text. The default is 0 (don't force snippet generation).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n## Highlighting via SQL\n\nThe `HIGHLIGHT()` function can be used to highlight search results. Here's the syntax:\n\nCODE_BLOCK_44\n\n\n\nBy default, it works with no arguments.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\n`HIGHLIGHT()` retrieves all available full-text fields from document storage and highlights them against the provided query. Field syntax in queries is supported. Field text is separated by `field_separator`, which can be modified in the options.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\n\n\nOptional first argument in `HIGHLIGHT()` is the list of options.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\n\n\nThe optional second argument is a string containing a single field or a comma-separated list of fields. If this argument is present, only the specified fields will be fetched from document storage and highlighted. An empty string as the second argument signifies \"fetch all available fields.\"\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nCODE_BLOCK_60\n\n\n\n\n\nAlternatively, you can use the second argument to specify a string attribute or field name without quotes. In this case, the supplied string will be highlighted against the provided query, but field syntax will be ignored.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\n\n\nThe optional third argument is the query. This is used to highlight search results against a query different from the one used for searching.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\n\n\nAlthough `HIGHLIGHT()` is designed to work with stored full-text fields and string attributes, it can also be used to highlight arbitrary text. Keep in mind that if the query contains any field search operators (e.g., `@title hello @body world`), the field part of them is ignored in this case.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nSeveral options are relevant only when generating a single string as a result (not an array of snippets). This applies exclusively to the SQL `HIGHLIGHT()` function:\n\n#### snippet_separator\n\nA string to insert between snippets. The default is ` ... `.\n\n#### field_separator\n\nA string to insert between fields. The default is `|`.\n\nAnother way to highlight text is to use the [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS) statement. This mostly duplicates the `HIGHLIGHT()` functionality but cannot use built-in document storage. However, it can load source text from files.", + "translations": { + "chinese": "定义 HTML 去除模式设置。默认为 `index`，表示将使用表设置。其他值包括 `none` 和 `strip`，无论表设置如何，均强制跳过或应用去除；以及 `retain`，保留 HTML 标记并防止其被高亮。`retain` 模式只能用于高亮完整文档，因此要求未设置片段大小限制。允许的字符串值为 `none`、`strip`、`index` 和 `retain`。\n\n#### allow_empty\n\n允许在当前字段无法生成任何片段（无关键字匹配或无片段符合限制）的情况下返回空字符串作为高亮结果。默认情况下，将返回原始文本的开头，而不是空字符串。默认值为 0（不允许空结果）。\n\n#### snippet_boundary\n\n确保片段不会跨越句子、段落或区域边界（当与相应索引设置启用的表一起使用时）。允许的值为 `sentence`、`paragraph` 和 `zone`。\n\n#### emit_zones\n\n在每个片段前发出带有包含区域名称的 HTML 标签。默认值为 0（不发出区域名）。\n\n#### force_snippets\n\n确定是否强制生成片段，即使限制允许高亮整个文本。默认值为 0（不强制生成片段）。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n## 通过 SQL 进行高亮\n\n`HIGHLIGHT()` 函数可用于高亮搜索结果。语法如下：\n\nCODE_BLOCK_44\n\n\n\n默认情况下，无需参数即可使用。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\n`HIGHLIGHT()` 从文档存储中检索所有可用的全文字段，并针对提供的查询进行高亮。查询中支持字段语法。字段文本由 `field_separator` 分隔，该选项可在选项中修改。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\n\n\n`HIGHLIGHT()` 的可选第一个参数是选项列表。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\n\n\n可选的第二个参数是包含单个字段或逗号分隔字段列表的字符串。如果存在此参数，则仅从文档存储中获取并高亮指定字段。第二个参数为空字符串表示“获取所有可用字段”。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nCODE_BLOCK_60\n\n\n\n\n\n或者，您可以使用第二个参数指定字符串属性或字段名（无需引号）。此时，将针对提供的查询对所提供的字符串进行高亮，但字段语法将被忽略。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\n\n\n可选的第三个参数是查询。用于针对与用于搜索不同的查询高亮搜索结果。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\n\n\n虽然 `HIGHLIGHT()` 设计用于存储的全文字段和字符串属性，但它也可用于高亮任意文本。请注意，如果查询包含任何字段搜索操作符（例如 `@title hello @body world`），此时字段部分将被忽略。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\n若干选项仅在生成单个字符串作为结果时相关（而非片段数组）。这专门适用于 SQL 的 `HIGHLIGHT()` 函数：\n\n#### snippet_separator\n\n插入片段之间的字符串。默认是 ` ... `。\n\n#### field_separator\n\n插入字段之间的字符串。默认是 `|`。\n\n另一种高亮文本的方法是使用 [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS) 语句。这在很大程度上重复了 `HIGHLIGHT()` 的功能，但不能使用内置的文档存储。然而，它可以从文件加载源文本。", + "russian": "Определяет режим удаления HTML. По умолчанию `index`, что означает использование настроек таблицы. Другие значения включают `none` и `strip`, которые принудительно пропускают или применяют удаление независимо от настроек таблицы; и `retain`, который сохраняет HTML-разметку и защищает её от подсветки. Режим `retain` можно использовать только при подсветке полных документов, поэтому он требует отсутствия ограничений на размер фрагмента. Допустимые строковые значения: `none`, `strip`, `index` и `retain`.\n\n#### allow_empty\n\nРазрешает возвращать пустую строку в качестве результата подсветки, если в текущем поле не удалось сгенерировать фрагменты (нет совпадений по ключевым словам или ни один фрагмент не помещается в лимит). По умолчанию возвращается начало исходного текста вместо пустой строки. Значение по умолчанию — 0 (не разрешать пустой результат).\n\n#### snippet_boundary\n\nГарантирует, что фрагменты не будут пересекать границы предложения, абзаца или зоны (при использовании с таблицей, в которой включены соответствующие настройки индексирования). Допустимые значения: `sentence`, `paragraph` и `zone`.\n\n#### emit_zones\n\nВставляет HTML-тег с именем окружающей зоны перед каждым фрагментом. По умолчанию 0 (не вставлять имена зон).\n\n#### force_snippets\n\nОпределяет необходимость принудительной генерации фрагментов, даже если лимиты позволяют подсветить весь текст. По умолчанию 0 (не принуждать генерацию фрагментов).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n##### Java:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n## Подсветка через SQL\n\nФункция `HIGHLIGHT()` может использоваться для подсветки результатов поиска. Вот синтаксис:\n\nCODE_BLOCK_44\n\n\n\nПо умолчанию выполняется без аргументов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_45\n\n\n\nCODE_BLOCK_46\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_47\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\n`HIGHLIGHT()` извлекает все доступные полнотекстовые поля из хранилища документов и подсвечивает их относительно заданного запроса. В запросах поддерживается синтаксис поля. Текст поля разделяется с помощью `field_separator`, который можно изменить в опциях.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_51\n\n\n\nCODE_BLOCK_52\n\n\n\n\n\nНеобязательный первый аргумент в `HIGHLIGHT()` — это список опций.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_53\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\nCODE_BLOCK_56\n\n\n\n\n\nНеобязательный второй аргумент — строка с одним полем или списком полей, разделённых запятыми. Если этот аргумент присутствует, будут извлечены и подсвечены только указанные поля из хранилища документов. Пустая строка в качестве второго аргумента означает «извлечь все доступные поля».\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_57\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nCODE_BLOCK_60\n\n\n\n\n\nКроме того, второй аргумент можно использовать для указания строкового атрибута или имени поля без кавычек. В этом случае переданная строка будет подсвечена относительно предоставленного запроса, но синтаксис поля игнорируется.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_61\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nCODE_BLOCK_64\n\n\n\n\n\nНеобязательный третий аргумент — запрос. Он используется для подсветки результатов поиска по запросу, отличному от использованного при поиске.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_65\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nCODE_BLOCK_68\n\n\n\n\n\nХотя `HIGHLIGHT()` предназначена для работы с сохранёнными полнотекстовыми полями и строковыми атрибутами, её также можно использовать для подсветки произвольного текста. Имейте в виду, что если запрос содержит операторы поиска по полям (например, `@title hello @body world`), часть с полями будет игнорироваться.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_69\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nCODE_BLOCK_72\n\n\n\nНекоторые опции актуальны только при генерации одной строки в результате (не массива фрагментов). Это относится исключительно к SQL-функции `HIGHLIGHT()`:\n\n#### snippet_separator\n\nСтрока, вставляемая между фрагментами. Значение по умолчанию — ` ... `.\n\n#### field_separator\n\nСтрока, вставляемая между полями. Значение по умолчанию — `|`.\n\nДругой способ подсветки текста — использование оператора [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS). Он во многом дублирует функционал `HIGHLIGHT()`, но не может использовать встроенное хранилище документов. Вместо этого он может загружать исходный текст из файлов." + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/KNN.md.json b/.translation-cache/Searching/KNN.md.json index 459822461f..168f72e005 100644 --- a/.translation-cache/Searching/KNN.md.json +++ b/.translation-cache/Searching/KNN.md.json @@ -22,5 +22,29 @@ "chinese": "**重要提示：** 当使用 `hnsw_similarity='cosine'` 时，向量在插入时会自动归一化为单位向量（数学长度/幅度为1.0的向量）。这种归一化保持了向量的方向，同时标准化了其长度，这是高效计算余弦相似度所必需的。这意味着存储的值将与您原始输入的值不同。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n\n\n### KNN 向量搜索\n\n现在，您可以使用 SQL 或 JSON 格式中的 `knn` 子句执行 KNN 搜索。两种接口都支持相同的基本参数，确保无论选择哪种格式，都能获得一致的体验：\n\n- SQL: `select ... from
where knn ( , , [,] )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"query\": \"\",\n\n \"k\": ,\n\n \"ef\": ,\n\n\t\t \"rescore\": ,\n\n\t\t \"oversampling\": \n\n }\n\n }\n\n ```\n\n参数说明：\n\n* `field`：这是包含向量数据的浮点向量属性的名称。\n\n* `k`：表示返回的文档数量，是分层可导航小世界（HNSW）索引的关键参数。它指定单个 HNSW 索引应返回的文档数量。然而，最终结果中包含的文档数量可能会有所不同。例如，如果系统处理的是分割成磁盘块的实时表，每个块可能返回 `k` 个文档，导致总数超过指定的 `k`（因为累计计数为 `num_chunks * k`）。另一方面，如果在请求了 `k` 个文档后，根据特定属性过滤掉了一些文档，最终文档数可能少于 `k`。需要注意的是，参数 `k` 不适用于 ramchunks。在 ramchunks 的上下文中，检索过程不同，因此 `k` 参数对返回文档数量的影响不适用。\n\n* `query`：（推荐参数）搜索查询，可以是：\n\n - 文本字符串：如果字段配置了自动嵌入，则自动转换为嵌入向量。如果字段没有自动嵌入，将返回错误。\n\n - 向量数组：与 `query_vector` 功能相同。\n\n* `query_vector`：（遗留参数）作为数字数组的搜索向量。为向后兼容仍然支持。\n\n **注意：** 在同一请求中使用 `query` 或 `query_vector` 中的一个，不要同时使用。\n\n* `ef`：搜索过程中使用的动态列表大小的可选参数。`ef` 越大，搜索越准确但越慢。\n\n* `rescore`：启用 KNN 重新评分（默认禁用）。在 SQL 中设置为 `1`，在 JSON 中设置为 `true` 以启用重新评分。KNN 搜索完成后，使用量化向量（可能带有过采样）进行距离计算，然后用原始（全精度）向量重新计算距离并重新排序结果，以提高排名准确性。\n\n* `oversampling`：设置一个因子（浮点值），在执行 KNN 搜索时将 `k` 乘以该因子，导致使用量化向量检索的候选项多于所需数量。默认不应用过采样。如果启用重新评分，这些候选项可以稍后重新评估。过采样也适用于非量化向量。由于它增加了 `k`，影响 HNSW 索引的工作方式，可能会导致结果准确性略有变化。\n\n文档始终按与搜索向量的距离排序。您指定的任何额外排序条件将在此主要排序条件之后应用。要获取距离，有一个内置函数叫做 [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29)。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21\n\n\n\n\n\n### 向量量化\n\nHNSW 索引需要完全加载到内存中以执行 KNN 搜索，这可能导致显著的内存消耗。为了减少内存使用，可以应用标量量化——一种通过用有限数量的离散值表示每个分量（维度）来压缩高维向量的技术。Manticore 支持 8 位和 1 位量化，意味着每个向量分量从 32 位浮点压缩到 8 位甚至 1 位，分别减少了 4 倍或 32 倍的内存使用。这些压缩表示还允许更快的距离计算，因为可以在单个 SIMD 指令中处理更多的向量分量。虽然标量量化引入了一些近似误差，但通常是在搜索准确性和资源效率之间值得的权衡。为了获得更好的准确性，量化可以与重新评分和过采样结合使用：检索的候选项多于请求的数量，并使用原始 32 位浮点向量重新计算这些候选项的距离。\n\n支持的量化类型包括：\n\n* `8bit`：每个向量分量量化为 8 位。\n\n* `1bit`：每个向量分量量化为 1 位。使用非对称量化，查询向量量化为 4 位，存储向量量化为 1 位。这种方法比简单方法提供更高的精度，但性能有所折衷。\n\n* `1bitsimple`：每个向量分量量化为 1 位。此方法比 `1bit` 更快，但通常准确性较低。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n\n\n### 通过 id 查找相似文档\n\n> 注意：通过 id 查找相似文档需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。" }, "is_code_or_comment": false + }, + "0e558c9c8a9c7c4f86543972ec5b8ce376aa9e32c57345abb8e228702e986f5c": { + "original": "\n\n#### Manual Vector Insertion\n\n\n\nAlternatively, you can manually insert pre-computed vector data, ensuring it matches the dimensions you specified when creating the table. You can also insert an empty vector; this means that the document will be excluded from vector search results.\n\n**Important:** When using `hnsw_similarity='cosine'`, vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n### KNN vector search\n\nNow, you can perform a KNN search using the `knn` clause in either SQL or JSON format. Both interfaces support the same essential parameters, ensuring a consistent experience regardless of the format you choose:\n\n- SQL: `select ... from
where knn ( , , [,] )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"query\": \"\",\n\n \"k\": ,\n\n \"ef\": ,\n\n\t\t \"rescore\": ,\n\n\t\t \"oversampling\": \n\n }\n\n }\n\n ```\n\nThe parameters are:\n\n* `field`: This is the name of the float vector attribute containing vector data.\n\n* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable.\n\n* `query`: (Recommended parameter) The search query, which can be either:\n\n - Text string: Automatically converted to embeddings if the field has auto-embeddings configured. Will return an error if the field doesn't have auto-embeddings.\n\n - Vector array: Works the same as `query_vector`.\n\n* `query_vector`: (Legacy parameter) The search vector as an array of numbers. Still supported for backward compatibility.\n\n **Note:** Use either `query` or `query_vector`, not both in the same request.\n\n* `ef`: optional size of the dynamic list used during the search. A higher `ef` leads to more accurate but slower search.\n\n* `rescore`: Enables KNN rescoring (disabled by default). Set to `1` in SQL or `true` in JSON to enable rescoring. After the KNN search is completed using quantized vectors (with possible oversampling), distances are recalculated with the original (full-precision) vectors and results are re-sorted to improve ranking accuracy.\n\n* `oversampling`: Sets a factor (float value) by which `k` is multiplied when executing the KNN search, causing more candidates to be retrieved than needed using quantized vectors. No oversampling is applied by default. These candidates can be re-evaluated later if rescoring is enabled. Oversampling also works with non-quantized vectors. Since it increases `k`, which affects how the HNSW index works, it may cause a small change in result accuracy.\n\nDocuments are always sorted by their distance to the search vector. Any additional sorting criteria you specify will be applied after this primary sort condition. For retrieving the distance, there is a built-in function called [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n### Vector quantization\n\nHNSW indexes need to be fully loaded into memory to perform KNN search, which can lead to significant memory consumption. To reduce memory usage, scalar quantization can be applied - a technique that compresses high-dimensional vectors by representing each component (dimension) with a limited number of discrete values. Manticore supports 8-bit and 1-bit quantization, meaning each vector component is compressed from a 32-bit float to 8 bits or even 1 bit, reducing memory usage by 4x or 32x, respectively. These compressed representations also allow for faster distance calculations, as more vector components can be processed in a single SIMD instruction. Although scalar quantization introduces some approximation error, it is often a worthwhile trade-off between search accuracy and resource efficiency. For even better accuracy, quantization can be combined with rescoring and oversampling: more candidates are retrieved than requested, and distances for these candidates are recalculated using the original 32-bit float vectors.\n\nSupported quantization types include:\n\n* `8bit`: Each vector component is quantized to 8 bits.\n\n* `1bit`: Each vector component is quantized to 1 bit. Asymmetric quantization is used, with query vectors quantized to 4 bits and stored vectors to 1 bit. This approach offers greater precision than simpler methods, though with some performance trade-off.\n\n* `1bitsimple`: Each vector component is quantized to 1 bit. This method is faster than `1bit`, but typically less accurate.\n\n", + "translations": { + "chinese": "\n\n#### Manual Vector Insertion\n\n\n\nAlternatively, you can manually insert pre-computed vector data, ensuring it matches the dimensions you specified when creating the table. You can also insert an empty vector; this means that the document will be excluded from vector search results.\n\n**Important:** When using `hnsw_similarity='cosine'`, vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n### KNN vector search\n\nNow, you can perform a KNN search using the `knn` clause in either SQL or JSON format. Both interfaces support the same essential parameters, ensuring a consistent experience regardless of the format you choose:\n\n- SQL: `select ... from
where knn ( , , [,] )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"query\": \"\",\n\n \"k\": ,\n\n \"ef\": ,\n\n\t\t \"rescore\": ,\n\n\t\t \"oversampling\": \n\n }\n\n }\n\n ```\n\nThe parameters are:\n\n* `field`: This is the name of the float vector attribute containing vector data.\n\n* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable.\n\n* `query`: (Recommended parameter) The search query, which can be either:\n\n - Text string: Automatically converted to embeddings if the field has auto-embeddings configured. Will return an error if the field doesn't have auto-embeddings.\n\n - Vector array: Works the same as `query_vector`.\n\n* `query_vector`: (Legacy parameter) The search vector as an array of numbers. Still supported for backward compatibility.\n\n **Note:** Use either `query` or `query_vector`, not both in the same request.\n\n* `ef`: optional size of the dynamic list used during the search. A higher `ef` leads to more accurate but slower search.\n\n* `rescore`: Enables KNN rescoring (disabled by default). Set to `1` in SQL or `true` in JSON to enable rescoring. After the KNN search is completed using quantized vectors (with possible oversampling), distances are recalculated with the original (full-precision) vectors and results are re-sorted to improve ranking accuracy.\n\n* `oversampling`: Sets a factor (float value) by which `k` is multiplied when executing the KNN search, causing more candidates to be retrieved than needed using quantized vectors. No oversampling is applied by default. These candidates can be re-evaluated later if rescoring is enabled. Oversampling also works with non-quantized vectors. Since it increases `k`, which affects how the HNSW index works, it may cause a small change in result accuracy.\n\nDocuments are always sorted by their distance to the search vector. Any additional sorting criteria you specify will be applied after this primary sort condition. For retrieving the distance, there is a built-in function called [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n### Vector quantization\n\nHNSW indexes need to be fully loaded into memory to perform KNN search, which can lead to significant memory consumption. To reduce memory usage, scalar quantization can be applied - a technique that compresses high-dimensional vectors by representing each component (dimension) with a limited number of discrete values. Manticore supports 8-bit and 1-bit quantization, meaning each vector component is compressed from a 32-bit float to 8 bits or even 1 bit, reducing memory usage by 4x or 32x, respectively. These compressed representations also allow for faster distance calculations, as more vector components can be processed in a single SIMD instruction. Although scalar quantization introduces some approximation error, it is often a worthwhile trade-off between search accuracy and resource efficiency. For even better accuracy, quantization can be combined with rescoring and oversampling: more candidates are retrieved than requested, and distances for these candidates are recalculated using the original 32-bit float vectors.\n\nSupported quantization types include:\n\n* `8bit`: Each vector component is quantized to 8 bits.\n\n* `1bit`: Each vector component is quantized to 1 bit. Asymmetric quantization is used, with query vectors quantized to 4 bits and stored vectors to 1 bit. This approach offers greater precision than simpler methods, though with some performance trade-off.\n\n* `1bitsimple`: Each vector component is quantized to 1 bit. This method is faster than `1bit`, but typically less accurate.\n\n", + "russian": "\n\n#### Manual Vector Insertion\n\n\n\nAlternatively, you can manually insert pre-computed vector data, ensuring it matches the dimensions you specified when creating the table. You can also insert an empty vector; this means that the document will be excluded from vector search results.\n\n**Important:** When using `hnsw_similarity='cosine'`, vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\n\n\n### KNN vector search\n\nNow, you can perform a KNN search using the `knn` clause in either SQL or JSON format. Both interfaces support the same essential parameters, ensuring a consistent experience regardless of the format you choose:\n\n- SQL: `select ... from
where knn ( , , [,] )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"query\": \"\",\n\n \"k\": ,\n\n \"ef\": ,\n\n\t\t \"rescore\": ,\n\n\t\t \"oversampling\": \n\n }\n\n }\n\n ```\n\nThe parameters are:\n\n* `field`: This is the name of the float vector attribute containing vector data.\n\n* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable.\n\n* `query`: (Recommended parameter) The search query, which can be either:\n\n - Text string: Automatically converted to embeddings if the field has auto-embeddings configured. Will return an error if the field doesn't have auto-embeddings.\n\n - Vector array: Works the same as `query_vector`.\n\n* `query_vector`: (Legacy parameter) The search vector as an array of numbers. Still supported for backward compatibility.\n\n **Note:** Use either `query` or `query_vector`, not both in the same request.\n\n* `ef`: optional size of the dynamic list used during the search. A higher `ef` leads to more accurate but slower search.\n\n* `rescore`: Enables KNN rescoring (disabled by default). Set to `1` in SQL or `true` in JSON to enable rescoring. After the KNN search is completed using quantized vectors (with possible oversampling), distances are recalculated with the original (full-precision) vectors and results are re-sorted to improve ranking accuracy.\n\n* `oversampling`: Sets a factor (float value) by which `k` is multiplied when executing the KNN search, causing more candidates to be retrieved than needed using quantized vectors. No oversampling is applied by default. These candidates can be re-evaluated later if rescoring is enabled. Oversampling also works with non-quantized vectors. Since it increases `k`, which affects how the HNSW index works, it may cause a small change in result accuracy.\n\nDocuments are always sorted by their distance to the search vector. Any additional sorting criteria you specify will be applied after this primary sort condition. For retrieving the distance, there is a built-in function called [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\n\n\n### Vector quantization\n\nHNSW indexes need to be fully loaded into memory to perform KNN search, which can lead to significant memory consumption. To reduce memory usage, scalar quantization can be applied - a technique that compresses high-dimensional vectors by representing each component (dimension) with a limited number of discrete values. Manticore supports 8-bit and 1-bit quantization, meaning each vector component is compressed from a 32-bit float to 8 bits or even 1 bit, reducing memory usage by 4x or 32x, respectively. These compressed representations also allow for faster distance calculations, as more vector components can be processed in a single SIMD instruction. Although scalar quantization introduces some approximation error, it is often a worthwhile trade-off between search accuracy and resource efficiency. For even better accuracy, quantization can be combined with rescoring and oversampling: more candidates are retrieved than requested, and distances for these candidates are recalculated using the original 32-bit float vectors.\n\nSupported quantization types include:\n\n* `8bit`: Each vector component is quantized to 8 bits.\n\n* `1bit`: Each vector component is quantized to 1 bit. Asymmetric quantization is used, with query vectors quantized to 4 bits and stored vectors to 1 bit. This approach offers greater precision than simpler methods, though with some performance trade-off.\n\n* `1bitsimple`: Each vector component is quantized to 1 bit. This method is faster than `1bit`, but typically less accurate.\n\n" + }, + "is_code_or_comment": true + }, + "1bc252d34f3b4dffe798c8f817045999423c6c1db0e86fbbea60762bdbce9b72": { + "original": "##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\n### Find similar docs by id\n\n> NOTE: Finding similar documents by id requires [Manticore Buddy](../Installation/Manticore_Buddy.md). If it doesn't work, make sure Buddy is installed.\n\nFinding documents similar to a specific one based on its unique ID is a common task. For instance, when a user views a particular item, Manticore Search can efficiently identify and display a list of items that are most similar to it in the vector space. Here's how you can do it:\n\n- SQL: `select ... from
where knn ( , , )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"doc_id\": ,\n\n \"k\": \n\n }\n\n }\n\n ```\n\nThe parameters are:\n\n* `field`: This is the name of the float vector attribute containing vector data.\n\n* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable.\n\n* `document id`: Document ID for KNN similarity search.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\n### Filtering KNN vector search results\n\nManticore also supports additional filtering of documents returned by the KNN search, either by full-text matching, attribute filters, or both.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n", + "translations": { + "chinese": "##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\n### 通过 id 查找相似文档\n\n> 注意：通过 id 查找相似文档需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。\n\n根据唯一 ID 查找类似文档是一项常见任务。例如，当用户查看某个特定条目时，Manticore Search 可以高效地识别并显示与该条目在向量空间中最相似的项目列表。操作方式如下：\n\n- SQL: `select ... from
where knn ( , , )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"doc_id\": ,\n\n \"k\": \n\n }\n\n }\n\n ```\n\n参数说明：\n\n* `field`：这是包含向量数据的浮点向量属性名称。\n\n* `k`：代表返回的文档数量，是层次导航小世界（HNSW）索引的一个关键参数。它指定单个 HNSW 索引应返回的文档数量。但最终结果中包含的文档数量可能会有所不同。例如，当系统处理分为磁盘块的实时表时，每个块都可能返回 `k` 个文档，导致总数超过指定的 `k`（因为总计为 `num_chunks * k`）。另一方面，如果请求了 `k` 个文档后，部分文档被基于特定属性过滤掉，则最终文档数可能少于 `k`。需要注意的是，参数 `k` 不适用于 ramchunks。在 ramchunks 的上下文中，检索过程不同，因此 `k` 参数对返回文档数量的影响不适用。\n\n* `document id`：用于 KNN 相似搜索的文档 ID。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\n### 过滤 KNN 向量搜索结果\n\nManticore 还支持对 KNN 搜索返回的文档进行额外过滤，过滤方式可以是全文匹配、属性过滤，或两者结合。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n", + "russian": "##### SQL:\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\n\n\n### Найти похожие документы по id\n\n> ПРИМЕЧАНИЕ: Поиск похожих документов по id требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если это не работает, убедитесь, что Buddy установлен.\n\nПоиск документов, похожих на конкретный на основе его уникального ID — распространённая задача. Например, когда пользователь просматривает определённый элемент, Manticore Search может эффективно определить и отобразить список элементов, наиболее похожих на него в векторном пространстве. Вот как это можно сделать:\n\n- SQL: `select ... from
where knn ( , , )`\n\n- JSON:\n\n ```\n\n POST /search\n\n {\n\n \"table\": \"
\",\n\n \"knn\":\n\n {\n\n \"field\": \"\",\n\n \"doc_id\": ,\n\n \"k\": \n\n }\n\n }\n\n ```\n\nПараметры:\n\n* `field`: Имя атрибута с плавающей точкой, содержащего векторные данные.\n\n* `k`: Количество документов для возврата, ключевой параметр для индексов Hierarchical Navigable Small World (HNSW). Он указывает, сколько документов должен вернуть один индекс HNSW. Однако фактическое количество документов в итоговых результатах может варьироваться. Например, если система работает с таблицами реального времени, разделёнными на дисковые чанки, каждый чанк может вернуть `k` документов, что в сумме превысит заданное `k` (так как суммарное количество будет равно `num_chunks * k`). С другой стороны, итоговое количество документов может быть меньше `k`, если после запроса `k` документов некоторые из них отфильтровываются по атрибутам. Важно отметить, что параметр `k` не применяется к ramchunks. В случае ramchunks процесс выборки устроен иначе, и параметр `k` не влияет на количество возвращаемых документов.\n\n* `document id`: ID документа для поиска по сходству KNN.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\n### Фильтрация результатов векторного поиска KNN\n\nManticore также поддерживает дополнительную фильтрацию документов, возвращаемых поиском KNN, как по полнотекстовому совпадению, так и по атрибутам, или по обоим критериям.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\n" + }, + "is_code_or_comment": false + }, + "e526c98701271dc16d81657c644796a2ea12f6638425b2fbf889489638775cf9": { + "original": "# K-nearest neighbor vector search\n\nManticore Search supports the ability to add embeddings generated by Machine Learning models to each document, and then doing a nearest-neighbor search on them. This lets you build features like similarity search, recommendations, semantic search, and relevance ranking based on NLP algorithms, among others, including image, video, and sound searches.\n\n## What is an embedding?\n\nAn embedding is a method of representing data - such as text, images, or sound - as vectors in a high-dimensional space. These vectors are crafted to ensure that the distance between them reflects the similarity of the data they represent. This process typically employs algorithms like word embeddings (e.g., Word2Vec, BERT) for text or neural networks for images. The high-dimensional nature of the vector space, with many components per vector, allows for the representation of complex and nuanced relationships between items. Their similarity is gauged by the distance between these vectors, often measured using methods like Euclidean distance or cosine similarity.\n\nManticore Search enables k-nearest neighbor (KNN) vector searches using the HNSW library. This functionality is part of the [Manticore Columnar Library](https://github.com/manticoresoftware/columnar).\n\n\n\n### Configuring a table for KNN search\n\nTo run KNN searches, you must first configure your table. Float vectors and KNN search are only supported in real-time tables (not in plain tables). The table needs to have at least one [float_vector](../Creating_a_table/Data_types.md#Float-vector) attribute, which serves as a data vector. You need to specify the following properties:\n\n* `knn_type`: A mandatory setting; currently, only `hnsw` is supported.\n\n* `knn_dims`: A mandatory setting that specifies the dimensions of the vectors being indexed.\n\n* `hnsw_similarity`: A mandatory setting that specifies the distance function used by the HNSW index. Acceptable values are:\n\n - `L2` - Squared L2\n\n - `IP` - Inner product\n\n - `COSINE` - Cosine similarity\n\n \n\n **Note:** When using `COSINE` similarity, vectors are automatically normalized upon insertion. This means the stored vector values may differ from the original input values, as they will be converted to unit vectors (vectors with a mathematical length/magnitude of 1.0) to enable efficient cosine similarity calculations. This normalization preserves the direction of the vector while standardizing its length.\n\n* `hnsw_m`: An optional setting that defines the maximum number of outgoing connections in the graph. The default is 16.\n\n* `hnsw_ef_construction`: An optional setting that defines a construction time/accuracy trade-off.\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Plain mode (using configuration file):\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n### Inserting vector data\n\n#### Auto Embeddings (Recommended)\n\nThe easiest way to work with vector data is using **auto embeddings**. With this feature, you create a table with `MODEL_NAME` and `FROM` parameters, then simply insert your text data - Manticore automatically generates embeddings for you.\n\n##### Creating a table with auto embeddings\n\nWhen creating a table for auto embeddings, specify:\n\n- `MODEL_NAME`: The embedding model to use\n\n- `FROM`: Which fields to use for embedding generation (empty means all text/string fields)\n\n**Supported embedding models:**\n\n- **Sentence Transformers**: Any [suitable BERT-based Hugging Face model](https://huggingface.co/sentence-transformers/models) (e.g., `sentence-transformers/all-MiniLM-L6-v2`) — no API key needed. Manticore downloads the model when you create the table.\n\n- **OpenAI**: OpenAI embedding models like `openai/text-embedding-ada-002` - requires `API_KEY=''` parameter\n\n- **Voyage**: Voyage AI embedding models - requires `API_KEY=''` parameter\n\n- **Jina**: Jina AI embedding models - requires `API_KEY=''` parameter\n\nMore information about setting up a `float_vector` attribute can be found [here](../Creating_a_table/Data_types.md#Float-vector).\n\n\n\n##### SQL:\n\n\n\nUsing sentence-transformers (no API key needed)\n\nCODE_BLOCK_5\n\nUsing OpenAI (requires API_KEY parameter)\n\nCODE_BLOCK_6\n\nUsing all text fields for embeddings (FROM is empty)\n\nCODE_BLOCK_7\n\n\n\n##### JSON:\n\n\n\nUsing sentence-transformers (no API key needed)\n\nCODE_BLOCK_8\n\nUsing OpenAI (requires API_KEY parameter)\n\nCODE_BLOCK_9\n\nUsing all text fields for embeddings (FROM is empty)\n\nCODE_BLOCK_10\n\n\n\n##### Inserting data with auto embeddings\n\n\n\nWhen using auto embeddings, **do not specify the vector field** in your INSERT statement. The embeddings are generated automatically from the text fields specified in the `FROM` parameter.\n\n\n\n##### SQL:\n\n\n\nInsert text data only - embeddings generated automatically\n\nCODE_BLOCK_11\n\nInsert multiple fields - both used for embedding if FROM='title,description' \n\nCODE_BLOCK_12\n\nInsert empty vector (document excluded from vector search)\n\nCODE_BLOCK_13\n\n\n\n##### JSON:\n\n\n\nInsert text data only - embeddings generated automatically\n\nCODE_BLOCK_14\n\nInsert multiple fields - both used for embedding if FROM='title,description' \n\nCODE_BLOCK_15\n\nInsert empty vector (document excluded from vector search)\n\nCODE_BLOCK_16\n\n\n\n##### Searching with auto embeddings\n\n\n\nSearch works the same way - provide your query text and Manticore will generate embeddings and find similar documents:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON:\n\n\n\nUsing text query with auto-embeddings\n\nCODE_BLOCK_19\n\nUsing vector query directly\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21", + "translations": { + "chinese": "# K近邻向量搜索\n\nManticore Search 支持向每个文档添加由机器学习模型生成的嵌入向量，然后对它们进行最近邻搜索。这使您可以构建类似度搜索、推荐、语义搜索和基于NLP算法的相关性排名等功能，还包括图像、视频和声音搜索。\n\n## 什么是嵌入？\n\n嵌入是一种表示数据的方法——例如文本、图像或声音——将其表示为高维空间中的向量。这些向量设计成使它们之间的距离反映出所代表数据的相似性。该过程通常采用诸如词嵌入（例如 Word2Vec、BERT）算法来处理文本，或使用神经网络处理图像。向量空间的高维特性，每个向量具有多个分量，能够表现项目之间复杂而微妙的关系。它们的相似度通过向量之间的距离来衡量，通常使用欧氏距离或余弦相似度等方法。\n\nManticore Search 使用 HNSW 库支持 k近邻（KNN）向量搜索。此功能是 [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) 的一部分。\n\n\n\n### 配置用于KNN搜索的表\n\n要运行KNN搜索，必须首先配置表。浮点向量和KNN搜索仅支持实时表（不支持普通表）。表需要至少包含一个 [float_vector](../Creating_a_table/Data_types.md#Float-vector) 属性，该属性作为数据向量。您需指定以下属性：\n\n* `knn_type`：必填设置；当前仅支持 `hnsw`。\n\n* `knn_dims`：必填设置，指定索引向量的维数。\n\n* `hnsw_similarity`：必填设置，指定HNSW索引使用的距离函数。可接受的值：\n\n - `L2` - 平方L2距离\n\n - `IP` - 内积\n\n - `COSINE` - 余弦相似度\n\n \n\n **注意：** 当使用 `COSINE` 相似度时，插入时向量会自动归一化。这意味着存储的向量值可能与原始输入不同，因为它们会被转换为单位向量（数学长度/幅度为1.0的向量），以实现高效的余弦相似度计算。归一化保持向量方向不变，同时标准化其长度。\n\n* `hnsw_m`：可选设置，定义图中最多的出边连接数，默认值为16。\n\n* `hnsw_ef_construction`：可选设置，定义构建阶段的时间与精度折衷。\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### 普通模式（使用配置文件）：\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n### 插入向量数据\n\n#### 自动嵌入（推荐）\n\n处理向量数据最简单的方式是使用**自动嵌入**。通过此功能，您创建一个包含 `MODEL_NAME` 和 `FROM` 参数的表，然后只需插入文本数据—Manticore 会自动为您生成嵌入。\n\n##### 创建包含自动嵌入的表\n\n创建自动嵌入表时，请指定：\n\n- `MODEL_NAME`：要使用的嵌入模型\n\n- `FROM`：用于生成嵌入的字段（空表示所有文本/字符串字段）\n\n**支持的嵌入模型：**\n\n- **Sentence Transformers**：任何[合适的基于BERT的Hugging Face模型](https://huggingface.co/sentence-transformers/models)（例如 `sentence-transformers/all-MiniLM-L6-v2`）—无需API密钥。创建表时，Manticore会下载该模型。\n\n- **OpenAI**：OpenAI嵌入模型，如 `openai/text-embedding-ada-002` - 需要 `API_KEY=''` 参数\n\n- **Voyage**：Voyage AI 嵌入模型 - 需要 `API_KEY=''` 参数\n\n- **Jina**：Jina AI 嵌入模型 - 需要 `API_KEY=''` 参数\n\n更多关于设置 `float_vector` 属性的信息可以见[这里](../Creating_a_table/Data_types.md#Float-vector)。\n\n\n\n##### SQL：\n\n\n\n使用 sentence-transformers（无须API密钥）\n\nCODE_BLOCK_5\n\n使用 OpenAI（需要 API_KEY 参数）\n\nCODE_BLOCK_6\n\n使用所有文本字段进行嵌入（FROM为空）\n\nCODE_BLOCK_7\n\n\n\n##### JSON：\n\n\n\n使用 sentence-transformers（无须API密钥）\n\nCODE_BLOCK_8\n\n使用 OpenAI（需要 API_KEY 参数）\n\nCODE_BLOCK_9\n\n使用所有文本字段进行嵌入（FROM为空）\n\nCODE_BLOCK_10\n\n\n\n##### 使用自动嵌入插入数据\n\n\n\n使用自动嵌入时，**不要在INSERT语句中指定向量字段**。嵌入会自动从`FROM`参数指定的文本字段生成。\n\n\n\n##### SQL：\n\n\n\n仅插入文本数据——嵌入自动生成\n\nCODE_BLOCK_11\n\n插入多个字段 — 如果FROM='title,description'，则两者都会用于嵌入生成\n\nCODE_BLOCK_12\n\n插入空向量（文档被排除在向量搜索之外）\n\nCODE_BLOCK_13\n\n\n\n##### JSON：\n\n\n\n仅插入文本数据——嵌入自动生成\n\nCODE_BLOCK_14\n\n插入多个字段 — 如果FROM='title,description'，则两者都会用于嵌入生成\n\nCODE_BLOCK_15\n\n插入空向量（文档被排除在向量搜索之外）\n\nCODE_BLOCK_16\n\n\n\n##### 使用自动嵌入进行搜索\n\n\n\n搜索方式相同—提供查询文本，Manticore 会生成嵌入并找到类似文档：\n\n\n\n##### SQL：\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON：\n\n\n\n使用文本查询与自动嵌入\n\nCODE_BLOCK_19\n\n直接使用向量查询\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21", + "russian": "# K-ближайшего соседа векторный поиск\n\nManticore Search поддерживает возможность добавления эмбеддингов, сгенерированных моделями машинного обучения, к каждому документу, а затем выполнения поиска ближайших соседей по ним. Это позволяет создавать такие функции, как поиск по похожести, рекомендации, семантический поиск и ранжирование релевантности на основе алгоритмов обработки естественного языка, а также поиск изображений, видео и звуков.\n\n## Что такое эмбеддинг?\n\nЭмбеддинг – это метод представления данных, таких как текст, изображения или звук, в виде векторов в высокоразмерном пространстве. Эти векторы создаются таким образом, чтобы расстояние между ними отражало сходство представляемых данных. В этом процессе обычно используются алгоритмы, такие как эмбеддинги слов (например, Word2Vec, BERT) для текста или нейронные сети для изображений. Высокая размерность векторного пространства с множеством компонентов на вектор позволяет представлять сложные и тонкие взаимоотношения между элементами. Их сходство оценивается по расстоянию между этими векторами, часто измеряемым методами, такими как евклидово расстояние или косинусное сходство.\n\nManticore Search обеспечивает поиск по векторам k-ближайших соседей (KNN) с использованием библиотеки HNSW. Эта функциональность является частью [Manticore Columnar Library](https://github.com/manticoresoftware/columnar).\n\n\n\n### Настройка таблицы для KNN поиска\n\nДля выполнения KNN поиска сначала необходимо настроить таблицу. Векторные данные с плавающей точкой и KNN поиск поддерживаются только в таблицах реального времени (не в обычных таблицах). В таблице должен быть хотя бы один атрибут типа [float_vector](../Creating_a_table/Data_types.md#Float-vector), который служит вектором данных. Необходимо указать следующие свойства:\n\n* `knn_type`: обязательный параметр; в настоящее время поддерживается только `hnsw`.\n\n* `knn_dims`: обязательный параметр, указывающий размерность индексируемых векторов.\n\n* `hnsw_similarity`: обязательный параметр, определяющий функцию расстояния, используемую индексом HNSW. Допустимые значения:\n\n - `L2` - квадрат евклидова расстояния\n\n - `IP` - внутреннее произведение\n\n - `COSINE` - косинусное сходство\n\n \n\n **Примечание:** При использовании `COSINE` сходства векторы автоматически нормализуются при вставке. Это означает, что хранимые значения векторов могут отличаться от исходных, так как они преобразуются в единичные векторы (векторы с математической длиной/модулем 1.0) для эффективного вычисления косинусного сходства. Такая нормализация сохраняет направление вектора при стандартизации его длины.\n\n* `hnsw_m`: необязательный параметр, определяющий максимальное количество исходящих связей в графе. По умолчанию 16.\n\n* `hnsw_ef_construction`: необязательный параметр, определяющий компромисс между временем построения и точностью.\n\n\n\n##### SQL\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n##### Режим Plain (с использованием конфигурационного файла):\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\n### Вставка векторных данных\n\n#### Автоматические эмбеддинги (рекомендуется)\n\nСамый простой способ работать с векторными данными – использовать **автоматические эмбеддинги**. С этой функцией вы создаёте таблицу с параметрами `MODEL_NAME` и `FROM`, а затем просто вставляете текстовые данные – Manticore автоматически генерирует эмбеддинги для вас.\n\n##### Создание таблицы с автоматическими эмбеддингами\n\nПри создании таблицы для автоматических эмбеддингов указывайте:\n\n- `MODEL_NAME`: модель эмбеддинга для использования\n\n- `FROM`: поля, используемые для генерации эмбеддинга (пустое значение означает все текстовые/строковые поля)\n\n**Поддерживаемые модели эмбеддингов:**\n\n- **Sentence Transformers**: Любая [подходящая модель BERT на Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — API-ключ не нужен. Manticore загружает модель при создании таблицы.\n\n- **OpenAI**: Модели эмбеддингов OpenAI, например `openai/text-embedding-ada-002` - требует параметр `API_KEY=''`\n\n- **Voyage**: Модели эмбеддингов Voyage AI - требует параметр `API_KEY=''`\n\n- **Jina**: Модели эмбеддингов Jina AI - требует параметр `API_KEY=''`\n\nПодробнее о настройке атрибута `float_vector` можно узнать [здесь](../Creating_a_table/Data_types.md#Float-vector).\n\n\n\n##### SQL:\n\n\n\nИспользование sentence-transformers (API ключ не требуется)\n\nCODE_BLOCK_5\n\nИспользование OpenAI (требуется параметр API_KEY)\n\nCODE_BLOCK_6\n\nИспользование всех текстовых полей для эмбеддингов (FROM пустой)\n\nCODE_BLOCK_7\n\n\n\n##### JSON:\n\n\n\nИспользование sentence-transformers (API ключ не требуется)\n\nCODE_BLOCK_8\n\nИспользование OpenAI (требуется параметр API_KEY)\n\nCODE_BLOCK_9\n\nИспользование всех текстовых полей для эмбеддингов (FROM пустой)\n\nCODE_BLOCK_10\n\n\n\n##### Вставка данных с автоматическими эмбеддингами\n\n\n\nПри использовании автоматических эмбеддингов **не указывайте векторное поле** в инструкции INSERT. Эмбеддинги генерируются автоматически из текстовых полей, указанных в параметре `FROM`.\n\n\n\n##### SQL:\n\n\n\nВставьте только текстовые данные – эмбеддинги генерируются автоматически\n\nCODE_BLOCK_11\n\nВставка нескольких полей – оба используются для эмбеддинга если FROM='title,description' \n\nCODE_BLOCK_12\n\nВставка пустого вектора (документ исключён из векторного поиска)\n\nCODE_BLOCK_13\n\n\n\n##### JSON:\n\n\n\nВставьте только текстовые данные – эмбеддинги генерируются автоматически\n\nCODE_BLOCK_14\n\nВставка нескольких полей – оба используются для эмбеддинга если FROM='title,description' \n\nCODE_BLOCK_15\n\nВставка пустого вектора (документ исключён из векторного поиска)\n\nCODE_BLOCK_16\n\n\n\n##### Поиск с использованием автоматических эмбеддингов\n\n\n\nПоиск работает так же – предоставьте текст запроса, и Manticore сгенерирует эмбеддинги и найдёт похожие документы:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\n##### JSON:\n\n\n\nИспользование текстового запроса с автоэмбеддингами\n\nCODE_BLOCK_19\n\nИспользование запроса вектора напрямую\n\nCODE_BLOCK_20\n\n\n\nCODE_BLOCK_21" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Multi-queries.md.json b/.translation-cache/Searching/Multi-queries.md.json index 128a7f46fc..7a16f515a1 100644 --- a/.translation-cache/Searching/Multi-queries.md.json +++ b/.translation-cache/Searching/Multi-queries.md.json @@ -6,5 +6,13 @@ "russian": "# Мультизапросы\n\nМультизапросы, или пакеты запросов, позволяют отправлять несколько поисковых запросов в Manticore в одном сетевом запросе.\n\n👍 Почему стоит использовать мультизапросы?\n\nОсновная причина — производительность. Отправляя запросы в Manticore пакетами, а не по одному, вы экономите время за счёт уменьшения количества сетевых обращений. Кроме того, отправка запросов пакетами позволяет Manticore выполнять определённые внутренние оптимизации. Если оптимизации пакета применить нельзя, запросы будут обработаны по отдельности.\n\n⛔ Когда не стоит использовать мультизапросы?\n\nМультизапросы требуют, чтобы все поисковые запросы в пакете были независимы, что бывает не всегда. Иногда запрос B зависит от результатов запроса A, то есть запрос B можно сформировать только после выполнения запроса A. Например, вы можете захотеть показать результаты из вторичного индекса только если в основной таблице не было найдено результатов, или указать смещение во втором наборе результатов на основе количества совпадений в первом наборе. В таких случаях нужно использовать отдельные запросы (или отдельные пакеты).\n\n\n\nВы можете выполнять несколько поисковых запросов в SQL, разделяя их точкой с запятой. Когда Manticore получает такой запрос от клиента, применяются все оптимизации между запросами.\n\nМультизапросы не поддерживают запросы с `FACET`. Количество мультизапросов в одном пакете не должно превышать [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\n## Оптимизации мультизапросов\n\nСуществует две основные оптимизации, о которых стоит знать: оптимизация общих запросов и оптимизация общих поддеревьев.\n\n**Оптимизация общих запросов** означает, что `searchd` определит все запросы в пакете, которые отличаются только настройками сортировки и группировки, и *выполнит поиск только один раз*. Например, если пакет состоит из 3 запросов, все они по запросу \"ipod nano\", но первый запрос запрашивает топ-10 результатов, отсортированных по цене, второй группирует по ID поставщика и запрашивает топ-5 поставщиков, отсортированных по рейтингу, а третий запрашивает максимальную цену, полнотекстовый поиск по \"ipod nano\" будет выполнен только один раз, а его результаты будут использованы для построения трёх разных наборов результатов.\n\n[Фасетный поиск](../Searching/Faceted_search.md) — особенно важный случай, который выигрывает от этой оптимизации. Действительно, фасетный поиск можно реализовать, выполняя несколько запросов: один для получения самих результатов поиска и несколько других с тем же полнотекстовым запросом, но с разными настройками группировки, чтобы получить все необходимые группы результатов (топ-3 авторов, топ-5 поставщиков и т.д.). Пока полнотекстовый запрос и настройки фильтрации остаются одинаковыми, сработает оптимизация общих запросов, значительно улучшая производительность.\n\n**Оптимизация общих поддеревьев** ещё интереснее. Она позволяет `searchd` использовать сходства между пакетными полнотекстовыми запросами. Он выявляет общие части полнотекстовых запросов (поддеревья) во всех запросах и кэширует их между запросами. Например, рассмотрим следующий пакет запросов:\n\nCODE_BLOCK_1\n\nЕсть общая двухсловная часть `donald trump`, которую можно вычислить один раз, затем закэшировать и использовать во всех запросах. Именно это и делает оптимизация общих поддеревьев. Размер кэша на запрос строго контролируется директивами [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) и [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) (чтобы кэширование *всех* шестнадцати миллиардов документов, соответствующих \"i am\", не исчерпало оперативную память и не убило сервер).\n\n\n\nКак узнать, были ли запросы в пакете действительно оптимизированы? Если да, в соответствующем логе запросов появится поле \"multiplier\", указывающее, сколько запросов было обработано вместе:\n\nОбратите внимание на поле \"x3\". Это означает, что запрос был оптимизирован и обработан в под-пакете из 3 запросов.\n\n\n\n##### log:\n\n\n\nCODE_BLOCK_2\n\n\n\n\n\nДля сравнения, вот как выглядел бы обычный лог, если бы запросы не были объединены в пакет:\n\n\n\n##### log:\n\n\n\nCODE_BLOCK_3\n\n\n\nОбратите внимание, что время на запрос в случае мультизапроса улучшилось в 1.5–2.3 раза, в зависимости от конкретного режима сортировки.\n\n" }, "is_code_or_comment": false + }, + "1ea8b682d0ff6acce6687ddcd2a52c433129548e49438d149743ac45f8075ea3": { + "original": "# Multi-queries\n\nMulti-queries, or query batches, allow you to send multiple search queries to Manticore in a single network request.\n\n👍 Why use multi-queries?\n\nThe primary reason is performance. By sending requests to Manticore in a batch instead of one by one, you save time by reducing network round-trips. Additionally, sending queries in a batch allows Manticore to perform certain internal optimizations. If no batch optimizations can be applied, queries will be processed individually.\n\n⛔ When not to use multi-queries?\n\nMulti-queries require all search queries in a batch to be independent, which isn't always the case. Sometimes query B depends on query A's results, meaning query B can only be set up after executing query A. For example, you might want to display results from a secondary index only if no results were found in the primary table, or you may want to specify an offset into the 2nd result set based on the number of matches in the 1st result set. In these cases, you'll need to use separate queries (or separate batches).\n\n\n\nYou can run multiple search queries with SQL by separating them with a semicolon. When Manticore receives a query formatted like this from a client, all inter-statement optimizations will be applied.\n\nMulti-queries don't support queries with `FACET`. The number of multi-queries in one batch shouldn't exceed [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_1\n\n\n\n## Multi-queries optimizations\n\nThere are two major optimizations to be aware of: common query optimization and common subtree optimization.\n\n**Common query optimization** means that `searchd` will identify all those queries in a batch where only the sorting and group-by settings differ, and *only perform searching once*. For example, if a batch consists of 3 queries, all of them are for \"ipod nano\", but the 1st query requests the top-10 results sorted by price, the 2nd query groups by vendor ID and requests the top-5 vendors sorted by rating, and the 3rd query requests the max price, full-text search for \"ipod nano\" will only be performed once, and its results will be reused to build 3 different result sets.\n\n[Faceted search](../Searching/Faceted_search.md) is a particularly important case that benefits from this optimization. Indeed, faceted searching can be implemented by running several queries, one to retrieve search results themselves, and a few others with the same full-text query but different group-by settings to retrieve all the required groups of results (top-3 authors, top-5 vendors, etc). As long as the full-text query and filtering settings stay the same, common query optimization will trigger, and greatly improve performance.\n\n**Common subtree optimization** is even more interesting. It allows `searchd` to exploit similarities between batched full-text queries. It identifies common full-text query parts (subtrees) in all queries and caches them between queries. For example, consider the following query batch:\n\nCODE_BLOCK_2\n\nThere's a common two-word part `donald trump` that can be computed only once, then cached and shared across the queries. And common subtree optimization does just that. Per-query cache size is strictly controlled by [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) and [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) directives (so that caching *all* sixteen gazillions of documents that match \"i am\" does not exhaust the RAM and instantly kill your server).\n\n\n\nHow can you tell if the queries in the batch were actually optimized? If they were, the respective query log will have a \"multiplier\" field that specifies how many queries were processed together:\n\nNote the \"x3\" field. It means that this query was optimized and processed in a sub-batch of 3 queries.\n\n\n\n##### log:\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nFor reference, this is how the regular log would look like if the queries were not batched:\n\n\n\n##### log:\n\n\n\nCODE_BLOCK_4\n\n\n\nNotice how the per-query time in the multi-query case improved by a factor of 1.5x to 2.3x, depending on the specific sorting mode.\n\n", + "translations": { + "chinese": "# 多查询\n\n多查询，或称查询批处理，允许您在一次网络请求中向 Manticore 发送多个搜索查询。\n\n👍 为什么使用多查询？\n\n主要原因是性能。通过批量发送请求给 Manticore，而不是一条条发送，您可以通过减少网络往返时间来节省时间。此外，批量发送查询还允许 Manticore 执行某些内部优化。如果无法应用批处理优化，查询将被单独处理。\n\n⛔ 什么时候不使用多查询？\n\n多查询要求批处理中所有搜索查询相互独立，但情况并非总是如此。有时查询 B 依赖于查询 A 的结果，也就是说查询 B 只能在执行查询 A 后才能设置。例如，您可能想在主表中没有找到结果时，显示来自辅助索引的结果，或者您可能想基于第一个结果集中的匹配数，指定第二个结果集的偏移量。在这些情况下，您需要使用单独的查询（或单独的批处理）。\n\n\n\n您可以通过用分号分隔多个搜索查询来使用 SQL 运行多查询。当 Manticore 从客户端接收到这样格式的查询时，所有语句间的优化都将被应用。\n\n多查询不支持带 `FACET` 的查询。单个批处理中的多查询数量不应超过 [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries)。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_1\n\n\n\n## 多查询优化\n\n主要有两种需要注意的优化：公共查询优化和公共子树优化。\n\n**公共查询优化** 意味着 `searchd` 会识别批处理中所有仅排序和分组设置不同的查询，并*只执行一次搜索*。例如，如果批处理中有 3 个查询，它们都是针对 \"ipod nano\" 的，但第一个查询请求按价格排序的前 10 条结果，第二个查询按供应商 ID 分组并请求按评分排序的前 5 个供应商，第三个查询请求最大价格，则全文搜索 \"ipod nano\" 只会执行一次，其结果将被重用以构建这 3 个不同的结果集。\n\n[分面搜索](../Searching/Faceted_search.md) 是特别受益于此优化的一个重要案例。事实上，分面搜索可以通过运行多个查询来实现，一个查询检索搜索结果本身，几个其他查询使用相同的全文查询但不同的分组设置，以检索所有所需的结果组（前 3 名作者，前 5 名供应商等）。只要全文查询和过滤设置保持相同，公共查询优化便会被触发，大幅提升性能。\n\n**公共子树优化** 则更加有趣。它允许 `searchd` 利用批量全文查询之间的相似性。它识别所有查询中的公共全文查询部分（子树），并在查询间缓存它们。例如，考虑以下查询批处理：\n\nCODE_BLOCK_2\n\n这里存在一个共同的两词部分 `donald trump`，只需计算一次，然后缓存并在查询间共享。公共子树优化就是这样工作的。每个查询的缓存大小由 [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) 和 [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) 指令严格控制（以防缓存 *所有* 匹配 “i am” 的十六亿兆文档耗尽内存并立即使服务器崩溃）。\n\n\n\n怎么判断批处理中的查询是否确实被优化了？如果是，相关查询日志将包含一个 \"multiplier\" 字段，指定一起处理了多少个查询：\n\n注意 \"x3\" 字段。这意味着此查询被优化，并在一个包含 3 个查询的子批处理中处理。\n\n\n\n##### 日志:\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\n作为参考，如果查询未批处理，常规日志将如下所示：\n\n\n\n##### 日志:\n\n\n\nCODE_BLOCK_4\n\n\n\n注意多查询情况下每个查询的时间提升了 1.5 到 2.3 倍，具体取决于排序模式。\n\n", + "russian": "# Мультизапросы\n\nМультизапросы, или пакетные запросы, позволяют отправлять несколько поисковых запросов в Manticore одним сетевым запросом.\n\n👍 Зачем использовать мультизапросы?\n\nОсновная причина — производительность. Отправляя запросы в Manticore пакетом, а не по одному, вы экономите время за счет уменьшения количества сетевых кругов. Кроме того, отправка запросов пакетно позволяет Manticore выполнять определённые внутренние оптимизации. Если оптимизации пакета применить нельзя, запросы будут обработаны по отдельности.\n\n⛔ Когда не стоит использовать мультизапросы?\n\nДля мультизапросов все поисковые запросы в пакете должны быть независимы, что бывает не всегда. Иногда запрос B зависит от результатов запроса A, то есть запрос B может быть сформирован только после выполнения запроса A. Например, вы можете хотеть отобразить результаты из вторичного индекса только если в основной таблице не было найдено результатов, или указать смещение во втором наборе результатов на основе количества совпадений в первом наборе данных. В таких случаях потребуется использовать отдельные запросы (или отдельные пакеты).\n\n\n\nВы можете выполнить несколько поисковых запросов с помощью SQL, разделяя их точкой с запятой. Когда Manticore получает такой запрос от клиента, применяются все межинструкционные оптимизации.\n\nМультизапросы не поддерживают запросы с `FACET`. Число мультизапросов в одном пакете не должно превышать значение [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries).\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_0\n\n\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_1\n\n\n\n## Оптимизации мультизапросов\n\nСуществуют две основные оптимизации, о которых стоит знать: оптимизация общих запросов и оптимизация общих поддеревьев.\n\n**Оптимизация общих запросов** означает, что `searchd` выявит в пакете все запросы, отличающиеся только настройками сортировки и группировки, и *выполнит поиск только один раз*. Например, если пакет состоит из 3 запросов, все они по запросу «ipod nano», но 1-й запрос выводит топ-10 результатов, отсортированных по цене, 2-й запрет группирует по ID поставщика и выводит топ-5 поставщиков, отсортированных по рейтингу, а 3-й запрос запрашивает максимальную цену, поиск по полнотекстовому запросу «ipod nano» будет выполнен один раз, а результаты переиспользованы для формирования трёх разных наборов данных.\n\n[Фасетный поиск](../Searching/Faceted_search.md) — это особенно важный сценарий, для которого выгодна такая оптимизация. В самом деле, фасетный поиск реализуется запуском нескольких запросов — один для собственно поисковой выдачи, а несколько других с тем же полнотекстовым запросом, но разными настройками группировки для получения всех необходимых групп результатов (топ-3 авторов, топ-5 поставщиков и т.д.). Пока полнотекстовый запрос и настройки фильтрации остаются одинаковыми, оптимизация общих запросов сработает и значительно улучшит производительность.\n\n**Оптимизация общих поддеревьев** ещё интереснее. Она позволяет `searchd` использовать сходства между пакетными полнотекстовыми запросами. Она выявляет общие части полнотекстовых запросов (поддеревья) во всех запросах и кэширует их для повторного использования. Например, рассмотрим следующий пакет запросов:\n\nCODE_BLOCK_2\n\nВ нём есть общая двухсловная часть `donald trump`, вычисляющаяся один раз, а затем кэшируемая и используемая всеми запросами. Именно это и делает оптимизация общих поддеревьев. Размер кэша на запрос строго контролируется директивами [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) и [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) (чтобы кэширование *всех* шестнадцати миллионных документов, соответствующих \"i am\", не исчерпывало оперативную память и не приводило к краху сервера).\n\n\n\nКак понять, что запросы в пакете действительно были оптимизированы? Если да, в журнале запросов появится поле \"multiplier\", указывающее, сколько запросов обработано вместе:\n\nОбратите внимание на поле \"x3\". Оно означает, что этот запрос был оптимизирован и обработан в подпакете из 3 запросов.\n\n\n\n##### журнал:\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nДля сравнения, вот как выглядел бы обычный журнал, если бы запросы не были пакетными:\n\n\n\n##### журнал:\n\n\n\nCODE_BLOCK_4\n\n\n\nОбратите внимание, что время обработки на запрос в случае мультизапроса улучшилось в 1.5-2.3 раза, в зависимости от конкретного режима сортировки.\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Options.md.json b/.translation-cache/Searching/Options.md.json index e21338db6c..e9aecd6513 100644 --- a/.translation-cache/Searching/Options.md.json +++ b/.translation-cache/Searching/Options.md.json @@ -22,5 +22,13 @@ "russian": "# Параметры поиска\n\nSQL [SELECT](../Searching/Full_text_matching/Basic_usage.md#SQL) оператор и HTTP [/search](../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON) эндпоинт поддерживают ряд опций, которые можно использовать для тонкой настройки поведения поиска.\n\n## OPTION\n\n### Общий синтаксис\n\n\n\n**SQL**:\n\nCODE_BLOCK_0\n\n**HTTP**:\n\nCODE_BLOCK_1\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nПоддерживаемые опции:\n\n### accurate_aggregation\n\nЦелое число. Включает или отключает гарантированную точность агрегатов при выполнении запросов groupby в нескольких потоках. По умолчанию 0.\n\nПри выполнении запроса groupby он может выполняться параллельно на простой таблице с несколькими псевдо-шардами (если включен `pseudo_sharding`). Аналогичный подход работает с RT таблицами. Каждый шард/чанк выполняет запрос, но количество групп ограничено `max_matches`. Если наборы результатов из разных шардов/чанков содержат разные группы, подсчёты групп и агрегаты могут быть неточными. Обратите внимание, что Manticore пытается увеличить `max_matches` до [`max_matches_increase_threshold`](../Searching/Options.md#max_matches_increase_threshold) на основе количества уникальных значений атрибута groupby (получаемых из вторичных индексов). Если это удаётся, потери точности не будет.\n\nОднако, если количество уникальных значений атрибута groupby велико, дальнейшее увеличение `max_matches` может быть не лучшей стратегией, так как это может привести к снижению производительности и увеличению использования памяти. Установка `accurate_aggregation` в 1 заставляет groupby-запросы выполняться в одном потоке, что решает проблему точности. Обратите внимание, что выполнение в одном потоке принудительно только тогда, когда `max_matches` нельзя установить достаточно высоким; в противном случае запросы с `accurate_aggregation=1` всё равно будут выполняться в нескольких потоках.\n\nВ целом, установка `accurate_aggregation` в 1 обеспечивает точность подсчёта групп и агрегатов в RT таблицах и простых таблицах с `pseudo_sharding=1`. Недостаток в том, что запросы будут выполняться медленнее, так как будут вынуждены работать в одном потоке.\n\nОднако, если у нас есть RT таблица и простая таблица с одинаковыми данными, и мы выполняем запрос с `accurate_aggregation=1`, мы всё равно можем получить разные результаты. Это происходит потому, что демон может выбрать разные настройки `max_matches` для RT и простой таблицы из-за настройки [`max_matches_increase_threshold`](../Searching/Options.md#max_matches_increase_threshold).\n\n### agent_query_timeout\n\nЦелое число. Максимальное время в миллисекундах ожидания завершения удалённых запросов, см. [этот раздел](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent_query_timeout).\n\n### boolean_simplify\n\n`0` или `1` (по умолчанию `1`). `boolean_simplify=1` включает [упрощение запроса](../Searching/Full_text_matching/Boolean_optimization.md) для ускорения его выполнения.\n\nЭту опцию также можно установить глобально в [конфигурации searchd](../Server_settings/Searchd.md#boolean_simplify), чтобы изменить поведение по умолчанию для всех запросов. Опция на уровне запроса переопределит глобальную настройку.\n\n### comment\n\nСтрока, пользовательский комментарий, который копируется в файл журнала запросов.\n\n### cutoff\n\nЦелое число. Указывает максимальное количество обрабатываемых совпадений. Если не задано, Manticore автоматически выберет подходящее значение.\n\n\n\n* `N = 0`: Отключает ограничение на количество совпадений.\n\n* `N > 0`: Инструктирует Manticore прекратить обработку результатов, как только будет найдено `N` совпадающих документов.\n\n* Не задано: Manticore самостоятельно определяет порог.\n\nКогда Manticore не может определить точное количество совпадающих документов, поле `total_relation` в [метаинформации](../Node_info_and_management/SHOW_META.md#SHOW-META) запроса покажет `gte`, что означает **Больше или равно**. Это указывает, что фактическое количество совпадений как минимум равно указанному `total_found` (в SQL) или `hits.total` (в JSON). Когда количество точное, `total_relation` будет показывать `eq`.\n\nПримечание: использование `cutoff` в агрегатных запросах не рекомендуется, так как это может привести к неточным или неполным результатам.\n\n\n\nИспользование `cutoff` в агрегатных запросах может привести к неправильным или вводящим в заблуждение результатам, как показано в следующем примере:\n\nCODE_BLOCK_6\n\nСравните с тем же запросом без `cutoff`:\n\nCODE_BLOCK_7\n\n\n\n### distinct_precision_threshold\n\nЦелое число. По умолчанию `3500`. Эта опция задаёт порог, ниже которого подсчёты, возвращаемые `count distinct`, гарантированно точны в пределах простой таблицы.\n\nДопустимые значения варьируются от `500` до `15500`. Значения вне этого диапазона будут ограничены.\n\nЕсли эта опция установлена в 0, включается алгоритм, обеспечивающий точные подсчёты. Этот алгоритм собирает пары `{group, value}`, сортирует их и периодически устраняет дубликаты. Результат — точные подсчёты в пределах простой таблицы. Однако этот подход не подходит для наборов данных с высокой кардинальностью из-за высокого потребления памяти и медленного выполнения запросов.\n\nЕсли `distinct_precision_threshold` установлен в значение больше 0, Manticore использует другой алгоритм. Он загружает подсчёты в хеш-таблицу и возвращает размер таблицы. Если хеш-таблица становится слишком большой, её содержимое переносится в структуру данных `HyperLogLog`. В этот момент подсчёты становятся приближенными, так как HyperLogLog — вероятностный алгоритм. Этот подход поддерживает фиксированное максимальное использование памяти на группу, но с компромиссом в точности подсчётов.\n\nТочность `HyperLogLog` и порог для перехода от хеш-таблицы к HyperLogLog выводятся из настройки `distinct_precision_threshold`. Важно использовать эту опцию с осторожностью, так как удвоение её значения также удвоит максимальное количество памяти, необходимое для подсчётов. Максимальное использование памяти можно примерно оценить по формуле: `64 * max_matches * distinct_precision_threshold`, хотя на практике подсчёты часто используют меньше памяти, чем в худшем случае.\n\n### expand_keywords" }, "is_code_or_comment": false + }, + "8889bb70716f5ce1141ad913fbd9c9d4ae5cb8f1a8294eededc286157f820f29": { + "original": "You can also enforce a guaranteed groupby/aggregate accuracy mode using the [accurate_aggregation](../Searching/Options.md#accurate_aggregation) option.\n\n### max_query_time\n\nSets the maximum search query time in milliseconds. Must be a non-negative integer. The default value is 0, which means \"do not limit.\" Local search queries will be stopped once the specified time has elapsed. Note that if you're performing a search that queries multiple local tables, this limit applies to each table separately. Be aware that this may slightly increase the query's response time due to the overhead caused by constantly tracking whether it's time to stop the query.\n\n### max_predicted_time\n\nInteger. Maximum predicted search time; see [predicted_time_costs](../Server_settings/Searchd.md#predicted_time_costs).\n\n### morphology\n\n`none` allows replacing all query terms with their exact forms if the table was built with [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words) enabled. This is useful for preventing stemming or lemmatizing query terms.\n\n### not_terms_only_allowed\n\n\n\n`0` or `1` allows standalone [negation](../Searching/Full_text_matching/Operators.md#Negation-operator) for the query. The default is 0. See also the corresponding [global setting](../Server_settings/Searchd.md#not_terms_only_allowed).\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### ranker\n\nChoose from the following options:\n\n* `proximity_bm25`\n\n* `bm25`\n\n* `none`\n\n* `wordcount`\n\n* `proximity`\n\n* `matchany`\n\n* `fieldmask`\n\n* `sph04`\n\n* `expr`\n\n* `export`\n\nFor more details on each ranker, refer to [Search results ranking](../Searching/Sorting_and_ranking.md#Available-built-in-rankers).\n\n### rand_seed\n\nAllows you to specify a specific integer seed value for an `ORDER BY RAND()` query, for example: `... OPTION rand_seed=1234`. By default, a new and different seed value is autogenerated for every query.\n\n### retry_count\n\nInteger. Distributed retries count.\n\n### retry_delay\n\nInteger. Distributed retry delay, in milliseconds.\n\n### scroll\n\nString. A scroll token for paginating results using the [Scroll pagination approach](../Searching/Pagination.md#Scroll-Search-Option).\n\n### sort_method\n\n* `pq` - priority queue, set by default\n\n* `kbuffer` - provides faster sorting for already pre-sorted data, e.g., table data sorted by id\n\nThe result set is the same in both cases; choosing one option or the other may simply improve (or worsen) performance.\n\n### threads\n\nLimits the max number of threads used for current query processing. Default - no limit (the query can occupy all [threads](../Server_settings/Searchd.md#threads) as defined globally).\n\nFor a batch of queries, the option must be attached to the very first query in the batch, and it is then applied when the working queue is created and is effective for the entire batch. This option has the same meaning as the option [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query), but is applied only to the current query or batch of queries.\n\n### token_filter\n\nQuoted, colon-separated string of `library name:plugin name:optional string of settings`. A query-time token filter is created for each search when full-text is invoked by every table involved, allowing you to implement a custom tokenizer that generates tokens according to custom rules.\n\nCODE_BLOCK_11\n\n### expansion_limit\n\nRestricts the maximum number of expanded keywords for a single wildcard, with a default value of 0 indicating no limit. For additional details, refer to [expansion_limit](../Server_settings/Searchd.md#expansion_limit).\n\n## Query optimizer hints\n\n\n\nIn rare cases, Manticore's built-in query analyzer may be incorrect in understanding a query and determining whether a docid index, secondary indexes, or columnar scan should be used. To override the query optimizer's decisions, you can use the following hints in your query:\n\n* `/*+ DocidIndex(id) */` to force the use of a docid index, `/*+ NO_DocidIndex(id) */` to tell the optimizer to ignore it\n\n* `/*+ SecondaryIndex([, ]) */` to force the use of a secondary index (if available), `/*+ NO_SecondaryIndex(id) */` to tell the optimizer to ignore it\n\n* `/*+ ColumnarScan([, ]) */` to force the use of a columnar scan (if the attribute is columnar), `/*+ NO_ColumnarScan(id) */` to tell the optimizer to ignore it\n\nNote that when executing a full-text query with filters, the query optimizer decides between intersecting the results of the full-text tree with the filter results or using a standard match-then-filter approach. Specifying *any* hint will force the daemon to use the code path that performs the intersection of the full-text tree results with the filter results.\n\nFor more information on how the query optimizer works, refer to the [Cost based optimizer](../Searching/Cost_based_optimizer.md) page.\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\nWhen using a MySQL/MariaDB client, make sure to include the `--comments` flag to enable the hints in your queries.\n\n\n\nCODE_BLOCK_14\n\n\n\n", + "translations": { + "chinese": "您还可以使用[accurate_aggregation](../Searching/Options.md#accurate_aggregation) 选项强制保证 groupby/聚合的准确模式。\n\n### max_query_time\n\n设置最大搜索查询时间，单位为毫秒。必须为非负整数。默认值为 0，表示“不限制”。本地搜索查询将在达到指定时间后停止。请注意，如果您执行的是查询多个本地表的搜索，此限制对每个表分别适用。请注意，由于需要不断跟踪是否到达停止查询时间，这可能会略微增加查询的响应时间。\n\n### max_predicted_time\n\n整数。最大预测搜索时间；参见[predicted_time_costs](../Server_settings/Searchd.md#predicted_time_costs)。\n\n### morphology\n\n`none` 允许在表使用了 [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words) 时，将所有查询词替换为其精确形式。这对于防止查询词的词干化或词形还原非常有用。\n\n### not_terms_only_allowed\n\n\n\n`0` 或 `1` 允许查询中独立的[否定](../Searching/Full_text_matching/Operators.md#Negation-operator)。默认值为0。另请参见对应的[全局设置](../Server_settings/Searchd.md#not_terms_only_allowed)。\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### ranker\n\n可选以下排名器：\n\n* `proximity_bm25`\n\n* `bm25`\n\n* `none`\n\n* `wordcount`\n\n* `proximity`\n\n* `matchany`\n\n* `fieldmask`\n\n* `sph04`\n\n* `expr`\n\n* `export`\n\n关于每个排名器的详细信息，请参考[搜索结果排名](../Searching/Sorting_and_ranking.md#Available-built-in-rankers)。\n\n### rand_seed\n\n允许您为 `ORDER BY RAND()` 查询指定特定的整数种子值，例如：`... OPTION rand_seed=1234`。默认情况下，每个查询都会自动生成一个新的不同的种子值。\n\n### retry_count\n\n整数。分布式重试次数。\n\n### retry_delay\n\n整数。分布式重试延迟，单位为毫秒。\n\n### scroll\n\n字符串。用于使用[滚动分页方法](../Searching/Pagination.md#Scroll-Search-Option)进行结果分页的滚动令牌。\n\n### sort_method\n\n* `pq` - 优先队列，默认设置\n\n* `kbuffer` - 为已经预排序的数据提供更快的排序，例如按 id 排序的表数据\n\n两种方式结果集相同；选择其中一个选项可能仅影响性能的提升或降低。\n\n### threads\n\n限制当前查询处理使用的最大线程数。默认不限制（查询可占用全局定义的所有[线程](../Server_settings/Searchd.md#threads)）。\n\n对于一批查询，该选项必须附加在批次中的第一个查询上，并在创建工作队列时生效，对整个批次有效。该选项与选项[max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query)含义相同，但仅应用于当前查询或查询批次。\n\n### token_filter\n\n引号包围的，并用冒号分隔的字符串格式为 `库名:插件名:可选的设置字符串`。查询时的令牌过滤器在每个涉及的表调用全文索引时创建，允许您实现根据自定义规则生成令牌的自定义分词器。\n\nCODE_BLOCK_11\n\n### expansion_limit\n\n限制单个通配符所展开的最大关键词数，默认值为0表示不限制。有关详细信息，请参阅[expansion_limit](../Server_settings/Searchd.md#expansion_limit)。\n\n## 查询优化器提示\n\n\n\n在极少数情况下，Manticore 内置的查询分析器可能无法正确理解查询，也可能无法正确决定应使用 docid 索引、二级索引还是列式扫描。要覆盖查询优化器的决定，可以在查询中使用以下提示：\n\n* `/*+ DocidIndex(id) */` 强制使用 docid 索引，`/*+ NO_DocidIndex(id) */` 告诉优化器忽略它\n\n* `/*+ SecondaryIndex([, ]) */` 强制使用二级索引（如果可用），`/*+ NO_SecondaryIndex(id) */` 告诉优化器忽略它\n\n* `/*+ ColumnarScan([, ]) */` 强制使用列式扫描（如果属性是列式的），`/*+ NO_ColumnarScan(id) */` 告诉优化器忽略它\n\n请注意，在执行带过滤器的全文查询时，查询优化器会决定是将全文树结果与过滤结果求交叉还是使用标准的匹配后过滤方法。指定*任何*提示都会强制守护进程使用执行全文树结果与过滤结果交集的代码路径。\n\n有关查询优化器工作原理的更多信息，请参阅[基于成本的优化器](../Searching/Cost_based_optimizer.md)页面。\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\n使用 MySQL/MariaDB 客户端时，确保包含 `--comments` 标志以启用查询中的提示。\n\n\n\nCODE_BLOCK_14\n\n\n\n", + "russian": "Вы также можете включить режим гарантированной точности groupby/aggregate с помощью опции [accurate_aggregation](../Searching/Options.md#accurate_aggregation).\n\n### max_query_time\n\nУстанавливает максимальное время выполнения поискового запроса в миллисекундах. Должно быть неотрицательным целым числом. Значение по умолчанию — 0, что означает «не ограничивать». Локальные поисковые запросы будут остановлены после истечения указанного времени. Обратите внимание, что если вы выполняете поиск, который опрашивает несколько локальных таблиц, это ограничение применяется к каждой таблице отдельно. Имейте в виду, что это может незначительно увеличить время ответа запроса из-за накладных расходов, связанных с постоянным отслеживанием времени остановки запроса.\n\n### max_predicted_time\n\nЦелое число. Максимальное предсказанное время поиска; см. [predicted_time_costs](../Server_settings/Searchd.md#predicted_time_costs).\n\n### morphology\n\n`none` позволяет заменять все термины запроса их точными формами, если таблица была создана с включённой опцией [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words). Это полезно для предотвращения стемминга или лемматизации терминов запроса.\n\n### not_terms_only_allowed\n\n\n\n`0` или `1` разрешает использование отдельного [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) в запросе. Значение по умолчанию – 0. Также смотрите соответствующую [глобальную настройку](../Server_settings/Searchd.md#not_terms_only_allowed).\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n### ranker\n\nВыберите из следующих вариантов:\n\n* `proximity_bm25`\n\n* `bm25`\n\n* `none`\n\n* `wordcount`\n\n* `proximity`\n\n* `matchany`\n\n* `fieldmask`\n\n* `sph04`\n\n* `expr`\n\n* `export`\n\nДля получения подробной информации о каждом ранжировщике смотрите раздел [Ранжирование результатов поиска](../Searching/Sorting_and_ranking.md#Available-built-in-rankers).\n\n### rand_seed\n\nПозволяет указать конкретное целочисленное значение начального зерна для запроса `ORDER BY RAND()`, например: `... OPTION rand_seed=1234`. По умолчанию для каждого запроса автоматически генерируется новое и отличное значение зерна.\n\n### retry_count\n\nЦелое число. Количество попыток повторного выполнения в распределённой системе.\n\n### retry_delay\n\nЦелое число. Задержка между повторными попытками в распределённой системе, в миллисекундах.\n\n### scroll\n\nСтрока. Токен прокрутки для постраничной навигации с использованием подхода [Scroll pagination](../Searching/Pagination.md#Scroll-Search-Option).\n\n### sort_method\n\n* `pq` — очередь с приоритетом, используется по умолчанию\n\n* `kbuffer` — обеспечивает более быструю сортировку для уже предварительно отсортированных данных, например, данных таблицы, отсортированных по id\n\nРезультат одинаков в обоих случаях; выбор одного из вариантов может только улучшить (или ухудшить) производительность.\n\n### threads\n\nОграничивает максимальное количество потоков, используемых для обработки текущего запроса. По умолчанию нет ограничений (запрос может занять все [потоки](../Server_settings/Searchd.md#threads), определённые глобально).\n\nДля пакета запросов опция должна быть прикреплена к первому запросу в пакете и применяется при создании рабочей очереди, действуя на весь пакет. Эта опция имеет то же значение, что и опция [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query), но применяется только к текущему запросу или пакету запросов.\n\n### token_filter\n\nЗаключённая в кавычки строка с разделением двоеточием в формате `название библиотеки:название плагина:необязательная строка с настройками`. Фильтр токенов во время запроса создаётся для каждого поиска при вызове полнотекстового поиска каждой задействованной таблицей, что позволяет реализовать собственный токенизатор, генерирующий токены по индивидуальным правилам.\n\nCODE_BLOCK_11\n\n### expansion_limit\n\nОграничивает максимальное количество расширенных ключевых слов для одного подстановочного знака, значение по умолчанию — 0, что означает отсутствие ограничения. Дополнительные сведения см. в разделе [expansion_limit](../Server_settings/Searchd.md#expansion_limit).\n\n## Подсказки оптимизатора запросов\n\n\n\nВ редких случаях встроенный анализатор запросов Manticore может некорректно понять запрос и определить, следует ли использовать индекс docid, вторичные индексы или колонночное сканирование. Чтобы переопределить решения оптимизатора запросов, вы можете использовать следующие подсказки в вашем запросе:\n\n* `/*+ DocidIndex(id) */` чтобы принудительно использовать индекс docid, `/*+ NO_DocidIndex(id) */` чтобы сообщить оптимизатору игнорировать его\n\n* `/*+ SecondaryIndex([, ]) */` чтобы принудительно использовать вторичный индекс (если доступен), `/*+ NO_SecondaryIndex(id) */` чтобы сообщить оптимизатору игнорировать его\n\n* `/*+ ColumnarScan([, ]) */` чтобы принудительно использовать колонночное сканирование (если атрибут колонночный), `/*+ NO_ColumnarScan(id) */` чтобы сообщить оптимизатору игнорировать его\n\nОбратите внимание, что при выполнении полнотекстового запроса с фильтрами оптимизатор запроса выбирает между пересечением результатов полнотекстового дерева с результатами фильтра или использованием стандартного подхода match-then-filter. Указание *любой* подсказки заставит демон использовать кодовый путь, который выполняет пересечение результатов полнотекстового дерева с результатами фильтра.\n\nДля получения дополнительной информации о работе оптимизатора запросов обратитесь к странице [Оптимизатор на основе затрат](../Searching/Cost_based_optimizer.md).\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\n\n\nПри использовании клиента MySQL/MariaDB убедитесь, что включили флаг `--comments` для активации подсказок в ваших запросах.\n\n\n\nCODE_BLOCK_14\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Percolate_query.md.json b/.translation-cache/Searching/Percolate_query.md.json index 7590fb3b3c..cf79cdfe55 100644 --- a/.translation-cache/Searching/Percolate_query.md.json +++ b/.translation-cache/Searching/Percolate_query.md.json @@ -30,5 +30,29 @@ "russian": "SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nPython\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\njavascript\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\njava\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nC#\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nRust\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nGo\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### Я хочу узнать полные правила PQ, соответствующие моему документу\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nPython\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\njavascript\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\njava\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nC#\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nRust\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nGo\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n##### Как насчёт нескольких документов?\n\nОбратите внимание, что с помощью `CALL PQ` вы можете предоставить несколько документов разными способами:\n\n* как массив простых документов в круглых скобках `('doc1', 'doc2')`. Для этого требуется `0 as docs_json`\n\n* как массив JSON в круглых скобках `('{doc1}', '{doc2}')`\n\n* или как стандартный JSON-массив `'[{doc1}, {doc2}]'`\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nPython\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\njavascript\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\njava\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nC#\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nRust\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nGo\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n\n\n##### Я хочу узнать, какие документы соответствуют каким правилам\n\nИспользование опции `1 as docs` позволяет увидеть, какие из предоставленных документов соответствуют каким правилам.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nPython\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\njavascript\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\njava\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nC#\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nRust\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nGo\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n\n\n#### Статические идентификаторы\n\nПо умолчанию идентификаторы совпадающих документов соответствуют их относительным номерам в списке, который вы предоставляете. Однако в некоторых случаях у каждого документа уже есть свой собственный идентификатор. Для этого случая существует опция `'id field name' as docs_id` для `CALL PQ`.\n\nОбратите внимание, что если идентификатор не может быть найден по указанному имени поля, правило PQ не будет отображено в результатах.\n\nЭта опция доступна только для `CALL PQ` через SQL.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n\n\n##### У меня могут быть некорректные JSON, пожалуйста, пропускайте их" }, "is_code_or_comment": false + }, + "38a71003cd1de6c4473f3b45f04778d948ed713bedacc3f217439778b0f85ff6": { + "original": "In some cases, you might want to get more details about the performance of a percolate query. For that purpose, there is the option `1 as verbose`, which is only available via SQL and allows you to save more performance metrics. You can see them using the `SHOW META` query, which you can run after `CALL PQ`. See [SHOW META](../Node_info_and_management/SHOW_META.md) for more info.\n\n\n\n1 as verbose:\n\n\n\nCODE_BLOCK_170\n\n\n\nCODE_BLOCK_171\n\n\n\n0 as verbose (default):\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\n", + "translations": { + "chinese": "在某些情况下，您可能想要获得有关穿透查询性能的更多详细信息。为此，有一个选项 `1 as verbose`，该选项仅通过 SQL 可用，允许您保存更多的性能指标。您可以使用 `SHOW META` 查询查看它们，该查询可以在 `CALL PQ` 之后运行。更多信息请参见 [SHOW META](../Node_info_and_management/SHOW_META.md)。\n\n\n\n1 as verbose：\n\n\n\nCODE_BLOCK_170\n\n\n\nCODE_BLOCK_171\n\n\n\n0 as verbose（默认）：\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\n", + "russian": "В некоторых случаях вы можете захотеть получить более подробную информацию о производительности перколяционного запроса. Для этой цели существует опция `1 as verbose`, которая доступна только через SQL и позволяет сохранить больше метрик производительности. Вы можете просмотреть их с помощью запроса `SHOW META`, который можно выполнить после `CALL PQ`. Подробнее смотрите в [SHOW META](../Node_info_and_management/SHOW_META.md).\n\n\n\n1 as verbose:\n\n\n\nCODE_BLOCK_170\n\n\n\nCODE_BLOCK_171\n\n\n\n0 as verbose (по умолчанию):\n\n\n\nCODE_BLOCK_172\n\n\n\nCODE_BLOCK_173\n\n\n\n" + }, + "is_code_or_comment": false + }, + "ae56d12d505a6a6c1a6e21766313db756a4473e341ef99c374d4de1a74ba6280": { + "original": "When using CALL PQ with separate JSONs, you can use the option 1 as skip_bad_json to skip any invalid JSONs in the input. In the example below, the 2nd query fails due to an invalid JSON, but the 3rd query avoids the error by using 1 as skip_bad_json. Keep in mind that this option is not available when sending JSON queries over HTTP, as the whole JSON query must be valid in that case.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\n##### I want higher performance of a percolate query\n\nPercolate queries are designed with high throughput and large data volumes in mind. To optimize performance for lower latency and higher throughput, consider the following.\n\nThere are two modes of distribution for a percolate table and how a percolate query can work against it:\n\n* **Sparse (default).** Ideal for: many documents, mirrored PQ tables. When your document set is large but the set of queries stored in the PQ table is small, the sparse mode is beneficial. In this mode, the batch of documents you pass will be divided among the number of agents, so each node processes only a portion of the documents from your request. Manticore splits your document set and distributes chunks among the mirrors. Once the agents have finished processing the queries, Manticore collects and merges the results, returning a final query set as if it came from a single table. Use [replication](../References.md#Replication) to assist the process.\n\n* **Sharded.** Ideal for: many PQ rules, rules split among PQ tables. In this mode, the entire document set is broadcast to all tables of the distributed PQ table without initially splitting the documents. This is beneficial when pushing a relatively small set of documents, but the number of stored queries is large. In this case, it's more appropriate to store only a portion of PQ rules on each node and then merge the results returned from the nodes that process the same set of documents against different sets of PQ rules. This mode must be explicitly set, as it implies an increase in network payload and expects tables with different PQs, which [replication](../References.md#Replication) cannot do out-of-the-box.\n\nAssume you have table `pq_d2` defined as:\n\nCODE_BLOCK_118\n\n\n\nEach of 'pq' and 'ptitle' contains:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nPython\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_127\n\n\n\nCODE_BLOCK_128\n\n\n\njavascript\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\njavascript\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\njava\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nC#\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\nRust\n\n\n\nCODE_BLOCK_137\n\n\n\nCODE_BLOCK_138\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nGo\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\n\n\nAnd you execute `CALL PQ` on the distributed table with a couple of documents.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_143\n\n\n\nCODE_BLOCK_144\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nPython\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_151\n\n\n\nCODE_BLOCK_152\n\n\n\njavascript\n\n\n\nCODE_BLOCK_153\n\n\n\nCODE_BLOCK_154\n\n\n\njava\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nC#\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nRust\n\n\n\nCODE_BLOCK_159\n\n\n\nCODE_BLOCK_160\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nGo\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nIn the previous example, we used the default **sparse** mode. To demonstrate the **sharded** mode, let's create a distributed PQ table consisting of 2 local PQ tables and add 2 documents to \"products1\" and 1 document to \"products2\":\n\nCODE_BLOCK_165\n\n\n\nNow, if you add `'sharded' as mode` to `CALL PQ`, it will send the documents to all the agent's tables (in this case, just local tables, but they can be remote to utilize external hardware). This mode is not available via the JSON interface.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_168\n\n\n\nCODE_BLOCK_169\n\n\n\nNote that the syntax of agent mirrors in the configuration (when several hosts are assigned to one `agent` line, separated with `|`) has nothing to do with the `CALL PQ` query mode. Each `agent` always represents **one** node, regardless of the number of HA mirrors specified for that agent.\n\n\n\n##### How can I learn more about performance?", + "translations": { + "chinese": "当使用带有独立 JSON 的 CALL PQ 时，您可以使用选项 1 作为 skip_bad_json 来跳过输入中的任何无效 JSON。下面的示例中，第 2 个查询由于无效的 JSON 而失败，但第 3 个查询通过使用 1 作为 skip_bad_json 避免了错误。请记住，当通过 HTTP 发送 JSON 查询时，此选项不可用，因为此时整个 JSON 查询必须有效。\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\n##### 我想获得更高性能的 percolate 查询\n\nPercolate 查询设计时考虑了高吞吐量和大数据量。为了优化性能，实现更低延迟和更高吞吐量，请考虑以下几点。\n\nPercolate 表有两种分布模式，以及 percolate 查询如何针对它们工作：\n\n* **稀疏（默认）。** 适用于：大量文档，镜像 PQ 表。当您的文档集很大但存储在 PQ 表中的查询集很小时，稀疏模式是有益的。在此模式中，您传递的文档批次将被分配到多个代理数量中，因此每个节点只处理请求中文档的一部分。Manticore 将您的文档集拆分并分发给镜像。一旦代理完成查询处理，Manticore 会收集并合并结果，返回一个就像来自单一表的最终查询集。使用[复制](../References.md#Replication)来辅助该过程。\n\n* **分片。** 适用于：大量 PQ 规则，规则分散在多个 PQ 表中。在此模式下，整个文档集会广播到分布式 PQ 表的所有表中，而不是最初拆分文档。当推送的文档集相对较小时，但存储的查询数量很大时，这种方式更合适。在这种情况下，更合适是在每个节点只存储部分 PQ 规则，然后合并从不同节点处理同一文档集但针对不同 PQ 规则集返回的结果。该模式必须明确设置，因为它意味着网络负载增加，并且期望表具有不同的 PQ，这超出了[复制](../References.md#Replication)的默认能力。\n\n假设您有定义为：\n\nCODE_BLOCK_118\n\n\n\n'pq' 和 'ptitle' 分别包含：\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nPython\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_127\n\n\n\nCODE_BLOCK_128\n\n\n\njavascript\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\njavascript\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\njava\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nC#\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\nRust\n\n\n\nCODE_BLOCK_137\n\n\n\nCODE_BLOCK_138\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nGo\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\n\n\n并且您用几个文档对分布式表执行 `CALL PQ`。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_143\n\n\n\nCODE_BLOCK_144\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nPython\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_151\n\n\n\nCODE_BLOCK_152\n\n\n\njavascript\n\n\n\nCODE_BLOCK_153\n\n\n\nCODE_BLOCK_154\n\n\n\njava\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nC#\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nRust\n\n\n\nCODE_BLOCK_159\n\n\n\nCODE_BLOCK_160\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nGo\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\n在上一个示例中，我们使用了默认的**稀疏**模式。为了演示**分片**模式，我们创建一个由两个本地 PQ 表组成的分布式 PQ 表，并向 \"products1\" 添加 2 个文档，向 \"products2\" 添加 1 个文档：\n\nCODE_BLOCK_165\n\n\n\n现在，如果您在 `CALL PQ` 中加入 `'sharded' as mode`，它将把文档发送到所有代理的表（在本例中仅本地表，但它们也可以是远程的，以利用外部硬件）。此模式在 JSON 接口中不可用。\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_168\n\n\n\nCODE_BLOCK_169\n\n\n\n请注意，配置中代理镜像的语法（当多个主机分配给一条 `agent` 线路且以 `|` 分隔时）与 `CALL PQ` 查询模式无关。每个 `agent` 始终代表**一个**节点，无论该代理指定了多少 HA 镜像。\n\n\n\n##### 我如何能了解更多关于性能的信息？", + "russian": "При использовании CALL PQ с отдельными JSON можно использовать опцию 1 в качестве skip_bad_json, чтобы пропускать любые некорректные JSON в вводе. В приведённом ниже примере второй запрос не выполняется из-за некорректного JSON, но третий запрос избегает ошибки, используя 1 в качестве skip_bad_json. Имейте в виду, что эта опция недоступна при отправке JSON-запросов через HTTP, так как в этом случае весь JSON-запрос должен быть корректным.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_114\n\n\n\nCODE_BLOCK_115\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_116\n\n\n\nCODE_BLOCK_117\n\n\n\n##### Я хочу повысить производительность перколяционного запроса\n\nПерколяционные запросы разработаны с учётом высокой пропускной способности и больших объёмов данных. Чтобы оптимизировать производительность для снижения задержек и увеличения пропускной способности, рассмотрите следующие варианты.\n\nСуществует два режима распределения для перколяционной таблицы и способа работы с ней перколяционного запроса:\n\n* **Разреженный (по умолчанию).** Идеально для: большого количества документов, зеркальных PQ таблиц. Когда набор ваших документов большой, но набор запросов, хранящихся в PQ таблице, мал, полезен разреженный режим. В этом режиме пакет документов, который вы передаёте, делится между агентами, так что каждый узел обрабатывает только часть документов из вашего запроса. Manticore разбивает ваш набор документов и распределяет части между зеркалами. После того, как агенты закончат обработку запросов, Manticore собирает и объединяет результаты, возвращая итоговый набор запросов, как если бы он исходил из одной таблицы. Используйте [репликацию](../References.md#Replication) для поддержки процесса.\n\n* **Шардированный.** Идеально для: большого количества правил PQ, разделённых между PQ таблицами. В этом режиме весь набор документов транслируется всем таблицам распределённой PQ таблицы без первоначального разделения документов. Это полезно при передаче относительно небольшого набора документов, но когда количество хранимых запросов велико. В этом случае правильнее хранить только часть правил PQ на каждом узле, а затем объединять результаты, возвращаемые узлами, которые обрабатывают одинаковый набор документов, но применяют разные наборы правил PQ. Этот режим должен быть установлен явно, так как он увеличивает сетевой трафик и предполагает таблицы с разными PQ, что [репликация](../References.md#Replication) не обеспечивает \"из коробки\".\n\nПредположим, у вас есть таблица `pq_d2`, определённая как:\n\nCODE_BLOCK_118\n\n\n\nКаждая из таблиц 'pq' и 'ptitle' содержит:\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_119\n\n\n\nCODE_BLOCK_120\n\n\n\nCODE_BLOCK_121\n\n\n\nCODE_BLOCK_122\n\n\n\nCODE_BLOCK_123\n\n\n\nCODE_BLOCK_124\n\n\n\nPython\n\n\n\nCODE_BLOCK_125\n\n\n\nCODE_BLOCK_126\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_127\n\n\n\nCODE_BLOCK_128\n\n\n\njavascript\n\n\n\nCODE_BLOCK_129\n\n\n\nCODE_BLOCK_130\n\n\n\njavascript\n\n\n\nCODE_BLOCK_131\n\n\n\nCODE_BLOCK_132\n\n\n\njava\n\n\n\nCODE_BLOCK_133\n\n\n\nCODE_BLOCK_134\n\n\n\nC#\n\n\n\nCODE_BLOCK_135\n\n\n\nCODE_BLOCK_136\n\n\n\nRust\n\n\n\nCODE_BLOCK_137\n\n\n\nCODE_BLOCK_138\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_139\n\n\n\nCODE_BLOCK_140\n\n\n\nGo\n\n\n\nCODE_BLOCK_141\n\n\n\nCODE_BLOCK_142\n\n\n\n\n\nИ вы выполняете `CALL PQ` на распределённой таблице с несколькими документами.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_143\n\n\n\nCODE_BLOCK_144\n\n\n\nCODE_BLOCK_145\n\n\n\nCODE_BLOCK_146\n\n\n\nCODE_BLOCK_147\n\n\n\nCODE_BLOCK_148\n\n\n\nPython\n\n\n\nCODE_BLOCK_149\n\n\n\nCODE_BLOCK_150\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_151\n\n\n\nCODE_BLOCK_152\n\n\n\njavascript\n\n\n\nCODE_BLOCK_153\n\n\n\nCODE_BLOCK_154\n\n\n\njava\n\n\n\nCODE_BLOCK_155\n\n\n\nCODE_BLOCK_156\n\n\n\nC#\n\n\n\nCODE_BLOCK_157\n\n\n\nCODE_BLOCK_158\n\n\n\nRust\n\n\n\nCODE_BLOCK_159\n\n\n\nCODE_BLOCK_160\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_161\n\n\n\nCODE_BLOCK_162\n\n\n\nGo\n\n\n\nCODE_BLOCK_163\n\n\n\nCODE_BLOCK_164\n\n\n\nВ предыдущем примере мы использовали режим по умолчанию — **разреженный**. Чтобы показать работу **шардированного** режима, создадим распределённую PQ таблицу, состоящую из 2 локальных PQ таблиц, и добавим 2 документа в \"products1\" и 1 документ в \"products2\":\n\nCODE_BLOCK_165\n\n\n\nТеперь, если добавить `'sharded' as mode` к `CALL PQ`, то документы будут отправлены во все таблицы агента (в данном случае только локальные таблицы, но они могут быть удалёнными для использования внешнего оборудования). Этот режим недоступен через JSON-интерфейс.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_166\n\n\n\nCODE_BLOCK_167\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_168\n\n\n\nCODE_BLOCK_169\n\n\n\nОбратите внимание, что синтаксис зеркал агентов в конфигурации (когда несколько хостов указаны в одной строке `agent`, разделённой символом `|`) не связан с режимом запроса `CALL PQ`. Каждый `agent` всегда представляет **один** узел, независимо от количества зеркал HA, указанных для этого агента.\n\n\n\n##### Как я могу узнать больше о производительности?" + }, + "is_code_or_comment": false + }, + "45b6bd813a1cb73776889e5f05125dfd17e3cc5f17702dc1fee594e4630d1c85": { + "original": "SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nPython\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\njavascript\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\njava\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nC#\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nRust\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nGo\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### I want to know complete PQ rules matching my document\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nPython\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\njavascript\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\njava\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nC#\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nRust\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nGo\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n##### How about multiple documents?\n\nNote that with `CALL PQ`, you can provide multiple documents in different ways:\n\n* as an array of plain documents in round brackets `('doc1', 'doc2')`. This requires `0 as docs_json`\n\n* as an array of JSONs in round brackets `('{doc1}', '{doc2}')`\n\n* or as a standard JSON array `'[{doc1}, {doc2}]'`\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nPython\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\njavascript\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\njava\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nC#\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nRust\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nGo\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n\n\n##### I want to know what docs match what rules\n\nUsing the option `1 as docs` allows you to see which documents of the provided ones match which rules.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nPython\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\njavascript\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\njava\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nC#\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nRust\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nGo\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n\n\n#### Static ids\n\nBy default, matching document ids correspond to their relative numbers in the list you provide. However, in some cases, each document already has its own id. For this case, there's an option `'id field name' as docs_id` for `CALL PQ`.\n\nNote that if the id cannot be found by the provided field name, the PQ rule will not be shown in the results.\n\nThis option is only available for `CALL PQ` via SQL.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n\n\n##### I may have invalid JSONs, please skip them", + "translations": { + "chinese": "SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nPython\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\njavascript\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\njava\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nC#\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nRust\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nGo\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### 我想知道完全匹配我文档的 PQ 规则\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nPython\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\njavascript\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\njava\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nC#\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nRust\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nGo\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n##### 多文档情况如何处理？\n\n请注意，使用 `CALL PQ`，您可以通过不同方式提供多个文档：\n\n* 作为圆括号中的普通文档数组 `('doc1', 'doc2')`。这需要 `0 as docs_json`\n\n* 作为圆括号中的 JSON 数组 `('{doc1}', '{doc2}')`\n\n* 或作为标准 JSON 数组 `'[{doc1}, {doc2}]'`\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nPython\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\njavascript\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\njava\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nC#\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nRust\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nGo\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n\n\n##### 我想知道哪些文档匹配哪些规则\n\n使用选项 `1 as docs` 允许您查看提供的文档中哪些匹配了哪些规则。\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nPython\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\njavascript\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\njava\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nC#\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nRust\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nGo\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n\n\n#### 静态 ID\n\n默认情况下，匹配文档的 ID 对应于您提供列表中的相对编号。但是，在某些情况下，每个文档已经有自己的 ID。对于这种情况，`CALL PQ` 有一个选项 `'id field name' as docs_id`。\n\n请注意，如果通过提供的字段名找不到 ID，则结果中不会显示该 PQ 规则。\n\n此选项仅适用于通过 SQL 使用 `CALL PQ`。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n\n\n##### 我可能有无效的 JSON，请跳过它们", + "russian": "SQL:\n\n\n\nCODE_BLOCK_22\n\n\n\nCODE_BLOCK_23\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_24\n\n\n\nCODE_BLOCK_25\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_26\n\n\n\nCODE_BLOCK_27\n\n\n\nPython\n\n\n\nCODE_BLOCK_28\n\n\n\nCODE_BLOCK_29\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_30\n\n\n\nCODE_BLOCK_31\n\n\n\njavascript\n\n\n\nCODE_BLOCK_32\n\n\n\nCODE_BLOCK_33\n\n\n\njava\n\n\n\nCODE_BLOCK_34\n\n\n\nCODE_BLOCK_35\n\n\n\nC#\n\n\n\nCODE_BLOCK_36\n\n\n\nCODE_BLOCK_37\n\n\n\nRust\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_40\n\n\n\nCODE_BLOCK_41\n\n\n\nGo\n\n\n\nCODE_BLOCK_42\n\n\n\nCODE_BLOCK_43\n\n\n\n\n\n##### Я хочу узнать все правила PQ, соответствующие моему документу\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_44\n\n\n\nCODE_BLOCK_45\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_46\n\n\n\nCODE_BLOCK_47\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_48\n\n\n\nCODE_BLOCK_49\n\n\n\nPython\n\n\n\nCODE_BLOCK_50\n\n\n\nCODE_BLOCK_51\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_52\n\n\n\nCODE_BLOCK_53\n\n\n\njavascript\n\n\n\nCODE_BLOCK_54\n\n\n\nCODE_BLOCK_55\n\n\n\njava\n\n\n\nCODE_BLOCK_56\n\n\n\nCODE_BLOCK_57\n\n\n\nC#\n\n\n\nCODE_BLOCK_58\n\n\n\nCODE_BLOCK_59\n\n\n\nRust\n\n\n\nCODE_BLOCK_60\n\n\n\nCODE_BLOCK_61\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_62\n\n\n\nCODE_BLOCK_63\n\n\n\nGo\n\n\n\nCODE_BLOCK_64\n\n\n\nCODE_BLOCK_65\n\n\n\n\n\n##### А как насчет нескольких документов?\n\nОбратите внимание, что с помощью `CALL PQ` вы можете предоставить несколько документов разными способами:\n\n* в виде массива простых документов в круглых скобках `('doc1', 'doc2')`. Для этого требуется `0 as docs_json`\n\n* в виде массива JSON в круглых скобках `('{doc1}', '{doc2}')`\n\n* или как стандартный JSON-массив `'[{doc1}, {doc2}]'`\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_66\n\n\n\nCODE_BLOCK_67\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_68\n\n\n\nCODE_BLOCK_69\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_70\n\n\n\nCODE_BLOCK_71\n\n\n\nPython\n\n\n\nCODE_BLOCK_72\n\n\n\nCODE_BLOCK_73\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_74\n\n\n\nCODE_BLOCK_75\n\n\n\njavascript\n\n\n\nCODE_BLOCK_76\n\n\n\nCODE_BLOCK_77\n\n\n\njava\n\n\n\nCODE_BLOCK_78\n\n\n\nCODE_BLOCK_79\n\n\n\nC#\n\n\n\nCODE_BLOCK_80\n\n\n\nCODE_BLOCK_81\n\n\n\nRust\n\n\n\nCODE_BLOCK_82\n\n\n\nCODE_BLOCK_83\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_84\n\n\n\nCODE_BLOCK_85\n\n\n\nGo\n\n\n\nCODE_BLOCK_86\n\n\n\nCODE_BLOCK_87\n\n\n\n\n\n##### Я хочу узнать, какие документы соответствуют каким правилам\n\nИспользование опции `1 as docs` позволяет увидеть, какие из предоставленных документов соответствуют каким правилам.\n\n\n\nSQL:\n\n\n\nCODE_BLOCK_88\n\n\n\nCODE_BLOCK_89\n\n\n\nJSON:\n\n\n\nCODE_BLOCK_90\n\n\n\nCODE_BLOCK_91\n\n\n\nPHP:\n\n\n\nCODE_BLOCK_92\n\n\n\nCODE_BLOCK_93\n\n\n\nPython\n\n\n\nCODE_BLOCK_94\n\n\n\nCODE_BLOCK_95\n\n\n\nPython-asyncio\n\n\n\nCODE_BLOCK_96\n\n\n\nCODE_BLOCK_97\n\n\n\njavascript\n\n\n\nCODE_BLOCK_98\n\n\n\nCODE_BLOCK_99\n\n\n\njava\n\n\n\nCODE_BLOCK_100\n\n\n\nCODE_BLOCK_101\n\n\n\nC#\n\n\n\nCODE_BLOCK_102\n\n\n\nCODE_BLOCK_103\n\n\n\nRust\n\n\n\nCODE_BLOCK_104\n\n\n\nCODE_BLOCK_105\n\n\n\nTypeScript\n\n\n\nCODE_BLOCK_106\n\n\n\nCODE_BLOCK_107\n\n\n\nGo\n\n\n\nCODE_BLOCK_108\n\n\n\nCODE_BLOCK_109\n\n\n\n\n\n#### Статические идентификаторы\n\nПо умолчанию идентификаторы соответствующих документов соответствуют их относительным номерам в списке, который вы предоставляете. Однако в некоторых случаях каждый документ уже имеет свой собственный идентификатор. Для этого случая существует опция `'id field name' as docs_id` для `CALL PQ`.\n\nОбратите внимание, что если идентификатор не может быть найден по предоставленному имени поля, правило PQ не будет показано в результатах.\n\nЭта опция доступна только для `CALL PQ` через SQL.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_110\n\n\n\nCODE_BLOCK_111\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_112\n\n\n\nCODE_BLOCK_113\n\n\n\n\n\n##### Возможно, у меня есть некорректные JSON, пожалуйста, пропустите их" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Search_results.md.json b/.translation-cache/Searching/Search_results.md.json index 38f2b00419..611d24c1d4 100644 --- a/.translation-cache/Searching/Search_results.md.json +++ b/.translation-cache/Searching/Search_results.md.json @@ -6,5 +6,13 @@ "russian": "# Результаты поиска\n\n## SQL\n\n\n\nКогда вы выполняете запрос через SQL по протоколу MySQL, вы получаете запрошенные столбцы в результате или пустой набор результатов, если ничего не найдено.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\n\n\nКроме того, вы можете использовать вызов [SHOW META](../Node_info_and_management/SHOW_META.md), чтобы увидеть дополнительную мета-информацию о последнем запросе.\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nВ некоторых случаях, например при выполнении [фасетного поиска](../Searching/Faceted_search.md), вы можете получить несколько наборов результатов в ответ на ваш SQL-запрос.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\n\n\nВ случае предупреждения набор результатов будет содержать флаг предупреждения, и вы можете увидеть предупреждение с помощью [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md).\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n\n\nЕсли ваш запрос завершится ошибкой, вы получите ошибку:\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\n## HTTP\n\nЧерез HTTP JSON интерфейс результат запроса отправляется в виде JSON-документа. Пример:\n\nCODE_BLOCK_10\n\n* `took`: время в миллисекундах, затраченное на выполнение поиска\n\n* `timed_out`: истекло ли время выполнения запроса\n\n* `hits`: результаты поиска, с следующими свойствами:\n\n - `total`: общее количество совпадающих документов\n\n - `hits`: массив, содержащий совпадения\n\nРезультат запроса также может включать информацию о профилировании запроса. См. [Профиль запроса](../Node_info_and_management/Profiling/Query_profile.md).\n\nКаждое совпадение в массиве `hits` имеет следующие свойства:\n\n* `_id`: идентификатор совпадения\n\n* `_score`: вес совпадения, вычисленный ранкером\n\n* `_source`: массив, содержащий атрибуты этого совпадения\n\n### Выбор источника\n\nПо умолчанию все атрибуты возвращаются в массиве `_source`. Вы можете использовать свойство `_source` в теле запроса, чтобы выбрать поля, которые хотите включить в набор результатов. Пример:\n\nCODE_BLOCK_11\n\nВы можете указать атрибуты, которые хотите включить в результат запроса, в виде строки (`\"_source\": \"attr*\"`) или массива строк (`\"_source\": [ \"attr1\", \"attri*\" ]\"`). Каждая запись может быть именем атрибута или шаблоном с подстановочными знаками (`*`, `%` и `?` поддерживаются).\n\nВы также можете явно указать, какие атрибуты хотите включить, а какие исключить из набора результатов, используя свойства `includes` и `excludes`:\n\nCODE_BLOCK_12\n\nПустой список includes интерпретируется как «включить все атрибуты», в то время как пустой список excludes не совпадает ни с чем. Если атрибут совпадает и с includes, и с excludes, то приоритет имеет excludes.\n\n" }, "is_code_or_comment": false + }, + "31e009cff7980fe04baae26fa2811cd381ec0270d06b9c03ca25f3446594ea38": { + "original": "# Search results\n\n## SQL\n\n\n\nWhen you run a query via SQL over the MySQL protocol, you receive the requested columns as a result or an empty result set if nothing is found.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nAdditionally, you can use the [SHOW META](../Node_info_and_management/SHOW_META.md) call to see extra meta-information about the latest query.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n\n\nIn some cases, such as when performing a [faceted search](../Searching/Faceted_search.md), you may receive multiple result sets as a response to your SQL query.\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\nIn case of a warning, the result set will include a warning flag, and you can see the warning using [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md).\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\nIf your query fails, you will receive an error:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n## HTTP\n\nVia the HTTP JSON interface, the query result is sent as a JSON document. Example:\n\nCODE_BLOCK_20\n\n* `took`: time in milliseconds it took to execute the search\n\n* `timed_out`: whether the query timed out or not\n\n* `hits`: search results, with the following properties:\n\n - `total`: total number of matching documents\n\n - `hits`: an array containing matches\n\nThe query result can also include query profile information. See [Query profile](../Node_info_and_management/Profiling/Query_profile.md).\n\nEach match in the `hits` array has the following properties:\n\n* `_id`: match id\n\n* `_score`: match weight, calculated by the ranker\n\n* `_source`: an array containing the attributes of this match\n\n### Source selection\n\nBy default, all attributes are returned in the `_source` array. You can use the `_source` property in the request payload to select the fields you want to include in the result set. Example:\n\nCODE_BLOCK_21\n\nYou can specify the attributes you want to include in the query result as a string (`\"_source\": \"attr*\"`) or as an array of strings (`\"_source\": [ \"attr1\", \"attri*\" ]\"`). Each entry can be an attribute name or a wildcard (`*`, `%` and `?` symbols are supported).\n\nYou can also explicitly specify which attributes you want to include and which to exclude from the result set using the `includes` and `excludes` properties:\n\nCODE_BLOCK_22\n\nAn empty list of includes is interpreted as \"include all attributes,\" while an empty list of excludes does not match anything. If an attribute matches both the includes and excludes, then the excludes win.\n\n", + "translations": { + "chinese": "# 搜索结果\n\n## SQL\n\n\n\n当您通过 MySQL 协议运行 SQL 查询时，您将收到请求的列作为结果，如果未找到任何内容，则返回一个空结果集。\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\n此外，您可以使用 [SHOW META](../Node_info_and_management/SHOW_META.md) 调用来查看有关最新查询的额外元信息。\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n\n\n在某些情况下，例如执行 [分面搜索](../Searching/Faceted_search.md) 时，您可能会收到多个结果集作为对您的 SQL 查询的响应。\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\n如果有警告，结果集将包含警告标志，您可以使用 [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md) 查看警告。\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\n如果您的查询失败，您将收到一个错误：\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n## HTTP\n\n通过 HTTP JSON 接口，查询结果以 JSON 文档格式发送。示例：\n\nCODE_BLOCK_20\n\n* `took`：执行搜索所用时间，单位为毫秒\n\n* `timed_out`：查询是否超时\n\n* `hits`：搜索结果，包含以下属性：\n\n - `total`：匹配文档的总数\n\n - `hits`：包含匹配项的数组\n\n查询结果还可以包含查询配置文件信息。参见 [查询配置文件](../Node_info_and_management/Profiling/Query_profile.md)。\n\n`hits` 数组中的每个匹配项具有以下属性：\n\n* `_id`：匹配 ID\n\n* `_score`：匹配权重，由排序器计算得出\n\n* `_source`：包含此匹配项属性的数组\n\n### 源选择\n\n默认情况下，所有属性都返回在 `_source` 数组中。您可以在请求负载中使用 `_source` 属性选择要包含在结果集中的字段。示例：\n\nCODE_BLOCK_21\n\n您可以将要包含在查询结果中的属性指定为字符串 (`\"_source\": \"attr*\"`) 或字符串数组 (`\"_source\": [ \"attr1\", \"attri*\" ]`)。每个条目可以是属性名称或通配符（支持 `*`、`%` 和 `?` 符号）。\n\n您还可以使用 `includes` 和 `excludes` 属性显式指定您希望包含或从结果集中排除的属性：\n\nCODE_BLOCK_22\n\n空的 includes 列表被解释为“包含所有属性”，而空的 excludes 列表不会匹配任何内容。如果一个属性同时匹配 includes 和 excludes，则以 excludes 为准。\n\n", + "russian": "# Результаты поиска\n\n## SQL\n\n\n\nКогда вы выполняете запрос через SQL по протоколу MySQL, вы получаете запрошенные столбцы в результате или пустой набор результатов, если ничего не найдено.\n\n\n\nCODE_BLOCK_0\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\n\n\nКроме того, вы можете использовать вызов [SHOW META](../Node_info_and_management/SHOW_META.md), чтобы увидеть дополнительную метаинформацию о последнем запросе.\n\n\n\nCODE_BLOCK_4\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\nCODE_BLOCK_7\n\n\n\n\n\nВ некоторых случаях, например, при выполнении [фасетного поиска](../Searching/Faceted_search.md), вы можете получить несколько наборов результатов в ответ на ваш SQL-запрос.\n\n\n\nCODE_BLOCK_8\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\nCODE_BLOCK_11\n\n\n\n\n\nВ случае предупреждения набор результатов будет включать флаг предупреждения, и вы можете просмотреть предупреждение с помощью [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md).\n\n\n\nCODE_BLOCK_12\n\n\n\nCODE_BLOCK_13\n\n\n\nCODE_BLOCK_14\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\nЕсли ваш запрос завершится ошибкой, вы получите ошибку:\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\nCODE_BLOCK_18\n\n\n\nCODE_BLOCK_19\n\n\n\n## HTTP\n\nЧерез HTTP JSON интерфейс результат запроса отправляется в виде JSON-документа. Пример:\n\nCODE_BLOCK_20\n\n* `took`: время в миллисекундах, затраченное на выполнение поиска\n\n* `timed_out`: указание, превысило ли время выполнения запроса лимит\n\n* `hits`: результаты поиска, с следующими свойствами:\n\n - `total`: общее количество совпадающих документов\n\n - `hits`: массив, содержащий совпадения\n\nРезультат запроса также может включать информацию о профиле запроса. См. [Query profile](../Node_info_and_management/Profiling/Query_profile.md).\n\nКаждое совпадение в массиве `hits` имеет следующие свойства:\n\n* `_id`: идентификатор совпадения\n\n* `_score`: вес совпадения, вычисленный ранкером\n\n* `_source`: массив, содержащий атрибуты этого совпадения\n\n### Выбор источника\n\nПо умолчанию все атрибуты возвращаются в массиве `_source`. Вы можете использовать свойство `_source` в теле запроса, чтобы выбрать поля, которые хотите включить в набор результатов. Пример:\n\nCODE_BLOCK_21\n\nВы можете указать атрибуты, которые хотите включить в результат запроса, как строку (`\"_source\": \"attr*\"`), так и массив строк (`\"_source\": [ \"attr1\", \"attri*\" ]\"`). Каждый элемент может быть именем атрибута или шаблоном с подстановочными знаками (`*`, `%` и `?` поддерживаются).\n\nВы также можете явно указать, какие атрибуты включать, а какие исключать из набора результатов, используя свойства `includes` и `excludes`:\n\nCODE_BLOCK_22\n\nПустой список includes интерпретируется как «включить все атрибуты», в то время как пустой список excludes ни с чем не совпадает. Если атрибут совпадает и с includes, и с excludes, то выигрывает исключение (excludes)." + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Searching/Sorting_and_ranking.md.json b/.translation-cache/Searching/Sorting_and_ranking.md.json index d04f87c45b..aa4fead8c0 100644 --- a/.translation-cache/Searching/Sorting_and_ranking.md.json +++ b/.translation-cache/Searching/Sorting_and_ranking.md.json @@ -38,5 +38,29 @@ "russian": "* `tf_idf` (float), сумма TF/IDF по всем ключевым словам, совпавшим в поле. IDF — это обратная частота документа, число с плавающей точкой от 0 до 1, описывающее, насколько часто встречается ключевое слово (по сути, 0 для ключевого слова, встречающегося в каждом проиндексированном документе, и 1 для уникального ключевого слова, встречающегося только в одном документе). TF — это частота термина, количество совпадений ключевого слова в поле. В качестве примечания, `tf_idf` фактически вычисляется суммированием IDF по всем совпавшим вхождениям. Это по конструкции эквивалентно суммированию TF*IDF по всем совпавшим ключевым словам.\n\n* `min_hit_pos` (integer), позиция первого совпавшего ключевого слова, считаемая в словах\n\n Следовательно, это относительно низкоуровневый, «сырой» фактор, который, вероятно, вы захотите *скорректировать* перед использованием для ранжирования. Конкретные корректировки сильно зависят от ваших данных и итоговой формулы, но вот несколько идей для начала: (a) любые бусты на основе min_gaps можно просто игнорировать, если word_count<2;\n\n (b) нетривиальные значения min_gaps (то есть когда word_count>=2) можно ограничить определённой «худшей» константой, в то время как тривиальные значения (то есть когда min_gaps=0 и word_count<2) можно заменить этой константой;\n\n (c) можно применить функцию преобразования, например 1/(1+min_gaps) (чтобы лучшие, меньшие значения min_gaps максимизировали её, а худшие, большие значения min_gaps постепенно уменьшали); и так далее.\n\n* `lccs` (integer). Длина самой длинной общей непрерывной подпоследовательности. Длина самой длинной общей подфразы между запросом и документом, вычисленная в ключевых словах.\n\n Фактор LCCS несколько похож на LCS, но более строгий. В то время как LCS может быть больше 1, даже если ни два слова запроса не совпадают рядом друг с другом, LCCS будет больше 1 только если в документе есть *точные*, непрерывные подфразы запроса. Например, запрос (one two three four five) и документ (one hundred three hundred five hundred) дадут lcs=3, но lccs=1, потому что, хотя взаимное расположение 3 ключевых слов (one, three, five) совпадает между запросом и документом, ни две совпадающие позиции фактически не соседствуют.\n\n Обратите внимание, что LCCS всё ещё не различает частые и редкие ключевые слова; для этого смотрите WLCCS.\n\n* `wlccs` (float). Взвешенная длина самой длинной общей непрерывной подпоследовательности. Сумма IDF ключевых слов самой длинной общей подфразы между запросом и документом.\n\n WLCCS вычисляется аналогично LCCS, но каждое «подходящее» вхождение ключевого слова увеличивает его на IDF ключевого слова, а не просто на 1 (как в LCS и LCCS). Это позволяет ранжировать последовательности более редких и важных ключевых слов выше, чем последовательности частых ключевых слов, даже если последние длиннее. Например, запрос `(Zanzibar bed and breakfast)` даст lccs=1 для документа `(hotels of Zanzibar)`, но lccs=3 для `(London bed and breakfast)`, хотя «Zanzibar» на самом деле несколько реже, чем вся фраза «bed and breakfast». Фактор WLCCS решает эту проблему, используя частоты ключевых слов.\n\n* `atc` (float). Aggregate Term Closeness. Мера близости, основанная на расположении, которая увеличивается, когда в документе содержится больше групп более близко расположенных и более важных (редких) ключевых слов запроса.\n\n **ВНИМАНИЕ:** следует использовать ATC с OPTION idf='plain,tfidf_unnormalized' (см. [ниже](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)); иначе вы можете получить неожиданные результаты.\n\n ATC работает следующим образом. Для каждого вхождения ключевого слова в документе вычисляется так называемая *близость термина*. Для этого рассматриваются все другие ближайшие вхождения всех ключевых слов запроса (включая само ключевое слово) слева и справа от рассматриваемого вхождения, вычисляется коэффициент затухания расстояния как k = pow(distance, -1.75) для этих вхождений, и суммируются затухающие IDF. В результате для каждого вхождения каждого ключевого слова получается значение «близости», описывающее «соседей» этого вхождения. Затем эти значения близости для каждого вхождения умножаются на соответствующий IDF ключевого слова, суммируются, и в конце вычисляется логарифм этой суммы.\n\nДругими словами, мы обрабатываем лучшие (ближайшие) пары совпавших ключевых слов в документе и вычисляем попарные «близости» как произведение их IDF, масштабированное коэффициентом расстояния:\n\nCODE_BLOCK_59\n\nЗатем мы суммируем такие близости и вычисляем итоговое, логарифмически затухающее значение ATC:\n\nCODE_BLOCK_60\n\nОбратите внимание, что именно этот финальный затухающий логарифм является причиной, по которой следует использовать OPTION idf=plain, потому что без него выражение внутри log() может быть отрицательным.\n\nБолее близкие вхождения ключевых слов вносят *гораздо* больший вклад в ATC, чем более частые ключевые слова. Действительно, когда ключевые слова находятся рядом, distance=1 и k=1; если между ними одно слово, distance=2 и k=0.297, при двух словах между ними distance=3 и k=0.146 и так далее. При этом IDF затухает несколько медленнее. Например, в коллекции из 1 миллиона документов значения IDF для ключевых слов, совпадающих в 10, 100 и 1000 документах, будут соответственно 0.833, 0.667 и 0.500. Таким образом, пара ключевых слов с двумя довольно редкими ключевыми словами, встречающимися всего в 10 документах каждое, но с двумя словами между ними, даст pair_tc = 0.101 и едва превзойдёт пару с ключевыми словами из 100 и 1000 документов с одним словом между ними и pair_tc = 0.099. Более того, пара из двух *уникальных*, встречающихся в 1 документе ключевых слов с тремя словами между ними получит pair_tc = 0.088 и проиграет паре из двух ключевых слов из 1000 документов, расположенных рядом, с pair_tc = 0.25. Таким образом, в целом, хотя ATC и сочетает частоту ключевых слов и близость, он всё же несколько отдаёт предпочтение близости.\n\n### Функции агрегации факторов ранжирования\n\n**Функция агрегации по полю** — это функция с одним аргументом, которая принимает выражение с факторами на уровне поля, перебирает все совпавшие поля и вычисляет итоговые результаты. В настоящее время реализованы следующие функции агрегации по полю:\n\n* `sum`, которая суммирует аргумент по всем совпавшим полям. Например, `sum(1)` должна возвращать количество совпавших полей." }, "is_code_or_comment": false + }, + "09903caed50baecf1eca5983b428856eb6af8bf7cd31f30a1a57c808c46612e8": { + "original": "Ranking (also known as weighting) of search results can be defined as a process of computing a so-called relevance (weight) for every given matched document regards to a given query that matched it. So relevance is, in the end, just a number attached to every document that estimates how relevant the document is to the query. Search results can then be sorted based on this number and/or some additional parameters, so that the most sought-after results would appear higher on the results page.\n\nThere is no single standard one-size-fits-all way to rank any document in any scenario. Moreover, there can never be such a way, because relevance is *subjective*. As in, what seems relevant to you might not seem relevant to me. Hence, in general cases, it's not just hard to compute; it's theoretically impossible.\n\nSo ranking in Manticore is configurable. It has a notion of a so-called **ranker**. A ranker can formally be defined as a function that takes a document and a query as its input and produces a relevance value as output. In layman's terms, a ranker controls exactly how (using which specific algorithm) Manticore will assign weights to the documents.\n\n## Available built-in rankers\n\nManticore ships with several built-in rankers suited for different purposes. Many of them use two factors: phrase proximity (also known as LCS) and BM25. Phrase proximity works on keyword positions, while BM25 works on keyword frequencies. Essentially, the better the degree of phrase match between the document body and the query, the higher the phrase proximity (it maxes out when the document contains the entire query as a verbatim quote). And BM25 is higher when the document contains more rare words. We'll save the detailed discussion for later.\n\nThe currently implemented rankers are:\n\n* `proximity_bm25`, the default ranking mode that uses and combines both phrase proximity and BM25 ranking.\n\n* `bm25`, a statistical ranking mode that uses BM25 ranking only (similar to most other full-text engines). This mode is faster but may result in worse quality for queries containing more than one keyword.\n\n* `none`, a no-ranking mode. This mode is obviously the fastest. A weight of 1 is assigned to all matches. This is sometimes called boolean searching, which just matches the documents but does not rank them.\n\n* `wordcount`, ranking by the keyword occurrences count. This ranker computes the per-field keyword occurrence counts, then multiplies them by field weights, and sums the resulting values.\n\n* `proximity` returns the raw phrase proximity value as a result. This mode is internally used to emulate `SPH_MATCH_ALL` queries.\n\n* `matchany` returns rank as it was computed in `SPH_MATCH_ANY` mode earlier and is internally used to emulate `SPH_MATCH_ANY` queries.\n\n* `fieldmask` returns a 32-bit mask with the N-th bit corresponding to the N-th full-text field, numbering from 0. The bit will only be set when the respective field has any keyword occurrences satisfying the query.\n\n* `sph04` is generally based on the default 'proximity_bm25' ranker, but additionally boosts matches when they occur at the very beginning or the very end of a text field. Thus, if a field equals the exact query, `sph04` should rank it higher than a field that contains the exact query but is not equal to it. (For instance, when the query is \"Hyde Park\", a document titled \"Hyde Park\" should be ranked higher than one titled \"Hyde Park, London\" or \"The Hyde Park Cafe\".)\n\n* `expr` allows you to specify the ranking formula at runtime. It exposes several internal text factors and lets you define how the final weight should be computed from those factors. You can find more details about its syntax and a reference of available factors in a [subsection below](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors).\n\nThe ranker name is case-insensitive. Example:\n\nCODE_BLOCK_60\n\n## Quick summary of the ranking factors\n\n| Name | Level | Type | Summary |\n\n| ----------------------- | --------- | ----- | ------------------------------------------------------------------------------------------------------------------ |\n\n| max_lcs | query | int | maximum possible LCS value for the current query |\n\n| bm25 | document | int | quick estimate of BM25(1.2, 0) |\n\n| bm25a(k1, b) | document | int | precise BM25() value with configurable K1, B constants and syntax support |\n\n| bm25f(k1, b, {field=weight, ...}) | document | int | precise BM25F() value with extra configurable field weights |\n\n| field_mask | document | int | bit mask of matched fields |\n\n| query_word_count | document | int | number of unique inclusive keywords in a query |\n\n| doc_word_count | document | int | number of unique keywords matched in the document |\n\n| lcs | field | int | Longest Common Subsequence between query and document, in words |\n\n| user_weight | field | int | user field weight |\n\n| hit_count | field | int | total number of keyword occurrences |\n\n| word_count | field | int | number of unique matched keywords |", + "translations": { + "chinese": "排名（也称为加权）搜索结果可以定义为对每个匹配的文档相对于匹配它的查询计算所谓相关性（权重）的过程。 因此，相关性最终只是附加到每个文档上的一个数字，用于估计该文档与查询的相关程度。然后可以基于该数字和/或一些附加参数对搜索结果进行排序，以便最受关注的结果出现在结果页的较高位置。\n\n没有单一通用的标准方法可以在任何场景中对任何文档进行排名。更重要的是，这样的方法永远不可能存在，因为相关性是*主观的*。换句话说，对你而言相关的东西对我而言可能不相关。因此，在一般情况下，不仅很难计算；从理论上讲是不可能的。\n\n所以 Manticore 中的排序是可配置的。它有一个所谓的**排序器**的概念。排序器可以形式上定义为一个函数，它以文档和查询为输入，输出一个相关性值。通俗来说，排序器控制着 Manticore 使用哪种具体算法为文档分配权重。\n\n## 内置排序器\n\nManticore 提供了几种适用于不同用途的内置排序器。它们中的许多使用两个因素：短语接近度（也称为 LCS）和 BM25。短语接近度依赖关键词的位置，BM25 依赖关键词频率。本质上，文档正文与查询之间短语匹配程度越高，短语接近度越高（当文档包含查询的完整逐字引用时，达到最大值）。BM25 在文档包含更多稀有词时更高。详细讨论稍后再讲。\n\n当前实现的排序器有：\n\n* `proximity_bm25`，默认排序模式，结合使用短语接近度和 BM25 排名。\n\n* `bm25`，只使用 BM25 排名的统计排序模式（类似于大多数其他全文搜索引擎）。该模式较快，但在查询包含多个关键词时可能导致质量下降。\n\n* `none`，无排序模式。该模式显然是最快的。所有匹配均赋值权重为 1。有时称为布尔搜索，只匹配文档但不排序。\n\n* `wordcount`，按关键词出现次数排名。该排序器计算每个字段的关键词出现次数，然后乘以字段权重，并将结果相加。\n\n* `proximity` 返回原始短语接近度值。该模式内部用于模拟 `SPH_MATCH_ALL` 查询。\n\n* `matchany` 返回在早期 `SPH_MATCH_ANY` 模式下计算的排名，内部用于模拟 `SPH_MATCH_ANY` 查询。\n\n* `fieldmask` 返回一个 32 位掩码，其中第 N 位对应第 N 个全文字段（从 0 开始编号）。只有当相应字段包含满足查询的关键词时，该位才会被置位。\n\n* `sph04` 通常基于默认的 `proximity_bm25` 排序器，但额外提升在文本字段开头或末尾出现的匹配。因此，如果一个字段与准确查询相等，`sph04` 会将其排名高于包含该查询但不相等的字段。（例如查询为 \"Hyde Park\"，标题为 \"Hyde Park\" 的文档应排名高于标题为 \"Hyde Park, London\" 或 \"The Hyde Park Cafe\" 的文档。）\n\n* `expr` 允许你在运行时指定排序公式。它暴露了若干内部文本因素，并允许你定义如何由这些因素计算最终权重。你可以在[下面的小节](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors)中找到关于语法及可用因素的详细信息和参考。\n\n排序器名称不区分大小写。示例：\n\nCODE_BLOCK_60\n\n## 排序因素简要汇总\n\n| 名称 | 级别 | 类型 | 说明 |\n\n| ----------------------- | ---------- | ----- | ------------------------------------------------------------------------------------------------------------------ |\n\n| max_lcs | 查询 | int | 当前查询的最大可能 LCS 值 |\n\n| bm25 | 文档 | int | BM25(1.2, 0) 的快速估计 |\n\n| bm25a(k1, b) | 文档 | int | 具有可配置 K1、B 常数和语法支持的精确 BM25() 值 |\n\n| bm25f(k1, b, {field=weight, ...}) | 文档 | int | 具有额外可配置字段权重的精确 BM25F() 值 |\n\n| field_mask | 文档 | int | 匹配字段的位掩码 |\n\n| query_word_count | 文档 | int | 查询中包含的唯一关键词数量 |\n\n| doc_word_count | 文档 | int | 文档中匹配到的唯一关键词数量 |\n\n| lcs | 字段 | int | 查询与文档之间最长公共子序列（以单词计） |\n\n| user_weight | 字段 | int | 用户字段权重 |\n\n| hit_count | 字段 | int | 关键词出现总次数 |\n\n| word_count | 字段 | int | 匹配到的唯一关键词数量 |", + "russian": "Ранжирование (также известное как взвешивание) результатов поиска можно определить как процесс вычисления так называемой релевантности (веса) для каждого совпавшего документа относительно данного запроса, который его совпал. Таким образом, релевантность в конечном итоге — это просто число, прикреплённое к каждому документу, которое оценивает, насколько релевантен документ запросу. Затем результаты поиска могут быть отсортированы на основе этого числа и/или некоторых дополнительных параметров, чтобы наиболее востребованные результаты появлялись выше на странице результатов.\n\nНе существует универсального стандарта для ранжирования любого документа в любой ситуации. Более того, такой способ никогда не сможет существовать, потому что релевантность — *субъективна*. То есть то, что кажется релевантным вам, может не казаться релевантным мне. Следовательно, в общем случае, это не просто трудно вычислить; это теоретически невозможно.\n\nПоэтому ранжирование в Manticore конфигурируемо. В нём есть понятие так называемого **ранкера**. Ранкер можно формально определить как функцию, которая принимает документ и запрос на вход и выдает значение релевантности на выходе. По-простому, ранкер контролирует, как именно (с использованием какого конкретного алгоритма) Manticore будет присваивать весовые значения документам.\n\n## Доступные встроенные ранкеры\n\nManticore поставляется с несколькими встроенными ранкерами, подходящими для разных целей. Многие из них используют два фактора: близость фраз (также известная как LCS) и BM25. Близость фраз работает с позициями ключевых слов, в то время как BM25 работает с частотами ключевых слов. По сути, чем лучше степень совпадения фраз между телом документа и запросом, тем выше близость фраз (она достигает максимума, когда документ содержит весь запрос дословно). А BM25 выше, когда в документе больше редких слов. Детальное обсуждение мы отложим на потом.\n\nВ настоящее время реализованы следующие ранкеры:\n\n* `proximity_bm25` — режим ранжирования по умолчанию, который использует и комбинирует как близость фраз, так и BM25.\n\n* `bm25` — статистический режим ранжирования, который использует только BM25 (похоже на большинство других полнотекстовых движков). Этот режим быстрее, но может ухудшить качество запросов, содержащих более одного ключевого слова.\n\n* `none` — режим без ранжирования. Этот режим, разумеется, самый быстрый. Вес 1 присваивается всем совпадениям. Иногда это называют булевым поиском, который просто находит документы, но не ранжирует их.\n\n* `wordcount` — ранжирование по количеству вхождений ключевых слов. Этот ранкер вычисляет количество вхождений ключевых слов в каждом поле, затем умножает их на веса полей и суммирует полученные значения.\n\n* `proximity` возвращает чистое значение близости фраз. Этот режим внутренне используется для эмуляции запросов с `SPH_MATCH_ALL`.\n\n* `matchany` возвращает ранг, как он вычислялся в режиме `SPH_MATCH_ANY` ранее, и также внутренне используется для эмуляции запросов с `SPH_MATCH_ANY`.\n\n* `fieldmask` возвращает 32-битную маску, где N-й бит соответствует N-му полнотекстовому полю, нумерация с 0. Бит устанавливается, только если соответствующее поле содержит вхождения ключевых слов, удовлетворяющих запросу.\n\n* `sph04` в целом основан на ранкере по умолчанию 'proximity_bm25', но дополнительно усиливает совпадения, если они встречаются либо в самом начале, либо в самом конце текстового поля. Таким образом, если поле равно точному запросу, `sph04` должен ранжировать его выше, чем поле, содержащее точный запрос, но не равное ему. (Например, когда запрос \"Hyde Park\", документ с заголовком \"Hyde Park\" будет иметь более высокий ранг, чем \"Hyde Park, London\" или \"The Hyde Park Cafe\".)\n\n* `expr` позволяет указать формулу ранжирования во время выполнения. Он раскрывает несколько внутренних текстовых факторов и позволяет определить, как вычислять итоговый вес из этих факторов. Больше подробностей о его синтаксисе и список доступных факторов можно найти в [подразделе ниже](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors).\n\nИмя ранкера не чувствительно к регистру. Пример:\n\nCODE_BLOCK_60\n\n## Краткое резюме факторов ранжирования\n\n| Название | Уровень | Тип | Краткое описание |\n\n| ------------------------ | --------- | ----- | ------------------------------------------------------------------------------------------------------------------ |\n\n| max_lcs | запрос | int | максимальное возможное значение LCS для текущего запроса |\n\n| bm25 | документ | int | быстрая оценка BM25(1.2, 0) |\n\n| bm25a(k1, b) | документ | int | точное значение BM25() с настраиваемыми константами K1, B и поддержкой синтаксиса |\n\n| bm25f(k1, b, {field=weight, ...}) | документ | int | точное значение BM25F() с дополнительной настройкой весов полей |\n\n| field_mask | документ | int | битовая маска совпавших полей |\n\n| query_word_count | документ | int | количество уникальных включённых ключевых слов в запросе |\n\n| doc_word_count | документ | int | количество уникальных ключевых слов, совпавших в документе |\n\n| lcs | поле | int | Длиннейшая общая подпоследовательность между запросом и документом, в словах |\n\n| user_weight | поле | int | вес пользовательского поля |\n\n| hit_count | поле | int | общее количество вхождений ключевых слов |\n\n| word_count | поле | int | количество уникальных совпавших ключевых слов |" + }, + "is_code_or_comment": false + }, + "8d83b6e63e7228fd298ae1bffd0f77b64967eaa02c968885ad77e51406533e0b": { + "original": "* `tf_idf` (float), the sum of TF/IDF over all the keywords matched in the field. IDF is the Inverse Document Frequency, a floating point value between 0 and 1 that describes how frequent the keyword is (basically, 0 for a keyword that occurs in every document indexed, and 1 for a unique keyword that occurs in just a single document). TF is the Term Frequency, the number of matched keyword occurrences in the field. As a side note, `tf_idf` is actually computed by summing IDF over all matched occurrences. That's by construction equivalent to summing TF*IDF over all matched keywords.\n\n* `min_hit_pos` (integer), the position of the first matched keyword occurrence, counted in words\n\n Therefore, this is a relatively low-level, \"raw\" factor that you'll likely want to *adjust* before using it for ranking. The specific adjustments depend heavily on your data and the resulting formula, but here are a few ideas to start with: (a) any min_gaps-based boosts could be simply ignored when word_count<2;\n\n (b) non-trivial min_gaps values (i.e., when word_count>=2) could be clamped with a certain \"worst-case\" constant, while trivial values (i.e., when min_gaps=0 and word_count<2) could be replaced by that constant;\n\n (c) a transfer function like 1/(1+min_gaps) could be applied (so that better, smaller min_gaps values would maximize it, and worse, larger min_gaps values would fall off slowly); and so on.\n\n* `lccs` (integer). Longest Common Contiguous Subsequence. The length of the longest subphrase common between the query and the document, computed in keywords.\n\n The LCCS factor is somewhat similar to LCS but more restrictive. While LCS can be greater than 1 even if no two query words are matched next to each other, LCCS will only be greater than 1 if there are *exact*, contiguous query subphrases in the document. For example, (one two three four five) query vs (one hundred three hundred five hundred) document would yield lcs=3, but lccs=1, because although the mutual dispositions of 3 keywords (one, three, five) match between the query and the document, no 2 matching positions are actually adjacent.\n\n Note that LCCS still doesn't differentiate between frequent and rare keywords; for that, see WLCCS.\n\n* `wlccs` (float). Weighted Longest Common Contiguous Subsequence. The sum of IDFs of the keywords of the longest subphrase common between the query and the document.\n\n WLCCS is calculated similarly to LCCS, but every \"suitable\" keyword occurrence increases it by the keyword IDF instead of just by 1 (as with LCS and LCCS). This allows ranking sequences of rarer and more important keywords higher than sequences of frequent keywords, even if the latter are longer. For example, a query `(Zanzibar bed and breakfast)` would yield lccs=1 for a `(hotels of Zanzibar)` document, but lccs=3 against `(London bed and breakfast)`, even though \"Zanzibar\" is actually somewhat rarer than the entire \"bed and breakfast\" phrase. The WLCCS factor addresses this issue by using keyword frequencies.\n\n* `atc` (float). Aggregate Term Closeness. A proximity-based measure that increases when the document contains more groups of more closely located and more important (rare) query keywords.\n\n **WARNING:** you should use ATC with OPTION idf='plain,tfidf_unnormalized' (see [below](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)); otherwise, you may get unexpected results.\n\n ATC essentially operates as follows. For each keyword *occurrence* in the document, we compute the so-called *term closeness*. To do this, we examine all the other closest occurrences of all the query keywords (including the keyword itself) to the left and right of the subject occurrence, calculate a distance dampening coefficient as k = pow(distance, -1.75) for these occurrences, and sum the dampened IDFs. As a result, for every occurrence of each keyword, we obtain a \"closeness\" value that describes the \"neighbors\" of that occurrence. We then multiply these per-occurrence closenesses by their respective subject keyword IDF, sum them all, and finally compute a logarithm of that sum.\n\nIn other words, we process the best (closest) matched keyword pairs in the document, and compute pairwise \"closenesses\" as the product of their IDFs scaled by the distance coefficient:\n\nCODE_BLOCK_61\n\nWe then sum such closenesses, and compute the final, log-dampened ATC value:\n\nCODE_BLOCK_62\n\nNote that this final dampening logarithm is precisely the reason you should use OPTION idf=plain because, without it, the expression inside the log() could be negative.\n\nHaving closer keyword occurrences contributes *much* more to ATC than having more frequent keywords. Indeed, when the keywords are right next to each other, distance=1 and k=1; when there's just one word in between them, distance=2 and k=0.297, with two words between, distance=3 and k=0.146, and so on. At the same time, IDF attenuates somewhat slower. For example, in a 1 million document collection, the IDF values for keywords that match in 10, 100, and 1000 documents would be respectively 0.833, 0.667, and 0.500. So a keyword pair with two rather rare keywords that occur in just 10 documents each but with 2 other words in between would yield pair_tc = 0.101 and thus barely outweigh a pair with a 100-doc and a 1000-doc keyword with 1 other word between them and pair_tc = 0.099. Moreover, a pair of two *unique*, 1-doc keywords with 3 words between them would get a pair_tc = 0.088 and lose to a pair of two 1000-doc keywords located right next to each other and yielding a pair_tc = 0.25. So, basically, while ATC does combine both keyword frequency and proximity, it still somewhat favors proximity.\n\n### Ranking factor aggregation functions\n\nA **field aggregation function** is a single-argument function that accepts an expression with field-level factors, iterates over all matched fields, and computes the final results. The currently implemented field aggregation functions include:\n\n* `sum`, which adds the argument expression over all matched fields. For example `sum(1)` should return the number of matched fields.", + "translations": { + "chinese": "* `tf_idf`（浮点数），字段中所有匹配关键词的TF/IDF之和。IDF是逆文档频率，是介于0和1之间的浮点值，用来描述关键词的频率（基本上，一个在每个被索引文档中都出现的关键词IDF为0，一个只出现在单个文档中的唯一关键词IDF为1）。TF是词频，表示字段中匹配关键词的出现次数。顺便说一句，`tf_idf` 实际上是通过对所有匹配出现的IDF求和计算的。从构造上讲，这等价于对所有匹配关键词求和TF*IDF。\n\n* `min_hit_pos`（整数），第一个匹配关键词出现的位置，按词数计数\n\n 因此，这是一个相对低级的、“原始”的因子，您很可能想在使用它进行排序之前进行*调整*。具体的调整很大程度上取决于您的数据和最终的公式，但这里有一些起步的想法：（a）当 word_count<2 时，可以简单忽略任何基于 min_gaps 的加分；\n\n （b）非平凡的 min_gaps 值（即当 word_count>=2 时）可以被限制在一个“最坏情况”的常数内，而平凡值（即当 min_gaps=0 且 word_count<2）可以被该常数替换；\n\n （c）可以使用类似 1/(1+min_gaps) 的传递函数（这样更好、更小的 min_gaps 值会最大化它，而更差、更大的 min_gaps 值会缓慢递减）；等等。\n\n* `lccs`（整数）。最长公共连续子序列。查询与文档之间最长公共子短语的长度，按关键词计算。\n\n LCCS 因子与 LCS 有些相似，但更具限制性。即使没有两个查询词是相邻匹配的，LCS 也可以大于1，而 LCCS 只有当文档中存在*完全相同*且连续的查询子短语时才会大于1。例如，查询（one two three four five）与文档（one hundred three hundred five hundred）会产生 lcs=3，但 lccs=1，因为虽然3个关键词（one、three、five）在查询和文档中的相对位置匹配，但没有两个匹配位置实际上是相邻的。\n\n 注意，LCCS 仍然不区分频繁和稀有关键词；关于这一点，请参见 WLCCS。\n\n* `wlccs`（浮点数）。加权最长公共连续子序列。查询和文档之间最长公共子短语中关键词的 IDF 之和。\n\n WLCCS 的计算方式与 LCCS 相似，但每个“合适”的关键词出现均由关键词的 IDF 增加，而非仅仅增加1（如 LCS 和 LCCS）。这允许对由较稀有和重要关键词组成的序列进行更高的排名，而不是由频繁关键词组成的更长序列。例如，查询 `(Zanzibar bed and breakfast)` 对文档 `(hotels of Zanzibar)` 会得到 lccs=1，但对于 `(London bed and breakfast)` 会得到 lccs=3，尽管“Zanzibar”实际上比整个“bed and breakfast”短语更稀有。WLCCS 因子通过使用关键词频率解决了这个问题。\n\n* `atc`（浮点数）。聚合词项接近度。基于接近度的度量，文档中包含更多更密集且更重要（稀有）查询关键词组时值更高。\n\n **警告：** 应该在 OPTION idf='plain,tfidf_unnormalized' 条件下使用 ATC（见[下文](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)）；否则，可能会得到意外结果。\n\n ATC 的工作原理基本如下。对于文档中每个关键词*出现*，计算所谓的*词项接近度*。为此，我们检查该出现位置左右的所有其它最接近的查询关键词出现位置（包括该关键词本身），计算距离衰减系数 k = pow(distance, -1.75)，并对衰减后的 IDF 求和。结果，对每个关键词出现，我们获得一个描述该出现“邻居”情况的“接近度”值。然后将这些每次出现的接近度乘以对应关键词的 IDF，将它们相加，最后计算该和的对数。\n\n换句话说，我们处理文档中最好（最近）的匹配关键词对，并计算它们的两两“接近度”，作为它们的 IDF 乘积再乘以距离系数：\n\nCODE_BLOCK_61\n\n然后我们将这些接近度求和，并计算最终的带对数衰减的 ATC 值：\n\nCODE_BLOCK_62\n\n注意，这个最终衰减的对数正是你应使用 OPTION idf=plain 的原因；否则，log() 内的表达式可能为负。\n\n关键词出现越接近，对 ATC 的贡献越大，远远大于关键词频率的影响。实际上，当关键词相邻时，distance=1，k=1；中间隔1个词时，distance=2，k=0.297，中间隔2个词时，distance=3，k=0.146，依此类推。与此同时，IDF 衰减速度较慢。例如，在一百万文档的集合中，分别匹配 10、100 和 1000 个文档的关键词的 IDF 值分别为 0.833、0.667 和 0.500。因此，一个两个都只出现于10篇文档的较稀有关键词对，中间隔两个词，其 pair_tc=0.101，稍微超过一个频率分别为100和1000篇文档的关键词对，中间隔一个词，pair_tc=0.099。此外，两个各自只出现在1篇文档的*唯一*关键词对，中间隔3个词，pair_tc=0.088，会输给一对两个频率为1000篇文档的紧邻关键词对，后者 pair_tc=0.25。所以，基本上，虽然 ATC 结合了关键词频率和接近度，但仍略偏向接近度。\n\n### 排名因子聚合函数\n\n**字段聚合函数**是单参数函数，接受带有字段级因子的表达式，遍历所有匹配字段，并计算最终结果。当前实现的字段聚合函数包括：\n\n* `sum`，对所有匹配字段的参数表达式求和。例如 `sum(1)` 应返回匹配字段的数量。", + "russian": "* `tf_idf` (float), сумма TF/IDF по всем ключевым словам, найденным в поле. IDF — обратная частота документов, число с плавающей точкой от 0 до 1, описывающее, насколько часто встречается ключевое слово (примерно 0 для ключевого слова, встречающегося в каждом проиндексированном документе, и 1 для уникального ключевого слова, встречающегося только в одном документе). TF — частота термина, количество совпадений ключевого слова в поле. Кстати, `tf_idf` фактически вычисляется как сумма IDF по всем найденным совпадениям. Это по сути эквивалентно суммированию TF*IDF по всем совпавшим ключевым словам.\n\n* `min_hit_pos` (integer), позиция первого найденного совпадения ключевого слова, считается в словах\n\n Следовательно, это относительно низкоуровневый, «сырой» фактор, который вы, вероятно, захотите *отрегулировать* перед использованием его для ранжирования. Конкретные настройки сильно зависят от ваших данных и итоговой формулы, но вот несколько идей для начала: (a) любые бусты, основанные на min_gaps, могут просто игнорироваться, если word_count < 2;\n\n (b) нетривиальные значения min_gaps (то есть когда word_count >= 2) могут быть ограничены определенной «наихудшей» константой, а тривиальные значения (то есть когда min_gaps = 0 и word_count < 2) могут быть заменены этой константой;\n\n (c) может применяться функция преобразования, например 1/(1+min_gaps) (чтобы лучшие, меньшие значения min_gaps максимизировали её, а худшие, большие значения min_gaps уменьшали плавно); и так далее.\n\n* `lccs` (integer). Longest Common Contiguous Subsequence — наиболее длинная общая непрерывная подпоследовательность. Длина самой длинной подфразы, общей для запроса и документа, вычисленная в ключевых словах.\n\n Фактор LCCS похож на LCS, но более строгий. В то время как LCS может быть больше 1, даже если ни два слова запроса не стоят рядом друг с другом, LCCS будет больше 1 только если в документе есть *точные*, непрерывные подфразы запроса. Например, запрос (one two three four five) и документ (one hundred three hundred five hundred) дадут lcs=3, но lccs=1, поскольку, хотя взаимное расположение 3 ключевых слов (one, three, five) совпадает между запросом и документом, ни две совпадающие позиции на самом деле не являются смежными.\n\n Обратите внимание, что LCCS по-прежнему не различает частотные и редкие ключевые слова; для этого см. WLCCS.\n\n* `wlccs` (float). Weighted Longest Common Contiguous Subsequence — взвешенная наиболее длинная общая непрерывная подпоследовательность. Сумма IDF ключевых слов самой длинной подфразы, общей для запроса и документа.\n\n WLCCS вычисляется аналогично LCCS, но каждое «подходящее» вхождение ключевого слова увеличивает её на IDF ключевого слова, а не просто на 1 (как в LCS и LCCS). Это позволяет ранжировать выше последовательности более редких и важных ключевых слов, чем последовательности часто встречающихся ключевых слов, даже если последние длиннее. Например, запрос `(Zanzibar bed and breakfast)` даст lccs=1 для документа `(hotels of Zanzibar)`, но lccs=3 для `(London bed and breakfast)`, хотя «Zanzibar» на самом деле несколько реже, чем вся фраза «bed and breakfast». Фактор WLCCS решает эту проблему, используя частоты ключевых слов.\n\n* `atc` (float). Aggregate Term Closeness — агрегированная близость терминов. Мера близости, которая увеличивается, если в документе содержится больше групп более близко расположенных и более важных (редких) ключевых слов из запроса.\n\n **ПРЕДУПРЕЖДЕНИЕ:** следует использовать ATC с OPTION idf='plain,tfidf_unnormalized' (см. [ниже](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)); иначе могут возникнуть неожиданные результаты.\n\n ATC работает таким образом. Для каждого *вхождения* ключевого слова в документе мы вычисляем так называемую *близость термина*. Для этого рассматриваем все другие ближайшие вхождения всех ключевых слов запроса (включая само ключевое слово) слева и справа от данного вхождения, вычисляем коэффициент затухания расстояния как k = pow(distance, -1.75) для этих вхождений и суммируем затухающие IDF. В результате для каждого вхождения каждого ключевого слова получаем значение «близости», описывающее «соседей» этого вхождения. Затем множим эти значения близости для каждого вхождения на соответствующий IDF ключевого слова, суммируем всё это и в конце вычисляем логарифм от суммы.\n\nПроще говоря, мы обрабатываем лучшие (ближайшие) пары совпавших ключевых слов в документе и вычисляем попарные «близости» как произведение их IDF, умноженное на коэффициент расстояния:\n\nCODE_BLOCK_61\n\nЗатем суммируем такие близости и вычисляем итоговое логарифмическое затухание ATC:\n\nCODE_BLOCK_62\n\nОбратите внимание, что именно из-за этого конечного логарифмического затухания вы должны использовать OPTION idf=plain, потому что без него выражение внутри log() могло бы быть отрицательным.\n\nБолее близкое расположение ключевых слов вносит *гораздо* больший вклад в ATC, чем более частотные ключевые слова. Действительно, когда ключевые слова расположены рядом, distance=1 и k=1; если между ними одно слово, distance=2 и k=0.297, при двух словах между distance=3 и k=0.146 и т.д. При этом IDF затухает несколько медленнее. Например, в коллекции из миллиона документов IDF ключевых слов, совпадающих в 10, 100 и 1000 документов соответственно, равны примерно 0.833, 0.667 и 0.500. Таким образом, пара ключевых слов с двумя достаточно редкими словами, каждое из которых встречается только в 10 документах и между которыми два слова, даст pair_tc = 0.101 и едва превзойдет пару из ключевых слов, которые встречаются в 100 и 1000 документах, с одним словом между ними и pair_tc = 0.099. Более того, пара из двух *уникальных* ключевых слов (по одному документу на каждое) с тремя словами между ними получит pair_tc = 0.088 и уступит паре из двух ключевых слов, встречающихся в 1000 документах, расположенных вплотную и дающих pair_tc = 0.25. Таким образом, хотя ATC и сочетает оба фактора — частоту ключевых слов и их близость, он по-прежнему несколько отдает предпочтение близости.\n\n### Функции агрегации факторов ранжирования\n\n**Функция агрегации поля** — это функция с одним аргументом, которая принимает выражение с факторами уровня поля, перебирает все совпавшие поля и вычисляет итоговый результат. В настоящее время реализованы следующие функции агрегации поля:\n\n* `sum`, которая суммирует аргументное выражение по всем совпавшим полям. Например, `sum(1)` должна возвращать количество совпавших полей." + }, + "is_code_or_comment": false + }, + "62664b9d274596946120f1675bb41cc945749f32df68c699a10cc04e71212d09": { + "original": "# Sorting and ranking\n\nQuery results can be sorted by full-text ranking weight, one or more attributes or expressions.\n\n**Full-text** queries return matches sorted by default. If nothing is specified, they are sorted by relevance, which is equivalent to `ORDER BY weight() DESC` in SQL format.\n\n**Non-full-text** queries do not perform any sorting by default.\n\n## Advanced sorting\n\nExtended mode is automatically enabled when you explicitly provide sorting rules by adding the `ORDER BY` clause in SQL format or using the `sort` option via HTTP JSON.\n\n### Sorting via SQL\n\nGeneral syntax:\n\nCODE_BLOCK_0\n\n\n\nIn the sort clause, you can use any combination of up to 5 columns, each followed by `asc` or `desc`. Functions and expressions are not allowed as arguments for the sort clause, except for the `weight()` and `random()` functions (the latter can only be used via SQL in the form of `ORDER BY random()`). However, you can use any expression in the SELECT list and sort by its alias.\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n## Sorting via JSON\n\n\n\n`\"sort\"` specifies an array where each element can be an attribute name or `_score` if you want to sort by match weights or `_random` if you want radnom match order. In that case, the sort order defaults to ascending for attributes and descending for `_score`.\n\n\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_13\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\nYou can also specify the sort order explicitly:\n\n* `asc`: sort in ascending order\n\n* `desc`: sort in descending order\n\n\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_19\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_22\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_26\n\n\n\n\n\nYou can also use another syntax and specify the sort order via the `order` property:\n\n\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_32\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_36\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\nSorting by MVA attributes is also supported in JSON queries. Sorting mode can be set via the `mode` property. The following modes are supported:\n\n* `min`: sort by minimum value\n\n* `max`: sort by maximum value\n\n\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_40\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_41\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_42\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_43\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_44\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_45\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_46\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_47\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\nWhen sorting on an attribute, match weight (score) calculation is disabled by default (no ranker is used). You can enable weight calculation by setting the `track_scores` property to `true`:\n\n\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_54\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_55\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_56\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_58\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_59\n\n\n\n## Ranking overview", + "translations": { + "chinese": "# 排序和排名\n\n查询结果可以按全文排名权重、一个或多个属性或表达式排序。\n\n**全文** 查询默认返回排序后的匹配项。如果没有指定任何内容，则按相关性排序，这相当于 SQL 格式中的 `ORDER BY weight() DESC` 。\n\n**非全文** 查询默认不进行任何排序。\n\n## 高级排序\n\n当您显式通过添加 SQL 格式的 `ORDER BY` 子句或通过 HTTP JSON 使用 `sort` 选项提供排序规则时，扩展模式会自动启用。\n\n### 通过 SQL 排序\n\n通用语法：\n\nCODE_BLOCK_0\n\n\n\n在排序子句中，您可以使用最多 5 列的任意组合，每列后跟 `asc` 或 `desc`。不允许将函数和表达式作为排序子句的参数，除了 `weight()` 和 `random()` 函数（后者只能以 `ORDER BY random()` 形式通过 SQL 使用）。但是，您可以在 SELECT 列表中使用任何表达式，并按其别名排序。\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n## 通过 JSON 排序\n\n\n\n`\"sort\"` 指定了一个数组，每个元素可以是属性名，若想按匹配权重排序则使用 `_score`，若想随机匹配顺序则使用 `_random`。在这种情况下，属性默认为升序排序，`_score` 默认为降序排序。\n\n\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_13\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\n您也可以显式指定排序顺序：\n\n* `asc`：按升序排序\n\n* `desc`：按降序排序\n\n\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_19\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_22\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_26\n\n\n\n\n\n您也可以使用另一种语法，通过 `order` 属性指定排序顺序：\n\n\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_32\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_36\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\nJSON 查询也支持按 MVA 属性排序。排序模式可以通过 `mode` 属性设置。支持以下模式：\n\n* `min`：按最小值排序\n\n* `max`：按最大值排序\n\n\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_40\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_41\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_42\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_43\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_44\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_45\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_46\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_47\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\n当按某个属性排序时，匹配权重（分数）计算默认被禁用（不使用排名器）。您可以通过将 `track_scores` 属性设置为 `true` 来启用权重计算：\n\n\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_54\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_55\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_56\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_58\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_59\n\n\n\n## 排名概述", + "russian": "# Сортировка и ранжирование\n\nРезультаты запроса можно сортировать по весу ранжирования полнотекстового поиска, одному или нескольким атрибутам или выражениям.\n\n**Полнотекстовые** запросы по умолчанию возвращают совпадения, отсортированные по релевантности. Если ничего не указано, они сортируются по релевантности, что эквивалентно `ORDER BY weight() DESC` в SQL-формате.\n\n**Не полнотекстовые** запросы по умолчанию не выполняют сортировку.\n\n## Расширенная сортировка\n\nРасширенный режим автоматически включается, когда вы явно задаёте правила сортировки, добавляя в запрос клаузы `ORDER BY` в SQL-формате или используя опцию `sort` через HTTP JSON.\n\n### Сортировка через SQL\n\nОбщий синтаксис:\n\nCODE_BLOCK_0\n\n\n\nВ клаузе сортировки можно использовать любую комбинацию до 5 колонок, каждая из которых сопровождается `asc` или `desc`. Функции и выражения не допускаются как аргументы для клауззы сортировки, за исключением функций `weight()` и `random()` (последнюю можно использовать только через SQL в виде `ORDER BY random()`). Однако вы можете использовать любое выражение в списке SELECT и сортировать по его псевдониму.\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n## Сортировка через JSON\n\n\n\nОпция `\"sort\"` задаёт массив, в котором каждый элемент может быть именем атрибута или `_score`, если вы хотите сортировать по весам совпадений, или `_random`, если хотите случайный порядок совпадений. В этом случае порядок сортировки по умолчанию — по возрастанию для атрибутов и по убыванию для `_score`.\n\n\n\n\n\nCODE_BLOCK_5\n\n\n\nCODE_BLOCK_6\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_7\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_8\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_9\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_10\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_11\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_12\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_13\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_14\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_15\n\n\n\n\n\nТакже можно явно указать порядок сортировки:\n\n* `asc`: сортировка по возрастанию\n\n* `desc`: сортировка по убыванию\n\n\n\n\n\nCODE_BLOCK_16\n\n\n\nCODE_BLOCK_17\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_18\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_19\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_20\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_21\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_22\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_23\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_24\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_25\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_26\n\n\n\n\n\nМожно также использовать другой синтаксис и указать порядок сортировки через свойство `order`:\n\n\n\n\n\nCODE_BLOCK_27\n\n\n\nCODE_BLOCK_28\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_29\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_30\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_31\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_32\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_33\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_34\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_35\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_36\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_37\n\n\n\n\n\nВ JSON-запросах также поддерживается сортировка по атрибутам MVA. Режим сортировки можно задать через свойство `mode`. Поддерживаются следующие режимы:\n\n* `min`: сортировка по минимальному значению\n\n* `max`: сортировка по максимальному значению\n\n\n\n\n\nCODE_BLOCK_38\n\n\n\nCODE_BLOCK_39\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_40\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_41\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_42\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_43\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_44\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_45\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_46\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_47\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_48\n\n\n\n\n\nПри сортировке по атрибуту вычисление веса совпадения (score) по умолчанию отключено (ранжировщик не используется). Вы можете включить вычисление веса, установив свойство `track_scores` в `true`:\n\n\n\n\n\nCODE_BLOCK_49\n\n\n\nCODE_BLOCK_50\n\n\n\n##### PHP:\n\n\n\nCODE_BLOCK_51\n\n\n\n##### Python:\n\n\n\nCODE_BLOCK_52\n\n\n\n##### Python-asyncio:\n\n\n\nCODE_BLOCK_53\n\n\n\n##### Javascript:\n\n\n\nCODE_BLOCK_54\n\n\n\n##### java:\n\n\n\nCODE_BLOCK_55\n\n\n\n##### C#:\n\n\n\nCODE_BLOCK_56\n\n\n\n##### Rust:\n\n\n\nCODE_BLOCK_57\n\n\n\n##### Typescript:\n\n\n\nCODE_BLOCK_58\n\n\n\n##### Go:\n\n\n\nCODE_BLOCK_59\n\n\n\n## Обзор ранжирования" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Securing_and_compacting_a_table/Compacting_a_table.md.json b/.translation-cache/Securing_and_compacting_a_table/Compacting_a_table.md.json index 81bf6c8452..b8186e150f 100644 --- a/.translation-cache/Securing_and_compacting_a_table/Compacting_a_table.md.json +++ b/.translation-cache/Securing_and_compacting_a_table/Compacting_a_table.md.json @@ -6,5 +6,13 @@ "russian": "# Компактирование таблицы\n\nСо временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или загрязняться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые были ранее удалены с помощью операторов DELETE.\n\nНачиная с Manticore 4, этот процесс происходит [автоматически по умолчанию](../Server_settings/Searchd.md#auto_optimize). Однако вы также можете использовать следующие команды для ручного запуска компактирования таблицы.\n\n## OPTIMIZE TABLE\n\n\n\nCODE_BLOCK_0\n\nОператор `OPTIMIZE` добавляет RT-таблицу в очередь оптимизации, которая будет обработана в фоновом потоке.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\n### Количество оптимизируемых дисковых чанков\n\n\n\nПо умолчанию OPTIMIZE объединяет дисковые чанки RT-таблицы до количества, меньшего или равного числу логических ядер процессора, умноженному на 2.\n\nОднако, если в таблице есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается как количество физических ядер процессора, делённое на 2, для улучшения производительности KNN-поиска.\n\nВы также можете вручную контролировать количество оптимизируемых дисковых чанков с помощью опции `cutoff`.\n\nДополнительные опции включают:\n\n* Настройку сервера [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) для переопределения порога по умолчанию\n\n* Настройку на уровне таблицы [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_2\n\n\n\n### Запуск в фореграунде\n\n\n\nПри использовании `OPTION sync=1` (по умолчанию 0) команда будет ждать завершения процесса оптимизации перед возвратом результата. Если соединение прервётся, оптимизация продолжит выполняться на сервере.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\n### Ограничение влияния на ввод-вывод\n\nОптимизация может быть длительным и интенсивным по вводу-выводу процессом. Чтобы минимизировать влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор `OPTIMIZE` просто добавляет задачу в его очередь. Фоновый поток оптимизации может быть ограничен по вводу-выводу, и вы можете контролировать максимальное количество операций ввода-вывода в секунду и максимальный размер ввода-вывода с помощью директив [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) и [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) соответственно.\n\nВо время оптимизации RT-таблица остаётся онлайн и доступна для поиска и обновлений почти всё время. Она блокируется на очень короткий период, когда успешно объединяется пара дисковых чанков, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы.\n\n### Оптимизация кластерных таблиц\n\nПока [auto_optimize](../Server_settings/Searchd.md#auto_optimize) не отключён, таблицы оптимизируются автоматически.\n\nЕсли вы сталкиваетесь с неожиданными SST или хотите, чтобы таблицы на всех узлах кластера были бинарно идентичны, необходимо:\n\n1. Отключить [auto_optimize](../Server_settings/Searchd.md#auto_optimize).\n\n2. Вручную оптимизировать таблицы:\n\n\n\nНа одном из узлов удалите таблицу из кластера:\n\n\n\nCODE_BLOCK_4\n\n\n\n\n\nОптимизируйте таблицу:\n\n\n\nCODE_BLOCK_5\n\n\n\n\n\nДобавьте таблицу обратно в кластер:\n\n\n\nCODE_BLOCK_6\n\n\n\nКогда таблица будет добавлена обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера.\n\nЛюбые локальные изменения, сделанные в таблице на других узлах, будут потеряны.\n\nИзменения данных таблицы (вставки, замены, удаления, обновления) должны либо:\n\n1. Быть отложены, либо\n\n2. Направляться на узел, где выполняется процесс оптимизации.\n\nОбратите внимание, что пока таблица отсутствует в кластере, команды insert/replace/delete/update должны обращаться к ней без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся с ошибкой.\n\nПосле того как таблица будет добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова использовать префикс имени кластера, иначе они будут завершаться с ошибкой.\n\nОперации поиска доступны как обычно на любом из узлов в процессе.\n\n" }, "is_code_or_comment": false + }, + "d279a187a8b8b36518d9a87c3f9ec5c4acd2ece5f61b06e07413dfff8fa0cab5": { + "original": "# Compacting a Table\n\nOver time, RT tables may become fragmented into numerous disk chunks and/or contaminated with deleted, yet unpurged data, affecting search performance. In these cases, optimization is necessary. Essentially, the optimization process combines pairs of disk chunks, removing documents that were previously deleted using DELETE statements.\n\nBeginning with Manticore 4, this process occurs [automatically by default](../Server_settings/Searchd.md#auto_optimize). However, you can also use the following commands to manually initiate table compaction.\n\n## OPTIMIZE TABLE\n\n\n\nCODE_BLOCK_0\n\n`OPTIMIZE` statement adds an RT table to the optimization queue, which will be processed in a background thread.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\n### Number of optimized disk chunks\n\n\n\nBy default, OPTIMIZE merges the RT table's disk chunks down to a number less than or equal to the number of logical CPU cores multiplied by 2.\n\nHowever, if the table has attributes with KNN indexes, this threshold is different. In this case, it is set to the number of physical CPU cores divided by 2 to improve KNN search performance.\n\nYou can also control the number of optimized disk chunks manually using the `cutoff` option.\n\nAdditional options include:\n\n* Server setting [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) for overriding the default threshold\n\n* Per-table setting [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_4\n\n\n\n### Running in foreground\n\n\n\nWhen using `OPTION sync=1` (0 by default), the command will wait for the optimization process to complete before returning. If the connection is interrupted, the optimization will continue running on the server.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_6\n\n\n\n### Throttling the IO impact\n\nOptimization can be a lengthy and I/O-intensive process. To minimize the impact, all actual merge work is executed serially in a special background thread, and the `OPTIMIZE` statement simply adds a job to its queue. The optimization thread can be I/O-throttled, and you can control the maximum number of I/Os per second and the maximum I/O size with the [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) and [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) directives, respectively.\n\nDuring optimization, the RT table being optimized remains online and available for both searching and updates nearly all the time. It is locked for a very brief period when a pair of disk chunks is successfully merged, allowing for the renaming of old and new files and updating the table header.\n\n### Optimizing clustered tables\n\nAs long as [auto_optimize](../Server_settings/Searchd.md#auto_optimize) is not disabled, tables are optimized automatically.\n\nIf you are experiencing unexpected SSTs or want tables across all nodes of the cluster to be binary identical, you need to:\n\n1. Disable [auto_optimize](../Server_settings/Searchd.md#auto_optimize).\n\n2. Manually optimize tables:\n\n\n\nOn one of the nodes, drop the table from the cluster:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\nOptimize the table:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\nAdd back the table to the cluster:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nWhen the table is added back, the new files created by the optimization process will be replicated to the other nodes in the cluster.\n\nAny local changes made to the table on other nodes will be lost.\n\nTable data modifications (inserts, replaces, deletes, updates) should either:\n\n1. Be postponed, or\n\n2. Be directed to the node where the optimization process is running.\n\nNote that while the table is out of the cluster, insert/replace/delete/update commands should refer to it without the cluster name prefix (for SQL statements or the cluster property in case of an HTTP JSON request), otherwise they will fail.\n\nOnce the table is added back to the cluster, you must resume write operations on the table and include the cluster name prefix again, or they will fail.\n\nSearch operations are available as usual during the process on any of the nodes.\n\n", + "translations": { + "chinese": "# 压缩表\n\n随着时间的推移，RT 表可能会分散成多个磁盘块和/或被删除但未清除的数据污染，从而影响搜索性能。在这种情况下，有必要进行优化。基本上，优化过程是将成对的磁盘块合并，移除先前通过 DELETE 语句删除的文档。\n\n从 Manticore 4 开始，这一过程[默认自动进行](../Server_settings/Searchd.md#auto_optimize)。不过，你也可以使用以下命令手动启动表压缩。\n\n## OPTIMIZE TABLE\n\n\n\nCODE_BLOCK_0\n\n`OPTIMIZE` 语句将 RT 表添加到优化队列，该队列将在后台线程中处理。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\n### 优化后的磁盘块数量\n\n\n\n默认情况下，OPTIMIZE 会将 RT 表的磁盘块合并到小于或等于逻辑 CPU 核心数乘以 2 的数量。\n\n但是，如果表中带有带有 KNN 索引的属性，则该阈值不同。在这种情况下，它设置为物理 CPU 核心数除以 2，以提升 KNN 搜索性能。\n\n你也可以使用 `cutoff` 选项手动控制优化后磁盘块的数量。\n\n其他选项包括：\n\n* 覆盖默认阈值的服务器设置 [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff)\n\n* 每表设置 [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_4\n\n\n\n### 前台运行\n\n\n\n使用 `OPTION sync=1`（默认值为 0）时，命令将在返回之前等待优化过程完成。如果连接中断，优化将在服务器上继续运行。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_6\n\n\n\n### 限制 IO 影响\n\n优化可能是一个漫长且 I/O 密集的过程。为了减少影响，所有实际的合并工作都在一个特殊的后台线程中串行执行，而 `OPTIMIZE` 语句仅将任务加入其队列。优化线程可以进行 I/O 限速，你可以通过[rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) 和 [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) 指令分别控制最大每秒 I/O 数和最大 I/O 大小。\n\n优化期间，被优化的 RT 表几乎始终在线且可供搜索和更新使用。只有在一对磁盘块成功合并时，会短暂锁定，以便重命名旧文件和新文件并更新表头。\n\n### 优化集群表\n\n只要未禁用[auto_optimize](../Server_settings/Searchd.md#auto_optimize)，表将自动优化。\n\n如果你遇到意外的 SSTs，或者希望所有节点上的表二进制完全一致，则需要：\n\n1. 禁用 [auto_optimize](../Server_settings/Searchd.md#auto_optimize)。\n\n2. 手动优化表：\n\n\n\n在某个节点上，从集群中删除表：\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\n优化表：\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\n将表重新添加到集群：\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\n当表被重新添加后，优化过程中产生的新文件将被复制到集群中的其他节点。\n\n在其他节点对该表做的任何本地更改将丢失。\n\n表数据的修改（插入、替换、删除、更新）应当：\n\n1. 被推迟，或者\n\n2. 定向到正在运行优化过程的节点。\n\n请注意，在表不在集群时，插入/替换/删除/更新命令应当不带集群名称前缀（对 SQL 语句或 HTTP JSON 请求中的 cluster 属性），否则将失败。\n\n一旦表被重新添加到集群，必须恢复对表的写操作并重新包含集群名称前缀，否则操作将失败。\n\n在此过程中，任一节点上的搜索操作正常可用。\n\n", + "russian": "# Компактизация таблицы\n\nСо временем RT-таблицы могут фрагментироваться на множество кусков на диске и/или сопровождаться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары кусков на диске, удаляя документы, которые были ранее удалены с помощью операторов DELETE.\n\nНачиная с Manticore 4, этот процесс происходит [автоматически по умолчанию](../Server_settings/Searchd.md#auto_optimize). Однако вы также можете использовать следующие команды для ручного запуска компактизации таблицы.\n\n## OPTIMIZE TABLE\n\n\n\nCODE_BLOCK_0\n\nОператор `OPTIMIZE` добавляет RT-таблицу в очередь оптимизации, которая будет обрабатываться в фоновом потоке.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_2\n\n\n\n### Количество оптимизируемых кусков на диске\n\n\n\nПо умолчанию OPTIMIZE сливает дисковые куски RT-таблицы до количества, не превышающего число логических ядер процессора, умноженное на 2.\n\nОднако, если в таблице есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается как число физических ядер процессора, делённое на 2, для улучшения производительности KNN-поиска.\n\nВы также можете вручную контролировать количество оптимизируемых кусков на диске с помощью опции `cutoff`.\n\nДополнительные опции включают:\n\n* Параметр сервера [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) для переопределения порога по умолчанию\n\n* Параметр для конкретной таблицы [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff)\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_3\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_4\n\n\n\n### Запуск в фореграунд режиме\n\n\n\nПри использовании `OPTION sync=1` (по умолчанию 0) команда дождётся завершения процесса оптимизации перед возвратом результата. Если соединение будет прервано, оптимизация продолжит выполняться на сервере.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_5\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_6\n\n\n\n### Ограничение влияния на ввод-вывод\n\nОптимизация может быть продолжительным и ресурсоёмким процессом по вводу-выводу. Чтобы уменьшить влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор `OPTIMIZE` всего лишь добавляет задачу в его очередь. Фоновый поток оптимизации может ограничивать скорость ввода-вывода, и вы можете контролировать максимальное число операций ввода-вывода в секунду и максимальный размер ввода-вывода с помощью директив [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) и [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) соответственно.\n\nВо время оптимизации оптимизируемая RT-таблица остаётся онлайн и доступна для поиска и обновлений почти всё время. Она блокируется на очень короткий период, когда успешно сливается пара кусков на диске, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы.\n\n### Оптимизация кластерных таблиц\n\nПока [auto_optimize](../Server_settings/Searchd.md#auto_optimize) не отключён, таблицы оптимизируются автоматически.\n\nЕсли у вас возникают неожиданные SST или вы хотите, чтобы таблицы на всех узлах кластера были бинарно идентичны, вам необходимо:\n\n1. Отключить [auto_optimize](../Server_settings/Searchd.md#auto_optimize).\n\n2. Вручную оптимизировать таблицы:\n\n\n\nНа одном из узлов удалите таблицу из кластера:\n\n\n\nCODE_BLOCK_7\n\n\n\nCODE_BLOCK_8\n\n\n\n\n\nОптимизируйте таблицу:\n\n\n\nCODE_BLOCK_9\n\n\n\nCODE_BLOCK_10\n\n\n\n\n\nДобавьте таблицу обратно в кластер:\n\n\n\nCODE_BLOCK_11\n\n\n\nCODE_BLOCK_12\n\n\n\nПосле того как таблица будет добавлена обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера.\n\nЛюбые локальные изменения, произведённые в таблице на других узлах, будут потеряны.\n\nИзменения данных таблицы (вставки, замены, удаления, обновления) должны либо:\n\n1. Быть отложены, или\n\n2. Быть направлены на узел, где выполняется процесс оптимизации.\n\nОбратите внимание, что пока таблица отсутствует в кластере, команды insert/replace/delete/update должны обращаться к ней без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся неудачей.\n\nКогда таблица добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова включить префикс имени кластера, иначе они не будут работать.\n\nОперации поиска доступны как обычно на любом из узлов в процессе.\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md.json b/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md.json index 78d5c4019f..9be7cebbb9 100644 --- a/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md.json +++ b/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md.json @@ -6,5 +6,13 @@ "russian": "# Сброс RAM-чанка в новый диск-чанк\n\n## FLUSH RAMCHUNK\n\n\n\nCODE_BLOCK_0\n\nКоманда `FLUSH RAMCHUNK` создает новый диск-чанк в RT-таблице.\n\nОбычно RT-таблица автоматически сбрасывает и конвертирует содержимое RAM-чанка в новый диск-чанк, когда выполняется одно из [специальных условий](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions). Однако в некоторых случаях вы можете захотеть инициировать сброс вручную — и оператор `FLUSH RAMCHUNK` позволяет это сделать.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n" }, "is_code_or_comment": false + }, + "18a4bf8ba14ead163445ad10819461b62d652e28a35b9166a67cfc8a1a78b937": { + "original": "# Flushing RAM chunk to a new disk chunk\n\n## FLUSH RAMCHUNK\n\n\n\nCODE_BLOCK_0\n\nThe `FLUSH RAMCHUNK` command creates a new disk chunk in an RT table.\n\nNormally, an RT table automatically flushes and converts the contents of the RAM chunk into a new disk chunk when one of the [special conditions](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions) is met. In some cases, though, you may want to trigger the flush manually — and the `FLUSH RAMCHUNK` statement lets you do that.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "translations": { + "chinese": "# 刷新 RAM 块到新的磁盘块\n\n## FLUSH RAMCHUNK\n\n\n\nCODE_BLOCK_0\n\n`FLUSH RAMCHUNK` 命令会在 RT 表中创建一个新的磁盘块。\n\n通常，当满足某个[特殊条件](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions)时，RT 表会自动刷新并将 RAM 块的内容转换成新的磁盘块。不过，在某些情况下，您可能想手动触发刷新 — `FLUSH RAMCHUNK` 语句可以让您做到这一点。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "russian": "# Сброс чанк RAM в новый чанк на диске\n\n## FLUSH RAMCHUNK\n\n\n\nCODE_BLOCK_0\n\nКоманда `FLUSH RAMCHUNK` создаёт новый чанк на диске в RT-таблице.\n\nОбычно RT-таблица автоматически сбрасывает и преобразует содержимое чанка RAM в новый чанк на диске, когда выполняется одно из [специальных условий](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions). Однако в некоторых случаях вы можете захотеть вызвать сброс вручную — и инструкция `FLUSH RAMCHUNK` позволяет это сделать.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md.json b/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md.json index f85af998db..44a045ca1e 100644 --- a/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md.json +++ b/.translation-cache/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md.json @@ -6,5 +6,13 @@ "russian": "# Сброс чанка RAM на диск\n\n## FLUSH TABLE\n\n\n\nCODE_BLOCK_0\n\n`FLUSH TABLE` принудительно сбрасывает содержимое RAM чанка RT таблицы на диск.\n\nЧанк RAM реального времени таблицы [RT table](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) автоматически сбрасывается на диск при корректном завершении работы или периодически каждые [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) секунд.\n\nВыполнение команды `FLUSH TABLE` не только принудительно записывает содержимое RAM чанка на диск, но и запускает очистку бинарных лог-файлов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n" }, "is_code_or_comment": false + }, + "c61376fa341590a6c3a4c5d9ad34b1bdb6b5fe92f94d3d0d11bf60862daf349b": { + "original": "# Flushing RAM chunk to disk\n\n## FLUSH TABLE\n\n\n\nCODE_BLOCK_0\n\n`FLUSH TABLE` forcefully flushes RT table RAM chunk contents to disk.\n\nThe real-time table [RAM chunk](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) is automatically flushed to disk during a clean shutdown, or periodically every [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) seconds.\n\nIssuing a `FLUSH TABLE` command not only forces the RAM chunk contents to be written to disk but also triggers the cleanup of binary log files.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "translations": { + "chinese": "# 将RAM块刷新到磁盘\n\n## FLUSH TABLE\n\n\n\nCODE_BLOCK_0\n\n`FLUSH TABLE` 强制将RT表的RAM块内容刷新到磁盘。\n\n实时表的 [RAM块](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) 会在正常关闭时自动刷新到磁盘，或每隔 [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) 秒周期性刷新。\n\n执行 `FLUSH TABLE` 命令不仅强制将RAM块内容写入磁盘，还会触发二进制日志文件的清理。\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n", + "russian": "# Сброс чанка ОЗУ в файл\n\n## FLUSH TABLE\n\n\n\nCODE_BLOCK_0\n\n`FLUSH TABLE` принудительно сбрасывает содержимое чанка ОЗУ RT-таблицы на диск.\n\nЧанк ОЗУ таблицы реального времени [RAM chunk](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) автоматически сбрасывается на диск при корректном завершении работы или периодически каждые [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) секунд.\n\nВыполнение команды `FLUSH TABLE` не только принудительно записывает содержимое чанка ОЗУ на диск, но и запускает очистку бинарных логов.\n\n\n\n##### SQL:\n\n\n\nCODE_BLOCK_1\n\n\n\nCODE_BLOCK_2\n\n\n\n##### JSON:\n\n\n\nCODE_BLOCK_3\n\n\n\nCODE_BLOCK_4\n\n\n\n" + }, + "is_code_or_comment": false } } diff --git a/manual/chinese/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md b/manual/chinese/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md index 58ecc468dd..125b48c49d 100644 --- a/manual/chinese/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md +++ b/manual/chinese/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md @@ -106,24 +106,29 @@ utils_api.sql("JOIN CLUSTER posts AT '10.12.1.35:9312'", Some(true)).await; -在大多数情况下，当只有一个复制集群时，上述内容已足够。然而，如果您正在创建多个复制集群，则还必须设置 [路径](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 并确保该目录可用。 +在大多数情况下，当只有单个复制集群时，上述方式已足够。然而，如果您创建多个复制集群，则必须同时设置 [path](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 并确保该目录可用。 ```sql JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path ``` + + +```JSON +POST /sql?mode=raw -d "JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path" +``` -节点通过从指定节点获取数据来加入集群，如果成功，则会以与手动通过 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 操作相同的方式更新所有其他集群节点的节点列表。此列表用于在重启时重新加入节点到集群。 +节点通过从指定节点获取数据加入集群，如果成功，则会在所有其他集群节点上以与手动执行 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 相同的方式更新节点列表。此列表用于在重启时重新加入节点到集群。 有两个节点列表： -1.`cluster__nodes_set`：用于在重启时重新加入节点到集群。它会以与 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 相同的方式在所有节点间更新。`JOIN CLUSTER` 命令会自动执行此更新。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示此列表为 `cluster__nodes_set`。 -2. `cluster__nodes_view`：此列表包含所有用于复制的活动节点，无需手动管理。[ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 实际上是将此节点列表复制到用于重启时重新加入的节点列表中。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示此列表为 `cluster__nodes_view`。 +1.`cluster__nodes_set`：用于在重启时重新加入节点到集群。它会在所有节点上以与 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 操作相同的方式更新。`JOIN CLUSTER` 命令自动执行此更新。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示该列表为 `cluster__nodes_set`。 +2.`cluster__nodes_view`：这个列表包含所有用于复制的活跃节点，无需手动管理。[ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) 实际上是将该活动节点列表复制到重启时使用的节点列表中。[集群状态](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) 显示该列表为 `cluster__nodes_view`。 -当节点位于不同的网络段或数据中心时，可以显式设置 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项。这可以最小化节点间的流量，并利用网关节点实现数据中心间的通信。以下代码使用 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项加入现有集群。 +当节点位于不同的网络段或数据中心时，可以显式设置 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项。这可以最小化节点间的流量，并利用网关节点实现数据中心间的通信。以下代码示例使用 [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) 选项加入现有集群。 -> **注意：** 使用此语法时，集群的 `cluster__nodes_set` 列表不会自动更新。要更新它，请使用 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md)。 +> **注意：** 当使用此语法时，集群 `cluster__nodes_set` 列表不会自动更新。要更新它，请使用 [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md)。 @@ -225,8 +230,8 @@ utils_api.sql("JOIN CLUSTER click_query 'clicks_mirror1:9312;clicks_mirror2:9312 -`JOIN CLUSTER` 命令是同步执行的，一旦节点从集群中的其他节点接收完所有数据并与它们同步，即完成操作。 +`JOIN CLUSTER` 命令是同步工作的，一旦节点接收到集群中其他节点的所有数据并与其同步后即完成。 -`JOIN CLUSTER` 操作可能会失败，并显示重复的 [server_id](../../Server_settings/Searchd.md#server_id) 错误信息。这种情况发生在加入的节点与集群中已有节点的 `server_id` 相同。为解决此问题，请确保复制集群中的每个节点具有唯一的 [server_id](../../Server_settings/Searchd.md#server_id)。您可以在配置文件的 "searchd" 部分将默认的 [server_id](../../Server_settings/Searchd.md#server_id) 更改为唯一值，然后再尝试加入集群。 +`JOIN CLUSTER` 操作可能因重复的 [server_id](../../Server_settings/Searchd.md#server_id) 而失败，错误信息中会提示相同的 server_id。这种情况发生在加入的节点与集群中已有节点具有相同的 `server_id`。为解决该问题，请确保复制集群中的每个节点均有唯一的 [server_id](../../Server_settings/Searchd.md#server_id)。您可以在配置文件的 "searchd" 部分更改默认的 [server_id](../../Server_settings/Searchd.md#server_id) 为唯一值，然后再尝试加入集群。 diff --git a/manual/chinese/Creating_a_table/Data_types.md b/manual/chinese/Creating_a_table/Data_types.md index 877cf7d4a5..283d35448a 100644 --- a/manual/chinese/Creating_a_table/Data_types.md +++ b/manual/chinese/Creating_a_table/Data_types.md @@ -2485,60 +2485,60 @@ let search_res = search_api.search(search_req).await; -Float vector attributes allow storing variable-length lists of floats, primarily used for machine learning applications and similarity searches. This type differs from [multi-valued attributes](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) (MVAs) in several important ways: -- Preserves the exact order of values (unlike MVAs which may reorder) -- Retains duplicate values (unlike MVAs which deduplicate) -- No additional processing during insertion (unlike MVAs which sort and deduplicate) +浮点向量属性允许存储可变长度的浮点列表，主要用于机器学习应用和相似性搜索。这种类型与[多值属性](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29)（MVA）在几个重要方面不同： +- 保留值的确切顺序（不像MVA可能重新排序） +- 保留重复值（不像MVA去重） +- 插入时无额外处理（不像MVA会排序和去重） -Float vector attributes allow storing variable-length lists of floats, primarily used for machine learning applications and similarity searches. +浮点向量属性允许存储可变长度的浮点列表，主要用于机器学习应用和相似性搜索。 -### Usage and Limitations -- Currently only supported in real-time tables -- Can only be utilized in KNN (k-nearest neighbor) searches -- Not supported in plain tables or other functions/expressions -- When used with KNN settings, you cannot `UPDATE` `float_vector` values. Use `REPLACE` instead -- When used without KNN settings, you can `UPDATE` `float_vector` values -- Float vectors cannot be used in regular filters or sorting -- The only way to filter by `float_vector` values is through vector search operations (KNN) +### 用法和限制 +- 目前仅支持实时表 +- 只能用于KNN（k近邻）搜索 +- 不支持普通表或其他函数/表达式 +- 使用KNN设置时，不能`UPDATE` `float_vector`值，应使用`REPLACE` +- 不使用KNN设置时，可以`UPDATE` `float_vector`值 +- 浮点向量不能用于常规过滤或排序 +- 唯一通过`float_vector`值过滤的方法是通过向量搜索操作（KNN） -### Common Use Cases -- Text embeddings for semantic search -- Recommendation system vectors -- Image embeddings for similarity search -- Feature vectors for machine learning +### 常见用例 +- 语义搜索的文本嵌入 +- 推荐系统向量 +- 用于相似性搜索的图像嵌入 +- 机器学习的特征向量 -** Keep in mind that the `float_vector` data type is not compatible with the [Auto schema](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema) mechanism. ** +** 请注意，`float_vector`数据类型与[自动模式](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema)机制不兼容。** -For more details on setting up float vectors and using them in searches, see [KNN search](../Searching/KNN.md). +有关设置浮点向量及其搜索使用的详细信息，请参阅[KNN搜索](../Searching/KNN.md)。 -### Auto Embeddings (Recommended) +### 自动嵌入（推荐） -The most convenient way to work with float vectors is using **auto embeddings**. This feature automatically generates embeddings from your text data using machine learning models, eliminating the need to manually compute and insert vectors. +使用**自动嵌入**是处理浮点向量最便捷的方法。此功能通过机器学习模型自动从文本数据生成嵌入，免去了手动计算和插入向量的需要。 -#### Benefits of Auto Embeddings -- **Simplified workflow**: Just insert text, embeddings are generated automatically -- **No manual vector computation**: No need to run separate embedding models -- **Consistent embeddings**: Same model ensures consistent vector representations -- **Multiple model support**: Choose from [sentence-transformers](https://huggingface.co/sentence-transformers/models), OpenAI, Voyage, and Jina models -- **Flexible field selection**: Control which fields are used for embedding generation +#### 自动嵌入的优点 +- **简化流程**：只需插入文本，嵌入自动生成 +- **无需手动计算向量**：无需运行独立的嵌入模型 +- **嵌入一致性**：相同模型确保向量表现一致 +- **支持多模型**：可选择[sentence-transformers](https://huggingface.co/sentence-transformers/models)、OpenAI、Voyage 和 Jina模型 +- **灵活字段选择**：控制用于生成嵌入的字段 -#### Creating tables with auto embeddings +#### 创建带自动嵌入的表 -When creating a table with auto embeddings, specify these additional parameters: -- `MODEL_NAME`: The embedding model to use for automatic vector generation -- `FROM`: Which fields to use for embedding generation (empty string means all text/string fields) +创建带自动嵌入的表时，指定以下附加参数： +- `MODEL_NAME`：用于自动生成向量的嵌入模型 +- `FROM`：用于生成嵌入的字段（空字符串表示所有文本/字符串字段） -**Supported embedding models:** -- **Sentence Transformers**: Any [suitable BERT-based Hugging Face model](https://huggingface.co/sentence-transformers/models) (e.g., `sentence-transformers/all-MiniLM-L6-v2`) — no API key needed. Manticore downloads the model when you create the table. -- **OpenAI**: OpenAI embedding models like `openai/text-embedding-ada-002` - requires `API_KEY=''` parameter -- **Voyage**: Voyage AI embedding models - requires `API_KEY=''` parameter -- **Jina**: Jina AI embedding models - requires `API_KEY=''` parameter +**支持的嵌入模型：** +- **Sentence Transformers**：任何[适用的基于BERT的Hugging Face模型](https://huggingface.co/sentence-transformers/models)（例如，`sentence-transformers/all-MiniLM-L6-v2`）— 无需API密钥。Manticore在创建表时下载模型。 +- **OpenAI**：OpenAI嵌入模型，如`openai/text-embedding-ada-002` - 需要`API_KEY=''`参数 +- **Voyage**：Voyage AI嵌入模型 - 需要`API_KEY=''`参数 +- **Jina**：Jina AI嵌入模型 - 需要`API_KEY=''`参数 ##### SQL: -Using [sentence-transformers model](https://huggingface.co/sentence-transformers/models) (no API key needed) +使用[sentence-transformers模型](https://huggingface.co/sentence-transformers/models)（无需API密钥） ```sql CREATE TABLE products ( title TEXT, @@ -2548,7 +2548,7 @@ CREATE TABLE products ( ); ``` -Using OpenAI model (requires API_KEY parameter) +使用OpenAI模型（需要API_KEY参数） ```sql CREATE TABLE products_openai ( title TEXT, @@ -2558,7 +2558,7 @@ CREATE TABLE products_openai ( ); ``` -Using all text fields for embeddings (FROM is empty) +使用所有文本字段进行嵌入（FROM为空） ```sql CREATE TABLE products_all_fields ( title TEXT, @@ -2569,20 +2569,39 @@ CREATE TABLE products_all_fields ( ); ``` + +##### JSON: + + +使用[sentence-transformers模型](https://huggingface.co/sentence-transformers/models)（无需API密钥） +```JSON +POST /sql?mode=raw -d "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');" +``` + +使用OpenAI模型（需要API_KEY参数） +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_openai (title TEXT, content TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine' MODEL_NAME='openai/text-embedding-ada-002' FROM='title,content' API_KEY='');" +``` + +使用所有文本字段进行嵌入（FROM为空） +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_all_fields (title TEXT, description TEXT, tags TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2' MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='');" +``` + -#### FROM parameter usage +#### FROM参数用法 -The `FROM` parameter controls which fields are used for embedding generation: +`FROM`参数控制用于生成嵌入的字段： -- **Specific fields**: `FROM='title'` - only the title field is used -- **Multiple fields**: `FROM='title,description'` - both title and description are concatenated and used -- **All text fields**: `FROM=''` (empty) - all `text` (full-text field) and `string` (string attribute) fields in the table are used -- **Empty vectors**: You can still insert empty vectors using `()` to exclude documents from vector search +- **特定字段**：`FROM='title'` - 仅使用title字段 +- **多个字段**：`FROM='title,description'` - 将title和description拼接后使用 +- **所有文本字段**：`FROM=''`（空） - 使用表中所有`text`（全文字段）和`string`（字符串属性）字段 +- **空向量**：仍然可以使用`()`插入空向量，以排除文档参与向量搜索 -#### Inserting data with auto embeddings +#### 使用自动嵌入插入数据 -When using auto embeddings, **do not specify the vector field** in your INSERT statements. The embeddings are automatically generated from the specified text fields: +使用自动嵌入时，**不要在INSERT语句中指定向量字段**。嵌入将自动从指定文本字段生成： ```sql -- Insert text data - embeddings generated automatically @@ -2595,10 +2614,10 @@ INSERT INTO products (title, description, embedding_vector) VALUES ('no-vector item', 'this item has no embedding', ()); ``` -### Manual Float Vector Usage +### 手动浮点向量用法 -Alternatively, you can work with manually computed float vectors. +或者，你可以使用手动计算的浮点向量。 ##### SQL: @@ -2704,11 +2723,11 @@ table products -## Multi-value integer (MVA) +## 多值整数（MVA） -Multi-value attributes allow storing variable-length lists of 32-bit unsigned integers. This can be useful for storing one-to-many numeric values, such as tags, product categories, and properties. +多值属性允许存储可变长度的32位无符号整数列表。适合存储一对多的数值，比如标签、产品类别和属性。 ##### SQL: diff --git a/manual/chinese/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md b/manual/chinese/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md index 4006b76f74..2463cf13bb 100644 --- a/manual/chinese/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md +++ b/manual/chinese/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md @@ -606,7 +606,7 @@ source 字段指定在当前表索引期间将从哪个源获取文档。必须 killlist_target = main:kl -此设置确定将应用 kill-list 的表。当前表中更新或删除的目标表中的匹配项将被抑制。在 `:kl` 模式下，要抑制的文档取自 [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)。在 `:id` 模式下，当前表中的所有文档 ID 都会在目标表中被抑制。如果两者都未指定，则两种模式都会生效。[在此了解有关 kill-list 的更多信息](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md) +此设置确定将应用杀死列表的表。当前表中更新或删除的目标表中的匹配项将被抑制。在 `:kl` 模式下，要抑制的文档取自 [杀死列表](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md)。在 `:id` 模式下，当前表中的所有文档 ID 在目标表中被抑制。如果两者都未指定，则两种模式都会生效。[在此处了解有关杀死列表的更多信息](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md) ```ini 值：**未指定**（默认），target_table_name:kl，target_table_name:id，target_table_name。允许多个值 @@ -619,8 +619,8 @@ columnar_attrs = * columnar_attrs = id, attr1, attr2, attr3 ```ini -此配置设置确定哪些属性应存储在[列存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)中，而非行存储中。 -您可以设置 `columnar_attrs = *` 以将所有支持的数据类型存储在列存储中。 +此配置设置确定哪些属性应存储在[列存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)中，而不是行存储中。 +您可以设置 `columnar_attrs = *` 来将所有支持的数据类型存储在列存储中。 ``` 此外，`id` 是支持存储在列存储中的属性。 @@ -629,7 +629,7 @@ columnar_attrs = id, attr1, attr2, attr3 columnar_strings_no_hash = attr1, attr2, attr3 -默认情况下，存储在列存储中的所有字符串属性都会存储预计算的哈希值。这些哈希用于分组和过滤。然而，它们占用额外空间，如果您不需要按该属性分组，可以通过禁用哈希生成来节省空间。 +默认情况下，所有存储在列存储中的字符串属性都会存储预先计算的哈希值。这些哈希值用于分组和过滤。然而，它们会占用额外空间，如果您不需要按此属性分组，可以通过禁用哈希生成来节省空间。 ```ini ### 通过 CREATE TABLE 在线创建实时表 @@ -643,30 +643,30 @@ CREATE TABLE [IF NOT EXISTS] name ( [data type op ##### 数据类型： ```sql -有关数据类型的更多信息，请参见[此处关于数据类型的更多内容](../../Creating_a_table/Data_types.md)。 +有关数据类型的更多信息，请参见[有关数据类型的更多内容](../../Creating_a_table/Data_types.md)。 ``` -| 类型 | 配置文件中的等价项 | 说明 | 别名 | +| 类型 | 配置文件中的等价项 | 备注 | 别名 | | - | - | - | - | -| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | 选项：indexed, stored。默认：**两者**。若只想存储文本但不索引，指定 "stored"。若只想索引文本不存储，指定 "indexed"。 | string | +| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | 选项：indexed, stored。默认：**两者都有**。要保持文本被存储但被索引，仅指定 "stored"。要保持文本仅被索引，仅指定 "indexed"。 | string | | [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | 整数 | int, uint | | [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint) | 大整数 | | | [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | 浮点数 | | | [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | 浮点值向量 | | -| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | 多值整数 | | -| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | 多值大整数 | | +| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | 多整数 | | +| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | 多大整数 | | | [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | 布尔值 | | | [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | | -| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | 字符串。选项 `indexed, attribute` 会使值同时具备全文索引、可过滤、可排序和可分组功能 | | +| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | 字符串。选项 `indexed, attribute` 将使该值同时具备全文索引以及可过滤、可排序和可分组的属性 | | | [timestamp](../../Creating_a_table/Data_types.md#Timestamps) | [rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | 时间戳 | | -| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N 是要保留的最大位数 | | +| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N 是可保留的最大位数 | | ##### 通过 CREATE TABLE 创建实时表的示例 CREATE TABLE products (title text, price float) morphology='stem_en' -这将创建一个名为 "products" 的表，包含两个字段："title"（全文索引）和 "price"（浮点数），并将 "morphology" 设置为 "stem_en"。 +这将创建一个名为 "products" 的表，包含两个字段：“title”（全文）和 “price”（浮点），并将“morphology”设置为“stem_en”。 ```sql @@ -679,26 +679,43 @@ CREATE TABLE products (title text indexed, description text stored, author text, * "title" 被索引，但不存储。 ``` * "description" 被存储，但不索引。 -* "author" 同时被存储和索引。 +* "author" 同时存储和索引。 +POST /sql?mode=raw -d "CREATE TABLE products (title text, price float) morphology='stem_en';" +这将创建一个名为 "products" 的表，包含两个字段：“title”（全文）和 “price”（浮点），并将“morphology”设置为“stem_en”。 + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE products (title text indexed, description text stored, author text, price float);" +``` + +这将创建一个名为 "products" 的表，包含三个字段： + +```JSON +* "title" 被索引，但不存储。 +``` +* "description" 被存储，但不索引。 +* "author" 同时存储和索引。 ## 引擎 create table ... engine='columnar'; + create table ... engine='rowwise'; ```ini -engine 设置更改表中所有属性的默认[属性存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。您也可以为[每个属性单独指定 engine](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages)。 +engine 设置改变表中所有属性的默认[属性存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。您也可以为[每个属性分别指定 engine](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages)。 有关如何为普通表启用列存储的信息，请参见 [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs)。 ``` -取值： +值： -* columnar - 为所有表属性启用列存储，除了 [json](../../Creating_a_table/Data_types.md#JSON) +* columnar - 为所有表属性启用列存储，除 [json](../../Creating_a_table/Data_types.md#JSON) 类型外 -* **rowwise（默认）** - 不做任何更改，使用传统的行存储。 +* **rowwise（默认）** - 不改变任何内容，使用传统的行存储方式。 ## 其他设置 -以下设置适用于实时表和普通表，无论是在配置文件中指定还是通过 `CREATE` 或 `ALTER` 命令在线设置。 +以下设置适用于实时和普通表，无论它们是在配置文件中指定还是通过 `CREATE` 或 `ALTER` 命令在线设置。 ### 性能相关 @@ -706,71 +723,71 @@ engine 设置更改表中所有属性的默认[属性存储](../../Creating_a_ta Manticore 支持两种读取表数据的访问模式：seek+read 和 mmap。 -在 seek+read 模式下，服务器使用 `pread` 系统调用读取文档列表和关键字位置，这些由 `*.spd` 和 `*.spp` 文件表示。服务器使用内部读取缓冲区来优化读取过程，这些缓冲区的大小可以通过选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 进行调整。还有一个选项 [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen) 用于控制 Manticore 启动时如何打开文件。 -在 mmap 访问模式下，搜索服务器使用 `mmap` 系统调用将表文件映射到内存中，操作系统缓存文件内容。选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 对该模式下的相应文件无效。mmap 读取器还可以使用特权调用 `mlock` 锁定表数据在内存中，防止操作系统将缓存数据交换到磁盘。 +在 seek+read 模式中，服务器使用 `pread` 系统调用读取文档列表和关键字位置，这些由 `*.spd` 和 `*.spp` 文件表示。服务器使用内部读取缓冲区来优化读取过程，缓冲区大小可以通过选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 调整。还有一个选项 [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen) 控制 Manticore 如何在启动时打开文件。 +在 mmap 访问模式中，搜索服务器使用 `mmap` 系统调用将表文件映射到内存中，操作系统缓存文件内容。选项 [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) 和 [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) 对应文件在此模式下无效。mmap 读取器还可以使用特权调用 `mlock` 锁定表数据在内存中，防止操作系统将缓存数据换出到磁盘。 -为了控制使用哪种访问模式，提供了选项 **access_plain_attrs**、**access_blob_attrs**、**access_doclists**、**access_hitlists** 和 **access_dict**，其取值如下： +为了控制使用哪种访问模式，提供了选项 **access_plain_attrs**、**access_blob_attrs**、**access_doclists**、**access_hitlists** 和 **access_dict**，其值如下： | 值 | 描述 | | - | - | | file | 服务器使用内部缓冲区通过 seek+read 从磁盘读取表文件 | -| mmap | 服务器将表文件映射到内存，操作系统缓存其内容 | -| mmap_preread | 服务器将表文件映射到内存，后台线程会读取一次以预热缓存 | -| mlock | 服务器将表文件映射到内存，然后执行 mlock() 系统调用缓存文件内容并锁定在内存中，防止被交换出去 | -| 设置 | 取值 | 描述 | +| mmap | 服务器将表文件映射到内存中，操作系统缓存其内容 | +| mmap_preread | 服务器将表文件映射到内存中，后台线程读取一次以预热缓存 | +| mlock | 服务器将表文件映射到内存后执行 mlock() 系统调用，将文件内容缓存并锁定在内存中防止被换出 | +| 设置 | 值 | 描述 | | - | - | - | -| access_plain_attrs | mmap, **mmap_preread** (默认), mlock | 控制如何读取 `*.spa`（普通属性）、`*.spe`（跳跃列表）、`*.spt`（查找表）、`*.spm`（已删除文档） | -| access_blob_attrs | mmap, **mmap_preread** (默认), mlock | 控制如何读取 `*.spb`（blob 属性）（字符串、多值和 json 属性） | -| access_doclists | **file** (默认), mmap, mlock | 控制如何读取 `*.spd`（文档列表）数据 | -| access_hitlists | **file** (默认), mmap, mlock | 控制如何读取 `*.spp`（命中列表）数据 | -| access_dict | mmap, **mmap_preread** (默认), mlock | 控制如何读取 `*.spi`（字典） | -下面的表格可以帮助您选择所需的模式： -| 表部分 | 保留在磁盘 | 保留在内存 | 服务器启动时缓存到内存 | 锁定在内存 | +| access_plain_attrs | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spa`（普通属性）`*.spe`（跳跃列表）`*.spt`（查找表）`*.spm`（已删除文档） | +| access_blob_attrs | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spb`（blob 属性）（字符串、多值和 json 属性） | +| access_doclists | **file**（默认）, mmap, mlock | 控制如何读取 `*.spd`（文档列表）数据 | +| access_hitlists | **file**（默认）, mmap, mlock | 控制如何读取 `*.spp`（命中列表）数据 | +| access_dict | mmap, **mmap_preread**（默认）, mlock | 控制如何读取 `*.spi`（字典） | +下面的表格帮助您选择所需模式： +| 表部分 | 保持在磁盘 | 保持在内存 | 服务器启动时缓存于内存 | 锁定在内存 | | - | - | - | - | - | -| [行存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)（非列存储）的普通属性、跳跃列表、词表、查找表、已删除文档 | mmap | mmap | **mmap_preread** (默认) | mlock | -| 行存储的字符串、多值属性（MVA）和 json 属性 | mmap | mmap | **mmap_preread** (默认) | mlock | -| [列存储](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) 的数值、字符串和多值属性 | 始终 | 仅通过操作系统 | 否 | 不支持 | -| 文档列表 | **file** (默认) | mmap | 否 | mlock | -| 命中列表 | **file** (默认) | mmap | 否 | mlock | -| 字典 | mmap | mmap | **mmap_preread** (默认) | mlock | +| 使用[行式](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)（非列式）存储的普通属性、跳跃列表、词表、查找表、已删除文档 | mmap | mmap | **mmap_preread**（默认） | mlock | +| 行式字符串、多值属性（MVA）和 json 属性 | mmap | mmap | **mmap_preread**（默认） | mlock | +| [列式](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) 数值、字符串和多值属性 | 始终 | 仅由操作系统实现 | 否 | 不支持 | +| 文档列表 | **file**（默认） | mmap | 否 | mlock | +| 命中列表 | **file**（默认） | mmap | 否 | mlock | +| 字典 | mmap | mmap | **mmap_preread**（默认） | mlock | ##### 推荐如下： -* 若追求 **最快的搜索响应时间** 且内存充足，使用 [行存储](../../Creating_a_table/Data_types.md#JSON) 属性并通过 `mlock` 锁定在内存中。同时，对文档列表/命中列表也使用 mlock。 +* 若需**最快的搜索响应时间**且内存充足，使用[行式](../../Creating_a_table/Data_types.md#JSON)属性并通过 `mlock` 锁定它们在内存中。同时，文档列表/命中列表也使用 mlock。 -* 如果优先考虑 **启动后不允许性能下降**，且愿意接受更长的启动时间，可使用 [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options) 选项。若希望更快的 searchd 重启，则保持默认的 `mmap_preread` 选项。 +* 若优先考虑**启动后不可接受性能下降**，并且愿意接受较长启动时间，使用 [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options) 选项。如需搜索守护进程更快重启，请保持默认 `mmap_preread`。 -* 若希望 **节省内存**，但仍有足够内存容纳所有属性，则跳过使用 `mlock`。操作系统将根据频繁的磁盘读取决定保留哪些内容在内存中。 -* 如果行存储属性 **无法全部放入内存**，则选择 [列存储属性](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。 -* 如果全文搜索 **性能不是重点**，且希望节省内存，则使用 `access_doclists/access_hitlists=file`。 -默认模式提供了以下平衡： +* 若想**节省内存**，同时保证所有属性有足够内存，避免使用 `mlock`，操作系统将根据频繁的磁盘读取决定缓存内容。 +* 若行式属性**无法完全放入内存**，请选择[列式属性](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages)。 +* 若全文搜索**性能不是关键**且希望节省内存，使用 `access_doclists/access_hitlists=file`。 +默认模式平衡了： * mmap， -* 预读非列存储属性， -* 对列存储属性无预读的 seek+read， -* 对文档列表/命中列表无预读的 seek+read。 -这在大多数场景下提供了良好的搜索性能、内存利用率和更快的 searchd 重启。 +* 预读取非列式属性， +* 列式属性无预读取的 seek+read， +* 文档列表/命中列表无预读取的 seek+read。 +这在大多数情况下提供了良好的搜索性能、优化的内存利用和更快的搜索守护进程重启。 ### 其他性能相关设置 #### attr_update_reserve attr_update_reserve = 256k -此设置为更新 blob 属性（如多值属性 MVA、字符串和 JSON）预留额外空间。默认值为 128k。更新这些属性时，其长度可能变化。如果更新后的字符串比之前短，则会覆盖 `*.spb` 文件中的旧数据；如果更新后的字符串更长，则写入 `*.spb` 文件末尾。该文件是内存映射的，调整其大小可能较慢，具体取决于操作系统的内存映射文件实现。为避免频繁调整大小，可使用此设置在 .spb 文件末尾预留额外空间。 +此设置为 Blob 属性（如多值属性（MVA）、字符串和 JSON）更新预留额外空间。默认值为128k。更新这些属性时，其长度可能变化。如果更新后的字符串比之前短，会覆盖 `*.spb` 文件中的旧数据；如果更新后的字符串更长，则写到 `*.spb` 文件末尾。该文件被内存映射，重新调整大小可能因操作系统的内存映射文件实现而较慢。为避免频繁调整大小，可使用此设置在 .spb 文件末尾预留额外空间。 ```ini -取值：大小，默认 **128k**。 +值：大小，默认 **128k**。 ``` #### docstore_block_size docstore_block_size = 32k -此设置控制文档存储使用的块大小。默认值为16kb。当使用stored_fields或stored_only_fields存储原始文档文本时，文本存储在表内并进行压缩以提高效率。为了优化小文档的磁盘访问和压缩比，这些文档会被连接成块。索引过程会收集文档，直到它们的总大小达到此选项指定的阈值。此时，文档块会被压缩。可以调整此选项以实现更好的压缩比（通过增加块大小）或更快的文档文本访问速度（通过减小块大小）。 +此设置控制文档存储中使用的块大小。默认值为16kb。当使用stored_fields或stored_only_fields存储原始文档文本时，其存储在表中并进行压缩以提高效率。为了优化小型文档的磁盘访问和压缩比，这些文档被连接成块。索引过程会收集文档，直到其总大小达到此选项指定的阈值。此时，文档块将被压缩。该选项可以调整以实现更好的压缩比（通过增加块大小）或更快的文档文本访问速度（通过减小块大小）。 ```ini 值：大小，默认 **16k**。 @@ -780,7 +797,7 @@ docstore_block_size = 32k docstore_compression = lz4hc -此设置决定用于压缩存储在文档存储中的文档块的压缩类型。如果指定了stored_fields或stored_only_fields，文档存储会存储压缩的文档块。‘lz4’提供快速的压缩和解压速度，而‘lz4hc’（高压缩）牺牲部分压缩速度以获得更好的压缩比。‘none’完全禁用压缩。 +此设置决定了用于压缩文档存储中压缩文档块的压缩类型。如果指定了stored_fields或stored_only_fields，文档存储将存储压缩的文档块。'lz4'提供快速的压缩和解压速度，而'lz4hc'（高压缩）则牺牲一些压缩速度以获得更好的压缩比。'none' 完全禁用压缩。 ```ini 值：**lz4**（默认），lz4hc，none。 @@ -790,7 +807,7 @@ docstore_compression = lz4hc docstore_compression_level = 12 -当文档存储中使用‘lz4hc’压缩时使用的压缩级别。通过调整压缩级别，可以在使用‘lz4hc’压缩时找到性能和压缩比之间的平衡。请注意，此选项在使用‘lz4’压缩时不适用。 +在文档存储中应用'lz4hc'压缩时使用的压缩级别。通过调整压缩级别，您可以在使用'lz4hc'压缩时找到性能与压缩比之间的最佳平衡。注意，当使用'lz4'压缩时，此选项不适用。 ```ini 值：1到12之间的整数，默认值为 **9**。 @@ -800,7 +817,7 @@ docstore_compression_level = 12 preopen = 1 -此设置指示searchd在启动或轮换时应打开所有表文件，并在运行时保持打开状态。默认情况下，文件不会预先打开。预先打开的表每个表需要几个文件描述符，但它们消除了每次查询调用open()的需求，并且在高负载下表轮换时不会发生竞争条件。然而，如果您服务许多表，按查询打开它们可能更有效以节省文件描述符。 +此设置表示searchd应在启动或轮换时打开所有表文件，并在运行时保持打开状态。默认情况下，文件未预先打开。预先打开的表每个表需要几个文件描述符，但它们消除了每次查询调用open()的需求，且在高负载下表轮换时不会发生竞态条件。然而，如果您服务许多表，按查询方式打开它们可能更有效以节省文件描述符。 ```ini 值：**0**（默认），或1。 @@ -810,7 +827,7 @@ preopen = 1 read_buffer_docs = 1M -用于存储每个关键字文档列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。 +用于存储每个关键字的文档列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。 ```ini 值：大小，默认 **256k**，最小值为8k。 @@ -820,7 +837,7 @@ read_buffer_docs = 1M read_buffer_hits = 1M -用于存储每个关键字命中列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。 +用于存储每个关键字的命中列表的缓冲区大小。增加此值将在查询执行期间导致更高的内存使用，但可能减少I/O时间。 ```ini 值：大小，默认 **256k**，最小值为8k。 @@ -832,17 +849,17 @@ read_buffer_hits = 1M inplace_enable = {0|1} -启用就地表反转。可选，默认值为0（使用单独的临时文件）。 +启用原位表反转。可选，默认值为0（使用单独的临时文件）。 ```ini -`inplace_enable`选项在索引纯表时减少磁盘占用，同时略微降低索引速度（它使用大约2倍更少的磁盘，但性能约为原始的90-95%）。 +`inplace_enable`选项减少了纯表索引期间的磁盘占用，同时稍微降低索引速度（使用约减少2倍磁盘，但性能约为原始的90-95%）。 ``` -索引由两个主要阶段组成。第一阶段，收集文档，处理并按关键字部分排序，中间结果写入临时文件（.tmp*）。第二阶段，文档完全排序并创建最终表文件。在线重建生产表大约需要3倍峰值磁盘占用：首先是中间临时文件，其次是新构建的副本，第三是同时为生产查询服务的旧表。（中间数据大小与最终表相当。）对于大型数据集合，这可能占用过多磁盘，`inplace_enable`选项可用于减少它。启用时，它重用临时文件，将最终数据写回这些文件，并在完成时重命名它们。但这可能需要额外的临时数据块重定位，这就是性能影响的来源。 +索引由两个主要阶段组成。第一阶段，收集文档，按照关键字处理和部分排序，中间结果写入临时文件（.tmp*）。第二阶段，文档完成排序，创建最终表文件。在生产环境中动态重建表大约需要3倍峰值磁盘空间：首先是中间临时文件，占用和最终表相当；其次是新建表的副本；第三是仍在服务的旧表。这对于大型数据集合来说磁盘占用可能过大，可以使用`inplace_enable`选项减小它。启用后，复用临时文件，将最终数据输出回临时文件，完成后重命名它们。但是可能需要额外的临时数据块重新定位，这就是性能影响的来源。 -此指令对[searchd](../../Starting_the_server/Manually.md)无效，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)。 +此指令不影响[searchd](../../Starting_the_server/Manually.md)，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)。 ##### CONFIG: @@ -864,7 +881,7 @@ inplace_hit_gap = size ``` -[就地反转](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable)的微调选项。控制预分配的命中列表间隙大小。可选，默认值为0。 +[原位反转](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable)的微调选项。控制预分配的命中列表间隙大小。可选，默认值为0。 @@ -892,12 +909,12 @@ inplace_reloc_factor = 0.1 ``` -inplace_reloc_factor设置决定索引期间内存区域中重定位缓冲区的大小。默认值为0.1。 +inplace_reloc_factor设置确定索引期间内存区中重定位缓冲区的大小。默认值为0.1。 ```ini -此选项为可选，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。 +此选项可选，仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。 ``` ##### CONFIG: @@ -920,12 +937,12 @@ inplace_write_factor = 0.1 ``` -控制索引期间就地写入使用的缓冲区大小。可选，默认值为0.1。 +控制索引期间用于原位写入的缓冲区大小。可选，默认值为0.1。 ```ini -请注意，此指令仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。 +需注意，此指令仅影响[indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool)工具，不影响[searchd](../../Starting_the_server/Manually.md)服务器。 ``` ##### CONFIG: diff --git a/manual/chinese/Creating_a_table/Local_tables/Real-time_table.md b/manual/chinese/Creating_a_table/Local_tables/Real-time_table.md index 92062e4f19..17fb07274f 100644 --- a/manual/chinese/Creating_a_table/Local_tables/Real-time_table.md +++ b/manual/chinese/Creating_a_table/Local_tables/Real-time_table.md @@ -1,17 +1,17 @@ # 实时表 -**实时表** 是 Manticore 中的主要表类型。它允许您添加、更新和删除文档，并且您可以立即看到这些更改。您可以在配置文件中设置实时表，或者使用 `CREATE`、`UPDATE`、`DELETE` 或 `ALTER` 等命令。 +**实时表** 是 Manticore 中的主要表类型。它允许您添加、更新和删除文档，并且可以立即看到这些更改。您可以在配置文件中设置实时表，或者使用诸如 `CREATE`、`UPDATE`、`DELETE` 或 `ALTER` 之类的命令。 -内部来说，实时表由一个或多个称为 **chunks** 的[普通表](../../Creating_a_table/Local_tables/Plain_table.md)组成。有两种类型的 chunks： +内部实时表由一个或多个称为 **chunks** 的[普通表](../../Creating_a_table/Local_tables/Plain_table.md)组成。有两种类型的 chunk： -* 多个 **磁盘 chunk** - 这些保存在磁盘上，结构类似于[普通表](../../Creating_a_table/Local_tables/Plain_table.md)。 -* 单个 **内存 chunk** - 这个保存在内存中，收集所有更改。 +* 多个 **磁盘 chunk** - 这些存储在磁盘上，结构类似于[普通表](../../Creating_a_table/Local_tables/Plain_table.md)。 +* 单个 **内存 chunk** - 保存在内存中，收集所有更改。 -内存 chunk 的大小由 [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit) 设置控制。一旦达到此限制，内存 chunk 会被转移到磁盘，成为磁盘 chunk。如果磁盘 chunk 太多，Manticore 会[合并其中一些](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)以提升性能。 +内存 chunk 的大小由 [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit) 设置控制。一旦达到该限制，内存 chunk 会被转移到磁盘，成为一个磁盘 chunk。如果磁盘 chunk 过多，Manticore 会[合并其中的一些](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks)以提高性能。 ### 创建实时表： -您可以通过两种方式创建新的实时表：使用 `CREATE TABLE` 命令或通过 HTTP JSON API 的 [_mapping 端点](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:)。 +您可以通过两种方式创建新的实时表：使用 `CREATE TABLE` 命令，或通过 HTTP JSON API 的 [_mapping 端点](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:)。 #### CREATE TABLE 命令： @@ -64,21 +64,21 @@ $index->create([ ``` -##### Python: +##### Python： ```python utilsApi.sql('CREATE TABLE forum(title text, price float)') ``` -##### Python-asyncio: +##### Python-asyncio： ```python await utilsApi.sql('CREATE TABLE forum(title text, price float)') ``` -##### Javascript: +##### Javascript： ```javascript @@ -86,21 +86,21 @@ res = await utilsApi.sql('CREATE TABLE forum(title text, price float)'); ``` -##### Java: +##### Java： ```java utilsApi.sql("CREATE TABLE forum(title text, price float)"); ``` -##### C#: +##### C#： ```clike utilsApi.Sql("CREATE TABLE forum(title text, price float)"); ``` -##### Rust: +##### Rust： @@ -109,7 +109,7 @@ utils_api.sql("CREATE TABLE forum(title text, price float)", Some(true)).await; ``` -##### Typescript: +##### Typescript： ```typescript @@ -117,7 +117,7 @@ res = await utilsApi.sql('CREATE TABLE forum(title text, price float)'); ``` -##### Go: +##### Go： ```go @@ -142,11 +142,11 @@ table products { #### _mapping API: -> 注意：`_mapping` API 需要 [Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确保 Buddy 已安装。 +> 注意：`_mapping` API 需要[Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确认 Buddy 已安装。 -另外，您可以通过 `_mapping` 端点创建新表。该端点允许您定义类似 Elasticsearch 的表结构，并将其转换为 Manticore 表。 +另一方面，您也可以通过 `_mapping` 端点创建新表。此端点允许您定义类似 Elasticsearch 的表结构，然后转换为 Manticore 表。 请求体必须具有以下结构： @@ -171,7 +171,7 @@ table products { } ``` -创建表时，Elasticsearch 数据类型将根据以下规则映射为 Manticore 类型： +创建表时，Elasticsearch 数据类型将按以下规则映射到 Manticore 类型： - aggregate_metric => json - binary => string - boolean => bool @@ -243,13 +243,13 @@ POST /your_table_name/_mapping -d ' -您可以创建实时表的副本，可以选择是否包含数据。请注意，如果表很大，复制带数据的表可能需要一些时间。复制操作是同步模式，但如果连接中断，它会在后台继续。 +您可以创建实时表的副本，可以选择包含或不包含其数据。请注意，如果表较大，复制带数据的表可能需要一些时间。复制是同步进行的，但如果连接中断，它将继续在后台进行。 ```sql CREATE TABLE [IF NOT EXISTS] table_name LIKE old_table_name [WITH DATA] ``` -> 注意：复制表需要 [Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确保 Buddy 已安装。 +> 注意：复制表需要 [Manticore Buddy](Installation/Manticore_Buddy.md)。如果无法使用，请确认 Buddy 已安装。 ##### 示例： @@ -260,39 +260,52 @@ create table products LIKE old_products; ``` -##### 示例（包含数据）： +##### 示例（带数据）： ```sql create table products LIKE old_products WITH DATA; ``` + + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products;" +``` + + +##### JSON 示例（带数据）： + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products WITH DATA;" +``` + -### 👍 实时表可以做什么： +### 👍 使用实时表您可以做的事情： * [添加文档](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md)。 * 使用 [Update](../../Quick_start_guide.md#Update) 过程更新属性和全文字段。 * [删除文档](../../Quick_start_guide.md#Delete)。 * [清空表](../../Emptying_a_table.md)。 -* 使用 `ALTER` 命令在线更改模式，如[在线更改模式](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode)所述。 -* 在配置文件中定义表，如[定义表](../../Creating_a_table/Local_tables/Real-time_table.md)详细说明。 -* 使用 [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) 功能自动提供 ID。 +* 使用 `ALTER` 命令在线更改表模式，详见[在线更改模式](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode)。 +* 在配置文件中定义表，详见[定义表](../../Creating_a_table/Local_tables/Real-time_table.md)。 +* 使用 [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) 特性进行自动 ID 分配。 -### ⛔ 实时表不能做什么： +### ⛔ 使用实时表您不能做的事情： * 使用 [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) 功能导入数据。 -* 连接到 [sources](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) 以便从外部存储轻松索引。 +* 将其连接到 [sources](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md)，以便于从外部存储进行索引。 * 更新 [killlist_target](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#killlist_target)，因为它由实时表自动管理。 #### 实时表文件结构 -下表概述了实时表中不同文件扩展名及其各自的描述： +下表概述了实时表中不同文件扩展名及其相应的描述： | 扩展名 | 描述 | | - | - | -| `.lock` | 锁文件，确保一次只有一个进程可以访问该表。 | -| `.ram` | 表的 RAM 块，存储在内存中，用作更改的累加器。 | +| `.lock` | 一个锁文件，确保一次只有一个进程可以访问该表。 | +| `.ram` | 表的内存块，存储在内存中，用作更改的累加器。 | | `.meta` | 定义实时表结构和设置的头文件。 | | `.*.sp*` | 存储在磁盘上的磁盘块，格式与普通表相同。当 RAM 块大小超过 rt_mem_limit 时创建。| -有关磁盘块结构的更多信息，请参阅 [普通表文件结构](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure)。 + 有关磁盘块结构的更多信息，请参阅[普通表文件结构](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure)。 diff --git a/manual/chinese/Creating_a_table/NLP_and_tokenization/Wordforms.md b/manual/chinese/Creating_a_table/NLP_and_tokenization/Wordforms.md index 65197a7640..8c0bfc33f7 100644 --- a/manual/chinese/Creating_a_table/NLP_and_tokenization/Wordforms.md +++ b/manual/chinese/Creating_a_table/NLP_and_tokenization/Wordforms.md @@ -1,6 +1,6 @@ -# 词形变化 +# 词形变换 -词形变化在通过 [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) 规则对输入文本进行分词后应用。它们本质上允许你用另一个词替换一个词。通常，这用于将不同的词形归一化为单一的标准形式（例如，将所有变体如 "walks"、"walked"、"walking" 规范化为标准形式 "walk"）。它也可以用来实现 [词干提取](../../Creating_a_table/NLP_and_tokenization/Morphology.md) 的例外情况，因为词干提取不会应用于词形变化列表中的词。 +词形变换在通过[charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table)规则对传入文本进行分词后应用。它们本质上允许你用一个单词替换另一个单词。通常，这用于将不同的词形形式归一为一个标准形式（例如，将所有变体如“walks”、“walked”、“walking”归一为标准形式“walk”）。它也可以用来实现[词干提取](../../Creating_a_table/NLP_and_tokenization/Morphology.md)的例外，因为在词形变换列表中找到的单词不会应用词干提取。 ## wordforms @@ -11,9 +11,9 @@ wordforms = path/to/dict*.txt ``` -词形变化字典。可选，默认为空。 +词形变换字典。可选，默认为空。 -词形变化字典用于在索引和搜索过程中规范化输入词。因此，对于 [plain table](../../Creating_a_table/Local_tables/Plain_table.md) 来说，必须旋转表以应用词形变化文件中的更改。 +词形变换字典用于在建立索引和搜索时规范传入的单词。因此，对于[plain表](../../Creating_a_table/Local_tables/Plain_table.md)来说，需要轮换表以便应用词形变换文件中的更改。 ##### SQL: @@ -116,10 +116,10 @@ table products { ``` -Manticore 中的词形变化支持设计为能够良好处理大型字典。它们对索引速度有适度影响；例如，包含 100 万条目的字典会使全文索引速度降低约 1.5 倍。搜索速度完全不受影响。额外的内存占用大致等于字典文件大小，且字典在多个表之间共享。例如，如果同一个 50 MB 的词形变化文件被指定给 10 个不同的表，额外的 `searchd` 内存使用大约为 50 MB。 +Manticore中的词形变换支持设计为能够良好处理大型字典。它们中等程度地影响索引速度；例如，包含100万个条目的字典会使全文索引速度降低约1.5倍。搜索速度完全不受影响。额外的内存占用大致等于字典文件大小，并且字典在多个表之间共享。例如，如果完全相同的50 MB词形变换文件被指定给10个不同的表，额外的`searchd`内存使用将约为50 MB。 -字典文件应为简单的纯文本格式。每行应包含源词形和目标词形，使用 UTF-8 编码，并以“大于号”分隔。加载文件时会应用 [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) 中的规则。因此，如果你不修改 `charset_table`，你的词形变化将是不区分大小写的，类似于其他全文索引的数据。以下是文件内容的示例： +字典文件应为简单的纯文本格式。每行应包含源词形和目标词形，使用UTF-8编码，并由“greater than”符号分隔。加载文件时将应用[charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table)规则。因此，如果你不修改`charset_table`，词形变换将是大小写不敏感的，类似于你的其他全文索引数据。下面是文件内容的示例： ```ini @@ -129,12 +129,12 @@ walking > walk ``` -有一个捆绑的工具叫做 [Spelldump](../../Miscellaneous_tools.md#spelldump)，它可以帮助你创建 Manticore 可读取格式的字典文件。该工具可以读取以 `ispell` 或 `MySpell` 格式的源 `.dict` 和 `.aff` 字典文件，这些文件随 OpenOffice 一起捆绑提供。 +有一个捆绑的工具叫做[Spelldump](../../Miscellaneous_tools.md#spelldump)，帮助你创建Manticore能读取的字典文件格式。该工具能够读取以`ispell`或`MySpell`格式的源`.dict`和`.aff`字典文件，这些文件随OpenOffice捆绑提供。 -你可以将多个源词映射到一个目标词。该过程作用于分词后的词元，而非源文本，因此空白和标记的差异会被忽略。 +你可以将多个源单词映射到一个目标单词。此过程对词元进行，而非源文本，因此空白和标记的差异会被忽略。 -你可以使用 `=>` 符号代替 `>`。也允许注释（以 `#` 开头）。最后，如果一行以波浪号（`~`）开头，词形变化将在形态学处理之后应用，而非之前（注意此情况下只支持单个源词和目标词）。 +你可以使用`=>`符号代替`>`。允许添加注释（以`#`开头）。最后，如果一行以波浪号(`~`)开头，词形变换将在形态学处理后应用，而非之前（注意，此情况下仅支持单一的源词和目标词）。 ```ini @@ -146,7 +146,7 @@ core 2duo => c2d # Some people write '2duo' together... -如果你需要将 `>`、`=` 或 `~` 作为普通字符使用，可以通过在它们前面加反斜杠（`\`）来转义。`>` 和 `=` 都应以此方式转义。示例如下： +如果需要将`>`、`=`或`~`作为普通字符使用，可以通过在前面加反斜杠(`\`)进行转义。`>`和`=`均应如此转义。示例： ```ini @@ -170,11 +170,11 @@ s3 e3 > season 3 episode 3 -你可以指定多个文件，而不仅仅是一个。可以使用通配符作为模式，所有匹配的文件将按简单升序处理： +你可以指定多个文件，而不仅限于一个。可以使用通配符作为模式，所有匹配的文件将按简单升序处理： -在 RT 模式下，只允许使用绝对路径。 +在RT模式中，仅允许绝对路径。 -如果使用多字节编码页且文件名包含非拉丁字符，结果顺序可能不完全是字母顺序。如果在多个文件中发现相同的词形变化定义，后面的定义将覆盖之前的。 +如果使用多字节编码页且文件名包含非拉丁字符，结果顺序可能并非字母排序。如果在多个文件中发现同一个词形变换定义，则以后定义的将覆盖之前的。 ```sql @@ -182,6 +182,12 @@ create table tbl1 ... wordforms='/tmp/wf*' create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2' ``` + +```JSON +POST /sql?mode=raw -d "create table tbl1 ... wordforms='/tmp/wf*'" +POST /sql?mode=raw -d "create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2'" +``` + ```ini wordforms=/tmp/wf diff --git a/manual/chinese/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md b/manual/chinese/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md index ec592b958e..9e40a85448 100644 --- a/manual/chinese/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md +++ b/manual/chinese/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md @@ -1,18 +1,18 @@ # 向 percolate 表添加规则 -在 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) 中，percolate 查询规则被存储，且必须遵循四个字段的精确模式： +在 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) 中，存储了 percolate 查询规则，必须遵循包含四个字段的精确模式： | 字段 | 类型 | 描述 | | - | - | - | | id | bigint | PQ 规则标识符（如果省略，将自动分配） | -| query | string | 全文查询（可以为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) | -| filters | string | 通过非全文字段的附加过滤器（可以为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) | -| tags | string | 一个包含一个或多个逗号分隔标签的字符串，可用于选择性显示/删除已保存的查询 | +| query | string | 全文查询（可为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) | +| filters | string | 通过非全文字段的附加过滤器（可为空），兼容 [percolate 表](../../Creating_a_table/Local_tables/Percolate_table.md) | +| tags | string | 一个包含一个或多个逗号分隔标签的字符串，可用于有选择地显示/删除已保存的查询 | -任何其他字段名称不被支持，会触发错误。 +任何其他字段名不被支持，且会触发错误。 -**警告：** 通过 SQL 插入/替换 JSON 格式的 PQ 规则将不起作用。换句话说，JSON 特定的操作符（如 `match` 等）将仅被视为规则文本的一部分，应与文档匹配。如果你偏好 JSON 语法，请使用 HTTP 端点而非 `INSERT`/`REPLACE`。 +**警告：** 通过 SQL 插入/替换 JSON 格式的 PQ 规则将无法正常工作。换句话说，JSON 特定操作符（如 `match` 等）将被视为规则文本的一部分，应与文档匹配。如果您希望使用 JSON 语法，请使用 HTTP 端点而不是 `INSERT`/`REPLACE`。 ##### SQL @@ -36,8 +36,8 @@ SELECT * FROM pq; ##### JSON -有两种方式可以将 percolate 查询添加到 percolate 表中： -* 兼容 JSON /search 格式的查询，详见 [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON) +添加 percolate 查询到 percolate 表有两种方式： +* 使用 JSON /search 兼容格式的查询，详见 [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON) ```json PUT /pq/pq_table/doc/1 { @@ -55,7 +55,7 @@ PUT /pq/pq_table/doc/1 } ``` -* SQL 格式的查询，详见 [search query syntax](../../Searching/Filters.md#Queries-in-SQL-format) +* 使用 SQL 格式的查询，详见 [search query syntax](../../Searching/Filters.md#Queries-in-SQL-format) ```json PUT /pq/pq_table/doc/2 { @@ -163,7 +163,7 @@ let insert_res = index_api.insert(insert_req).await; ## 自动 ID 分配 -如果你未指定 ID，将自动分配。你可以在此处了解更多关于自动 ID 的信息 [here](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID)。 +如果未指定 ID，将自动分配。您可以在[此处](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID)阅读有关自动 ID 的更多信息。 ##### SQL: @@ -358,8 +358,8 @@ let insert_res = index_api.insert(insert_req).await; ## SQL 中无模式 -如果在 SQL `INSERT` 命令中省略了模式，预期的参数如下： -1. ID。你可以使用 `0` 作为 ID 以触发自动 ID 生成。 +如果 SQL `INSERT` 命令中省略了模式，则期望如下参数： +1. ID。您可以使用 `0` 作为 ID 来触发自动生成 ID。 2. Query - 全文查询。 3. Tags - PQ 规则标签字符串。 4. Filters - 通过属性的附加过滤器。 @@ -381,12 +381,82 @@ SELECT * FROM pq; | 2810855531667783689 | @title shoes | Louis Vuitton | | +---------------------+--------------+---------------+---------+ ``` + + + +```JSON +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', '', '');" +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', 'Louis Vuitton', '');" +POST /sql?mode=raw -d "SELECT * FROM pq;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "Louis Vuitton", + "filters": "" + }, + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "", + "filters": "" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ## 替换 PQ 表中的规则 -要在 SQL 中用新规则替换现有的 PQ 规则，只需使用常规的 [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md) 命令。通过 HTTP JSON 接口以 JSON 模式定义的 PQ 规则替换，有一个特殊语法 `?refresh=1`。 +要在 SQL 中用新规则替换现有的 PQ 规则，只需使用常规的 [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md) 命令。通过 HTTP JSON 接口替换**以 JSON 模式定义的** PQ 规则，有一个特殊语法 `?refresh=1`。 diff --git a/manual/chinese/Data_creation_and_modification/Deleting_documents.md b/manual/chinese/Data_creation_and_modification/Deleting_documents.md index f0b8c613ed..13367c9cc8 100644 --- a/manual/chinese/Data_creation_and_modification/Deleting_documents.md +++ b/manual/chinese/Data_creation_and_modification/Deleting_documents.md @@ -1,25 +1,25 @@ # 删除文档 -删除文档仅在以下表类型的[RT模式](../Read_this_first.md#Real-time-mode-vs-plain-mode)中支持： +删除文档仅支持在[RT 模式](../Read_this_first.md#Real-time-mode-vs-plain-mode)下，对以下表类型进行： * [实时](../Creating_a_table/Local_tables/Real-time_table.md) 表 * [Percolate](../Creating_a_table/Local_tables/Percolate_table.md) 表 * 仅包含 RT 表作为本地或远程代理的分布式表。 您可以根据文档的 ID 或某些条件从表中删除现有文档。 -此外，还提供了[批量删除](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion)功能以删除多个文档。 +另外，[批量删除](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) 可用于删除多个文档。 -文档的删除可以通过 SQL 和 JSON 接口完成。 +文档的删除可以通过 SQL 和 JSON 接口来完成。 对于 SQL，成功操作的响应将指示删除的行数。 -对于 JSON，使用 `json/delete` 端点。服务器将响应一个 JSON 对象，指示操作是否成功以及删除的行数。 +对于 JSON，使用 `json/delete` 端点。服务器将返回一个 JSON 对象，指示操作是否成功以及删除的行数。 建议使用[表截断](../Emptying_a_table.md)来删除表中的所有文档，因为这是一种更快的操作。 -在此示例中，我们从名为 `test` 的表中删除所有匹配全文查询 `test document` 的文档： +在此示例中，我们删除了名称为 `test` 的表中所有符合全文查询 `test document` 的文档： @@ -73,7 +73,7 @@ POST /delete -d ' }' ``` -* JSON 中的 `query` 包含全文搜索的子句；其语法与[JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON)中的相同。 +* JSON 的 `query` 包含全文搜索的条件；其语法与[JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON)中的相同。 @@ -257,7 +257,7 @@ deleteRequest.SetQuery(deleteQuery) -这里 - 从名为 `test` 的表中删除 `id` 等于 1 的文档： +这里 - 删除表 `test` 中 `id` 等于 1 的文档： @@ -280,7 +280,7 @@ POST /delete -d ' }' ``` -* JSON 中的 `id` 是应删除的行 `id`。 +* JSON 的 `id` 是要删除的行的 `id`。 @@ -451,10 +451,10 @@ deleteRequest.SetId(1) -这里，删除与名为 `test` 的表中值匹配的 `id` 的文档： +这里，删除表 `test` 中 `id` 匹配指定值的文档： -请注意，带有 `id=N` 或 `id IN (X,Y)` 的删除形式是最快的，因为它们在删除文档时不执行搜索。 -还请注意，响应中仅包含对应 `_id` 字段中第一个被删除文档的 id。 +注意，形式为 `id=N` 或 `id IN (X,Y)` 的删除是最快的，因为它们在删除文档时不执行搜索。 +另外注意，响应中只包含第一个被删除文档的 id ，对应字段为 `_id`。 ##### SQL: @@ -518,7 +518,7 @@ Array( Manticore SQL 允许对 `DELETE` 语句使用复杂条件。 -例如，这里我们删除匹配全文查询 `test document` 并且属性 `mva1` 的值大于 206 或 `mva1` 值为 100 或 103 的文档，来自名为 `test` 的表： +例如，这里我们删除表 `test` 中符合全文查询 `test document` 且属性 `mva1` 大于 206，或 `mva1` 的值为 100 或 103 的文档： @@ -547,10 +547,68 @@ Query OK, 4 rows affected (0.00 sec) +------+------+-------------+------+ 6 rows in set (0.00 sec) ``` + + + +```JSON +POST /sql?mode=raw -d "DELETE FROM TEST WHERE MATCH ('test document') AND ( mva1>206 or mva1 in (100, 103) );" + +POST /sql?mode=raw -d "SELECT * FROM TEST;" +``` + + +```JSON +[ + { + "total": 4, + "error": "", + "warning": "" + } +] + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "mva1": { + "type": "long" + } + }, + { + "mva2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "gid": "1001", + "mva1": 101,102, + "mva2": 101 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -这是在集群 `cluster` 的表 `test` 中删除文档的示例。请注意，我们必须提供集群名称属性以及表属性，才能从复制集群中的表删除行： +这是在集群 `cluster` 的表 `test` 中删除文档的示例。注意我们必须提供集群名称属性以及表属性，才能删除复制集群中的表中的行： @@ -571,7 +629,7 @@ POST /delete -d ' "id": 100 }' ``` -* JSON 中的 `cluster` 是包含所需表的[复制集群](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster)的名称 +* JSON 的 `cluster` 是包含所需表的[复制集群](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster)名称。 ##### PHP: @@ -735,11 +793,11 @@ deleteRequest.SetId(1) -## 批量删除 +## Bulk deletion -您还可以使用 `/bulk` 端点在单个调用中执行多个删除操作。此端点仅适用于 `Content-Type` 设置为 `application/x-ndjson` 的数据。数据应格式化为换行分隔的 JSON（NDJSON）。本质上，这意味着每行应包含一个完整的 JSON 语句，并以换行符 `\n` 结尾，可能还有一个 `\r`。 +You can also perform multiple delete operations in a single call using the `/bulk` endpoint. This endpoint only works with data that has `Content-Type` set to `application/x-ndjson`. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline `\n` and, possibly, a `\r`. diff --git a/manual/chinese/Extensions/FEDERATED.md b/manual/chinese/Extensions/FEDERATED.md index 0c48d59bf1..52b952db13 100644 --- a/manual/chinese/Extensions/FEDERATED.md +++ b/manual/chinese/Extensions/FEDERATED.md @@ -1,12 +1,12 @@ # FEDERATED -使用 MySQL 的 FEDERATED 引擎，您可以从 MySQL/MariaDB 连接到本地或远程的 Manticore 实例并执行搜索查询。 +通过 MySQL 的 FEDERATED 引擎，您可以从 MySQL/MariaDB 连接到本地或远程的 Manticore 实例，并执行搜索查询。 ## 使用 FEDERATED -由于 FEDERATED 引擎的限制以及 Manticore 实现了自定义语法（如 [MATCH](../Searching/Full_text_matching/Basic_usage.md) 子句），实际的 Manticore 查询不能直接用于 FEDERATED 引擎，必须通过“代理”（作为列中的字符串发送）。 +由于 FEDERATED 引擎的限制以及 Manticore 实现了自定义语法如 [MATCH](../Searching/Full_text_matching/Basic_usage.md) 子句，实际的 Manticore 查询不能直接用于 FEDERATED 引擎，必须“代理”（以字符串形式在列中发送）。 -要通过 `FEDERATED` 进行搜索，首先需要创建一个 FEDERATED 引擎表。Manticore 查询将包含在对 FEDERATED 表执行的 `SELECT` 中的 `query` 列中。 +要通过 `FEDERATED` 进行搜索，首先需要创建一个 FEDERATED 引擎表。Manticore 查询将作为 `query` 列中的字符串包含在对 FEDERATED 表执行的 `SELECT` 中。 创建一个兼容 FEDERATED 的 MySQL 表： @@ -34,6 +34,20 @@ CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies'; ```sql Query OK, 0 rows affected (0.00 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE t1 (id INTEGER UNSIGNED NOT NULL, year INTEGER NOT NULL, rating FLOAT, query VARCHAR(1024) NOT NULL, INDEX(query)) ENGINE=FEDERATED DEFAULT CHARSET=utf8 CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies';" +``` + + +```JSON +``` + @@ -61,35 +75,35 @@ SELECT * FROM t1 WHERE query='SELECT * FROM movies WHERE MATCH (\'pie\')'; ``` -唯一固定的映射是 `query` 列。它是必需的，并且必须是唯一附加表的列。 +唯一固定的映射是 `query` 列。它是必需的，并且必须是唯一附带表的列。 -通过 `FEDERATED` 连接的 Manticore 表**必须**是物理表（普通表或实时表）。 +通过 `FEDERATED` 关联的 Manticore 表 **必须** 是物理表（普通表或实时表）。 -FEDERATED 表应具有与远程 Manticore 表属性同名的列，因为它们将按名称绑定到 Manticore 结果集中提供的属性。然而，它可能只映射部分属性，而非全部。 +FEDERATED 表应具有与远程 Manticore 表属性同名的列，因为它们将按名称绑定到 Manticore 结果集中提供的属性。但它可能只映射某些属性，而非全部。 -Manticore 服务器通过用户名 "FEDERATED" 识别来自 FEDERATED 客户端的查询。`CONNECTION` 字符串参数用于指定 Manticore 主机、SQL 端口和通过连接进行查询的表。连接字符串语法如下： +Manticore 服务器通过用户名 "FEDERATED" 识别来自 FEDERATED 客户端的查询。`CONNECTION` 字符串参数用于指定通过该连接进行查询的 Manticore 主机、SQL 端口和表。连接字符串语法如下： ```ini CONNECTION="mysql://FEDERATED@HOST:PORT/DB/TABLENAME" ``` -由于 Manticore 没有数据库的概念，`DB` 字符串可以是任意的，因为 Manticore 会忽略它，但 MySQL 要求在 `CONNECTION` 字符串定义中必须有值。如示例所示，完整的 `SELECT` SQL 查询应放在针对 `query` 列的 WHERE 子句中。 +由于 Manticore 没有数据库的概念，`DB` 字符串可以是任意的，因为 Manticore 会忽略它，但 MySQL 需要在 `CONNECTION` 字符串定义中有一个值。如示例所示，完整的 `SELECT` SQL 查询应放置在对 `query` 列的 WHERE 子句中。 仅支持 `SELECT` 语句，不支持 `INSERT`、`REPLACE`、`UPDATE` 或 `DELETE`。 ### FEDERATED 提示 -一个**非常重要**的注意事项是，让 Manticore 执行排序、过滤和结果集切片要**远远**比增加最大匹配数并在 MySQL 端使用 WHERE、ORDER BY 和 LIMIT 子句更高效。原因有两个。首先，Manticore 实现了多种优化，执行这些任务的性能优于 MySQL。其次，搜索守护进程（searchd）需要打包、传输和解包的数据量更少。 +有一点 **非常重要**，就是让 Manticore 执行排序、过滤和结果集的切片要 **远** 比增加最大匹配数并在 MySQL 端使用 WHERE、ORDER BY 和 LIMIT 子句更高效。原因有两点。首先，Manticore 实现了多种优化，这些任务的性能优于 MySQL。其次，searchd 需要打包、传输及解包的数据更少，减少了 Manticore 与 MySQL 之间的数据传输。 -可以在 FEDERATED 表和其他 MySQL 表之间执行 JOIN。这可以用来检索未存储在 Manticore 表中的信息。 +可以在 FEDERATED 表与其他 MySQL 表之间执行 JOIN。这可用于检索未存储在 Manticore 表中的信息。 ##### SQL: -##### 将基于 MySQL 的表与由 Manticore 提供服务的 FEDERATED 表进行 JOIN 的查询： +##### 对 MySQL 基础表与由 Manticore 提供服务的 FEDERATED 表执行 JOIN 的查询： ```sql SELECT t1.id, t1.year, comments.comment FROM t1 JOIN comments ON t1.id=comments.post_id WHERE query='SELECT * FROM movies WHERE MATCH (\'pie\')'; diff --git a/manual/chinese/Extensions/SphinxSE.md b/manual/chinese/Extensions/SphinxSE.md index 2cea985108..baac28b6f1 100644 --- a/manual/chinese/Extensions/SphinxSE.md +++ b/manual/chinese/Extensions/SphinxSE.md @@ -1,30 +1,30 @@ # SphinxSE -SphinxSE 是一个 MySQL 存储引擎，可以通过 MySQL/MariaDB 服务器的可插拔架构进行编译。 +SphinxSE 是一种 MySQL 存储引擎，可以通过 MySQL/MariaDB 服务器的可插拔架构编译进去。 -尽管名字叫 SphinxSE，但它实际上并不存储任何数据。相反，它作为一个内置客户端，使 MySQL 服务器能够与 `searchd` 通信，执行搜索查询并检索搜索结果。所有的索引和搜索都在 MySQL 之外进行。 +尽管名字叫 SphinxSE，但它*并不*实际存储任何数据。它充当内置客户端，使 MySQL 服务器能够与 `searchd` 通信，执行搜索查询并检索搜索结果。所有索引和搜索都发生在 MySQL 之外。 一些常见的 SphinxSE 应用包括： -* 简化将 MySQL 全文搜索（FTS）应用移植到 Manticore 的过程； -* 使 Manticore 能够与尚无原生 API 的编程语言一起使用； -* 当需要在 MySQL 端进行额外的 Manticore 结果集处理时提供优化（例如，与原始文档表的 JOIN 或额外的 MySQL 端过滤）。 +* 简化将 MySQL 全文搜索 (FTS) 应用移植到 Manticore 的过程； +* 使尚无原生 API 的编程语言能够使用 Manticore； +* 在 MySQL 端需要额外的 Manticore 结果集处理（例如与原始文档表 JOIN 或额外的 MySQL 端过滤）时提供优化。 ## 安装 SphinxSE -您需要获取 MySQL 源代码，准备好后重新编译 MySQL 二进制文件。MySQL 源代码（mysql-5.x.yy.tar.gz）可以从 网站获取。 +你需要获得 MySQL 源代码，准备好后重新编译 MySQL 二进制文件。MySQL 源代码（mysql-5.x.yy.tar.gz）可以从 网站下载。 -### 编译带有 SphinxSE 的 MySQL 5.0.x +### 使用 SphinxSE 编译 MySQL 5.0.x 1. 将 `sphinx.5.0.yy.diff` 补丁文件复制到 MySQL 源代码目录并运行 ```bash $ patch -p1 < sphinx.5.0.yy.diff ``` -如果没有针对您需要构建的具体版本的 .diff 文件，请尝试应用版本号最接近的 .diff。补丁必须能够无拒绝地应用。 -2. 在 MySQL 源代码目录中，运行 +如果没有针对特定版本的 .diff 文件，尝试应用版本号最接近的 .diff 文件。补丁必须无拒绝地应用成功。 +2. 在 MySQL 源代码目录运行 ```bash $ sh BUILD/autorun.sh ``` -3. 在 MySQL 源代码目录中，创建 `sql/sphinx` 目录，并将 Manticore 源代码中的 `mysqlse` 目录下的所有文件复制到该目录。例如： +3. 在 MySQL 源代码目录中，创建 `sql/sphinx` 目录并将 Manticore 源代码中的 `mysqlse` 目录所有文件复制到该目录。示例： ```bash $ cp -R /root/builds/sphinx-0.9.7/mysqlse /root/builds/mysql-5.0.24/sql/sphinx ``` @@ -32,19 +32,19 @@ $ cp -R /root/builds/sphinx-0.9.7/mysqlse /root/builds/mysql-5.0.24/sql/sphinx ```bash $ ./configure --with-sphinx-storage-engine ``` -5. 构建并安装 MySQL： +5. 编译并安装 MySQL： ```bash $ make $ make install ``` -### 编译带有 SphinxSE 的 MySQL 5.1.x +### 使用 SphinxSE 编译 MySQL 5.1.x -1. 在 MySQL 源代码目录中，创建 `storage/sphinx` 目录，并将 Manticore 源代码中的 `mysqlse` 目录下的所有文件复制到该新位置。例如： +1. 在 MySQL 源代码目录中创建 `storage/sphinx` 目录，并将 Manticore 源代码的 `mysqlse` 目录里所有文件复制到此新位置。例如： ```bash $ cp -R /root/builds/sphinx-0.9.7/mysqlse /root/builds/mysql-5.1.14/storage/sphinx ``` -2. 在 MySQL 源代码目录中，运行： +2. 在 MySQL 源代码目录运行： ```bash $ sh BUILD/autorun.sh ``` @@ -52,7 +52,7 @@ $ sh BUILD/autorun.sh ```bash $ ./configure --with-plugins=sphinx ``` -4. 构建并安装 MySQL： +4. 编译并安装 MySQL： ```bash $ make $ make install @@ -63,7 +63,7 @@ $ make install -要验证 SphinxSE 是否已成功编译到 MySQL 中，启动新构建的服务器，运行 MySQL 客户端，并执行 `SHOW ENGINES` 查询。您应该看到所有可用引擎的列表。Manticore 应该存在，且“Support”列应显示“YES”： +要验证 SphinxSE 是否成功编译进 MySQL，启动新构建的服务器，运行 MySQL 客户端，发出 `SHOW ENGINES` 查询。你应该看到所有可用引擎的列表。Manticore 应该在其中，且 "Support" 列显示为 "YES"： @@ -84,13 +84,72 @@ mysql> show engines; 13 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "show engines;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Engine": { + "type": "string" + } + }, + { + "Support": { + "type": "string" + } + }, + { + "Comment": { + "type": "string" + } + }, + { + "Transactions": { + "type": "string" + } + }, + { + "XA": { + "type": "string" + } + }, + { + "Savepoints": { + "type": "string" + } + } + ], + "data": [ + { + "Engine": "MyISAM", + "Support": "DEFAULT", + "Comment": "MyISAM storage engine", + "Transactions": "NO", + "XA": "NO", + "Savepoints": "NO" + } + ] + } +] +``` + ## 使用 SphinxSE -要使用 SphinxSE 进行搜索，您需要创建一个特殊的 ENGINE=SPHINX “搜索表”，然后使用带有全文查询的 `SELECT` 语句，将查询放在查询列的 `WHERE` 子句中。 +要使用 SphinxSE 进行搜索，需要创建一个特殊的 ENGINE=SPHINX “搜索表”，然后对查询列使用带全文查询的 `WHERE` 子句的 `SELECT` 语句。 -以下是示例创建语句和搜索查询： +以下是示例建表语句和搜索查询： ```sql CREATE TABLE t1 @@ -105,77 +164,77 @@ CREATE TABLE t1 SELECT * FROM t1 WHERE query='test it;mode=any'; ``` -在搜索表中，前三列 *必须* 具有以下类型：第 1 列（文档 ID）为 `INTEGER UNSIGNED` 或 `BIGINT`，第 2 列（匹配权重）为 `INTEGER` 或 `BIGINT`，第 3 列（您的查询）为 `VARCHAR` 或 `TEXT`。此映射是固定的；您不能省略这三列中的任何一列，不能更改它们的位置或类型。此外，查询列必须被索引，而其他列应保持未索引。列名被忽略，因此您可以使用任意名称。 +在搜索表中，前三列*必须*具有以下类型：第1列（文档ID）为 `INTEGER UNSIGNED` 或 `BIGINT`，第2列（匹配权重）为 `INTEGER` 或 `BIGINT`，第3列（查询文本）为 `VARCHAR` 或 `TEXT`。此映射固定；不能省略这三列中的任何一列，不能调整顺序，也不能更改类型。此外，查询列必须被索引，其它列应保持未索引。列名被忽略，因此可以使用任意名称。 -附加列必须是 `INTEGER`、`TIMESTAMP`、`BIGINT`、`VARCHAR` 或 `FLOAT`。它们将按名称绑定到 Manticore 结果集中提供的属性，因此它们的名称必须与 `sphinx.conf` 中指定的属性名称匹配。如果 Manticore 搜索结果中没有匹配的属性名称，该列将包含 `NULL` 值。 +额外的列必须是 `INTEGER`、`TIMESTAMP`、`BIGINT`、`VARCHAR` 或 `FLOAT`。它们将按照名称绑定到 Manticore 结果集中提供的属性，因此它们的名称必须与 `sphinx.conf` 中指定的属性名称匹配。如果 Manticore 搜索结果中没有匹配的属性名称，该列的值为 `NULL`。 -特殊的“虚拟”属性名称也可以绑定到 SphinxSE 列。为此，请使用 `_sph_` 替代 `@`。例如，要获取 `@groupby`、`@count` 或 `@distinct` 虚拟属性的值，分别使用 `_sph_groupby`、`_sph_count` 或 `_sph_distinct` 列名。 +特殊的“虚拟”属性名称也可以绑定到 SphinxSE 列。为此使用 `_sph_` 代替 `@`。例如，要获取 `@groupby`、`@count` 或 `@distinct` 虚拟属性的值，分别使用 `_sph_groupby`、`_sph_count` 或 `_sph_distinct` 列名。 -`CONNECTION` 字符串参数用于指定 Manticore 主机、端口和表。如果在 `CREATE TABLE` 中未指定连接字符串，则假定表名为 `*`（即搜索所有表）且为 `localhost:9312`。连接字符串语法如下： +`CONNECTION` 字符串参数用于指定 Manticore 的主机、端口和表名。如果 `CREATE TABLE` 中未指定连接字符串，则假定表名为 `*`（即搜索所有表）且连接到 `localhost:9312`。连接字符串语法如下： ``` CONNECTION="sphinx://HOST:PORT/TABLENAME" ``` -您可以稍后更改默认连接字符串： +你可以稍后更改默认连接字符串： ```sql mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ``` -您也可以在每个查询中覆盖这些参数。 +你也可以针对每次查询覆盖这些参数。 -如示例所示，查询文本和搜索选项都应放在搜索查询列（即第 3 列）的 `WHERE` 子句中。选项用分号分隔，名称和值用等号分隔。可以指定任意数量的选项。可用选项包括： +如示例所示，查询文本和搜索选项均应放在搜索查询列（即第3列）的 `WHERE` 子句中。选项用分号分隔，名称和值用等号分隔。可指定任意多个选项。可用选项有： * query - 查询文本； * mode - 匹配模式。必须是 "all"、"any"、"phrase"、"boolean" 或 "extended" 之一。默认是 "all"； -* sort - 匹配排序模式。必须是 "relevance"、"attr_desc"、"attr_asc"、"time_segments" 或 "extended" 之一。除 "relevance" 外，其他模式后面还需要冒号后的属性名（或 "extended" 的排序子句）： +* sort - 匹配排序模式。必须是 "relevance"、"attr_desc"、"attr_asc"、"time_segments" 或 "extended" 之一。除 "relevance" 外，其他模式需要在冒号后指定属性名称（或 "extended" 的排序子句）： ``` ... WHERE query='test;sort=attr_asc:group_id'; ... WHERE query='test;sort=extended:@weight desc, group_id asc'; ``` -* offset - 结果集偏移量；默认是 0； -* limit - 从结果集中检索的匹配数；默认是 20； -* index - 要搜索的表名： +* offset - 结果集偏移，默认是 0； +* limit - 从结果集中检索的匹配数，默认是 20； +* index - 要搜索的表名列表： ```sql ... WHERE query='test;index=test1;'; ... WHERE query='test;index=test1,test2,test3;'; ``` -* minid, maxid - 匹配的最小和最大文档 ID； -* weights - 赋予 Manticore 全文字段的权重的逗号分隔列表： +* minid, maxid - 要匹配的最小和最大文档ID； +* weights - 分配给 Manticore 全文字段的权重逗号列表： ```sql ... WHERE query='test;weights=1,2,3;'; ``` -* filter, !filter - 逗号分隔的属性名和要匹配的值集合： +* filter, !filter - 逗号分隔的属性名及匹配值集合： ```sql # only include groups 1, 5 and 19 ... WHERE query='test;filter=group_id,1,5,19;'; # exclude groups 3 and 11 ... WHERE query='test;!filter=group_id,3,11;'; ``` -* range, !range - 逗号分隔的（整数或 bigint）Manticore 属性名，以及要匹配的最小和最大值： +* range, !range - 逗号分隔的（整数或 bigint）Manticore 属性名，以及最小和最大匹配值： ```sql # include groups from 3 to 7, inclusive ... WHERE query='test;range=group_id,3,7;'; # exclude groups from 5 to 25 ... WHERE query='test;!range=group_id,5,25;'; ``` -* floatrange, !floatrange - 逗号分隔的（浮点数）Manticore 属性名，以及要匹配的最小和最大值： +* floatrange, !floatrange - 逗号分隔的（浮点）Manticore 属性名，以及最小和最大匹配值： ```sql # filter by a float size ... WHERE query='test;floatrange=size,2,3;'; # pick all results within 1000 meter from geoanchor ... WHERE query='test;floatrange=@geodist,0,1000;'; ``` -* maxmatches - 每查询最大匹配数值，如 [max_matches 搜索选项](../Searching/Options.md#max_matches)： +* maxmatches - 每次查询的最大匹配数，详见 [max_matches 搜索选项](../Searching/Options.md#max_matches)： ```sql ... WHERE query='test;maxmatches=2000;'; ``` -* cutoff - 最大允许匹配数，如 [cutoff 搜索选项](../Searching/Options.md#cutoff)： +* cutoff - 最大允许匹配数，详见 [cutoff 搜索选项](../Searching/Options.md#cutoff)： ```sql ... WHERE query='test;cutoff=10000;'; ``` -* maxquerytime - 最大允许的查询时间（以毫秒为单位），如同 [max_query_time 搜索选项](../Searching/Options.md#max_query_time)： +* maxquerytime - 最大允许的查询时间（以毫秒为单位），如同 [max_query_time 搜索选项](../Searching/Options.md#max_query_time): ```sql ... WHERE query='test;maxquerytime=1000;'; ``` @@ -188,23 +247,23 @@ mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ```sql ... WHERE query='test;groupsort=@count desc;'; ``` -* distinct - 在进行分组时计算 [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) 的属性： +* distinct - 在执行分组时计算 [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) 的属性： ```sql ... WHERE query='test;groupby=attr:country_id;distinct=site_id'; ``` -* indexweights - 用逗号分隔的表名和权重列表，用于在多个表中搜索时使用： +* indexweights - 逗号分隔的表名和权重列表，用于搜索多个表时： ```sql ... WHERE query='test;indexweights=tbl_exact,2,tbl_stemmed,1;'; ``` -* fieldweights - 用逗号分隔的每字段权重列表，可被排序器使用： +* fieldweights - 逗号分隔的每字段权重列表，排名器可以使用： ```sql ... WHERE query='test;fieldweights=title,10,abstract,3,content,1;'; ``` -* comment - 用于在查询日志中标记此查询的字符串，如同 [comment 搜索选项](../Searching/Options.md#comment)： +* comment - 用于在查询日志中标记该查询的字符串，如同 [comment 搜索选项](../Searching/Options.md#comment): ```sql ... WHERE query='test;comment=marker001;'; ``` -* select - 用于计算的表达式字符串： +* select - 要计算的表达式字符串： ```sql ... WHERE query='test;select=2*a+3*** as myexpr;'; ``` @@ -212,12 +271,12 @@ mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ```sql ... WHERE query='test;host=sphinx-test.loc;port=7312;'; ``` -* ranker - 用于“扩展”匹配模式的排名函数，如同 [ranker](../Searching/Options.md#ranker)。已知值包括 "proximity_bm25"、"bm25"、"none"、"wordcount"、"proximity"、"matchany"、"fieldmask"、"sph04"、"expr:EXPRESSION" 语法以支持基于表达式的排名器（其中 EXPRESSION 应替换为您的具体排名公式），以及 "export:EXPRESSION"： +* ranker - 用于“扩展”匹配模式的排名函数，如同 [ranker](../Searching/Options.md#ranker)。已知的值包括 "proximity_bm25"、"bm25"、"none"、"wordcount"、"proximity"、"matchany"、"fieldmask"、"sph04"、“expr:EXPRESSION” 语法用于支持基于表达式的排名器（其中 EXPRESSION 应替换为你的具体排名公式），以及 "export:EXPRESSION"： ```sql ... WHERE query='test;mode=extended;ranker=bm25;'; ... WHERE query='test;mode=extended;ranker=expr:sum(lcs);'; ``` -“export”排名器的功能类似于 ranker=expr，但它保留每个文档的因子值，而 ranker=expr 在计算最终的 `WEIGHT()` 值后会丢弃它们。请注意，ranker=export 旨在偶尔使用，例如训练机器学习（ML）函数或手动定义您自己的排名函数，不应在实际生产中使用。使用此排名器时，您可能希望检查 `RANKFACTORS()` 函数的输出，该函数生成包含每个文档所有字段级因子的字符串。 +"export" 排名器功能类似于 ranker=expr，但它保留每个文档的因子值，而 ranker=expr 在计算最终的 `WEIGHT()` 值后会丢弃它们。请记住，ranker=export 旨在偶尔使用，例如训练机器学习（ML）函数或手动定义自己的排名函数，不应在实际生产环境中使用。使用该排名器时，你可能希望检查 `RANKFACTORS()` 函数的输出，它生成包含每个文档所有字段级别因子的字符串。 @@ -261,19 +320,93 @@ min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT *, WEIGHT(), RANKFACTORS() FROM myindex WHERE MATCH('dog') OPTION ranker=export('100*bm25');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "published": { + "type": "long long" + } + }, + { + "channel_id": { + "type": "long long" + } + }, + { + "title": { + "type": "long long" + } + }, + { + "content": { + "type": "long long" + } + }, + { + "weight()": { + "type": "long long" + } + }, + { + "rankfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 555617, + "published": 1110067331, + "channel_id": 1059819, + "title": 7, + "content": 428, + "weight()": 69900, + "rankfactors()": "bm25=699, bm25a=0.666478, field_mask=2, doc_word_count=1, field1=(lcs=1, hit_count=4, word_count=1, tf_idf=1.038127, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=120, min_best_span_pos=120, exact_hit=0, max_window_hits=1), word1=(tf=4, idf=0.259532)" + }, + { + "id": 555313, + "published": 1108438365, + "channel_id": 1058561, + "title": 8, + "content": 249, + "weight()": 68500, + "rankfactors()": "bm25=685, bm25a=0.675213, field_mask=3, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.259532, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=8, min_best_span_pos=8, exact_hit=0, max_window_hits=1), field1=(lcs=1, hit_count=2, word_count=1, tf_idf=0.519063, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=36, min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532)" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -* geoanchor - 地理距离锚点。更多关于地理搜索的信息请参见 [本节](../Searching/Geo_search.md)。接受4个参数，分别是纬度和经度属性名，以及锚点坐标： +* geoanchor - 地理距离锚点。请在[本节](../Searching/Geo_search.md)了解更多 Geo 搜索内容。接受四个参数，分别为纬度和经度属性名以及锚点坐标： ```sql ... WHERE query='test;geoanchor=latattr,lonattr,0.123,0.456'; ``` -一个**非常重要**的注意事项是，让 Manticore 处理排序、过滤和结果集切片要**高效得多**，而不是增加最大匹配数并在 MySQL 端使用 `WHERE`、`ORDER BY` 和 `LIMIT` 子句。这有两个原因。首先，Manticore 采用多种优化，执行这些任务比 MySQL 更好。其次，searchd 需要打包、传输和 SphinxSE 需要解包的数据量更少。 +一个**非常重要**的注意事项是，让 Manticore 处理排序、过滤和结果集切片比增加最大匹配数并在 MySQL 端使用 `WHERE`、`ORDER BY` 和 `LIMIT` 子句要**高效得多**。原因有二：首先，Manticore 运用多种优化，并能比 MySQL 更好地完成这些任务。其次，searchd 需要打包的数据、传输的数据和 SphinxSE 需要解包的数据都会更少。 -### 使用 SphinxSE 时关于存储字段的重要说明 +### 使用 SphinxSE 时有关存储字段的重要说明 -从版本 5.0.0 起，Manticore 默认存储所有字段。当 Manticore 与 MySQL 或 MariaDB 通过 SphinxSE 一起使用时，通常不需要存储所有字段，因为原始数据已经存储在 MySQL/MariaDB 中。在这种设置中，建议通过设置显式禁用相关 Manticore 表的存储字段： +从版本 5.0.0 起，Manticore 默认存储所有字段。当 Manticore 与 MySQL 或 MariaDB 一起通过 SphinxSE 使用时，存储所有字段通常没有意义，因为原始数据已存储在 MySQL/MariaDB 中。在这种配置下，建议通过设置显式禁用相关 Manticore 表的存储字段： ``` stored_fields = @@ -281,18 +414,18 @@ stored_fields = 请参阅设置参考：[stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields)。 -如果保持默认（存储所有字段），然后通过 SphinxSE 一次选择大量文档，可能会超过引擎的内部限制，并收到类似以下错误： +如果保持默认（存储所有字段）且通过 SphinxSE 一次选择大量文档，可能会超过引擎的内部限制，出现如下错误： "bad searchd response length" -设置 `stored_fields =` 可以避免将大量存储的负载发送回 MySQL/MariaDB，并防止在典型的 SphinxSE 集成中出现此错误。 +设置 `stored_fields =` 可避免将大量存储的负载返回给 MySQL/MariaDB，并防止此错误在典型的 SphinxSE 集成中出现。 ### SHOW ENGINE SPHINX STATUS -您可以使用 `SHOW ENGINE SPHINX STATUS` 语句获取与查询结果相关的更多信息： +你可以使用 `SHOW ENGINE SPHINX STATUS` 语句获取与查询结果相关的更多信息： @@ -312,12 +445,58 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 25, total found: 25, time: 126, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + -您也可以通过状态变量访问此信息。请注意，使用此方法不需要超级用户权限。 +你也可以通过状态变量访问这些信息。请注意，使用此方法无需超级用户权限。 @@ -339,12 +518,63 @@ mysql> SHOW STATUS LIKE 'sphinx_%'; 5 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SHOW STATUS LIKE 'sphinx_%';" +``` + + +```JSON +[ + { + "total": 5, + "error": "", + "warning": "", + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "sphinx_total", + "Value": "25" + }, + { + "Variable_name": "sphinx_total_found", + "Value": "25" + }, + { + "Variable_name": "sphinx_time", + "Value": "126" + }, + { + "Variable_name": "sphinx_word_count", + "Value": "2" + }, + { + "Variable_name": "sphinx_words", + "Value": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + -SphinxSE 搜索表可以与使用其他引擎的表进行连接。以下是使用 example.sql 中的 "documents" 表的示例： +SphinxSE 搜索表可以与使用其他引擎的表进行连接。以下示例使用 example.sql 中的 "documents" 表： @@ -376,14 +606,93 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT content, date_added FROM test.documents docs JOIN t1 ON (docs.id=t1.id) WHERE query="one document;mode=any";" + +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "content": { + "type": "string" + } + }, + { + "docdate": { + "type": "string" + } + } + ], + "data": [ + { + "content": "this is my test document number two", + "docdate": "2006-06-17 14:04:28" + }, + { + "content": "this is my test document number one", + "docdate": "2006-06-17 14:04:28" + } + ] + } +] + +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 2, total found: 2, time: 0, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "one:1:2 document:2:2" + } + ] + } +] +``` + -## 通过 MySQL 构建摘要 +## 通过 MySQL 构建摘要片段 -SphinxSE 还提供了一个 UDF 函数，允许您使用 MySQL 创建摘要。此功能类似于 [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting)，但可以通过 MySQL+SphinxSE 访问。 +SphinxSE 还提供了一个 UDF 函数，允许你通过 MySQL 创建摘要片段。此功能类似于 [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting)，但可通过 MySQL+SphinxSE 访问。 -提供 UDF 的二进制文件名为 `sphinx.so`，应自动构建并安装在与 SphinxSE 一起的适当位置。如果由于某种原因未自动安装，请在构建目录中找到 `sphinx.so` 并复制到您的 MySQL 实例的插件目录。完成后，使用以下语句注册 UDF： +提供此 UDF 的二进制文件名为 `sphinx.so`，应与 SphinxSE 一起自动构建并安装到相应位置。如果因某种原因未自动安装，请在构建目录中找到 `sphinx.so`，并复制到你的 MySQL 实例插件目录。完成后，使用以下语句注册 UDF： ```sql CREATE FUNCTION sphinx_snippets RETURNS STRING SONAME 'sphinx.so'; @@ -393,7 +702,7 @@ CREATE FUNCTION sphinx_snippets RETURNS STRING SONAME 'sphinx.so'; **原型：** function sphinx_snippets ( document, table, words [, options] ); -document 和 words 参数可以是字符串或表列。选项必须像这样指定：`'value' AS option_name`。有关支持的选项列表，请参阅 [高亮部分](../Searching/Highlighting.md)。唯一的 UDF 特定附加选项称为 `sphinx`，允许您指定 searchd 的位置（主机和端口）。 +document 和 words 参数可以是字符串或表列。options 必须以 `'value' AS option_name` 形式指定。支持的选项列表请参照[高亮部分](../Searching/Highlighting.md)。唯一特有的 UDF 额外选项为 `sphinx`，允许指定 searchd 位置（主机和端口）。 使用示例： diff --git a/manual/chinese/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md b/manual/chinese/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md index 3b7b44fdd1..ca305d5cb4 100644 --- a/manual/chinese/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md +++ b/manual/chinese/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md @@ -1,8 +1,8 @@ # 启用和禁用 Buddy 插件 -为了简化对 Buddy 插件的控制，特别是在开发新插件或修改现有插件时，提供了启用和禁用 Buddy 插件的命令。这些命令在运行时临时生效，重启守护进程或执行 Buddy 重置后将恢复默认状态。要永久禁用插件，必须将其移除。 +为了简化对 Buddy 插件的控制，特别是在开发新插件或修改现有插件时，提供了启用和禁用 Buddy 插件的命令。这些命令在运行时临时生效，重新启动守护进程或执行 Buddy 重置后将恢复默认。要永久禁用插件，必须将其删除。 -您需要插件的完全限定包名来启用或禁用它。要查找该名称，可以运行 `SHOW BUDDY PLUGINS` 查询，并在 `package` 字段中查找完全限定名称。例如，`SHOW` 插件的完全限定名称是 `manticoresoftware/buddy-plugin-show`。 +您需要插件的完全限定包名才能启用或禁用它。要查找它，可以运行 `SHOW BUDDY PLUGINS` 查询，并在 `package` 字段中查找完整限定名称。例如，`SHOW` 插件的完全限定名称是 `manticoresoftware/buddy-plugin-show`。 ## ENABLE BUDDY PLUGIN @@ -11,17 +11,26 @@ ENABLE BUDDY PLUGIN ``` -> 注意：`ENABLE BUDDY PLUGIN` 需要 [Manticore Buddy](../../../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。 +> 注意：`ENABLE BUDDY PLUGIN` 需要 [Manticore Buddy](../../../Installation/Manticore_Buddy.md)。如果命令无法执行，请确保已安装 Buddy。 -此命令重新激活先前禁用的 Buddy 插件，使其能够再次处理您的请求。 +此命令重新激活先前禁用的 Buddy 插件，使其再次处理您的请求。 -### 示例 +### SQL 示例 ```sql ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` + + +### JSON 示例 + + +```JSON +POST /sql?mode=raw -d "ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + @@ -31,16 +40,24 @@ ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show DISABLE BUDDY PLUGIN ``` -此命令停用一个活动的 Buddy 插件，阻止其处理任何后续请求。 +此命令停用一个活动的 Buddy 插件，防止其进一步处理任何请求。 -### 示例 +### SQL 示例 ```sql DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` -禁用后，如果尝试执行 `SHOW QUERIES` 命令，将会遇到错误，因为该插件已被禁用。 + +### JSON 示例 + + +```JSON +POST /sql?mode=raw -d "DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + +禁用后，如果尝试执行 `SHOW QUERIES` 命令，将会遇到错误，因为插件已被禁用。 diff --git a/manual/chinese/Functions/Date_and_time_functions.md b/manual/chinese/Functions/Date_and_time_functions.md index a1ed3cbf98..7696c53b01 100644 --- a/manual/chinese/Functions/Date_and_time_functions.md +++ b/manual/chinese/Functions/Date_and_time_functions.md @@ -1,10 +1,10 @@ # 日期和时间函数 -注意，`CURTIME()`、`UTC_TIME()`、`UTC_TIMESTAMP()` 和 `TIMEDIFF()` 可以通过任意转换函数如 `BIGINT()`、`DOUBLE()` 等提升为数值类型。 +注意，`CURTIME()`、`UTC_TIME()`、`UTC_TIMESTAMP()` 和 `TIMEDIFF()` 可以使用任意转换函数如 `BIGINT()`、`DOUBLE()` 等提升为数值类型。 ### NOW() -返回当前时间戳，类型为 INTEGER。 +返回当前时间戳，格式为 INTEGER。 ```sql @@ -18,11 +18,39 @@ select NOW(); | 1615788407 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select NOW();" +``` + +```JSON +[ + { + "columns": [ + { + "now()": { + "type": "long" + } + } + ], + "data": [ + { + "now()": 1615788407 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURTIME() -返回本地时区的当前时间，格式为 `hh:ii:ss`。 +返回本地时区当前时间，格式为 `hh:ii:ss`。 ```sql @@ -36,11 +64,39 @@ select CURTIME(); | 07:06:30 | +-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURTIME();" +``` + +```JSON +[ + { + "columns": [ + { + "CURTIME()": { + "type": "string" + } + } + ], + "data": [ + { + "CURTIME()": "07:06:30" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURDATE() -返回本地时区的当前日期，格式为 `YYYY-MM-DD`。 +返回本地时区当前日期，格式为 `YYYY-MM-DD`。 ```sql @@ -54,11 +110,38 @@ select curdate(); | 2023-08-02 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURDATE();" +``` + +```JSON +[ + { + "columns": [ + { + "CURDATE()": { + "type": "string" + } + } + ], + "data": [ + { + "CURDATE()": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIME() -返回 UTC 时区的当前时间，格式为 `hh:ii:ss`。 +返回 UTC 时区当前时间，格式为 `hh:ii:ss`。 ```sql @@ -72,11 +155,38 @@ select UTC_TIME(); | 06:06:18 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIME();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIME()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIME()": "06:06:18" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIMESTAMP() -返回 UTC 时区的当前时间，格式为 `YYYY-MM-DD hh:ii:ss`。 +返回 UTC 时区当前时间，格式为 `YYYY-MM-DD hh:ii:ss`。 ```sql @@ -90,11 +200,38 @@ select UTC_TIMESTAMP(); | 2021-03-15 06:06:03 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIMESTAMP();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIMESTAMP()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIMESTAMP()": "2021-03-15 06:06:0" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### SECOND() -根据当前时区，从时间戳参数中返回整数秒（范围 0..59）。 +根据当前时区，从时间戳参数中返回秒整数（范围 0..59）。 ```sql @@ -108,11 +245,38 @@ select second(now()); | 52 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select second(now());" +``` + +```JSON +[ + { + "columns": [ + { + "second(now())": { + "type": "long" + } + } + ], + "data": [ + { + "second(now())": 52 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MINUTE() -根据当前时区，从时间戳参数中返回整数分钟（范围 0..59）。 +根据当前时区，从时间戳参数中返回分钟整数（范围 0..59）。 ```sql @@ -126,11 +290,38 @@ select minute(now()); | 5 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select minute(now());" +``` + +```JSON +[ + { + "columns": [ + { + "minute(now())": { + "type": "long" + } + } + ], + "data": [ + { + "minute(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### HOUR() -根据当前时区，从时间戳参数中返回整数小时（范围 0..23）。 +根据当前时区，从时间戳参数中返回小时整数（范围 0..23）。 ```sql @@ -144,11 +335,38 @@ select hour(now()); | 7 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "hour(now())" +``` + +```JSON +[ + { + "columns": [ + { + "hour(now())": { + "type": "long" + } + } + ], + "data": [ + { + "hour(now())": 7 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAY() -根据当前时区，从时间戳参数中返回整数月份中的天数（范围 1..31）。 +根据当前时区，从时间戳参数中返回月份中某日的整数（范围 1..31）。 ```sql @@ -162,11 +380,38 @@ select day(now()); | 15 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select day(now());" +``` + +```JSON +[ + { + "columns": [ + { + "day(now())": { + "type": "long" + } + } + ], + "data": [ + { + "day(now())": 15 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTH() -根据当前时区，从时间戳参数中返回整数月份（范围 1..12）。 +根据当前时区，从时间戳参数中返回月份整数（范围 1..12）。 ```sql @@ -180,11 +425,38 @@ select month(now()); | 3 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select month(now());" +``` + +```JSON +[ + { + "columns": [ + { + "month(now())": { + "type": "long" + } + } + ], + "data": [ + { + "month(now())": 3 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### QUARTER() -根据当前时区，从时间戳参数中返回整数季度（范围 1..4）。 +根据当前时区，从时间戳参数中返回年第几季度的整数（范围 1..4）。 ```sql @@ -198,11 +470,38 @@ select quarter(now()); | 2 | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select quarter(now());" +``` + +```JSON +[ + { + "columns": [ + { + "quarter(now())": { + "type": "long" + } + } + ], + "data": [ + { + "quarter(now())": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEAR() -根据当前时区，从时间戳参数中返回整数年份（范围 1969..2038）。 +根据当前时区，从时间戳参数中返回年份整数（范围 1969..2038）。 ```sql @@ -216,11 +515,38 @@ select year(now()); | 2024 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select year(now());" +``` + +```JSON +[ + { + "columns": [ + { + "year(now())": { + "type": "long" + } + } + ], + "data": [ + { + "year(now())": 2024 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYNAME() -根据当前时区，返回给定时间戳参数的星期名称。 +根据当前时区，返回给定时间戳参数对应的星期几名称。 ```sql @@ -234,11 +560,38 @@ select dayname(now()); | Wednesday | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayname(now());" +``` + +```JSON +[ + { + "columns": [ + { + "dayname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "dayname(now())": "Wednesday" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTHNAME() -根据当前时区，返回给定时间戳参数的月份名称。 +根据当前时区，返回给定时间戳参数对应的月份名称。 ```sql @@ -252,12 +605,39 @@ select monthname(now()); | August | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select monthname(now())" +``` + +```JSON +[ + { + "columns": [ + { + "monthname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "monthname(now())": "August" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFWEEK() -根据当前时区，返回给定时间戳参数的整数星期索引（范围 1..7）。 -注意，星期从星期日开始。 +根据当前时区，返回给定时间戳参数对应的星期几索引（范围 1..7）。 +注意，周日为一周的第一天。 ```sql @@ -271,11 +651,38 @@ select dayofweek(now()); | 5 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofweek(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofweek(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFYEAR() -根据当前时区，返回给定时间戳参数的整数年份中的天数（范围 1..366）。 +根据当前时区，返回给定时间戳参数对应的年度中的第几天整数（范围 1..366）。 ```sql @@ -289,11 +696,38 @@ select dayofyear(now()); | 214 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofyear(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofyear(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofyear(now())": 214 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARWEEK() -根据当前时区，返回给定时间戳参数的当前周第一天的整数年份和日期代码（范围 1969001..2038366）。 +根据当前时区，返回给定时间戳参数对应的当前周第一天的年及日代码整数（范围 1969001..2038366）。 ```sql @@ -307,11 +741,38 @@ select yearweek(now()); | 2023211 | +-----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearweek(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearweek(now())": 2023211 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTH() -根据当前时区，从时间戳参数返回整数年份和月份代码（范围 196912..203801）。 +根据当前时区，从时间戳参数返回年和月份代码整数（范围 196912..203801）。 ```sql @@ -325,11 +786,38 @@ select yearmonth(now()); | 202103 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonth(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonth(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonth(now())": 202103 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTHDAY() -根据当前时区，返回整数年份、月份和日期代码（范围 19691231 到 20380119）。 +根据当前时区，返回整数年、月和日代码（范围从 19691231 到 20380119）。 ```sql @@ -343,11 +831,38 @@ select yearmonthday(now()); | 20210315 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonthday(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonthday(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonthday(now())": 20210315 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIMEDIFF() -计算两个时间戳之间的差值，格式为 `hh:ii:ss`。 +Calculates the difference between two timestamps in the format `hh:ii:ss`. ```sql @@ -361,11 +876,38 @@ select timediff(1615787586, 1613787583); | 555:33:23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select timediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "timediff(1615787586, 1613787583)": { + "type": "string" + } + } + ], + "data": [ + { + "timediff(1615787586, 1613787583)": "555:33:23" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATEDIFF() -计算两个给定时间戳之间的天数。 +Calculates the number of days between two given timestamps. ```sql @@ -379,11 +921,38 @@ select datediff(1615787586, 1613787583); | 23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select datediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "datediff(1615787586, 1613787583)": { + "type": "long long" + } + } + ], + "data": [ + { + "datediff(1615787586, 1613787583)": 23 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE() -将时间戳参数的日期部分格式化为字符串，格式为 `YYYY-MM-DD`。 +Formats the date part from a timestamp argument as a string in `YYYY-MM-DD` format. ```sql @@ -397,11 +966,38 @@ select date(now()); | 2023-08-02 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select date(now());" +``` + +```JSON +[ + { + "columns": [ + { + "date(now())": { + "type": "string" + } + } + ], + "data": [ + { + "date(now())": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIME() -将时间戳参数的时间部分格式化为字符串，格式为 `HH:MM:SS`。 +Formats the time part from a timestamp argument as a string in `HH:MM:SS` format. ```sql @@ -415,21 +1011,48 @@ select time(now()); | 15:21:27 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select time(now());" +``` + +```JSON +[ + { + "columns": [ + { + "time(now())": { + "type": "string" + } + } + ], + "data": [ + { + "time(now())": "15:21:27" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE_FORMAT() -根据提供的日期和格式参数返回格式化字符串。格式参数使用与 [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) 函数相同的格式说明符。为方便起见，以下是一些常用格式说明符： +Returns a formatted string based on the provided date and format arguments. The format argument uses the same specifiers as the [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) function. For convenience, here are some common format specifiers: -- `%Y` - 四位数年份 -- `%m` - 两位数月份（01-12） -- `%d` - 两位数月份中的天数（01-31） -- `%H` - 两位数小时（00-23） -- `%M` - 两位数分钟（00-59） -- `%S` - 两位数秒（00-59） -- `%T` - 24 小时制时间（`%H:%M:%S`） +- `%Y` - Four-digit year +- `%m` - Two-digit month (01-12) +- `%d` - Two-digit day of the month (01-31) +- `%H` - Two-digit hour (00-23) +- `%M` - Two-digit minute (00-59) +- `%S` - Two-digit second (00-59) +- `%T` - Time in 24-hour format (`%H:%M:%S`) -请注意，这不是完整的格式说明符列表。请查阅您操作系统中 `strftime()` 的文档以获取完整列表。 +Note that this is not a complete list of the specifiers. Please consult the documentation for `strftime()` for your operating system to get the full list. ```sql @@ -443,36 +1066,63 @@ SELECT DATE_FORMAT(NOW(), 'year %Y and time %T'); | year 2023 and time 11:54:52 | +------------------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select DATE_FORMAT(NOW(), 'year %Y and time %T');" +``` + +```JSON +[ + { + "columns": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": { + "type": "string" + } + } + ], + "data": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": "year 2023 and time 11:54:52" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` -此示例格式化当前日期和时间，显示四位数的年份和24小时制的时间。 +This example formats the current date and time, displaying the four-digit year and the time in 24-hour format. ### DATE_HISTOGRAM() -`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` 接受一个作为单位名称的桶大小，并返回该值的桶编号。值会被四舍五入到最接近的桶。关键函数是： +`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` Takes a bucket size as a unit name and returns the bucket number for the value. Values are rounded to the closest bucket. The key function is: ```sql key_of_the_bucket = interval * floor ( value / interval ) ``` -间隔可以使用单位名称指定，如 `week`，或作为单个单位，如 `1M`。但是，多个单位，如 `2d`，不支持 `calendar_interval`，但允许使用 `fixed_interval`。 +Intervals can be specified using a unit name, like `week`, or as a single unit, such as `1M`. However, multiple units, like `2d`, are not supported with `calendar_interval` but are allowed with `fixed_interval`. -`calendar_interval` 的有效间隔为： +The valid intervals for `calendar_interval` are: -- `minute`，`1m` -- `hour`，`1h` -- `day`，`1d` -- `week`，`1w`（一周是从周的起始日、小时、分钟、秒到下一周同一天同一时间的间隔） -- `month`，`1M` -- `year`，`1y`（一年是从月的起始日、时间到下一年同一天同一时间的间隔） +- `minute`, `1m` +- `hour`, `1h` +- `day`, `1d` +- `week`, `1w` (a week is the interval between the start day of the week, hour, minute, second and the next week but the same day and time of the week) +- `month`, `1M` +- `year`, `1y` (a year is the interval between the start day of the month, time and the next year but the same day of the month, time) -`fixed_interval` 的有效间隔为： +The valid intervals for `fixed_interval` are: -- `minute`，`2m` -- `hour`，`3h` -- `day`，`5d` +- `minute`, `2m` +- `hour`, `3h` +- `day`, `5d` -用于聚合、`FACET` 和分组。 +Used in aggregation, `FACET`, and grouping. -示例： +Example: ```sql SELECT COUNT(*), @@ -483,13 +1133,13 @@ GROUP BY months ORDER BY months ASC; ### DATE_RANGE() -`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` 接受一组范围，并返回该值的桶编号。 -表达式包括每个范围的 `range_from` 值，但不包括 `range_to` 值。范围可以是开放的——只有 `range_from` 或只有 `range_to`。 -此函数与 [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) 函数的区别在于，`range_from` 和 `range_to` 的值可以用 [日期数学](../Functions/Date_and_time_functions.md#Date-math) 表达式表示。 +`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` takes a set of ranges and returns the bucket number for the value. +The expression includes the `range_from` value and excludes the `range_to` value for each range. The range can be open - having only the `range_from` or only the `range_to` value. +The difference between this and the [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) function is that the `range_from` and `range_to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions. -用于聚合、`FACET` 和分组。 +Used in aggregation, `FACET`, and grouping. -示例： +Example: ```sql SELECT COUNT(*), @@ -498,32 +1148,32 @@ FROM idx_dates GROUP BY points ORDER BY points ASC; ``` -##### 日期数学 +##### Date math -日期数学让您可以直接在搜索中处理日期和时间。它特别适用于处理随时间变化的数据。通过日期数学，您可以轻松完成诸如查找某一时期的条目、分析数据趋势或管理信息何时应被删除等操作。它简化了日期处理，允许您在搜索查询中对给定日期加减时间、将日期四舍五入到最近的时间单位等。 +Date math lets you work with dates and times directly in your searches. It's especially useful for handling data that changes over time. With date math, you can easily do things like find entries from a certain period, analyze data trends, or manage when information should be removed. It simplifies working with dates by letting you add or subtract time from a given date, round dates to the nearest time unit, and more, all within your search queries. -使用日期数学时，您从一个基准日期开始，该日期可以是： -- `now` 表示当前日期和时间， -- 或以 `||` 结尾的特定日期字符串。 +To use date math, you start with a base date, which can be: +- `now` for the current date and time, +- or a specific date string ending with `||`. -然后，您可以用以下操作修改此日期： -- `+1y` 表示加一年， -- `-1h` 表示减一小时， -- `/m` 表示四舍五入到最近的月份。 +Then, you can modify this date with operations like: +- `+1y` to add one year, +- `-1h` to subtract one hour, +- `/m` to round to the nearest month. -您可以在操作中使用以下单位： -- `s` 表示秒， -- `m` 表示分钟， -- `h`（或 `H`）表示小时， -- `d` 表示天， -- `w` 表示周， -- `M` 表示月， -- `y` 表示年。 +You can use these units in your operations: +- `s` for seconds, +- `m` for minutes, +- `h` (or `H`) for hours, +- `d` for days, +- `w` for weeks, +- `M` for months, +- `y` for years. -以下是一些日期数学的示例用法： -- `now+4h` 表示从现在起四小时。 -- `now-2d/d` 表示两天前的时间，四舍五入到最近的一天。 -- `2010-04-20||+2M/d` 表示2010年6月20日，四舍五入到最近的一天。 +Here are some examples of how you might use date math: +- `now+4h` means four hours from now. +- `now-2d/d` is the time two days ago, rounded to the nearest day. +- `2010-04-20||+2M/d` is June 20, 2010, rounded to the nearest day. diff --git a/manual/chinese/Integration/Kafka.md b/manual/chinese/Integration/Kafka.md index 3540df64bc..dc152a54b0 100644 --- a/manual/chinese/Integration/Kafka.md +++ b/manual/chinese/Integration/Kafka.md @@ -1,13 +1,13 @@ # 从 Kafka 同步 -> 注意：此功能需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。 +> 注意：此功能需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果不起作用，请确保已安装 Buddy。 Manticore 支持通过 Kafka 源和物化视图与 [Apache Kafka](https://kafka.apache.org/) 实时数据摄取集成，实现实时数据索引和搜索。目前，**apache/kafka 版本 3.7.0-4.1.0** 已测试并支持。 -开始之前，您需要： -1. **定义源：** 指定 Manticore Search 将读取消息的 Kafka 主题。此设置包括代理的主机、端口和主题名称等详细信息。 -2. **设置目标表：** 选择一个 Manticore 实时表来存储传入的 Kafka 数据。 -3. **创建物化视图：** 设置物化视图（`mv`）以处理从 Kafka 到 Manticore Search 目标表的数据转换和映射。在这里，您将定义字段映射、数据转换以及传入数据流的任何过滤器或条件。 +开始时，您需要： +1. **定义源：** 指定 Manticore Search 将读取消息的 Kafka 主题。此设置包括代理主机、端口和主题名称等详细信息。 +2. **设置目标表：** 选择一个 Manticore 实时表用于存储接收到的 Kafka 数据。 +3. **创建物化视图：** 设置一个物化视图（`mv`）来处理 Kafka 到 Manticore Search 目标表的数据转换和映射。在这里，您将定义字段映射、数据转换及任何传入数据流的过滤器或条件。 ## 源 @@ -17,17 +17,17 @@ Manticore 支持通过 Kafka 源和物化视图与 [Apache Kafka](https://kafka. #### 架构 -使用 Manticore 字段类型定义架构，如 `int`、`float`、`text`、`json` 等。 +使用 Manticore 字段类型如 `int`、`float`、`text`、`json` 等定义架构。 ```sql CREATE SOURCE [(column type, ...)] [source_options] ``` -所有架构键不区分大小写，意味着 `Products`、`products` 和 `PrOdUcTs` 被视为相同。它们都会被转换为小写。 +所有架构键不区分大小写，这意味着 `Products`、`products` 和 `PrOdUcTs` 被视为相同。它们都会被转换为小写。 -如果您的字段名不符合 Manticore Search 允许的 [字段名语法](../Creating_a_table/Data_types.md#Field-name-syntax)（例如，包含特殊字符或以数字开头），则必须定义架构映射。例如，`$keyName` 或 `123field` 在 JSON 中是有效键，但在 Manticore Search 中不是有效字段名。如果尝试使用无效字段名且未正确映射，Manticore 会返回错误，且源创建将失败。 +如果您的字段名称与 Manticore Search 允许的[字段名称语法](../Creating_a_table/Data_types.md#Field-name-syntax)不匹配（例如，包含特殊字符或以数字开头），您必须定义架构映射。例如，`$keyName` 或 `123field` 是 JSON 中有效的键，但在 Manticore Search 中不是有效的字段名称。如果尝试使用无效字段名称且没有适当映射，则 Manticore 会返回错误并且源创建会失败。 -为处理此类情况，请使用以下架构语法将无效字段名映射为有效字段名： +为处理此类情况，请使用以下架构语法将无效字段名称映射为有效名称： ``` allowed_field_name 'original JSON key name with special symbols' type @@ -61,25 +61,47 @@ batch=50 Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE SOURCE kafka (id bigint, term text, abbrev '$abbrev' text, GlossDef json) type='kafka' broker_list='kafka:9092' topic_list='my-data' consumer_group='manticore' num_consumers='2' batch=50" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + #### 选项 -| 选项 | 可接受的值 | 描述 | -|-|----------------|---------------------------------------------------------------------------------------------------------------------| -| `type` | `kafka` | 设置源类型。目前仅支持 `kafka` | -| `broker_list` | `host:port [, ...]` | 指定 Kafka 代理 URL | -| `topic_list` | `string [, ...]` | 列出要消费的 Kafka 主题 | -| `consumer_group`| `string` | 定义 Kafka 消费者组，默认为 `manticore`。 | -| `num_consumers` | `int` | 处理消息的消费者数量。 | -| `partition_list`| `int [, ...]` | 读取的分区列表，[更多信息](../Integration/Kafka.md#Sharding-with-Kafka)。 | -| `batch` | `int` | 处理多少条消息后继续。默认是 `100`；超时则处理剩余消息。 | +| 选项 | 接受值 | 描述 | +|-|----------------|-------------------------------------------------------------------------------------------------------------| +| `type` | `kafka` | 设置源类型。目前仅支持 `kafka` | +| `broker_list` | `host:port [, ...]`| 指定 Kafka 代理 URL | +| `topic_list` | `string [, ...]` | 列出要消费的 Kafka 主题 | +| `consumer_group` | `string` | 定义 Kafka 消费组，默认为 `manticore`。 | +| `num_consumers` | `int` | 处理消息的消费者数量。 | +| `partition_list` | `int [, ...]` | 读取的分区列表，详见[更多](../Integration/Kafka.md#Sharding-with-Kafka)。 | +| `batch` | `int` | 处理消息数目阈值，处理完后才继续。默认是 `100`；超时则处理剩余消息。 | ### 目标表 -目标表是一个常规的实时表，用于存储 Kafka 消息处理的结果。该表应定义以匹配传入数据的架构要求，并针对应用程序的查询性能需求进行优化。有关创建实时表的更多信息，请参阅[这里](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:)。 +目标表是一个常规的实时表，用于存储 Kafka 消息处理的结果。该表应根据传入数据的架构需求定义，并针对应用查询性能需求进行优化。关于创建实时表请阅读[这里](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:)。 @@ -98,15 +120,37 @@ CREATE TABLE destination_kafka Query OK, 0 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE destination_kafka (id bigint, name text, short_name text, received_at text, size multi)" +``` + + + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + ### 物化视图 -物化视图支持对 Kafka 消息进行数据转换。您可以重命名字段，应用 Manticore Search 函数，并执行排序、分组及其他数据操作。 +物化视图支持对 Kafka 消息进行数据转换。您可以重命名字段，应用 Manticore Search 函数，执行排序、分组及其他数据操作。 -物化视图充当一个查询，将数据从 Kafka 源移动到目标表，允许您使用 Manticore Search 语法自定义这些查询。确保 `select` 中的字段与源中的字段匹配。 +物化视图作为从 Kafka 源到目标表的数据转移查询，允许您使用 Manticore Search 语法自定义这些查询。请确保 `select` 中的字段与源中的字段匹配。 ``` CREATE MATERIALIZED VIEW @@ -134,23 +178,45 @@ SELECT id, term as name, abbrev as short_name, Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + -数据以批次方式从 Kafka 传输到 Manticore Search，每次运行后批次被清空。对于跨批次的计算（如 AVG），请谨慎使用，因为批次处理可能导致结果不符合预期。 +数据以批处理方式从 Kafka 传输到 Manticore Search，批次在每次运行后被清空。进行跨批次计算（如 AVG）时请谨慎，因为批次逐批处理可能导致结果不符合预期。 ### 字段映射 以下是基于上述示例的映射表： -| Kafka | 源 | 缓冲区 | 物化视图 | 目标表 | -|-----------------|----------|----------|-----------------------------------|-------------| -| `id` | `id` | `id` | `id` | `id` | -| `term` | `term` | `term` | `term as name` | `name` | -| `unnecessary_key`（我们不感兴趣的） | - | - | | | -| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name`| -| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at`| -| `GlossDef` | `glossdef`| `glossdef`| `glossdef.size as size` | `size` | +| Kafka | 源 | 缓冲区 | 物化视图 | 目标表 | +|------------------------|--------------|----------------|---------------------------------|--------------| +| `id` | `id` | `id` | `id` | `id` | +| `term` | `term` | `term` | `term as name` | `name` | +| `unnecessary_key`（我们不感兴趣的字段） | - | - | | | +| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name` | +| - | - | - | `UTC_TIMESTAMP() as received_at`| `received_at`| +| `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` | ### 列表 @@ -181,6 +247,40 @@ SHOW SOURCES +-------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCES" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "kafka" + } + ] + } +] +``` + @@ -212,6 +312,46 @@ SHOW SOURCE kafka; +--------+-------------------------------------------------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCE kafka" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Source": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + } + ], + "data": [ + { + "Source": "kafka", + "Create Table": "CREATE SOURCE kafka \n(id bigint, term text, abbrev '' text, GlossDef json)\ntype='kafka'\nbroker_list='kafka:9092'\ntopic_list='my-data'\nconsumer_group='manticore'\nnum_consumers='2'\n batch=50" + } + ] + } +] +``` + @@ -236,6 +376,40 @@ SHOW MVS +------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW MVS" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "view_table" + } + ] + } +] +``` + @@ -262,6 +436,52 @@ SHOW MV view_table +------------+--------------------------------------------------------------------------------------------------------+-----------+ ``` + + +##### JSON: + + + +```sql +POST /sql?mode=raw -d "SHOW MV view_table" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "View": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + }, + { + "suspended": { + "type": "string" + } + } + ], + "data": [ + { + "View": "view_table", + "Create Table": "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka", + "suspended": 0 + } + ] + } +] +``` + ### 修改物化视图 @@ -270,9 +490,9 @@ SHOW MV view_table 您可以通过修改物化视图来暂停数据消费。 -如果您移除 `source` 而不删除物化视图，它会自动暂停。重新创建源后，需手动使用 `ALTER` 命令取消暂停物化视图。 +如果您移除 `source` 而不删除物化视图，物化视图会自动暂停。重新创建源后，使用 `ALTER` 命令手动取消暂停物化视图。 -目前，仅支持修改物化视图。要更改 `source` 参数，请删除并重新创建源。 +目前，只能修改物化视图。要更改 `source` 参数，需要删除并重新创建源。 @@ -290,13 +510,35 @@ ALTER MATERIALIZED VIEW view_table suspended=1 Query OK (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "ALTER MATERIALIZED VIEW view_table suspended=1" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + -### 使用 Kafka 进行分片 +### Kafka 分片 -您还可以为每个 Kafka 主题指定 `partition_list`。 -这种方法的主要优点之一是能够通过 Kafka 实现表的 `sharding`（分片）。 -为此，您应为每个分片创建一条独立的链：`source` → `materialized view` → `destination table`： +您也可以为每个 Kafka 主题指定一个 `partition_list`。 +这种方法的主要优点之一是可以通过 Kafka 来实现表的 `分片`。 +要实现这一点，您应该为每个分片创建一条独立的 `source` → `materialized view` → `destination table` 的链： **源：** ```sql @@ -323,31 +565,31 @@ CREATE MATERIALIZED VIEW mv_1 TO destination_shard_1 AS SELECT id, term AS name CREATE MATERIALIZED VIEW mv_2 TO destination_shard_2 AS SELECT id, term AS name FROM kafka_p2; ``` -#### ⚠️ 重要提示： +#### ⚠️ 重要注意事项： -* 在此设置中，重新平衡必须手动管理。 +* 在此设置中，必须手动管理重平衡。 * Kafka 默认不使用轮询（round-robin）策略分发消息。 -* 若要在发送数据时实现类似轮询的分发，请确保您的 Kafka 生产者配置了： +* 要在发送数据时实现类似轮询的分发，请确保您的 Kafka 生产者配置了： * `parse.key=true` * `key.separator={your_delimiter}` -否则，Kafka 会根据其内部规则分发消息，可能导致分区不均。 +否则，Kafka 将根据其内部规则分发消息，可能导致分区不均。 -### 故障排除 +### 故障排查 #### 重复条目 -Kafka 在每个批次后或处理超时后提交偏移量。如果物化视图查询过程中进程意外停止，可能会出现重复条目。为避免此情况，请在您的模式中包含 `id` 字段，使 Manticore Search 能防止表中出现重复。 +Kafka 会在每个批次后或处理超时后提交 offset。如果物化视图查询过程中进程意外停止，可能会看到重复条目。为避免此情况，请在方案中包含 `id` 字段，允许 Manticore Search 防止表中出现重复数据。 ### 内部工作原理 -- **工作线程初始化：** 配置源和物化视图后，Manticore Search 会设置专用工作线程处理来自 Kafka 的数据摄取。 -- **消息映射：** 根据源配置的模式映射消息，将其转换为结构化格式。 -- **批处理：** 将消息分组为批次以提高处理效率。批次大小可根据性能和延迟需求调整。 -- **缓冲：** 映射后的数据批次存储在缓冲表中，以便高效批量操作。 -- **物化视图处理：** 对缓冲表中的数据应用视图逻辑，执行任何转换或过滤。 -- **数据传输：** 处理后的数据随后传输到目标实时表。 -- **清理：** 每个批次处理后清空缓冲表，确保为下一批数据做好准备。 +- **工作线程初始化：** 在配置好源和物化视图后，Manticore Search 会设置专用工作线程来处理来自 Kafka 的数据摄取。 +- **消息映射：** 根据源配置方案映射消息，将其转换为结构化格式。 +- **批处理：** 将消息分组为批次以提高处理效率。批次大小可根据性能和延迟需求进行调整。 +- **缓冲：** 映射后的数据批次存储在缓冲表中，以支持高效的批量操作。 +- **物化视图处理：** 将视图逻辑应用于缓冲表中的数据，执行转换或过滤。 +- **数据传输：** 处理后的数据传输到目标实时表。 +- **清理：** 每批处理完成后清空缓冲表，准备接收下一批数据。 diff --git a/manual/chinese/Listing_tables.md b/manual/chinese/Listing_tables.md index 0f269ff6f6..99aa7e47c7 100644 --- a/manual/chinese/Listing_tables.md +++ b/manual/chinese/Listing_tables.md @@ -1,8 +1,8 @@ -# 列出表 +# 列出表格 -Manticore Search 对表只有单层层级结构。 +Manticore Search 对表格只有单级层级结构。 -与其他数据库管理系统不同，Manticore 中没有将表分组到数据库中的概念。然而，为了与 SQL 方言的互操作性，Manticore 接受 `SHOW DATABASES` 语句，但该语句不会返回任何结果。 +与其他数据库管理系统不同，Manticore 中没有将表格分组到数据库中的概念。然而，为了与 SQL 方言兼容，Manticore 接受 `SHOW DATABASES` 语句，但该语句不会返回任何结果。 ## SHOW TABLES @@ -40,6 +40,56 @@ SHOW TABLES; 5 rows in set (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW TABLES" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "dist", + "Type": "distributed" + }, + { + "Table": "plain", + "Type": "local" + }, + { + "Table": "pq", + "Type": "percolate" + },{ + "Table": "rt", + "Type": "rt" + },{ + "Table": "template", + "Type": "template" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] + +``` + + ```php @@ -158,7 +208,7 @@ utils_api.sql("SHOW TABLES", Some(true)).await -支持可选的 LIKE 子句，用于按名称过滤表。 +支持可选的 LIKE 子句，用于按名称过滤表格。 @@ -181,6 +231,41 @@ SHOW TABLES LIKE 'pro%'; 1 row in set (0.00 sec) ``` + + +```sql +POST /sql?mode=raw -d "SHOW TABLES LIKE 'pro%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "products", + "Type": "distributed" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ```php @@ -302,7 +387,7 @@ utils_api.sql("SHOW TABLES LIKE 'pro%'", Some(true)).await {DESC | DESCRIBE} table_name [ LIKE pattern ] ``` -`DESCRIBE` 语句列出表的列及其相关类型。列包括文档 ID、全文字段和属性。顺序与 `INSERT` 和 `REPLACE` 语句中字段和属性的预期顺序相匹配。列类型包括 `field`、`integer`、`timestamp`、`ordinal`、`bool`、`float`、`bigint`、`string` 和 `mva`。ID 列的类型为 `bigint`。示例： +`DESCRIBE` 语句列出表的列及其关联类型。列包括文档 ID、全文字段和属性。顺序与 `INSERT` 和 `REPLACE` 语句中字段和属性的顺序一致。列类型包括 `field`、`integer`、`timestamp`、`ordinal`、`bool`、`float`、`bigint`、`string` 和 `mva`。ID 列的类型为 `bigint`。示例： ```sql mysql> DESC rt; @@ -323,7 +408,7 @@ mysql> DESC rt; ### SELECT FROM name.@table -你也可以通过执行查询 `select * from .@table` 来查看表结构。此方法的好处是可以使用 `WHERE` 子句进行过滤： +你也可以通过执行查询 `select * from .@table` 查看表结构。此方法的好处是可以使用 `WHERE` 子句进行过滤： ```sql @@ -340,11 +425,29 @@ select * from tbl.@table where type='text'; 1 row in set (0.00 sec) ``` + +```sql +POST /sql?mode=raw -d "select * from tbl.@table where type='text';" +``` + + +```JSON +[{ +"columns":[{"id":{"type":"long long"}},{"field":{"type":"string"}},{"type":{"type":"string"}},{"properties":{"type":"string"}}], +"data":[ +{"id":2,"field":"title","type":"text","properties":"indexed stored"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + -你还可以对 `.@table` 执行许多其他操作，将其视为具有整数和字符串属性列的常规 Manticore 表。 +你也可以对 `.@table` 执行许多其他操作，将其视为包含整数和字符串属性列的常规 Manticore 表。 @@ -354,6 +457,14 @@ select field, properties from tbl.@table where type in ('text', 'uint'); select * from tbl.@table where properties any ('stored'); ``` + + +```JSON +POST /sql?mode=raw -d "select field from tbl.@table;" +POST /sql?mode=raw -d "select field, properties from tbl.@table where type in ('text', 'uint');" +POST /sql?mode=raw -d "select * from tbl.@table where properties any ('stored');" +``` + ## SHOW CREATE TABLE @@ -381,11 +492,33 @@ f text indexed stored ) charset_table='non_cont,cont' morphology='icu_chinese' 1 row in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW CREATE TABLE tbl;" +``` + + +```JSON +[{ +"columns":[{"Table":{"type":"string"}},{"Create Table":{"type":"string"}}], +"data":[ +{"Table":"tbl","Create Table":"CREATE TABLE tbl (\nf text)"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + ### Percolate 表结构 -如果你对 percolate 表使用 `DESC` 语句，它将显示外部表结构，即存储查询的结构。此结构是静态的，所有本地 percolate 表相同： +如果你对 percolate 表执行 `DESC` 语句，它将显示外部表结构，也就是存储查询的结构。该结构是静态的，所有本地 percolate 表都相同： ```sql mysql> DESC pq; @@ -400,7 +533,7 @@ mysql> DESC pq; 4 rows in set (0.00 sec) ``` -如果你想查看预期的文档结构，请使用以下命令： +如果你想查看期望的文档结构，请使用以下命令： `DESC table`： ```sql @@ -415,7 +548,7 @@ mysql> DESC pq TABLE; 3 rows in set (0.00 sec) ``` -同时支持 `desc pq table like ...`，其工作方式如下： +同时支持 `desc pq table like ...`，行为如下： ```sql mysql> desc pq table like '%title%'; diff --git a/manual/chinese/Node_info_and_management/KILL.md b/manual/chinese/Node_info_and_management/KILL.md index c4c049b701..b8caeb5187 100644 --- a/manual/chinese/Node_info_and_management/KILL.md +++ b/manual/chinese/Node_info_and_management/KILL.md @@ -5,7 +5,7 @@ KILL ``` -`KILL` 通过查询的 ID 终止查询的执行，您可以在 [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES) 中找到该 ID。 +`KILL` 通过查询的 ID 终止该查询的执行，您可以在 [SHOW QUERIES](../Node_info_and_management/SHOW_QUERIES.md#SHOW-QUERIES) 中找到该 ID。 ```sql @@ -13,6 +13,18 @@ mysql> KILL 4; Query OK, 1 row affected (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "KILL 4" +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Node_info_and_management/Node_status.md b/manual/chinese/Node_info_and_management/Node_status.md index 723fa6ba5a..ec6e74f610 100644 --- a/manual/chinese/Node_info_and_management/Node_status.md +++ b/manual/chinese/Node_info_and_management/Node_status.md @@ -3,25 +3,25 @@ ## 状态 -查看 Manticore 节点的高级信息最简单的方法是在 MySQL 客户端中运行 `status`。它将显示各种方面的信息，例如： +查看 Manticore 节点高级信息的最简单方法是在 MySQL 客户端中运行 `status`。它将显示有关各个方面的信息，例如： * 当前版本 * 是否启用了 SSL -* 当前 TCP 端口/Unix 套接字 +* 当前的 TCP 端口/Unix 套接字 * 运行时间 -* [线程](../Server_settings/Searchd.md#threads) 数量 -* [队列中的作业](../Server_settings/Searchd.md#jobs_queue_size) 数量 -* 连接数（`clients`） +* 线程数 ([threads](../Server_settings/Searchd.md#threads)) +* 队列中的作业数 ([jobs_queue_size](../Server_settings/Searchd.md#jobs_queue_size)) +* 连接数 (`clients`) * 当前正在处理的任务数 * 自启动以来执行的查询数 -* 队列中的作业数和任务数，按线程数归一化 +* 按线程数归一化的队列中作业数和任务数 -```sql +```mysql mysql> status ``` -```sql +```mysql -------------- mysql Ver 14.14 Distrib 5.7.30, for Linux (x86_64) using EditLine wrapper @@ -58,7 +58,7 @@ SHOW STATUS [ LIKE pattern ] -`SHOW STATUS` 是一个 SQL 语句，显示各种有用的性能计数器。IO 和 CPU 计数器仅在 `searchd` 启动时使用了 `--iostats` 和 `--cpustats` 开关（或通过 `SET GLOBAL iostats/cpustats=1` 启用）时可用。 +`SHOW STATUS` 是一个 SQL 语句，展示各种有用的性能计数器。IO 和 CPU 计数器仅在 `searchd` 使用 `--iostats` 和 `--cpustats` 开关启动时可用（或通过 `SET GLOBAL iostats/cpustats=1` 启用）。 ##### SQL: @@ -151,11 +151,344 @@ SHOW STATUS; +-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+ ``` + +##### JSON: + + +```JSON +SHOW STATUS; +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "uptime", + "Value": "107191" + }, + { + "Counter": "connections", + "Value": "214577" + }, + { + "Counter": "maxed_out", + "Value": "0" + }, + { + "Counter": "version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1) (buddy v3.35.1+25090418-41d9811f-dev)" + }, + { + "Counter": "mysql_version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1)" + }, + { + "Counter": "command_search", + "Value": "47" + }, + { + "Counter": "command_excerpt", + "Value": "3" + }, + { + "Counter": "command_update", + "Value": "0" + }, + { + "Counter": "command_keywords", + "Value": "0" + }, + { + "Counter": "command_persist", + "Value": "0" + }, + { + "Counter": "command_status", + "Value": "361" + }, + { + "Counter": "command_flushattrs", + "Value": "0" + }, + { + "Counter": "command_sphinxql", + "Value": "0" + }, + { + "Counter": "command_ping", + "Value": "0" + }, + { + "Counter": "command_delete", + "Value": "1" + }, + { + "Counter": "command_set", + "Value": "0" + }, + { + "Counter": "command_insert", + "Value": "13" + }, + { + "Counter": "command_replace", + "Value": "0" + }, + { + "Counter": "command_commit", + "Value": "0" + }, + { + "Counter": "command_suggest", + "Value": "0" + }, + { + "Counter": "command_json", + "Value": "0" + }, + { + "Counter": "command_callpq", + "Value": "8" + }, + { + "Counter": "command_cluster", + "Value": "0" + }, + { + "Counter": "command_getfield", + "Value": "0" + }, + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "agent_connect", + "Value": "0" + }, + { + "Counter": "agent_tfo", + "Value": "0" + }, + { + "Counter": "agent_retry", + "Value": "0" + }, + { + "Counter": "queries", + "Value": "44" + }, + { + "Counter": "dist_queries", + "Value": "0" + }, + { + "Counter": "workers_total", + "Value": "8" + }, + { + "Counter": "workers_active", + "Value": "3" + }, + { + "Counter": "workers_clients", + "Value": "1" + }, + { + "Counter": "workers_clients_vip", + "Value": "0" + }, + { + "Counter": "workers_clients_buddy", + "Value": "1" + }, + { + "Counter": "work_queue_length", + "Value": "8" + }, + { + "Counter": "load", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_primary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_secondary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "query_wall", + "Value": "0.007" + }, + { + "Counter": "query_cpu", + "Value": "OFF" + }, + { + "Counter": "dist_wall", + "Value": "0.000" + }, + { + "Counter": "dist_local", + "Value": "0.000" + }, + { + "Counter": "dist_wait", + "Value": "0.000" + }, + { + "Counter": "query_reads", + "Value": "OFF" + }, + { + "Counter": "query_readkb", + "Value": "OFF" + }, + { + "Counter": "query_readtime", + "Value": "OFF" + }, + { + "Counter": "avg_query_wall", + "Value": "0.000" + }, + { + "Counter": "avg_query_cpu", + "Value": "OFF" + }, + { + "Counter": "avg_dist_wall", + "Value": "0.000" + }, + { + "Counter": "avg_dist_local", + "Value": "0.000" + }, + { + "Counter": "avg_dist_wait", + "Value": "0.000" + }, + { + "Counter": "avg_query_reads", + "Value": "OFF" + }, + { + "Counter": "avg_query_readkb", + "Value": "OFF" + }, + { + "Counter": "avg_query_readtime", + "Value": "OFF" + }, + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 75, + "error": "", + "warning": "" + } +] +``` + -支持可选的 `LIKE` 子句，允许您仅选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。 +支持可选的 `LIKE` 子句，允许仅选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符规则，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。 @@ -177,6 +510,61 @@ SHOW STATUS LIKE 'qcache%'; +-----------------------+-------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE 'qcache%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + ```sql @@ -206,26 +594,116 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` ### 查询时间统计 -`SHOW STATUS` 命令提供了 Manticore 中各种性能指标的详细报告，包括插入/替换、搜索和更新查询的查询时间统计。这些统计数据是在 1、5 和 15 分钟的滑动窗口内计算的，显示查询时间的平均值、最小值、最大值以及 95%/99% 百分位值。 +`SHOW STATUS` 命令详细报告了 Manticore 中各种性能指标，包括插入/替换、搜索和更新查询的查询时间统计。这些统计是在 1、5 和 15 分钟的滑动窗口内计算的，显示查询时间的平均值、最小值、最大值以及第 95 和 99 百分位值。 -这些指标有助于跟踪特定时间间隔内的性能，使得更容易发现查询响应时间的趋势并找到可能的瓶颈。 +这些指标有助于跟踪特定时间区间内的性能，更易识别查询响应时间的趋势和潜在瓶颈。 -以下指标是 `SHOW STATUS` 输出的一部分： -- `*_avg`：过去 1、5 和 15 分钟内每种查询类型的平均查询时间。 +以下指标包含在 `SHOW STATUS` 的输出中： +- `*_avg`：每种查询类型在最近 1、5 和 15 分钟内的平均查询时间。 - `*_min`：每种查询类型记录的最短查询时间。 - `*_max`：每种查询类型记录的最长查询时间。 -- `*_pct95`：95% 查询完成所需的时间。 -- `*_pct99`：99% 查询完成所需的时间。 +- `*_pct95`：95% 查询完成时间的上限。 +- `*_pct99`：99% 查询完成时间的上限。 -这些统计数据分别针对插入/替换（`insert_replace_stats_*`）、搜索（`search_stats_*`）和更新（`update_stats_*`）查询提供，详细展示了不同操作的性能。 +这些统计分别针对插入/替换 (`insert_replace_stats_*`)、搜索 (`search_stats_*`) 和更新 (`update_stats_*`) 查询提供，详尽洞察不同操作的性能。 -如果在监控间隔内没有执行查询，系统将显示 `N/A`。 +如果监控间隔内未执行查询，系统将显示 `N/A`。 @@ -256,17 +734,108 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` + ## SHOW SETTINGS -`SHOW SETTINGS` 是一个 SQL 语句，显示配置文件中的当前设置。设置名称以以下格式表示：`'config_section_name'.'setting_name'` +`SHOW SETTINGS` 是一个 SQL 语句，显示配置文件中的当前设置。设置名称格式为：`'config_section_name'.'setting_name'` -结果还包括两个附加值： -- `configuration_file` - 配置文件的路径 -- `worker_pid` - 正在运行的 `searchd` 实例的进程 ID +结果还包括两个额外值： +- `configuration_file` - 配置文件路径 +- `worker_pid` - 运行中的 `searchd` 实例的进程 ID ##### SQL: @@ -298,6 +867,83 @@ SHOW SETTINGS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Setting_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Setting_name": "configuration_file", + "Value": "/etc/manticoresearch/manticore.conf.sh" + }, + { + "Setting_name": "worker_pid", + "Value": 1 + }, + { + "Setting_name": "searchd.listen", + "Value": "9306:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "/var/run/mysqld/mysqld.sock:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "9308:http" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9312" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9315-9325:replication" + }, + { + "Setting_name": "searchd.pid_file", + "Value": "/run/manticore/searchd.pid" + }, + { + "Setting_name": "searchd.data_dir", + "Value": "/var/lib/manticore" + }, + { + "Setting_name": "searchd.binlog_path", + "Value": "/var/lib/manticore/binlog" + }, + { + "Setting_name": "common.plugin_dir", + "Value": "/usr/local/lib/manticore" + } + ], + "total": 11, + "error": "", + "warning": "" + } +] +``` + ## SHOW AGENT STATUS @@ -307,7 +953,7 @@ SHOW AGENT ['agent_or_index'] STATUS [ LIKE pattern ] -`SHOW AGENT STATUS` 显示[远程代理](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent)或分布式表的统计信息。它包括最后请求时间、最后响应时间、各种错误和成功次数等值。统计信息针对每个代理在最近 1、5 和 15 个间隔内显示，每个间隔由 [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) 秒组成。 +`SHOW AGENT STATUS` 显示[远程代理](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent)或分布式表的统计信息。包括上次请求和回答的时间间隔，各类错误和成功次数等。统计信息分别用于过去的 1、5、15 个由 [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) 秒组成的时间段内的每个代理。 ##### SQL: @@ -378,6 +1024,47 @@ SHOW AGENT STATUS; 50 rows in set (0.01 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "status_period_seconds", + "Value": "60" + }, + { + "Key": "status_stored_periods", + "Value": "15" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1022,7 +1709,7 @@ res := apiClient.UtilsAPI.Sql(context.Background()).Body("SHOW AGENT STATUS").Ex -支持可选的 `LIKE` 子句，语法与 `SHOW STATUS` 中相同。 +支持可选的 `LIKE` 子句，其语法与 `SHOW STATUS` 中相同。 ##### SQL: @@ -1044,6 +1731,51 @@ SHOW AGENT STATUS LIKE '%5period%msec%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS LIKE '%5period%msec%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "ag_0_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_1_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_2_5periods_msecsperquery", + "Value": "234.72" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1295,6 +2027,76 @@ SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%'; 9 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql? mode=raw -d "SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "agent_15periods_query_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_failures", + "Value": "0" + }, + { + "Key": "agent_15periods_network_errors", + "Value": "0" + }, + { + "Key": "agent_15periods_wrong_replies", + "Value": "0" + }, + { + "Key": "agent_15periods_unexpected_closings", + "Value": "0" + }, + { + "Key": "agent_15periods_warnings", + "Value": "0" + }, + { + "Key": "agent_15periods_succeeded_queries", + "Value": "439" + }, + { + "Key": "agent_15periods_msecsperquery", + "Value": "231.73" + } + ], + "total": 9, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1615,6 +2417,91 @@ SHOW AGENT dist_index STATUS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT dist_index STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "dstindex_1_is_ha", + "Value": "1" + }, + { + "Key": "dstindex_1mirror1_id", + "Value": "192.168.0.202:6713:loc" + }, + { + "Key": "dstindex_1mirror1_probability_weight", + "Value": "0.372864" + }, + { + "Key": "dstindex_1mirror1_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror1_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_id", + "Value": "192.168.0.202:6714:loc" + }, + { + "Key": "dstindex_1mirror2_probability_weight", + "Value": "0.3746350" + }, + { + "Key": "dstindex_1mirror2_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_id", + "Value": "dev1.manticoresearch.com:6714:loc" + }, + { + "Key": "dstindex_1mirror3_probability_weight", + "Value": "0.252501" + }, + { + "Key": "dstindex_1mirror3_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_is_persistent", + "Value": "0" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/chinese/Node_info_and_management/SHOW_META.md b/manual/chinese/Node_info_and_management/SHOW_META.md index 44f8c7f47f..05f1618991 100644 --- a/manual/chinese/Node_info_and_management/SHOW_META.md +++ b/manual/chinese/Node_info_and_management/SHOW_META.md @@ -5,22 +5,22 @@ SHOW META [ LIKE pattern ] ``` -`SHOW META` 是一个 SQL 语句，用于显示有关处理查询的附加元信息，包括查询时间、关键字统计以及使用的二级索引信息。语法如下： +`SHOW META` 是一个 SQL 语句，用于显示有关处理查询的附加元信息，包括查询时间、关键词统计以及所用二级索引的信息。语法为： -包含的项目有： -* `total`：实际检索并发送给客户端的匹配数。该值通常受 [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results) 搜索选项的限制。 +所包含的项目有： +* `total`：实际检索并发送给客户端的匹配数。此值通常受 [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results) 搜索选项限制。 * `total_found`： - - 索引中查询的估计匹配总数。如果需要精确的匹配数，请使用 `SELECT COUNT(*)`，而不是依赖此值。 - - 对于带有 `GROUP BY` 的查询，`total_found` 表示组的数量，而非单个匹配数。 - - 对于 [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) 查询，`total_found` 仍表示组的数量，无论 `N` 的值是多少。 -* `total_relation`：指示 `total_found` 值是精确的还是估计的。 - - 如果 Manticore 无法确定精确的 `total_found` 值，此字段将显示 `total_relation: gte`，表示实际匹配数**大于或等于**报告的 `total_found`。 - - 如果 `total_found` 值是精确的，则显示 `total_relation: eq`。 -* `time`：处理搜索查询所用的时间（秒）。 -* `keyword[N]`：搜索查询中使用的第 n 个关键字。注意关键字可以是通配符形式，例如 `abc*`。 -* `docs[N]`：包含搜索查询中第 n 个关键字的文档（或记录）总数。如果关键字是通配符形式，此值表示所有展开子关键字的文档总和，可能超过实际匹配文档数。 -* `hits[N]`：第 n 个关键字在所有文档中出现的总次数（命中数）。 -* `index`：所使用索引的信息（例如二级索引）。 + - 索引中查询的估计总匹配数。如果需要精确匹配数，请使用 `SELECT COUNT(*)`，而不要依赖此值。 + - 对于带有 `GROUP BY` 的查询，`total_found` 表示分组数量，而非单个匹配。 + - 对于 [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) 查询，`total_found` 仍然表示分组数，而不管 `N` 的值。 +* `total_relation`：指示 `total_found` 值是精确还是估计。 + - 如果 Manticore 无法确定精确的 `total_found` 值，该字段将显示 `total_relation: gte`，表示实际匹配数 **大于等于** 报告的 `total_found`。 + - 如果 `total_found` 值是精确的，将显示 `total_relation: eq`。 +* `time`：处理搜索查询花费的时长（秒）。 +* `keyword[N]`：搜索查询中使用的第 n 个关键词。注意关键词可以是通配符形式，例如 `abc*`。 +* `docs[N]`：包含搜索查询中第 n 个关键词的文档（或记录）总数。如果关键词是通配符形式，此值表示所有扩展子关键词对应文档的总和，可能大于实际匹配文档数。 +* `hits[N]`：所有文档中第 n 个关键词的总出现次数（或命中数）。 +* `index`：有关使用的索引（例如二级索引）的信息。 ##### SQL: @@ -66,10 +66,140 @@ show meta; 14 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +SELECT id, story_author FROM hn_small WHERE MATCH('one|two|three') and comment_ranking > 2 limit 5; +show meta; +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 151171, + "story_author": "anewkid" + }, + { + "id": 302758, + "story_author": "bks" + }, + { + "id": 805806, + "story_author": "drRoflol" + }, + { + "id": 1099245, + "story_author": "tnorthcutt" + }, + { + "id": 303252, + "story_author": "whiten" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "2308" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + }, + { + "Variable_name": "index", + "Value": "comment_ranking:SecondaryIndex (100%)" + } + ], + "total": 14, + "error": "", + "warning": "" + } +] +``` + -`SHOW META` 可以显示 I/O 和 CPU 计数器，但仅当 searchd 启动时带有 `--iostats` 和 `--cpustats` 参数时才可用。 +`SHOW META` 可以显示 I/O 和 CPU 计数器，但只有当 searchd 启动时分别包含 `--iostats` 和 `--cpustats` 开关时，这些信息才可用。 ##### SQL: @@ -129,10 +259,191 @@ SHOW META; 27 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,channel_id FROM records WHERE MATCH('one|two|three') limit 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "cpu_time", + "Value": "18.004" + }, + { + "Variable_name": "agents_cpu_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_ops", + "Value": "0" + }, + { + "Variable_name": "io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "io_write_ops", + "Value": "0" + }, + { + "Variable_name": "io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_read_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_write_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 27, + "error": "", + "warning": "" + } +] +``` + -额外的值，如 `predicted_time`、`dist_predicted_time`、`local_fetched_docs`、`local_fetched_hits`、`local_fetched_skips` 及其对应的 `dist_fetched_*`，仅在 `searchd` 配置了[预测时间成本](../Server_settings/Searchd.md#predicted_time_costs)且查询的 `OPTION` 子句中包含 `predicted_time` 时可用。 +附加值，如 `predicted_time`、`dist_predicted_time`、`local_fetched_docs`、`local_fetched_hits`、`local_fetched_skips` 及其相应的 `dist_fetched_*` 对应项，只有在 `searchd` 配置了[预测时间成本](../Server_settings/Searchd.md#predicted_time_costs)并且查询的 `OPTION` 子句中包含 `predicted_time` 时才会提供。 ##### SQL: @@ -183,11 +494,152 @@ mysql> show meta; 17 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') limit 5 option max_predicted_time=100; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.012" + }, + { + "Variable_name": "local_fetched_docs", + "Value": "307212" + }, + { + "Variable_name": "local_fetched_hits", + "Value": "407390" + }, + { + "Variable_name": "local_fetched_skips", + "Value": "24" + }, + { + "Variable_name": "predicted_time", + "Value": "56" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 17, + "error": "", + "warning": "" + } +] +``` + -`SHOW META` 必须在**同一**会话中紧接查询之后执行。由于某些 MySQL 连接器/库使用连接池，单独执行 `SHOW META` 可能导致意外结果，例如获取到其他查询的元数据。在这些情况下（且通常推荐），应执行包含查询和 `SHOW META` 的多语句。一些连接器/库支持在同一方法中执行多查询，而其他可能需要专用方法或在连接设置时配置特定选项。 +`SHOW META` 必须在**同一**会话中紧接着查询立即执行。由于某些 MySQL 连接器/库使用连接池，在单独语句中执行 `SHOW META` 可能造成意外结果，例如检索到其他查询的元数据。在这些情况下（并且通常推荐），请执行包含查询和 `SHOW META` 的多语句操作。有些连接器/库支持单个方法中的多查询，而有些则可能需要使用专门的方法或在连接设置时启用特定选项来支持多查询。 ##### SQL: @@ -231,11 +683,136 @@ SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.011" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + -你也可以使用可选的 LIKE 子句，只选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。 +你也可以使用可选的 LIKE 子句，允许你仅选择匹配特定模式的变量。模式语法遵循标准 SQL 通配符，其中 `%` 表示任意数量的任意字符，`_` 表示单个字符。 ##### SQL: @@ -258,13 +835,59 @@ SHOW META LIKE 'total%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW META LIKE 'total%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + -## SHOW META 和 facets +## SHOW META 与 facets -使用[分面搜索](../Searching/Faceted_search.md)时，可以查看 `SHOW META` 输出中的 `multiplier` 字段，以确定优化分组中执行了多少查询。 +当使用[分面搜索](../Searching/Faceted_search.md)时，你可以通过 `SHOW META` 输出中的 `multiplier` 字段，了解优化分组内执行了多少查询。 ##### SQL: @@ -310,15 +933,143 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 1, + "count(*)": 7 + } + ... + ], + "total": 658, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": 10, + "count(*)": 2436 + } + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -## SHOW META 和查询优化器 +## SHOW META 与查询优化器 -当[基于成本的查询优化器](../Searching/Cost_based_optimizer.md)选择使用 `DocidIndex`、`ColumnarScan` 或 `SecondaryIndex` 而非简单过滤器时，`SHOW META` 命令会反映这一点。 +当[基于成本的查询优化器](../Searching/Cost_based_optimizer.md)选择使用 `DocidIndex`、`ColumnarScan` 或 `SecondaryIndex` 替代普通过滤时，`SHOW META` 命令会有所反映。 -`index` 变量显示查询执行期间使用的二级索引的名称和类型。百分比表示使用二级索引的磁盘块数量（RT 表情况）或伪分片数量（普通表情况）。 +`index` 变量显示查询执行期间所用二级索引的名称和类型。百分比表示利用二级索引的磁盘块数量（对于 RT 表）或伪分片数量（对于普通表）。 ##### SQL: @@ -344,21 +1095,92 @@ SHOW META; 5 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT count(*) FROM taxi1 WHERE tip_amount = 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "count(*)": 1 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.016" + }, + { + "Variable_name": "index", + "Value": "tip_amount:SecondaryIndex (100%)" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -## SHOW META 用于 PQ 表 +## SHOW META 针对 PQ 表 -`SHOW META` 可在执行[CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ) 语句后使用，此时输出不同。 +`SHOW META` 可在执行 [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ) 语句后使用，此时它提供不同的输出。 -`CALL PQ` 语句后执行的 `SHOW META` 包含： +紧跟 `CALL PQ` 语句之后的 `SHOW META` 包括： * `total` - 匹配文档所花费的总时间 * `queries_matched` - 匹配文档的存储查询数量 * `document_matches` - 匹配表中存储查询的文档数量 * `total_queries_stored` - 表中存储的查询总数 -* `term_only_queries` - 表中包含词项的查询数量；其余查询使用扩展查询语法。 +* `term_only_queries` - 表中包含词条的查询数量；其余查询使用扩展查询语法。 ##### SQL: @@ -400,11 +1222,11 @@ CALL PQ ('pq', ('{"title":"angry", "gid":3 }')); SHOW META; 它包括以下附加条目： -* `Setup` - 匹配过程初始设置所花费的时间，例如解析文档和设置选项 +* `Setup` - 匹配过程初始设置所花时间，如解析文档和设置选项 * `Queries failed` - 失败的查询数量 -* `Fast rejected queries` - 未完全评估但通过过滤器或其他条件快速匹配并拒绝的查询数量 +* `Fast rejected queries` - 使用过滤器或其他条件快速匹配并拒绝的查询数量，这些查询未被完全评估 * `Time per query` - 每个查询的详细时间 -* `Time of matched queries` - 匹配到任何文档的查询所花费的总时间 +* `Time of matched queries` - 匹配任何文档的查询所花费的总时间 diff --git a/manual/chinese/Node_info_and_management/SHOW_QUERIES.md b/manual/chinese/Node_info_and_management/SHOW_QUERIES.md index 60b87e3e8c..51907000e2 100644 --- a/manual/chinese/Node_info_and_management/SHOW_QUERIES.md +++ b/manual/chinese/Node_info_and_management/SHOW_QUERIES.md @@ -5,14 +5,14 @@ SHOW QUERIES ``` -> 注意：`SHOW QUERIES` 需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果它不起作用，请确保已安装 Buddy。 +> 注意：`SHOW QUERIES` 需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法工作，请确保 Buddy 已安装。 -`SHOW QUERIES` 返回所有当前正在运行的查询的信息。输出是一个具有以下结构的表： +`SHOW QUERIES` 返回所有当前正在运行的查询的信息。输出是一个结构如下的表： -- `id`：查询 ID，可用于 [KILL](../Node_info_and_management/KILL.md) 终止查询 +- `id`：查询 ID，可用于 [KILL](../Node_info_and_management/KILL.md) 中终止查询 - `query`：查询语句或其部分内容 -- `time`：命令执行所用时间或查询执行的时间（在这种情况下，值将包含 `ago`） -- `protocol`：[连接协议](../Server_settings/Searchd.md#listen)，可能的值为 `sphinx`、`mysql`、`http`、`ssl`、`compressed`、`replication`，或组合（例如，`http,ssl` 或 `compressed,mysql`） +- `time`：命令执行所用时间或距查询执行的时间（此情况下，值将包含 `ago`） +- `protocol`： [连接协议](../Server_settings/Searchd.md#listen)，可能的值有 `sphinx`、`mysql`、`http`、`ssl`、`compressed`、`replication`，或组合形式（例如 `http,ssl` 或 `compressed,mysql`） - `host`：客户端的 `ip:port` @@ -32,9 +32,69 @@ mysql> SHOW QUERIES; 2 rows in set (0.61 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW QUERIES;" +``` + + +``` +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "time": { + "type": "string" + } + }, + { + "protocol": { + "type": "string" + } + }, + { + "host": { + "type": "string" + } + } + ], + "data": [ + { + "id": 111, + "query": "select", + "time": "5ms ago", + "protocol": "http", + "host": "127.0.0.1:58986" + }, + { + "id": 96, + "query": "SHOW QUERIES", + "time": "255us", + "protocol": "mysql", + "host": "127.0.0.1:33616" + } + ] + } +] + +``` + -如果您想从线程本身的角度获取信息，请参阅 [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md)。 +如果您想从线程本身的角度了解情况，请参考 [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md)。 diff --git a/manual/chinese/Node_info_and_management/SHOW_VERSION.md b/manual/chinese/Node_info_and_management/SHOW_VERSION.md index 41e99f13f9..1bc5ae636a 100644 --- a/manual/chinese/Node_info_and_management/SHOW_VERSION.md +++ b/manual/chinese/Node_info_and_management/SHOW_VERSION.md @@ -7,7 +7,7 @@ SHOW VERSION > 注意：`SHOW VERSION` 需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。 -`SHOW VERSION` 提供 Manticore Search 实例中各个组件的详细版本信息。该命令对于需要验证所运行的 Manticore Search 版本及其相关组件版本的管理员和开发人员特别有用。 +`SHOW VERSION` 提供 Manticore Search 实例各个组件的详细版本信息。此命令对于需要验证正在运行的 Manticore Search 版本及其相关组件版本的管理员和开发人员尤其有用。 输出表包含两列： - `Component`：此列显示 Manticore Search 的具体组件名称。 @@ -19,17 +19,71 @@ mysql> SHOW VERSION; ``` +```sql ++------------+-------------------------------------+ +| Component | Version | ++------------+-------------------------------------+ +| Daemon | 13.13.4 0bc5a9641@25101507 dev | +| Columnar | columnar 8.1.0 e1522a2@25100213 | +| Secondary | secondary 8.1.0 e1522a2@25100213 | +| Knn | knn 8.1.0 e1522a2@25100213 | +| Embeddings | embeddings 1.0.1 | +| Buddy | buddy v3.35.1+25090418-41d9811f-dev | ++------------+-------------------------------------+ +``` + + +```JSON +POST /sql?mode=raw -d "SHOW VERSION" ``` -+------------+--------------------------------+ -| Component | Version | -+------------+--------------------------------+ -| Daemon | 6.2.13 61cfe38d2@24011520 dev | -| Columnar | columnar 2.2.5 214ce90@240115 | -| Secondary | secondary 2.2.5 214ce90@240115 | -| Knn | knn 2.2.5 214ce90@240115 | -| Embeddings | embeddings 1.0.0 | -| Buddy | buddy v2.0.11 | -+------------+--------------------------------+ + + +```JSON +[ + { + "total": 6, + "error": "", + "warning": "", + "columns": [ + { + "Component": { + "type": "string" + } + }, + { + "Version": { + "type": "string" + } + } + ], + "data": [ + { + "Component": "Daemon", + "Version": "13.13.4 0bc5a9641@25101507 dev" + }, + { + "Component": "Columnar", + "Version": "columnar 8.1.0 e1522a2@25100213" + }, + { + "Component": "Secondary", + "Version": "secondary 8.1.0 e1522a2@25100213" + }, + { + "Component": "Knn", + "Version": "knn 8.1.0 e1522a2@25100213" + }, + { + "Component": "Embeddings", + "Version": "embeddings 1.0.1" + }, + { + "Component": "Buddy", + "Version": "buddy v3.35.1+25090418-41d9811f-dev" + } + ] + } +] ``` diff --git a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md index 7223db1f36..fd455ee282 100644 --- a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md +++ b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md @@ -1,9 +1,9 @@ # SHOW TABLE INDEXES -`SHOW TABLE INDEXES` SQL 语句显示指定表的可用二级索引及其属性。[二级索引](../../Server_settings/Searchd.md#secondary_indexes) 通过创建额外的数据结构来加速特定列的搜索，从而提升查询性能。 +`SHOW TABLE INDEXES` SQL 语句显示指定表可用的二级索引及其属性。[二级索引](../../Server_settings/Searchd.md#secondary_indexes)通过创建额外的数据结构来加速对特定列的搜索，从而提高查询性能。 -语法如下： +语法为： ```sql SHOW TABLE table_name INDEXES @@ -11,12 +11,12 @@ SHOW TABLE table_name INDEXES 显示的属性包括以下列： -* **Name**：二级索引的名称。可用于[查询优化器提示](../../Searching/Options.md#Query-optimizer-hints)。 -* **Type**：二级索引中存储的数据类型。对于普通属性，类型与原始属性类型相同。对于从 JSON 属性生成的二级索引，类型通过扫描所有文档并确定所有 JSON 属性的类型来推断。 -* **Enabled**：指示索引当前是否启用，是否可用于提升搜索速度。当属性被更新时，该属性的二级索引会暂时禁用，直到索引重建。您可以使用[ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index) 命令重建被禁用的索引。 -* **Percent**：在 RT 表中，不同的磁盘块可能包含不同的二级索引，尤其是在使用 JSON 属性时。此百分比显示有多少块包含具有相同名称、类型和启用状态的索引。 +* **Name**：二级索引的名称。可以在[查询优化器提示](../../Searching/Options.md#Query-optimizer-hints)中使用。 +* **Type**：二级索引中存储的数据类型。对于普通属性，类型与原始属性的类型相匹配。对于由 JSON 属性生成的二级索引，类型通过扫描所有文档并确定所有 JSON 属性的类型来推断。 +* **Enabled**：指示索引当前是否启用且可用于提升搜索速度。当属性更新时，该属性的二级索引会暂时被禁用，直到索引被重建。您可以使用[ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index)命令重建被禁用的索引。 +* **Percent**：在 RT 表中，不同的磁盘块可能包含不同的二级索引，特别是在使用 JSON 属性时。此百分比显示有多少块包含相同名称、类型和启用状态的索引。 -> **注意：** 对于 RT 表，二级索引仅为磁盘块创建，不为 RAM 段中的数据创建。当您首次向 RT 表插入数据时，数据保存在 RAM 中，二级索引不会显示。索引仅在数据刷新到磁盘块后可见，默认情况下，当表变为活动状态（同时接收插入和搜索）时会自动刷新。 +> **注意：** 对于 RT 表，二级索引仅为磁盘块创建，而不为 RAM 分段中的数据创建。当您首次将数据插入 RT 表时，数据保留在 RAM 中，且不会显示二级索引。只有在数据被刷新到磁盘块后索引才可见，默认情况下，这会在表变为活动状态（同时接收插入和搜索）时自动发生。 ##### SQL: @@ -64,5 +64,224 @@ SHOW TABLE test INDEXES; +------------------------------+--------+---------+---------+ 29 rows in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE test INDEXES;" +``` + + + +```JSON +[ + { + "columns": [ + { + "Name": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + }, + { + "Enabled": { + "type": "string" + } + }, + { + "Percent": { + "type": "string" + } + } + ], + "data": [ + { + "Name": "j['addresses']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['factor']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['int_arr']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "id", + "Type": "int64", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['price']", + "Type": "float", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['arr']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['str']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['1']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['2']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['3']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + } + ], + "total": 29, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md index 678d099747..0321ecdb14 100644 --- a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md +++ b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md @@ -4,7 +4,7 @@ `SHOW TABLE SETTINGS` 是一个 SQL 语句，用于以与配置文件兼容的格式显示每个表的设置。 -语法为： +语法如下： ```sql SHOW TABLE table_name[.N | CHUNK N] SETTINGS @@ -31,6 +31,43 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE forum SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -56,6 +93,43 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```sql +POST /sql?mode=raw -d "SHOW TABLE forum CHUNK 0 SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md index a681b40a71..f3b8971267 100644 --- a/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md +++ b/manual/chinese/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md @@ -45,13 +45,13 @@ SHOW TABLE table_name STATUS * `max_stack_need`：计算存储的 percolate 查询中最复杂查询所需的栈空间。该值是动态的，取决于构建细节如编译器、优化、硬件等。 * `average_stack_base`：通常在开始计算 percolate 查询时占用的栈空间。 * `desired_thread_stack`：上述值的总和，向上取整到 128 字节边界。如果该值大于 `thread_stack`，则可能无法对该表执行 `call pq`，因为某些存储的查询会失败。默认 `thread_stack` 值为 1M（即 1048576）；其他值应自行配置。 -* `tid` 和 `tid_saved`：表示表的保存状态。`tid` 随每次更改（事务）递增。`tid_saved` 显示保存在 `
.ram` 文件中 RAM 块状态的最大 `tid`。当数字不同时，某些更改仅存在于 RAM 中，并且也由 binlog 备份（如果启用）。执行 `FLUSH TABLE` 或安排定期刷新会保存这些更改。刷新后，binlog 被清除，`tid_saved` 表示新的实际状态。 -* `query_time_*`，`exact_query_time_*`：查询执行时间统计，针对最近 1 分钟、5 分钟、15 分钟和服务器启动以来的总时间；数据封装为 JSON 对象，包括查询次数以及最小、最大、平均、95 和 99 百分位值。 -* `found_rows_*`：查询找到的行数统计；提供最近 1 分钟、5 分钟、15 分钟和服务器启动以来的总时间；数据封装为 JSON 对象，包括查询次数以及最小、最大、平均、95 和 99 百分位值。 +* `tid` 和 `tid_saved`：表示表的保存状态。`tid` 随每次更改（事务）递增。`tid_saved` 显示保存在 `
.ram` 文件的 RAM 块中的状态的最大 `tid`。当两者数字不同时，表示有些更改只存在于 RAM 中，同时也由 binlog 备份（如果已启用）。执行 `FLUSH TABLE` 或定期刷新保存这些更改。刷新后，binlog 被清除，`tid_saved` 表示新的实际状态。 +* `query_time_*`、`exact_query_time_*`：查询执行时间统计，涵盖最近 1 分钟、5 分钟、15 分钟及自服务器启动以来的总计；数据封装为 JSON 对象，包括查询数量及最小、最大、平均、95 和 99 百分位值。 +* `found_rows_*`：查询找到的行数统计，提供最近 1 分钟、5 分钟、15 分钟及自服务器启动以来的总计；数据封装为 JSON 对象，包括查询数量及最小、最大、平均、95 和 99 百分位值。 * `command_*`：针对该表成功执行特定命令的总次数计数器。 -* `search_stats_ms_*`：搜索查询执行时间（毫秒）统计。* 表示时间窗口（例如 1min、5min、15min、total）。这些统计基于 1、5 和 15 分钟的滑动窗口计算，显示查询时间的平均值、最小值、最大值以及 95 和 99 百分位值。 -* `insert_replace_stats_ms_*`：插入和替换查询执行时间（毫秒）统计。* 表示时间窗口（例如 1min、5min、15min、total）。这些统计基于 1、5 和 15 分钟的滑动窗口计算，显示查询时间的平均值、最小值、最大值以及 95 和 99 百分位值。 -* `update_stats_ms_*`：更新查询执行时间（毫秒）统计。* 表示时间窗口（例如 1min、5min、15min、total）。这些统计基于 1、5 和 15 分钟的滑动窗口计算，显示查询时间的平均值、最小值、最大值以及 95 和 99 百分位值。 +* `search_stats_ms_*`：搜索查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。 +* `insert_replace_stats_ms_*`：插入和替换查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。 +* `update_stats_ms_*`：更新查询执行时间（毫秒）统计。* 代表时间窗口（例如 1min、5min、15min、total）。统计基于 1、5、15 分钟滑动窗口，显示查询时间的平均、最小、最大及 95% 和 99% 百分位值。 ##### SQL: @@ -129,6 +129,271 @@ mysql> SHOW TABLE statistic STATUS; 29 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE t STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "table_type", + "Value": "rt" + }, + { + "Variable_name": "indexed_documents", + "Value": "5" + }, + { + "Variable_name": "indexed_bytes", + "Value": "28" + }, + { + "Variable_name": "ram_bytes", + "Value": "23400" + }, + { + "Variable_name": "disk_bytes", + "Value": "1969" + }, + { + "Variable_name": "disk_mapped", + "Value": "196" + }, + { + "Variable_name": "disk_mapped_cached", + "Value": "16384" + }, + { + "Variable_name": "disk_mapped_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_hitlists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_hitlists", + "Value": "0" + }, + { + "Variable_name": "killed_documents", + "Value": "0" + }, + { + "Variable_name": "killed_rate", + "Value": "0.00%" + }, + { + "Variable_name": "ram_chunk", + "Value": "0" + }, + { + "Variable_name": "ram_chunk_segments_count", + "Value": "0" + }, + { + "Variable_name": "disk_chunks", + "Value": "1" + }, + { + "Variable_name": "mem_limit", + "Value": "134217728" + }, + { + "Variable_name": "mem_limit_rate", + "Value": "95.00%" + }, + { + "Variable_name": "ram_bytes_retired", + "Value": "0" + }, + { + "Variable_name": "optimizing", + "Value": "0" + }, + { + "Variable_name": "locked", + "Value": "0" + }, + { + "Variable_name": "tid", + "Value": "7" + }, + { + "Variable_name": "tid_saved", + "Value": "7" + }, + { + "Variable_name": "query_time_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_total", + "Value": "{\"queries\":30, \"avg_sec\":0.324, \"min_sec\":0.051, \"max_sec\":1.718, \"pct95_sec\":1.017, \"pct99_sec\":1.718}" + }, + { + "Variable_name": "found_rows_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_total", + "Value": "{\"queries\":30, \"avg\":2, \"min\":0, \"max\":5, \"pct95\":5, \"pct99\":5}" + }, + { + "Variable_name": "command_search", + "Value": "30" + }, + { + "Variable_name": "command_excerpt", + "Value": "3" + }, + { + "Variable_name": "command_update", + "Value": "0" + }, + { + "Variable_name": "command_keywords", + "Value": "0" + }, + { + "Variable_name": "command_status", + "Value": "1" + }, + { + "Variable_name": "command_delete", + "Value": "1" + }, + { + "Variable_name": "command_insert", + "Value": "6" + }, + { + "Variable_name": "command_replace", + "Value": "0" + }, + { + "Variable_name": "command_commit", + "Value": "0" + }, + { + "Variable_name": "command_suggest", + "Value": "0" + }, + { + "Variable_name": "command_callpq", + "Value": "0" + }, + { + "Variable_name": "command_getfield", + "Value": "0" + }, + { + "Variable_name": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 58, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/chinese/Searching/Faceted_search.md b/manual/chinese/Searching/Faceted_search.md index c961ae640f..500e0d9f08 100644 --- a/manual/chinese/Searching/Faceted_search.md +++ b/manual/chinese/Searching/Faceted_search.md @@ -1,18 +1,18 @@ # 分面搜索 -分面搜索对于现代搜索应用程序来说，与[自动完成](../Searching/Autocomplete.md)、[拼写纠正](../Searching/Spell_correction.md)和搜索关键词[高亮](../Searching/Highlighting.md)一样重要，尤其是在电子商务产品中。 +分面搜索对于现代搜索应用程序而言，与[自动完成](../Searching/Autocomplete.md)、[拼写纠正](../Searching/Spell_correction.md)和搜索关键词[高亮显示](../Searching/Highlighting.md)一样重要，特别是在电子商务产品中。 ![分面搜索](faceted.png) -当处理大量数据和各种相互关联的属性（如尺寸、颜色、制造商或其他因素）时，分面搜索非常有用。在查询大量数据时，搜索结果通常包含许多不符合用户期望的条目。分面搜索使最终用户能够明确指定他们希望搜索结果满足的条件。 +在处理大量数据和各种相互关联的属性（如尺寸、颜色、制造商或其他因素）时，分面搜索非常有用。在查询大量数据时，搜索结果通常包含许多不符合用户期望的条目。分面搜索使最终用户能够明确指定他们希望搜索结果满足的条件。 -在 Manticore Search 中，有一种优化方法可以维护原始查询的结果集，并在每个分面计算中重用它。由于聚合应用于已经计算好的文档子集，因此速度很快，总执行时间通常仅比初始查询稍长。分面可以添加到任何查询中，分面可以是任何属性或表达式。分面结果包括分面值和分面计数。可以使用 SQL `SELECT` 语句通过在查询末尾声明分面来访问分面。 +在 Manticore Search 中，有一种优化方法保持原始查询的结果集，并将其重用于每个分面计算。由于聚合应用于已经计算好的文档子集，因此它们执行得很快，总执行时间通常只比初始查询稍长。分面可以添加到任何查询中，分面可以是任何属性或表达式。分面结果包括分面值和分面计数。可以通过 SQL 的 `SELECT` 语句在查询末尾声明来访问分面。 ## 聚合 ### SQL -分面值可以来自属性、JSON 属性中的 JSON 属性，或表达式。分面值也可以被别名化，但**别名必须在所有结果集中唯一**（主查询结果集和其他分面结果集）。分面值来源于聚合的属性/表达式，但也可以来自另一个属性/表达式。 +分面值可以来自属性、JSON 属性中的 JSON 属性，或表达式。分面值也可以被别名，但**别名必须在所有结果集中唯一**（包括主查询结果集和其他分面结果集）。分面值来源于聚合的属性/表达式，但也可以来自另一个属性/表达式。 ```sql FACET {expr_list} [BY {expr_list} ] [DISTINCT {field_name}] [ORDER BY {expr | FACET()} {ASC | DESC}] [LIMIT [offset,] count] @@ -41,11 +41,11 @@ FACET {expr_list} [BY {expr_list} ] [DISTINCT {field_name}] [ORDER BY {expr | FA 其中： * `group name` 是分配给聚合的别名 -* `field` 值必须包含被分面的属性或表达式的名称 -* 可选的 `size` 指定结果中包含的最大桶数。如果未指定，则继承主查询的限制。更多细节可见[分面结果大小](../Searching/Faceted_search.md#Size-of-facet-result)部分。 +* `field` 的值必须包含被分面的属性或表达式名称 +* 可选的 `size` 指定结果中包含桶的最大数量。如果未指定，则继承主查询的限制。更多细节可参见[分面结果的大小](../Searching/Faceted_search.md#Size-of-facet-result)部分。 * 可选的 `sort` 指定一个属性和/或附加属性的数组，使用与[主查询中的“sort”参数](../Searching/Sorting_and_ranking.md#Sorting-via-JSON)相同的语法。 -结果集将包含一个 `aggregations` 节点，返回的分面中，`key` 是聚合值，`doc_count` 是聚合计数。 +结果集将包含一个 `aggregations` 节点及返回的分面，其中 `key` 是聚合值，`doc_count` 是聚合计数。 ``` json "aggregations": { @@ -761,7 +761,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea ### 通过另一个属性的聚合进行分面 -数据可以通过聚合另一个属性或表达式进行分面。例如，如果文档同时包含品牌 ID 和名称，我们可以在分面中返回品牌名称，但聚合品牌 ID。这可以通过使用 `FACET {expr1} BY {expr2}` 来实现。 +数据可以通过聚合另一个属性或表达式进行分面。例如，如果文档同时包含品牌 id 和名称，我们可以在分面中返回品牌名称，但以品牌 id 进行聚合。这可以通过使用 `FACET {expr1} BY {expr2}` 来实现。 @@ -803,17 +803,101 @@ SELECT * FROM facetdemo FACET brand_name by brand_id; 10 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name, brand_id FROM facetdemo FACET brand_name by brand_id;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "brand_id": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Ten", + "brand_id": 10 + }, + ... + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Nine", + "brand_id": 9 + } + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "count(*)": 1013 + }, + { + "brand_name": "Brand Ten", + "count(*)": 998 + }, + { + "brand_name": "Brand Eight", + "count(*)": 1033 + }, + { + "brand_name": "Brand Seven", + "count(*)": 965 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + -### 去重分面 +### 分面去重 -如果需要从 FACET 返回的桶中去除重复项，可以使用 `DISTINCT field_name`，其中 `field_name` 是你想要进行去重的字段。如果对分布式表进行 FACET 查询且不确定表中是否有唯一 ID（表应为本地且具有相同的模式），也可以使用 `id`（默认值）。 +如果需要从 FACET 返回的桶中去重，可以使用 `DISTINCT field_name`，其中 `field_name` 是用于去重的字段。如果对分布式表进行 FACET 查询而不确定表中是否有唯一 id（表应为本地且具有相同的模式），那么 `field_name` 可以是 `id`（默认）。 -如果查询中有多个 FACET 声明，`field_name` 应在所有声明中保持一致。 +如果查询中有多个 FACET 声明，`field_name` 应该在所有声明中保持一致。 -`DISTINCT` 会在 `count(*)` 列之前返回一个额外的列 `count(distinct ...)`，允许你同时获得两种结果，而无需进行另一次查询。 +`DISTINCT` 会在 `count(*)` 列之前返回额外的 `count(distinct ...)` 列，允许你在不需要另一个查询的情况下获取这两种结果。 ##### SQL: @@ -951,7 +1035,7 @@ POST /sql -d 'SELECT brand_name, property FROM facetdemo FACET brand_name distin ### 基于表达式的分面 -分面可以基于表达式进行聚合。一个经典的例子是按特定区间对价格进行分段： +分面可以对表达式进行聚合。一个经典的例子是按特定区间对价格进行分段： @@ -1525,9 +1609,9 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -### Facet over multi-level grouping +### 多层分组的 Facet -Facets can aggregate over multi-level grouping, with the result set being the same as if the query performed a multi-level grouping: +Facet 可以对多层分组进行聚合，结果集与查询执行多层分组的结果相同： @@ -1563,20 +1647,104 @@ FACET price_range AS price_range,brand_name ORDER BY brand_name asc; | 1 | Brand Four | 195 | ... ``` + + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name,INTERVAL(price,200,400,600,800) AS price_range FROM facetdemo +FACET price_range AS price_range,brand_name ORDER BY brand_name asc;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "price_range": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "price_range": 1 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "fprice_range": { + "type": "long" + } + }, + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "fprice_range": 1, + "brand_name": "Brand Eight", + "count(*)": 197 + }, + { + "fprice_range": 4, + "brand_name": "Brand Eight", + "count(*)": 235 + }, + ... + { + "fprice_range": 0, + "brand_name": "Brand Five", + "count(*)": 183 + }, + { + "fprice_range": 1, + "brand_name": "Brand Four", + "count(*)": 195 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + -### Facet over histogram values +### 基于直方图值的 Facet -Facets can aggregate over histogram values by constructing fixed-size buckets over the values. -The key function is: +Facet 能够通过在值上构建固定大小的桶对直方图值进行聚合。 +关键函数为： ```sql key_of_the_bucket = interval + offset * floor ( ( value - offset ) / interval ) ``` -The histogram argument `interval` must be positive, and the histogram argument `offset` must be positive and less than `interval`. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys. +直方图参数 `interval` 必须为正数，直方图参数 `offset` 必须为正数且小于 `interval`。默认情况下，桶作为数组返回。直方图参数 `keyed` 将响应变为带有桶键的字典。 @@ -1708,17 +1876,17 @@ POST /search -d ' -### Facet over histogram date values +### 基于直方图日期值的 Facet -Facets can aggregate over histogram date values, which is similar to the normal histogram. The difference is that the interval is specified using a date or time expression. Such expressions require special support because the intervals are not always of fixed length. Values are rounded to the closest bucket using the following key function: +Facet 可以对直方图日期值进行聚合，这与普通直方图类似。区别在于间隔使用日期或时间表达式指定。此类表达式需要特殊支持，因为间隔长度并不总是固定的。值使用以下关键函数四舍五入至最近的桶： ```sql key_of_the_bucket = interval * floor ( value / interval ) ``` -The histogram parameter `calendar_interval` understands months to have different amounts of days. -Unlike `calendar_interval`, the `fixed_interval` parameter uses a fixed number of units and does not deviate, regardless of where it falls on the calendar. However `fixed_interval` cannot process units such as months because a month is not a fixed quantity. Attempting to specify units like weeks or months for `fixed_interval` will result in an error. -The accepted intervals are described in the [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29) expression. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys. +直方图参数 `calendar_interval` 理解月份天数不同。 +与 `calendar_interval` 不同，`fixed_interval` 参数使用固定数量的单位，且不会偏移，无论其在日历中的位置如何。然而，`fixed_interval` 无法处理诸如月份之类的单位，因为月份不是固定的数量。尝试为 `fixed_interval` 指定诸如周或月的单位将导致错误。 +接受的间隔在 [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29) 表达式中有描述。默认情况下，桶作为数组返回。直方图参数 `keyed` 将响应变为带有桶键的字典。 @@ -1799,10 +1967,10 @@ POST /search -d ' -### Facet over set of ranges +### 基于一组范围的 Facet -Facets can aggregate over a set of ranges. The values are checked against the bucket range, where each bucket includes the `from` value and excludes the `to` value from the range. -Setting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array. +Facet 可以对一组范围进行聚合。值会与桶区间进行对比，每个桶包含 `from` 值，但不包含 `to` 值。 +将 `keyed` 属性设置为 `true` 会使响应变成以桶键为键的字典，而不是数组。 @@ -1942,9 +2110,9 @@ POST /search -d ' -### Facet over set of date ranges +### 基于一组日期范围的 Facet -Facets can aggregate over a set of date ranges, which is similar to the normal range. The difference is that the `from` and `to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions. This aggregation includes the `from` value and excludes the `to` value for each range. Setting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array. +Facet 可以对一组日期范围进行聚合，这与普通的范围类似。区别在于 `from` 和 `to` 值可以用[日期数学](../Functions/Date_and_time_functions.md#Date-math)表达式表示。此聚合包含每个范围的 `from` 值，但不包含 `to` 值。将 `keyed` 属性设置为 `true` 会使响应变成以桶键为键的字典，而不是数组。 @@ -2035,9 +2203,9 @@ POST /search -d ' -### Ordering in facet result +### Facet 结果中的排序 -Facets support the `ORDER BY` clause just like a standard query. Each facet can have its own ordering, and the facet ordering doesn't affect the main result set's ordering, which is determined by the main query's `ORDER BY`. Sorting can be done on attribute name, count (using `COUNT(*)`, `COUNT(DISTINCT attribute_name)`), or the special `FACET()` function, which provides the aggregated data values. By default, a query with `ORDER BY COUNT(*)` will sort in descending order. +Facet 支持 `ORDER BY` 子句，就像标准查询一样。每个 Facet 可以有自己的排序，Facet 的排序不会影响主结果集的排序，主结果的排序由主查询中的 `ORDER BY` 决定。排序可以基于属性名、计数（使用 `COUNT(*)`，`COUNT(DISTINCT attribute_name)`），或特殊的 `FACET()` 函数，它提供聚合的数据值。默认情况下，使用 `ORDER BY COUNT(*)` 的查询将按降序排序。 @@ -2220,11 +2388,11 @@ POST /search -d ' -### Size of facet result +### Facet 结果的大小 -By default, each facet result set is limited to 20 values. The number of facet values can be controlled with the `LIMIT` clause individually for each facet by providing either a number of values to return in the format `LIMIT count` or with an offset as `LIMIT offset, count`. +默认情况下，每个 Facet 结果集限制为 20 个值。每个 Facet 的返回值数量可以通过 `LIMIT` 子句单独控制，格式为 `LIMIT count` 返回指定数量的值，或 `LIMIT offset, count` 以偏移量和数量返回。 -The maximum facet values that can be returned is limited by the query's `max_matches` setting. If you want to implement dynamic `max_matches` (limiting `max_matches` to offset + per page for better performance), it must be taken into account that a too low `max_matches` value can affect the number of facet values. In this case, a minimum `max_matches` value should be used that is sufficient to cover the number of facet values. +返回的最大 Facet 值受查询的 `max_matches` 设置限制。如果你想实现动态的 `max_matches`（将 `max_matches` 限制为偏移量加每页数量以提高性能），必须考虑到过低的 `max_matches` 可能会影响 Facet 值的数量。在这种情况下，应使用足以涵盖 Facet 值数量的最小 `max_matches` 值。 ##### SQL: @@ -2816,17 +2984,17 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea ``` -### 返回的结果集 +### Returned result set -使用 SQL 时，带有分面的搜索会返回多个结果集。所使用的 MySQL 客户端/库/连接器**必须**支持多个结果集，才能访问分面结果集。 +When using SQL, a search with facets returns multiple result sets. The MySQL client/library/connector used **must** support multiple result sets in order to access the facet result sets. -### 性能 +### Performance -在内部，`FACET` 是执行多查询的简写，其中第一个查询包含主搜索查询，批次中的其余查询各自包含一个聚类。与多查询的情况一样，通用查询优化可以应用于分面搜索，这意味着搜索查询只执行一次，分面操作基于搜索查询结果，每个分面只为总查询时间增加一小部分时间。 +Internally, the `FACET` is a shorthand for executing a multi-query where the first query contains the main search query and the rest of the queries in the batch have each a clustering. As in the case of multi-query, the common query optimization can kick in for a faceted search, meaning the search query is executed only once, and the facets operate on the search query result, with each facet adding only a fraction of time to the total query time. -要检查分面搜索是否以优化模式运行，可以查看[查询日志](../Logging/Query_logging.md)，所有记录的查询都会包含一个 `xN` 字符串，其中 `N` 是在优化组中运行的查询数量。或者，您可以检查[SHOW META](../Node_info_and_management/SHOW_META.md) 语句的输出，它会显示一个 `multiplier` 指标： +To check if the faceted search ran in an optimized mode, you can look in the [query log](../Logging/Query_logging.md), where all logged queries will contain an `xN` string, where `N` is the number of queries that ran in the optimized group. Alternatively, you can check the output of the [SHOW META](../Node_info_and_management/SHOW_META.md) statement, which will display a `multiplier` metric: @@ -2870,6 +3038,132 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 306, + "count(*)": 7 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": "10,11", + "count(*)": 2436 + }, + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Searching/Full_text_matching/Basic_usage.md b/manual/chinese/Searching/Full_text_matching/Basic_usage.md index caa697c1b8..36c4743a65 100644 --- a/manual/chinese/Searching/Full_text_matching/Basic_usage.md +++ b/manual/chinese/Searching/Full_text_matching/Basic_usage.md @@ -1,14 +1,14 @@ # MATCH -`MATCH` 子句允许在文本字段中进行全文搜索。输入的查询字符串会使用与索引时应用于文本的相同设置进行[分词](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md)。除了对输入文本的分词外，查询字符串还支持多种[全文操作符](../../Searching/Full_text_matching/Operators.md)，这些操作符对关键词如何提供有效匹配施加各种规则。 +`MATCH` 子句允许在文本字段中进行全文搜索。输入的查询字符串会使用与索引期间应用于文本的相同设置进行[分词](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md)。除了对输入文本的分词外，查询字符串还支持许多[全文操作符](../../Searching/Full_text_matching/Operators.md)，用于规定关键字应如何提供有效匹配的各种规则。 -全文匹配子句可以与属性[过滤器](../../Searching/Filters.md)以 AND 布尔关系组合。**不支持全文匹配与属性过滤器之间的 OR 关系**。 +全文匹配子句可以与属性[过滤器](../../Searching/Filters.md)组合，作为 AND 布尔关系。**全文匹配与属性过滤器之间不支持 OR 关系**。 -匹配查询总是在过滤过程的第一步执行，随后是[属性过滤器](../../Searching/Filters.md)。属性过滤器应用于匹配查询的结果集。没有匹配子句的查询称为全表扫描。 +匹配查询总是在过滤过程中首先执行，随后是[属性过滤器](../../Searching/Filters.md)。属性过滤器应用于匹配查询的结果集。没有 MATCH 子句的查询称为全表扫描（fullscan）。 `SELECT` 子句中最多只能有一个 `MATCH()`。 -使用[全文查询语法](../../Searching/Full_text_matching/Operators.md)时，匹配会在文档的所有已索引文本字段中执行，除非表达式要求在某个字段内匹配（如短语搜索）或被字段操作符限制。 +使用[全文查询语法](../../Searching/Full_text_matching/Operators.md)时，匹配会跨文档的所有已索引文本字段执行，除非表达式要求在某字段内匹配（如短语搜索）或受字段操作符所限制。 在使用[JOIN](../../Searching/Joining.md)查询时，`MATCH()` 可以接受一个可选的第二个参数，指定全文搜索应应用于哪个表。默认情况下，全文查询应用于 `JOIN` 操作中的左表： @@ -16,7 +16,7 @@ SELECT * FROM table1 LEFT JOIN table2 ON table1.id = table2.id WHERE MATCH('search query', table2); ``` -这允许你在连接操作中对特定表执行全文搜索。有关使用 MATCH 与 JOIN 的更多详细信息，请参见[连接表](../../Searching/Joining.md)部分。 +这允许你在连接操作中针对特定表执行全文搜索。有关在 JOIN 中使用 MATCH 的更多详细信息，请参见[连接表](../../Searching/Joining.md)部分。 ## SQL @@ -26,10 +26,10 @@ SELECT * FROM table1 LEFT JOIN table2 ON table1.id = table2.id WHERE MATCH('sear MATCH('search query' [, table_name]) ``` - `'search query'`：全文搜索查询字符串，可以包含各种[全文操作符](../../Searching/Full_text_matching/Operators.md)。 -- `table_name`：（可选）应用全文搜索的表名，在 `JOIN` 查询中用于指定不同于默认左表的表。 +- `table_name`：（可选）要应用全文搜索的表名，用于 `JOIN` 查询中指定不同于默认左表的表。 -[SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) 语句使用 [MATCH](../../Searching/Full_text_matching/Basic_usage.md) 子句，必须位于 WHERE 之后，用于执行全文搜索。`MATCH()` 接受一个输入字符串，其中所有[全文操作符](../../Searching/Full_text_matching/Operators.md)均可用。 +[SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) 语句使用 [MATCH](../../Searching/Full_text_matching/Basic_usage.md) 子句，必须放在 WHERE 之后，用于执行全文搜索。`MATCH()` 接受输入字符串，其中所有[全文操作符](../../Searching/Full_text_matching/Operators.md)都可用。 @@ -52,8 +52,54 @@ SELECT * FROM myindex WHERE MATCH('"find me fast"/2'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM myindex WHERE MATCH('"find me fast"/2');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "gid": 11, + "title": "first find me" + }, + { + "id": 1, + "gid": 12, + "title": "second find me" + }, + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -使用 MATCH 和 WHERE 过滤器的更复杂查询示例。 +一个使用 MATCH 和 WHERE 过滤器进行更复杂查询的示例。 ```sql SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `id`=123); @@ -65,11 +111,11 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i -全文匹配可在 `/search` 端点和基于 HTTP 的客户端中使用。以下子句可用于执行全文匹配： +全文匹配功能可在 `/search` 端点及 HTTP 客户端中使用。以下子句可用于执行全文匹配： ### match -"match" 是一个简单查询，在指定字段中匹配指定的关键词。 +"match" 是简单查询，在指定字段中匹配指定的关键字。 ```json "query": @@ -86,9 +132,9 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i "field1,field2": "keyword" } ``` -或者你可以使用 `_all` 或 `*` 来搜索所有字段。 +或者使用 `_all` 或 `*` 来搜索所有字段。 -你可以使用 "!field" 搜索除某个字段外的所有字段： +你也可以使用 "!field" 搜索除某字段外的所有字段： ```json "match": @@ -96,7 +142,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i "!field1": "keyword" } ``` -默认情况下，关键词使用 OR 操作符组合。但是，你可以使用 "operator" 子句更改此行为： +默认情况下，关键字通过 OR 运算符组合。但你可以通过 "operator" 子句更改此行为： ```json "query": @@ -112,9 +158,9 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i } ``` -"operator" 可以设置为 "or" 或 "and"。 +"operator" 可设置为 "or" 或 "and"。 -还可以应用 `boost` 修饰符。它通过指定的因子提升词的[IDF](../../Searching/Options.md#idf)_分数，在包含 IDF 计算的排名分数中提高权重。它不会以任何方式影响匹配过程。 +也可以应用 `boost` 修改符。它通过指定的因子提升词的 [IDF](../../Searching/Options.md#idf) 分数（在评分中结合 IDF 的排名分数中体现）。它不会以任何方式影响匹配过程。 ```json "query": { @@ -131,7 +177,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ### match_phrase -"match_phrase" 是一个匹配整个短语的查询。它类似于 SQL 中的短语操作符。示例如下： +"match_phrase" 是匹配整个短语的查询，类似于 SQL 的短语操作符，示例： ```json "query": @@ -141,7 +187,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ``` ### query_string -"query_string" 接受一个输入字符串，作为 `MATCH()` 语法的全文查询。 +"query_string" 接受一个作为 `MATCH()` 语法的全文查询的输入字符串。 ```json "query": @@ -152,7 +198,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ### match_all -"match_all" 接受一个空对象，返回表中的文档，而不执行任何属性过滤或全文匹配。或者，你也可以在请求中省略 `query` 子句，效果相同。 +"match_all" 接受一个空对象，返回表中的文档，不执行任何属性过滤或全文匹配。或者，直接省略请求中的 `query` 子句也有同样效果。 ```json "query": @@ -162,9 +208,9 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ``` -### 将全文过滤与其他过滤器结合使用 +### 结合全文过滤和其他过滤器 -所有全文匹配子句都可以与[必须](../../Searching/Filters.md#must)、[必须不](../../Searching/Filters.md#must_not)和[应该](../../Searching/Filters.md#should)操作符结合使用，构成[JSON `bool` 查询](../../Searching/Filters.md#bool-query)。 +所有全文匹配子句都可以结合 [must](../../Searching/Filters.md#must)、[must_not](../../Searching/Filters.md#must_not) 和 [should](../../Searching/Filters.md#should) 操作符使用 [JSON `bool` 查询](../../Searching/Filters.md#bool-query)。 示例： diff --git a/manual/chinese/Searching/Full_text_matching/Profiling.md b/manual/chinese/Searching/Full_text_matching/Profiling.md index c8beaa88f4..685d6c5033 100644 --- a/manual/chinese/Searching/Full_text_matching/Profiling.md +++ b/manual/chinese/Searching/Full_text_matching/Profiling.md @@ -1,43 +1,43 @@ # 搜索分析 -## 查询的解释方式 +## 查询的解析方式 -考虑以下复杂查询示例： +考虑下面这个复杂的查询示例： ```sql "hello world" @title "example program"~5 @body python -(php|perl) @* code ``` -该搜索的完整含义是： +此搜索的完整含义是： -* 在文档的任何字段中定位相邻的单词 'hello' 和 'world'； -* 此外，同一文档的标题字段中必须包含单词 'example' 和 'program'，两者之间最多有但不包括 5 个单词；（例如，“example PHP program” 会匹配，但“example script to introduce outside data into the correct context for your program” 不会匹配，因为两个词之间有 5 个或更多单词） -* 此外，同一文档的正文字段中必须包含单词 'python'，同时排除 'php' 或 'perl'； -* 最后，同一文档的任何字段中必须包含单词 'code'。 +* 在文档的任意字段中定位相邻的单词 'hello' 和 'world'； +* 此外，同一文档的标题字段中必须包含单词 'example' 和 'program'，这两个词之间最多（但不包括）有 5 个单词；（例如，“example PHP program”会匹配，但“example script to introduce outside data into the correct context for your program”不会，因为这两个词之间有 5 个或更多单词） +* 此外，同一文档中正文字段必须包含词 'python'，同时排除 'php' 或 'perl'； +* 最后，同一文档中任意字段必须包含单词 'code'。 -OR 运算符优先于 AND，因此“looking for cat | dog | mouse” 意味着“looking for (cat | dog | mouse)”，而不是“(looking for cat) | dog | mouse”。 +OR 运算符优先于 AND，因此“looking for cat | dog | mouse”意味着“looking for (cat | dog | mouse)”，而不是“(looking for cat) | dog | mouse”。 -为了理解查询将如何执行，Manticore Search 提供了查询分析工具，用于检查由查询表达式生成的查询树。 +为了理解查询将如何执行，Manticore Search 提供了查询分析工具来检查由查询表达式生成的查询树。 -## 在 SQL 中分析查询树 +## 使用 SQL 进行查询树分析 -要启用带有 SQL 语句的全文查询分析，必须在执行所需查询之前激活它： +要用 SQL 语句启用全文查询分析，必须在执行所需查询之前激活它： ```sql SET profiling =1; SELECT * FROM test WHERE MATCH('@title abc* @body hey'); ``` -要查看查询树，请在运行查询后立即执行 `SHOW PLAN` 命令： +执行查询后，立即运行 `SHOW PLAN` 命令以查看查询树： ```sql SHOW PLAN; ``` -该命令将返回已执行查询的结构。请记住，3 个语句 - SET profiling、查询和 SHOW - 必须在同一会话中执行。 +此命令将返回执行查询的结构。请记住，3 条语句——SET profiling、查询和 SHOW——必须在同一会话中执行。 -## 在 HTTP JSON 中分析查询 +## 在 HTTP JSON 中进行查询分析 使用 HTTP JSON 协议时，只需启用 `"profile":true`，即可在响应中获得全文查询树结构。 @@ -51,24 +51,24 @@ SHOW PLAN; } } ``` -响应将包含一个 `profile` 对象，其中包含一个 `query` 成员。 +响应将包含一个 `profile` 对象，其中包含 `query` 成员。 -`query` 属性保存转换后的全文查询树。每个节点包括： +`query` 属性包含转换后的全文查询树。每个节点包括： * `type`：节点类型，可以是 AND、OR、PHRASE、KEYWORD 等。 -* `description`：该节点的查询子树，以字符串形式表示（`SHOW PLAN` 格式） -* `children`：任何子节点（如果存在） +* `description`：该节点表示的查询子树字符串（以 `SHOW PLAN` 格式） +* `children`：如果有，则为子节点 * `max_field_pos`：字段内的最大位置 -关键词节点还将包括： + 关键字节点还将包含： -* `word`：转换后的关键词。 -* `querypos`：该关键词在查询中的位置。 -* `excluded`：关键词是否被排除在查询之外。 -* `expanded`：关键词是否由前缀扩展添加。 -* `field_start`：关键词必须出现在字段开头。 -* `field_end`：关键词必须出现在字段结尾。 -* `boost`：关键词的 IDF 将乘以此值。 +* `word`：转换后的关键字。 +* `querypos`：该关键字在查询中的位置。 +* `excluded`：关键字被排除在查询之外。 +* `expanded`：关键字由前缀扩展添加。 +* `field_start`：关键字必须出现在字段开头。 +* `field_end`：关键字必须出现在字段末尾。 +* `boost`：关键字的 IDF 将乘以此值。 @@ -1174,10 +1174,10 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -## 不运行查询时的分析 +## 在不执行查询的情况下分析查询 -SQL 语句 `EXPLAIN QUERY` 允许显示给定全文查询的执行树，而无需对表执行实际的搜索查询。 +SQL 语句 `EXPLAIN QUERY` 允许显示给定全文查询的执行树，而不会真正对表进行搜索查询。 @@ -1201,10 +1201,47 @@ Variable: transformed_tree AND(fields=(title), KEYWORD(running, querypos=1, morphed)))) AND(fields=(body), KEYWORD(dog, querypos=2, morphed))) ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY t '@title a'" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "AND(fields=(title), KEYWORD(a, querypos=1))" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] + +``` + -`EXPLAIN QUERY ... option format=dot` 允许以分层格式显示提供的全文查询的执行树，适合使用现有工具进行可视化，例如 https://dreampuf.github.io/GraphvizOnline： +`EXPLAIN QUERY ... option format=dot` 允许以分层格式显示提供的全文查询的执行树，适合用现有工具如 https://dreampuf.github.io/GraphvizOnline 做可视化： ![EXPLAIN QUERY graphviz example](graphviz.png) @@ -1236,23 +1273,59 @@ Variable: transformed_tree 4 [shape=record label="me | { querypos=2 }"] } ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY tbl '@title a' option format=dot" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "digraph \"transformed_tree\" {\n\n0 [shape=record,style=filled label=\"AND | { fields=(title) }\"]\n0 -> 1\n1 [shape=record label=\"a | { qp=1 }\"]\n}" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## 查看匹配因子值 -使用表达式排序器时，可以通过 [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29) 函数显示计算出的因子值。 +当使用表达式排序器时，可以通过[PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29)函数揭示计算因子的值。 该函数返回： -* 文档级别因素的值（例如 bm25、field_mask、doc_word_count） +* 文档级别因子的值（例如 bm25、field_mask、doc_word_count） * 生成命中的每个字段的列表（包括 lcs、hit_count、word_count、sum_idf、min_hit_pos 等） -* 查询中每个关键词及其 tf 和 idf 值的列表 +* 查询中的每个关键字及其 tf 和 idf 值的列表 -这些值可用于理解为什么某些文档在搜索中获得较低或较高的分数，或用于优化现有的排名表达式。 +这些值可用于了解为什么某些文档在搜索中得分较低或较高，或者用于完善现有的排序表达式。 -Example: +示例： ```sql @@ -1271,6 +1344,41 @@ packedfactors(): bm25=569, bm25a=0.617197, field_mask=2, doc_word_count=2, word1=(tf=1, idf=0.215338) 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id, PACKEDFACTORS() FROM test1 WHERE MATCH('test one') OPTION ranker=expr('1')" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "packedfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "packedfactors()": "bm25=500, bm25a=0.500000, field_mask=1, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.000000, min_idf=0.000000, max_idf=0.000000, sum_idf=0.000000, min_hit_pos=1, min_best_span_pos=1, exact_hit=1, max_window_hits=1, min_gaps=0, exact_order=1, lccs=1, wlccs=0.000000, atc=0.000000), word0=(tf=1, idf=0.000000)" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Searching/Grouping.md b/manual/chinese/Searching/Grouping.md index bf237502d0..c4b407cc1f 100644 --- a/manual/chinese/Searching/Grouping.md +++ b/manual/chinese/Searching/Grouping.md @@ -1,14 +1,14 @@ # 分组搜索结果 -分组搜索结果通常有助于获取每个组的匹配计数或其他聚合。例如，它对于创建按月匹配博客帖子数量的图表，或按站点分组网页搜索结果，或按作者分组论坛帖子等非常有用。 +分组搜索结果通常有助于获得每个组的匹配计数或其他聚合。例如，它对于创建显示每月匹配博客文章数量的图表，或者按网站对网络搜索结果分组，或按作者对论坛帖子分组等非常有用。 -Manticore 支持按单列、多列和计算表达式对搜索结果进行分组。结果可以： +Manticore 支持按单列或多列以及计算表达式对搜索结果进行分组。结果可以： * 在组内排序 * 每组返回多行 -* 对组进行过滤 -* 对组进行排序 +* 过滤组 +* 对组排序 * 使用[聚合函数](../Searching/Grouping.md#Aggregation-functions)进行聚合 @@ -29,7 +29,7 @@ where_condition: {aggregation expression alias | COUNT(*)} ``` -JSON 查询格式目前支持基本分组，可检索聚合值及其 count(*)。 +JSON 查询格式当前支持基本分组，可以检索聚合值及其 count(*)。 ```json { @@ -46,19 +46,19 @@ JSON 查询格式目前支持基本分组，可检索聚合值及其 count(*)。 } ``` -标准查询输出返回未分组的结果集，可以通过 `limit`（或 `size`）将其隐藏。 -聚合需要设置组结果集大小 `size`。 +标准查询输出返回未分组的结果集，可以使用 `limit`（或 `size`）将其隐藏。 +聚合需要设置组结果集大小的 `size`。 ### 仅分组 -分组相当简单——只需在 `SELECT` 查询末尾添加 "GROUP BY smth"。该某物可以是： +分组非常简单——只需在 `SELECT` 查询末尾添加 "GROUP BY smth"。这里的某物可以是： -* 表中的任何非全文字段：整数、浮点、字符串、多值属性(MVA) -* 或者，如果你在 `SELECT` 列表中使用了别名，也可以按它分组 +* 表中的任何非全文字段：整数、浮点数、字符串、多值属性（MVA） +* 或者，如果你在 `SELECT` 列表中使用了别名，也可以按该别名分组 -你可以省略 `SELECT` 列表中的任何[聚合函数](../Searching/Grouping.md#Aggregation-functions)，仍然有效： +你可以在 `SELECT` 列表中省略任何[聚合函数](../Searching/Grouping.md#Aggregation-functions)，它仍然可以工作： ##### 示例： @@ -79,14 +79,54 @@ SELECT release_year FROM films GROUP BY release_year LIMIT 5; | 2000 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year FROM films GROUP BY release_year LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2004 + }, + { + "release_year": 2002 + }, + { + "release_year": 2001 + }, + { + "release_year": 2005 + }, + { + "release_year": 2000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -然而，在大多数情况下，你会想为每个组获得一些聚合数据，例如： +不过在大多数情况下，你会想获得每个组的一些聚合数据，比如： -* `COUNT(*)` 仅仅获取每组的元素数量 +* `COUNT(*)` 仅获取每组元素数量 * 或 `AVG(field)` 计算组内字段的平均值 -对于 HTTP JSON 请求，使用单个 `aggs` 桶，并在主查询级别设置 `limit=0`，效果类似于 SQL 查询中的 `GROUP BY` 和 `COUNT(*)`，提供等效的行为和性能。 +对于 HTTP JSON 请求，主查询层使用单个带 `limit=0` 的 `aggs` bucket，效果类似于 SQL 查询中的 `GROUP BY` 和 `COUNT(*)`，提供等效的行为和性能。 ##### 示例： @@ -501,8 +541,8 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -##### 组内排序 -默认情况下，组不排序，接下来你通常想做的是按某个字段排序，比如你分组用的字段： +##### 分组排序 +默认情况下，组不排序，通常接下来你会想按某个字段排序，比如你分组的字段： ##### 示例： @@ -523,12 +563,62 @@ SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_ | 2004 | 108 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_year asc limit 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2000, + "count(*)": 97 + }, + { + "release_year": 2001, + "count(*)": 91 + }, + { + "release_year": 2002, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2004, + "count(*)": 108 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -另外，你也可以按聚合排序： +或者，你可以按聚合排序： -* 按 `count(*)` 排序，优先显示包含最多元素的组 -* 按 `avg(rental_rate)` 排序，优先显示评分最高的电影。注意，在示例中，这是通过别名完成的：先在 `SELECT` 列表中将 `avg(rental_rate)` 映射为 `avg`，然后简单地执行 `ORDER BY avg` +* 按 `count(*)` 显示元素最多的组优先 +* 按 `avg(rental_rate)` 显示评分最高的电影优先。注意在示例中是通过别名完成的：`avg(rental_rate)` 首先映射为 `avg`，然后直接使用 `ORDER BY avg` @@ -567,11 +657,61 @@ SELECT release_year, AVG(rental_rate) avg FROM films GROUP BY release_year ORDER | 2008 | 2.99000049 | +--------------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year ORDER BY count(*) desc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2006, + "count(*)": 103 + }, + { + "release_year": 2008, + "count(*)": 102 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -##### 一次按多个字段 GROUP BY -有时你可能想按多个字段分组，而不仅仅是单个字段，比如电影的类别和年份： +##### 同时按多个字段 GROUP BY +有时，你可能想不仅按单个字段分组，而是同时按多个字段，比如电影的类别和年份： ##### 示例： @@ -687,8 +827,8 @@ POST /search -d ' -##### 给我 N 行 -有时看到每组不止一个元素也很有用。这可以通过 `GROUP N BY` 很容易实现。例如，下面的例子中，我们为每个年份获取两部电影，而不是简单 `GROUP BY release_year` 只返回一部。 +##### 每组返回 N 行 +有时不仅想查看每组一个元素，而是多个，这可以通过 `GROUP N BY` 轻松实现。例如，下面的情况我们每年获取两部电影，而不是简单的 `GROUP BY release_year` 只返回一部。 ##### 示例： @@ -710,16 +850,70 @@ SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_y | 2007 | ARACHNOPHOBIA ROLLERCOASTER | +--------------+-----------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_year DESC LIMIT 6;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "ALICE FANTASIA" + }, + { + "release_year": 2009, + "title": "ALIEN CENTER" + }, + { + "release_year": 2008, + "title": "AMADEUS HOLY" + }, + { + "release_year": 2008, + "title": "ANACONDA CONFESSIONS" + }, + { + "release_year": 2007, + "title": "ANGELS LIFE" + }, + { + "release_year": 2007, + "title": "ARACHNOPHOBIA ROLLERCOASTER" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + ##### 组内排序 -另一个关键的分析需求是对组内元素排序。为此，使用 `WITHIN GROUP ORDER BY ... {ASC|DESC}` 子句。例如，获取每年评分最高的电影。注意它与普通的 `ORDER BY` 并行工作： +另一个关键的分析需求是对组内元素排序。为此，使用 `WITHIN GROUP ORDER BY ... {ASC|DESC}` 子句。例如，我们想获取每年评分最高的电影。注意它与简单的 `ORDER BY` 并行工作： -* `WITHIN GROUP ORDER BY` 对**组内**结果排序 -* 而仅用 `GROUP BY` 对**组本身**排序 +* `WITHIN GROUP ORDER BY` 用于排序**组内结果** +* 而简单的 `GROUP BY` **排序的是组本身** -这两者完全独立工作。 +两者彼此完全独立。 @@ -741,11 +935,71 @@ SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN | 2005 | AIRPLANE SIERRA | 4.990000 | +--------------+------------------+-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN GROUP ORDER BY rental_rate DESC ORDER BY release_year DESC LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + }, + { + "rental_rate": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "AMERICAN CIRCUS", + "rental_rate": 4.990000 + }, + { + "release_year": 2009, + "title": "ANTHEM LUKE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ATTACKS HATE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ALADDIN CALENDAR", + "rental_rate": 4.990000 + }, + { + "release_year": 2007, + "title": "AIRPLANE SIERRA", + "rental_rate": 4.990000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + ##### 过滤组 -`HAVING expression` 是过滤组的有用子句。`WHERE` 用于分组前过滤，而 `HAVING` 用于分组后过滤。例如，我们只保留那些该年电影平均租赁率高于3的年份。结果只有四个年份： +`HAVING expression` 是一个用于过滤分组的有用子句。虽然 `WHERE` 在分组之前应用，`HAVING` 则作用于分组。例如，我们只保留那些该年份电影的平均租赁费率高于 3 的年份。结果只剩下四个年份： ##### 示例： @@ -765,15 +1019,60 @@ SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVIN | 2006 | 3.26184368 | +--------------+------------+ ``` + +```JSON +POST /sql?mode=raw -d "SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVING avg > 3;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "avg": 3.08259249 + }, + { + "release_year": 2001, + "avg": 3.09989142 + }, + { + "release_year": 2000, + "avg": 3.17556739 + }, + { + "release_year": 2006, + "avg": 3.26184368 + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + ##### GROUPBY() -有一个函数 `GROUPBY()`，它返回当前分组的键。在许多情况下非常有用，特别是当你[按 MVA 分组](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29)或按[JSON 值分组](../Searching/Grouping.md#Grouping-by-a-JSON-node)时。 +有一个函数 `GROUPBY()`，它返回当前分组的键。在很多情况下非常有用，特别是当你[对 MVA 进行 GROUP BY](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29)或对[JSON 值进行 GROUP BY](../Searching/Grouping.md#Grouping-by-a-JSON-node)时。 -它也可以用于 `HAVING`，例如，只保留年份 2000 和 2002。 +它也可以在 `HAVING` 中使用，例如，只保留年份 2000 和 2002。 -注意，当你一次按多个字段进行 GROUP BY 时，不推荐使用 `GROUPBY()`。它仍然可以工作，但由于此时的分组键是字段值的复合，可能不会以你期望的方式出现。 +注意，当你同时对多个字段进行 GROUP BY 时，不推荐使用 `GROUPBY()`。它仍然可以工作，但由于此时分组键是字段值的复合，可能不会按你预期的方式显示。 ##### 示例： @@ -791,10 +1090,48 @@ SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() | 2000 | 97 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() IN (2000, 2002);" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "count": 108 + }, + { + "release_year": 2000, + "count": 97 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### 按 MVA（多值属性）分组 -Manticore 支持按[MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29)分组。为了演示其工作原理，我们创建一个包含 MVA 字段 "sizes" 的表 "shoes"，并插入一些文档： +Manticore 支持按[MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29)分组。为演示其工作方式，我们创建一个带有 MVA “sizes” 的表 "shoes"，并插入几条文档： ```sql create table shoes(title text, sizes multi); insert into shoes values(0,'nike',(40,41,42)),(0,'adidas',(41,43)),(0,'reebook',(42,43)); @@ -810,7 +1147,7 @@ SELECT * FROM shoes; | 1657851069130080267 | 42,43 | reebook | +---------------------+----------+---------+ ``` -如果现在按 "sizes" 进行 GROUP BY，它将处理所有多值属性，并为每个返回一个聚合，在此例中仅是计数： +如果我们现在对 "sizes" 进行 GROUP BY，它会处理所有的多值属性，并为每个值返回一个聚合，在此例中只是计数： ##### 示例： @@ -1492,17 +1829,17 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -## Aggregation functions -Besides `COUNT(*)`, which returns the number of elements in each group, you can use various other aggregation functions: +## 聚合函数 +除了返回每组元素数量的 `COUNT(*)` 外，你还可以使用各种其他聚合函数： -##### COUNT(DISTINCT field) -While `COUNT(*)` returns the number of all elements in the group, `COUNT(DISTINCT field)` returns the number of unique values of the field in the group, which may be completely different from the total count. For instance, you can have 100 elements in the group, but all with the same value for a certain field. `COUNT(DISTINCT field)` helps to determine that. To demonstrate this, let's create a table "students" with the student's name, age, and major: +##### COUNT(DISTINCT 字段) +虽然 `COUNT(*)` 返回组中所有元素的数量，但 `COUNT(DISTINCT 字段)` 返回该字段在组中唯一值的数量，这可能与总数完全不同。例如，你可以有 100 个元素在组中，但它们某个字段的值都是相同的。`COUNT(DISTINCT 字段)` 有助于判断这一点。为演示此功能，创建一个包含学生姓名、年龄和专业的表 "students"： ```sql CREATE TABLE students(name text, age int, major string); INSERT INTO students values(0,'John',21,'arts'),(0,'William',22,'business'),(0,'Richard',21,'cs'),(0,'Rebecca',22,'cs'),(0,'Monica',21,'arts'); ``` -so we have: +所以我们有： ```sql MySQL [(none)]> SELECT * from students; @@ -1517,24 +1854,24 @@ MySQL [(none)]> SELECT * from students; +---------------------+------+----------+---------+ ``` -In the example, you can see that if we GROUP BY major and display both `COUNT(*)` and `COUNT(DISTINCT age)`, it becomes clear that there are two students who chose the major "cs" with two unique ages, but for the major "arts", there are also two students, yet only one unique age. +在示例中，你可以看到如果我们按专业进行 GROUP BY 并同时显示 `COUNT(*)` 和 `COUNT(DISTINCT age)`，很明显专业为 "cs" 的有两名学生，他们的年龄各不相同，而专业为 "arts" 的同样有两名学生，但是只有一个唯一年龄。 -There can be at most one `COUNT(DISTINCT)` per query. +每个查询最多只能有一个 `COUNT(DISTINCT)`。 -** By default, counts are approximate ** +** 默认情况下，计数是近似的 ** -Actually, some of them are exact, while others are approximate. More on that below. +实际上，有些计数是精确的，有些是近似的。下面会详细说明。 -Manticore supports two algorithms for computing counts of distinct values. One is a legacy algorithm that uses a lot of memory and is usually slow. It collects `{group; value}` pairs, sorts them, and periodically discards duplicates. The benefit of this approach is that it guarantees exact counts within a plain table. You can enable it by setting the [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option to `0`. +Manticore 支持两种计算不同值计数的算法。一种是传统算法，使用大量内存且通常速度较慢。它收集 `{group; value}` 对，排序并定期剔除重复项。这种方法的好处是能保证在纯表中计数的精确。你可以通过将 [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) 选项设置为 `0` 来启用它。 -The other algorithm (enabled by default) loads counts into a hash table and returns its size. If the hash table becomes too large, its contents are moved into a `HyperLogLog`. This is where the counts become approximate since `HyperLogLog` is a probabilistic algorithm. The advantage is that the maximum memory usage per group is fixed and depends on the accuracy of the `HyperLogLog`. The overall memory usage also depends on the [max_matches](../Searching/Options.md#max_matches) setting, which reflects the number of groups. +另一种算法（默认启用）将计数加载到哈希表中并返回其大小。如果哈希表变得过大，其内容会被移动至 `HyperLogLog`。这时计数成为近似值，因为 `HyperLogLog` 是概率算法。优点是每组最大内存使用固定，且依赖于 `HyperLogLog` 的精度。整体内存消耗也受 [max_matches](../Searching/Options.md#max_matches) 设置影响，该设置反映了组的数量。 -The [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option sets the threshold below which counts are guaranteed to be exact. The `HyperLogLog` accuracy setting and the threshold for the "hash table to HyperLogLog" conversion are derived from this setting. It's important to use this option with caution because doubling it will double the maximum memory required for count calculations. The maximum memory usage can be roughly estimated using this formula: `64 * max_matches * distinct_precision_threshold`. Note that this is the worst-case scenario, and in most cases, count calculations will use significantly less RAM. +[distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) 选项设置了计数保证精确的阈值。`HyperLogLog` 的精度设置以及从哈希表转换到 `HyperLogLog` 的阈值都来源于该设置。使用此选项需谨慎，因为阈值加倍将使计算计数所需的最大内存加倍。最大内存使用可粗略估算为：`64 * max_matches * distinct_precision_threshold`。请注意这是最坏情况，大多数情况下计数计算会使用明显更少的内存。 -**`COUNT(DISTINCT)` against a distributed table or a real-time table consisting of multiple disk chunks may return inaccurate results**, but the result should be accurate for a distributed table consisting of local plain or real-time tables with the same schema (identical set/order of fields, but may have different tokenization settings). +** 对分布式表或包含多个磁盘块的实时表执行 `COUNT(DISTINCT)` 可能返回不准确结果，**但对于由本地纯表或实时表（结构相同）组成的分布式表，结果应当准确（字段集合/顺序一致，但可能有不同的分词设置）。 -##### Example: +##### 示例： ```sql @@ -1550,17 +1887,67 @@ SELECT major, count(*), count(distinct age) FROM students GROUP BY major; | cs | 2 | 2 | +----------+----------+---------------------+ ``` + + +```JSON +POST /sql?mode=raw - d "SELECT major, count(*), count(distinct age) FROM students GROUP BY major;" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + -##### GROUP_CONCAT(field) +##### GROUP_CONCAT(字段) -Often, you want to better understand the contents of each group. You can use [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) for that, but it would return additional rows you might not want in the output. `GROUP_CONCAT()` enriches your grouping by concatenating values of a specific field in the group. Let's take the previous example and improve it by displaying all the ages in each group. +通常，你想更好地了解每个分组的内容。你可以使用 [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) 来实现，但它会返回你可能不想要的额外行。`GROUP_CONCAT()` 通过将组中特定字段的值连接起来丰富你的分组。让我们用之前的例子来改进，通过显示每个组中所有年龄。 -`GROUP_CONCAT(field)` returns the list as comma-separated values. +`GROUP_CONCAT(字段)` 返回逗号分隔的值列表。 -##### Example: +##### 示例： ```sql @@ -1576,13 +1963,71 @@ SELECT major, count(*), count(distinct age), group_concat(age) FROM students GRO | cs | 2 | 2 | 21,22 | +----------+----------+---------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT major, count(*), count(distinct age), group_concat(age) FROM students GROUP BY major" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + }, + { + "group_concat(age)": { + "type": "string" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1, + "group_concat(age)": 21,21 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1, + "group_concat(age)": 22 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2, + "group_concat(age)": 21,22 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### SUM(), MIN(), MAX(), AVG() -Of course, you can also obtain the sum, average, minimum, and maximum values within a group. +当然，你也可以获得组内的总和、平均值、最小值和最大值。 -##### Example: +##### 示例： ```sql @@ -1600,21 +2045,101 @@ SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental | 2004 | 300.920044 | 0.990000 | 4.990000 | 2.78629661 | +------+------------+----------+----------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental_rate) max, avg(rental_rate) avg FROM films GROUP BY release_year ORDER BY year asc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "sum": { + "type": "long long" + } + }, + { + "min": { + "type": "long long" + } + }, + { + "max": { + "type": "long long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2000, + "sum": 308.030029, + "min": 0.990000, + "max": 4.990000, + "avg": 3.17556739 + }, + { + "year": 2001, + "sum": 282.090118, + "min": 0.990000, + "max": 4.990000, + "avg": 3.09989142 + }, + { + "year": 2002, + "sum": 332.919983, + "min": 0.99, + "max": 4.990000, + "avg": 3.08259249 + }, + { + "year": 2003, + "sum": 310.940063, + "min": 0.990000, + "max": 4.990000, + "avg": 2.93339682 + }, + { + "year": 2004, + "sum": 300.920044, + "min": 0.990000, + "max": 4.990000, + "avg": 2.78629661 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -## Grouping accuracy +## 分组精度 -Grouping is done in fixed memory, which depends on the [max_matches](../Searching/Options.md#max_matches) setting. If `max_matches` allows for storage of all found groups, the results will be 100% accurate. However, if the value of `max_matches` is lower, the results will be less accurate. +分组是在固定内存中完成的，内存大小取决于 [max_matches](../Searching/Options.md#max_matches) 设置。如果 `max_matches` 允许存储所有找到的组，结果将是 100% 精确的。然而，如果 `max_matches` 的值较小，则结果会降低准确性。 -When parallel processing is involved, it can become more complicated. When `pseudo_sharding` is enabled and/or when using an RT table with several disk chunks, each chunk or pseudo shard gets a result set that is no larger than `max_matches`. This can lead to inaccuracies in aggregates and group counts when the result sets from different threads are merged. To fix this, either a larger `max_matches` value or disabling parallel processing can be used. +当涉及并行处理时，情况会更复杂。启用 `pseudo_sharding` 和/或使用带有多个磁盘块的 RT 表时，每个块或伪分片获得的结果集大小不超过 `max_matches`。这可能在不同线程的结果集合并时导致聚合和分组计数不准确。为解决此问题，可以使用更大的 `max_matches` 值或禁用并行处理。 -Manticore will try to increase `max_matches` up to [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold) if it detects that groupby may return inaccurate results. Detection is based on the number of unique values of the groupby attribute, which is retrieved from secondary indexes (if present). +Manticore 将尝试将 `max_matches` 增加到 [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold)，如果它检测到 groupby 可能返回不准确的结果。检测基于 groupby 属性的唯一值数量，这些值是从二级索引（如果存在）中检索的。 -To ensure accurate aggregates and/or group counts when using RT tables or `pseudo_sharding`, `accurate_aggregation` can be enabled. This will try to increase `max_matches` up to the threshold, and if the threshold is not high enough, Manticore will disable parallel processing for the query. +为了确保在使用 RT 表或 `pseudo_sharding` 时聚合和/或组计数的准确性，可以启用 `accurate_aggregation`。这将尝试将 `max_matches` 增加到阈值，如果阈值不够高，Manticore 将禁用该查询的并行处理。 -##### Example: +##### 示例： ```sql @@ -1653,6 +2178,143 @@ MySQL [(none)]> SELECT release_year year, count(*) FROM films GROUP BY year limi | 2001 | 91 | +------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + }, + { + "year": 2005, + "count(*)": 93 + }, + { + "year": 2000, + "count(*)": 97 + }, + ], + "total": 5, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=1;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=2;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + }, + { + "year": 2002, + "count(*)": 74 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=3;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Searching/Highlighting.md b/manual/chinese/Searching/Highlighting.md index 491ec372fb..11debddc6b 100644 --- a/manual/chinese/Searching/Highlighting.md +++ b/manual/chinese/Searching/Highlighting.md @@ -384,19 +384,19 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea 设置 `%SNIPPET_ID%` 宏的起始值（该宏在 `before_match`、`after_match` 字符串中被检测并展开）。默认值为 1。 #### html_strip_mode -定义HTML剥离模式设置。默认值为`index`，表示将使用表设置。其他值包括`none`和`strip`，无论表设置如何，强制跳过或应用剥离；以及`retain`，保留HTML标记并保护其不被高亮。`retain`模式只能在高亮完整文档时使用，因此要求不设置片段大小限制。允许的字符串值为`none`、`strip`、`index`和`retain`。 +定义 HTML 去除模式设置。默认为 `index`，表示将使用表设置。其他值包括 `none` 和 `strip`，无论表设置如何，均强制跳过或应用去除；以及 `retain`，保留 HTML 标记并防止其被高亮。`retain` 模式只能用于高亮完整文档，因此要求未设置片段大小限制。允许的字符串值为 `none`、`strip`、`index` 和 `retain`。 #### allow_empty -允许在当前字段无法生成片段时（无关键字匹配或无片段符合限制）返回空字符串作为高亮结果。默认情况下，将返回原始文本的开头而不是空字符串。默认值为0（不允许空结果）。 +允许在当前字段无法生成任何片段（无关键字匹配或无片段符合限制）的情况下返回空字符串作为高亮结果。默认情况下，将返回原始文本的开头，而不是空字符串。默认值为 0（不允许空结果）。 #### snippet_boundary -确保片段不会跨越句子、段落或区域边界（当与启用了相应索引设置的表一起使用时）。允许的值为`sentence`、`paragraph`和`zone`。 +确保片段不会跨越句子、段落或区域边界（当与相应索引设置启用的表一起使用时）。允许的值为 `sentence`、`paragraph` 和 `zone`。 #### emit_zones -在每个片段前发出包含区域名称的HTML标签。默认值为0（不发出区域名称）。 +在每个片段前发出带有包含区域名称的 HTML 标签。默认值为 0（不发出区域名）。 #### force_snippets -确定是否强制生成片段，即使限制允许高亮整个文本。默认值为0（不强制生成片段）。 +确定是否强制生成片段，即使限制允许高亮整个文本。默认值为 0（不强制生成片段）。 ##### SQL: @@ -830,9 +830,9 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -## 通过SQL进行高亮 +## 通过 SQL 进行高亮 -`HIGHLIGHT()`函数可用于高亮搜索结果。语法如下： +`HIGHLIGHT()` 函数可用于高亮搜索结果。语法如下： ```sql HIGHLIGHT([options], [field_list], [query] ) @@ -860,11 +860,43 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('before'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('before');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "A door opened before them, revealing a small room." + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -`HIGHLIGHT()`从文档存储中检索所有可用的全文字段，并针对提供的查询进行高亮。查询中支持字段语法。字段文本由`field_separator`分隔，可在选项中修改。 +`HIGHLIGHT()` 从文档存储中检索所有可用的全文字段，并针对提供的查询进行高亮。查询中支持字段语法。字段文本由 `field_separator` 分隔，该选项可在选项中修改。 ##### SQL: @@ -885,10 +917,42 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```json +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "Book one" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -`HIGHLIGHT()`的可选第一个参数是选项列表。 +`HIGHLIGHT()` 的可选第一个参数是选项列表。 ##### SQL: @@ -909,6 +973,36 @@ SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHE 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": "Book [match]one[/match]" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + + @@ -935,11 +1029,44 @@ SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title,content')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title,content')": "Book one | They followed Bander. The robots remained at a polite distance, but their presence was a constantly felt threat." + }, + { + "highlight({},'title,content')": "Bander ushered all three into the room. One of the robots followed as well. Bander gestured the other robots away and entered itself. The door closed behind it." + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + + -或者，可以使用第二个参数指定字符串属性或字段名（不带引号）。在这种情况下，提供的字符串将针对查询进行高亮，但字段语法将被忽略。 +或者，您可以使用第二个参数指定字符串属性或字段名（无需引号）。此时，将针对提供的查询对所提供的字符串进行高亮，但字段语法将被忽略。 ##### SQL: @@ -961,11 +1088,43 @@ SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},title)": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},title)": "Book one" + }, + { + "highlight({},title)": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -可选的第三个参数是查询。用于针对与搜索时不同的查询进行高亮。 +可选的第三个参数是查询。用于针对与用于搜索不同的查询高亮搜索结果。 ##### SQL: @@ -987,11 +1146,43 @@ SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title', 'five')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title', 'five')": "Book one" + }, + { + "highlight({},'title', 'five')": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -虽然`HIGHLIGHT()`设计用于存储的全文字段和字符串属性，但也可用于高亮任意文本。请注意，如果查询包含任何字段搜索操作符（例如`@title hello @body world`），则在此情况下忽略它们的字段部分。 +虽然 `HIGHLIGHT()` 设计用于存储的全文字段和字符串属性，但它也可用于高亮任意文本。请注意，如果查询包含任何字段搜索操作符（例如 `@title hello @body world`），此时字段部分将被忽略。 ##### SQL: @@ -1012,26 +1203,55 @@ SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": { + "type": "string" + } + } + ], + "data": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": "some text to highlight" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -某些选项仅在生成单个字符串结果（而非片段数组）时相关。这仅适用于SQL的`HIGHLIGHT()`函数： +若干选项仅在生成单个字符串作为结果时相关（而非片段数组）。这专门适用于 SQL 的 `HIGHLIGHT()` 函数： #### snippet_separator -插入片段之间的字符串。默认值为` ... `。 +插入片段之间的字符串。默认是 ` ... `。 #### field_separator -插入字段之间的字符串。默认值为`|`。 +插入字段之间的字符串。默认是 `|`。 -另一种高亮文本的方法是使用[CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS)语句。它大致复制了`HIGHLIGHT()`的功能，但不能使用内置文档存储。不过，它可以从文件加载源文本。 +另一种高亮文本的方法是使用 [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS) 语句。这在很大程度上重复了 `HIGHLIGHT()` 的功能，但不能使用内置的文档存储。然而，它可以从文件加载源文本。 -## 通过HTTP进行高亮 +## 通过 HTTP 进行高亮 -要通过HTTP在JSON查询中高亮全文搜索结果，字段内容必须存储在文档存储中（默认启用）。示例中，从文档存储中获取全文字段`content`和`title`，并针对`query`子句中指定的查询进行高亮。 +要通过 HTTP 在 JSON 查询中高亮全文搜索结果，字段内容必须存储在文档存储中（默认启用）。在示例中，全文字段 `content` 和 `title` 从文档存储中获取，并根据在 `query` 子句中指定的查询进行高亮。 -高亮片段在`hits`数组的`highlight`属性中返回。 +高亮片段在 `hits` 数组的 `highlight` 属性中返回。 ##### JSON: @@ -1360,7 +1580,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -要突出显示所有可能的字段，请将一个空对象作为 `highlight` 属性传递。 +要高亮所有可能的字段，将一个空对象作为 `highlight` 属性传递。 ##### JSON: @@ -1692,19 +1912,19 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -除了常见的高亮选项外，通过 HTTP 的 JSON 查询还提供了几个同义词： +除了常见的高亮选项外，JSON 查询通过 HTTP 还支持几个同义词： #### fields -`fields` 对象包含带有选项的属性名称。它也可以是字段名称的数组（不带任何选项）。 +`fields` 对象包含带有选项的属性名。它也可以是字段名的数组（不包含任何选项）。 -请注意，默认情况下，高亮尝试突出显示全文查询后的结果。在一般情况下，当您不指定要高亮的字段时，高亮基于您的全文查询。然而，如果您指定了要高亮的字段，则只有当全文查询匹配所选字段时才会高亮。 +注意，默认情况下，高亮尝试根据全文查询结果进行高亮。在一般情况下，当您未指定要高亮的字段时，高亮基于全文查询。然而，如果您指定了要高亮的字段，只有当全文查询匹配选定字段时才进行高亮。 #### encoder -`encoder` 可以设置为 `default` 或 `html`。当设置为 `html` 时，它在高亮时保留 HTML 标记。这与 `html_strip_mode=retain` 选项的作用类似。 +`encoder` 可以设置为 `default` 或 `html`。设置为 `html` 时，高亮时保留 HTML 标记。这与 `html_strip_mode=retain` 选项类似。 #### highlight_query -`highlight_query` 选项允许您针对除搜索查询之外的查询进行高亮。语法与主 `query` 中相同。 +`highlight_query` 选项允许您使用与搜索查询不同的查询进行高亮。语法与主查询的 `query` 相同。 ##### JSON: @@ -1975,7 +2195,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### pre_tags 和 post_tags -`pre_tags` 和 `post_tags` 设置高亮文本片段的起始和结束标签。它们的功能类似于 `before_match` 和 `after_match` 选项。这些是可选的，默认值分别为 `` 和 ``。 +`pre_tags` 和 `post_tags` 设置高亮文本片段的起始和结束标签。它们的功能类似于 `before_match` 和 `after_match` 选项。这些是可选项，默认值分别为 `` 和 ``。 ##### JSON: @@ -2246,7 +2466,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### no_match_size -`no_match_size` 的功能类似于 `allow_empty` 选项。如果设置为 0，则相当于 `allow_empty=1`，允许在无法生成片段时返回空字符串作为高亮结果。否则，将返回字段的开头。这是可选的，默认值为 1。 +`no_match_size` 的功能类似于 `allow_empty` 选项。如果设置为 0，则等同于 `allow_empty=1`，当无法生成高亮片段时允许返回空字符串作为高亮结果。否则，将返回字段的开头。此项是可选的，默认值为 1。 ##### JSON: @@ -2508,7 +2728,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### order -`order` 设置提取片段的排序顺序。如果设置为 `"score"`，则按相关性对提取的片段进行排序。此项为可选，且其工作方式类似于 `weight_order` 选项。 +`order` sets the sorting order of extracted snippets. If set to `"score"`, it sorts the extracted snippets in order of relevance. This is optional and works similarly to the `weight_order` option. ##### JSON: @@ -2770,7 +2990,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### fragment_size -`fragment_size` 设置片段的最大符号数。它可以是全局设置，也可以是按字段设置。按字段的选项会覆盖全局选项。此项为可选，默认值为 256。其工作方式类似于 `limit` 选项。 +`fragment_size` sets the maximum snippet size in symbols. It can be global or per-field. Per-field options override global options. This is optional, with a default value of 256. It works similarly to the `limit` option. ##### JSON: @@ -3024,7 +3244,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### number_of_fragments -`number_of_fragments` 限制结果中片段的最大数量。与 `fragment_size` 类似，它可以是全局设置或按字段设置。此项为可选，默认值为 0（无限制）。其工作方式类似于 `limit_snippets` 选项。 +`number_of_fragments` limits the maximum number of snippets in the result. Like `fragment_size`, it can be global or per-field. This is optional, with a default value of 0 (no limit). It works similarly to the `limit_snippets` option. ##### JSON: @@ -3285,7 +3505,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### limit, limit_words, limit_snippets -选项如 `limit`、`limit_words` 和 `limit_snippets` 可以设置为全局或按字段的选项。全局选项作为按字段的限制使用，除非被按字段选项覆盖。在示例中，`title` 字段使用默认限制设置进行高亮，而 `content` 字段使用不同的限制。 +Options like `limit`, `limit_words`, and `limit_snippets` can be set as global or per-field options. Global options are used as per-field limits unless per-field options override them. In the example, the `title` field is highlighted with default limit settings, while the `content` field uses a different limit. ##### JSON: @@ -3553,7 +3773,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### limits_per_field -全局限制也可以通过指定 `limits_per_field=0` 来强制执行。设置此选项意味着所有合并的高亮结果必须在指定的限制内。缺点是，如果高亮引擎认为某些片段更相关，可能会在一个字段中获得多个高亮片段，而另一个字段则没有。 +Global limits can also be enforced by specifying `limits_per_field=0`. Setting this option means that all combined highlighting results must be within the specified limits. The downside is that you may get several snippets highlighted in one field and none in another if the highlighting engine decides that they are more relevant. ##### JSON: @@ -3755,7 +3975,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -`CALL SNIPPETS` 语句使用指定的表设置，从提供的数据和查询中构建片段。它无法访问内置的文档存储，因此建议使用 [HIGHLIGHT() 函数](../Searching/Highlighting.md)。 +`CALL SNIPPETS` 语句使用指定的表设置根据提供的数据和查询构建摘要片段。它无法访问内置的文档存储，因此建议改用 [HIGHLIGHT() 函数](../Searching/Highlighting.md)。 语法如下： @@ -3764,13 +3984,13 @@ CALL SNIPPETS(data, table, query[, opt_value AS opt_name[, ...]]) ``` #### data -`data` 作为提取片段的来源。它可以是单个字符串，也可以是用花括号括起来的字符串列表。 +`data` 用作提取摘要片段的来源。它可以是单个字符串，也可以是用大括号括起来的字符串列表。 #### table -`table` 指定提供文本处理设置以生成片段的表名。 +`table` 指提供文本处理设置以生成摘要片段的表名。 #### query -`query` 是用于构建摘要的全文查询。 +`query` 是用于构建摘要片段的全文查询。 #### opt_value 和 opt_name -`opt_value` 和 `opt_name` 表示[摘要生成选项](../Searching/Highlighting.md)。 +`opt_value` 和 `opt_name` 表示 [摘要片段生成选项](../Searching/Highlighting.md)。 ##### SQL: @@ -3790,20 +4010,52 @@ CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', ' 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', 'is text', 5 AS around, 200 AS limit);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -大多数选项与[HIGHLIGHT() 函数](../Searching/Highlighting.md)中的相同。然而，有几个选项只能与 `CALL SNIPPETS` 一起使用。 +大多数选项与 [HIGHLIGHT() 函数](../Searching/Highlighting.md) 中相同。然而，有几个选项只可用于 `CALL SNIPPETS`。 -以下选项可用于突出显示存储在单独文件中的文本： +以下选项可用于高亮显示存储在独立文件中的文本： #### load_files -启用此选项时，将第一个参数视为文件名，而不是用于提取摘要的数据。服务器端将加载指定的文件以获取数据。当启用此标志时，每个请求将使用最多 [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) 个工作线程来并行处理工作。默认值为 0（无限制）。要在远程代理之间分配摘要生成，请在仅包含一个(!)本地代理和多个远程代理的分布式表中调用摘要生成。[snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) 选项用于生成最终文件名。例如，当 searchd 配置为 `snippets_file_prefix = /var/data_` 并且提供了文件名 `text.txt` 时，摘要将从 `/var/data_text.txt` 的内容生成。 +启用此选项时，会将第一个参数视为文件名，而非用于提取摘要片段的数据。服务器端将加载指定的文件作为数据。启用此标志时，每个请求将使用最多 [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) 个工作线程以实现并行处理。默认值为 0（无上限）。要在远程代理之间分发摘要片段生成，可以在包含一个（！）本地代理和多个远程代理的分布式表中调用摘要片段生成。选项 [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) 用于生成最终文件名。例如，当 searchd 配置为 `snippets_file_prefix = /var/data_` 并提供 `text.txt` 作为文件名时，摘要片段将由 `/var/data_text.txt` 的内容生成。 #### load_files_scattered -此选项仅适用于带有远程代理的分布式摘要生成。摘要生成的源文件可以分布在不同的代理上，主服务器将合并所有无错误的结果。例如，如果分布式表的一个代理有 `file1.txt`，另一个代理有 `file2.txt`，并且你使用 `CALL SNIPPETS` 处理这两个文件，searchd 将合并代理结果，因此你将获得来自 `file1.txt` 和 `file2.txt` 的结果。默认值为 0。 +此选项仅适用于带远程代理的分布式摘要片段生成。摘要片段生成的源文件可以分布在不同代理中，主服务器将合并所有无错误的结果。例如，如果分布式表的一个代理有 `file1.txt`，另一个代理有 `file2.txt`，并且你使用包含这两个文件的 `CALL SNIPPETS`，searchd 将合并代理结果，因此你将获得来自 `file1.txt` 和 `file2.txt` 的结果。默认值为 0。 -如果同时启用了 `load_files` 选项，则如果任何文件在任何地方不可用，请求将返回错误。否则（如果未启用 `load_files`），对于所有缺失的文件将返回空字符串。searchd 不会将此标志传递给代理，因此如果文件不存在，代理不会生成严重错误。如果你想确保所有源文件都被加载，请将 `load_files_scattered` 和 `load_files` 都设置为 1。如果某些代理上缺少某些源文件不是关键问题，只需将 `load_files_scattered` 设置为 1。 +如果 `load_files` 选项也启用，当任一文件不可用时，请求会返回错误。否则（如果未启用 `load_files`），对于所有缺失文件返回空字符串。Searchd 不会将此标志传递给代理，因此文件不存在时代理不会生成严重错误。如果你想确保所有源文件都被加载，请将 `load_files_scattered` 和 `load_files` 都设置为 1。如果某些代理缺失源文件不影响结果，则只设置 `load_files_scattered` 为 1。 ##### SQL: @@ -3824,6 +4076,38 @@ CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_f 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_files);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Searching/KNN.md b/manual/chinese/Searching/KNN.md index e6e98d39e4..d5826d4be5 100644 --- a/manual/chinese/Searching/KNN.md +++ b/manual/chinese/Searching/KNN.md @@ -1,28 +1,28 @@ -# K-近邻向量搜索 +# K近邻向量搜索 -Manticore Search 支持将由机器学习模型生成的嵌入向量添加到每个文档中，然后对它们进行最近邻搜索。这使您能够构建诸如相似性搜索、推荐、语义搜索和基于自然语言处理算法的相关性排序等功能，还包括图像、视频和声音搜索。 +Manticore Search 支持向每个文档添加由机器学习模型生成的嵌入向量，然后对它们进行最近邻搜索。这使您可以构建类似度搜索、推荐、语义搜索和基于NLP算法的相关性排名等功能，还包括图像、视频和声音搜索。 -## 什么是嵌入向量？ +## 什么是嵌入？ -嵌入向量是一种表示数据（如文本、图像或声音）的方法，将其表示为高维空间中的向量。这些向量被设计成使它们之间的距离反映所代表数据的相似性。该过程通常采用诸如词嵌入（例如 Word2Vec、BERT）用于文本，或神经网络用于图像的算法。向量空间的高维特性，每个向量包含多个分量，允许表示项目之间复杂且细微的关系。它们的相似性通过这些向量之间的距离来衡量，通常使用欧几里得距离或余弦相似度等方法。 +嵌入是一种表示数据的方法——例如文本、图像或声音——将其表示为高维空间中的向量。这些向量设计成使它们之间的距离反映出所代表数据的相似性。该过程通常采用诸如词嵌入（例如 Word2Vec、BERT）算法来处理文本，或使用神经网络处理图像。向量空间的高维特性，每个向量具有多个分量，能够表现项目之间复杂而微妙的关系。它们的相似度通过向量之间的距离来衡量，通常使用欧氏距离或余弦相似度等方法。 -Manticore Search 使用 HNSW 库实现 k-近邻（KNN）向量搜索。此功能是 [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) 的一部分。 +Manticore Search 使用 HNSW 库支持 k近邻（KNN）向量搜索。此功能是 [Manticore Columnar Library](https://github.com/manticoresoftware/columnar) 的一部分。 -### 配置用于 KNN 搜索的表 +### 配置用于KNN搜索的表 -要运行 KNN 搜索，您必须先配置表。浮点向量和 KNN 搜索仅支持实时表（不支持普通表）。表需要至少有一个 [float_vector](../Creating_a_table/Data_types.md#Float-vector) 属性，作为数据向量。您需要指定以下属性： -* `knn_type`：必填设置；目前仅支持 `hnsw`。 -* `knn_dims`：必填设置，指定被索引向量的维度。 -* `hnsw_similarity`：必填设置，指定 HNSW 索引使用的距离函数。可接受的值有： - - `L2` - 平方 L2 距离 +要运行KNN搜索，必须首先配置表。浮点向量和KNN搜索仅支持实时表（不支持普通表）。表需要至少包含一个 [float_vector](../Creating_a_table/Data_types.md#Float-vector) 属性，该属性作为数据向量。您需指定以下属性： +* `knn_type`：必填设置；当前仅支持 `hnsw`。 +* `knn_dims`：必填设置，指定索引向量的维数。 +* `hnsw_similarity`：必填设置，指定HNSW索引使用的距离函数。可接受的值： + - `L2` - 平方L2距离 - `IP` - 内积 - `COSINE` - 余弦相似度 - **注意：** 使用 `COSINE` 相似度时，向量在插入时会自动归一化。这意味着存储的向量值可能与原始输入值不同，因为它们会被转换为单位向量（数学长度/模为 1.0 的向量），以实现高效的余弦相似度计算。此归一化保持向量的方向，同时标准化其长度。 -* `hnsw_m`：可选设置，定义图中最大出边连接数。默认值为 16。 -* `hnsw_ef_construction`：可选设置，定义构建时的时间/准确性权衡。 + **注意：** 当使用 `COSINE` 相似度时，插入时向量会自动归一化。这意味着存储的向量值可能与原始输入不同，因为它们会被转换为单位向量（数学长度/幅度为1.0的向量），以实现高效的余弦相似度计算。归一化保持向量方向不变，同时标准化其长度。 +* `hnsw_m`：可选设置，定义图中最多的出边连接数，默认值为16。 +* `hnsw_ef_construction`：可选设置，定义构建阶段的时间与精度折衷。 ##### SQL @@ -38,6 +38,24 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di Query OK, 0 rows affected (0.01 sec) ``` + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' );" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + + ##### 普通模式（使用配置文件）： @@ -59,28 +77,28 @@ table test_vec { #### 自动嵌入（推荐） -处理向量数据最简单的方法是使用**自动嵌入**。使用此功能，您创建一个带有 `MODEL_NAME` 和 `FROM` 参数的表，然后只需插入文本数据——Manticore 会自动为您生成嵌入向量。 +处理向量数据最简单的方式是使用**自动嵌入**。通过此功能，您创建一个包含 `MODEL_NAME` 和 `FROM` 参数的表，然后只需插入文本数据—Manticore 会自动为您生成嵌入。 -##### 创建带自动嵌入的表 +##### 创建包含自动嵌入的表 -创建自动嵌入表时，指定： +创建自动嵌入表时，请指定： - `MODEL_NAME`：要使用的嵌入模型 -- `FROM`：用于生成嵌入的字段（为空表示所有文本/字符串字段） +- `FROM`：用于生成嵌入的字段（空表示所有文本/字符串字段） **支持的嵌入模型：** -- **Sentence Transformers**：任何[合适的基于 BERT 的 Hugging Face 模型](https://huggingface.co/sentence-transformers/models)（例如 `sentence-transformers/all-MiniLM-L6-v2`）——无需 API 密钥。Manticore 在创建表时下载模型。 -- **OpenAI**：OpenAI 嵌入模型，如 `openai/text-embedding-ada-002` - 需要 `API_KEY=''` 参数 +- **Sentence Transformers**：任何[合适的基于BERT的Hugging Face模型](https://huggingface.co/sentence-transformers/models)（例如 `sentence-transformers/all-MiniLM-L6-v2`）—无需API密钥。创建表时，Manticore会下载该模型。 +- **OpenAI**：OpenAI嵌入模型，如 `openai/text-embedding-ada-002` - 需要 `API_KEY=''` 参数 - **Voyage**：Voyage AI 嵌入模型 - 需要 `API_KEY=''` 参数 - **Jina**：Jina AI 嵌入模型 - 需要 `API_KEY=''` 参数 -有关设置 `float_vector` 属性的更多信息，请参见[这里](../Creating_a_table/Data_types.md#Float-vector)。 +更多关于设置 `float_vector` 属性的信息可以见[这里](../Creating_a_table/Data_types.md#Float-vector)。 ##### SQL： -使用 sentence-transformers（无需 API 密钥） +使用 sentence-transformers（无须API密钥） ```sql CREATE TABLE products ( title TEXT, @@ -100,7 +118,7 @@ CREATE TABLE products_openai ( ); ``` -使用所有文本字段生成嵌入（FROM 为空） +使用所有文本字段进行嵌入（FROM为空） ```sql CREATE TABLE products_all ( title TEXT, @@ -110,45 +128,85 @@ CREATE TABLE products_all ( ); ``` + +##### JSON： + + + +使用 sentence-transformers（无须API密钥） +```json +POST /sql?mode=raw -d "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');" +``` + +使用 OpenAI（需要 API_KEY 参数） +```json +POST /sql?mode=raw -d "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为空） +```json +POST /sql?mode=raw -d "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='');" +``` + ##### 使用自动嵌入插入数据 -使用自动嵌入时，**不要在 INSERT 语句中指定向量字段**。嵌入向量会自动从 `FROM` 参数指定的文本字段生成。 +使用自动嵌入时，**不要在INSERT语句中指定向量字段**。嵌入会自动从`FROM`参数指定的文本字段生成。 ##### SQL： -仅插入文本数据 - 嵌入自动生成 +仅插入文本数据——嵌入自动生成 ```sql INSERT INTO products (title) VALUES ('machine learning artificial intelligence'), ('banana fruit sweet yellow'); ``` -插入多个字段 - 如果 FROM='title,description'，则两者都用于生成嵌入 +插入多个字段 — 如果FROM='title,description'，则两者都会用于嵌入生成 ```sql INSERT INTO products_openai (title, description) VALUES ('smartphone', 'latest mobile device with advanced features'), ('laptop', 'portable computer for work and gaming'); ``` -插入空向量（文档将被排除在向量搜索之外） +插入空向量（文档被排除在向量搜索之外） ```sql INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ()); ``` + +##### JSON： + + + +仅插入文本数据——嵌入自动生成 +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title) VALUES ('machine learning artificial intelligence'),('banana fruit sweet yellow');" +``` + +插入多个字段 — 如果FROM='title,description'，则两者都会用于嵌入生成 +```JSON +POST /sql?mode=raw -d "INSERT INTO products_openai (title, description) VALUES ('smartphone', 'latest mobile device with advanced features'), ('laptop', 'portable computer for work and gaming');" +``` + +插入空向量（文档被排除在向量搜索之外） +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ());" +``` + -##### 使用自动嵌入搜索 +##### 使用自动嵌入进行搜索 -搜索方式相同——提供查询文本，Manticore 会生成嵌入并找到相似文档： +搜索方式相同—提供查询文本，Manticore 会生成嵌入并找到类似文档： ##### SQL： @@ -176,7 +234,7 @@ SELECT id, knn_dist() FROM products WHERE knn(embedding_vector, 3, 'machine lear -使用文本查询和自动嵌入 +使用文本查询与自动嵌入 ```json POST /search { @@ -235,12 +293,12 @@ POST /search -#### 手动插入向量 +#### Manual Vector Insertion -或者，您可以手动插入预先计算好的向量数据，确保其维度与创建表时指定的维度匹配。您也可以插入空向量；这意味着该文档将被排除在向量搜索结果之外。 +Alternatively, you can manually insert pre-computed vector data, ensuring it matches the dimensions you specified when creating the table. You can also insert an empty vector; this means that the document will be excluded from vector search results. -**重要提示：** 当使用 `hnsw_similarity='cosine'` 时，向量在插入时会自动归一化为单位向量（数学长度/幅度为1.0的向量）。这种归一化保持了向量的方向，同时标准化了其长度，这是高效计算余弦相似度所必需的。这意味着存储的值将与您原始输入的值不同。 +**Important:** When using `hnsw_similarity='cosine'`, vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values. ##### SQL: @@ -301,9 +359,9 @@ POST /insert -### KNN 向量搜索 +### KNN vector search -现在，您可以使用 SQL 或 JSON 格式中的 `knn` 子句执行 KNN 搜索。两种接口都支持相同的基本参数，确保无论选择哪种格式，都能获得一致的体验： +Now, you can perform a KNN search using the `knn` clause in either SQL or JSON format. Both interfaces support the same essential parameters, ensuring a consistent experience regardless of the format you choose: - SQL: `select ... from
where knn ( , , [,] )` - JSON: @@ -323,19 +381,19 @@ POST /insert } ``` -参数说明： -* `field`：这是包含向量数据的浮点向量属性的名称。 -* `k`：表示返回的文档数量，是分层可导航小世界（HNSW）索引的关键参数。它指定单个 HNSW 索引应返回的文档数量。然而，最终结果中包含的文档数量可能会有所不同。例如，如果系统处理的是分割成磁盘块的实时表，每个块可能返回 `k` 个文档，导致总数超过指定的 `k`（因为累计计数为 `num_chunks * k`）。另一方面，如果在请求了 `k` 个文档后，根据特定属性过滤掉了一些文档，最终文档数可能少于 `k`。需要注意的是，参数 `k` 不适用于 ramchunks。在 ramchunks 的上下文中，检索过程不同，因此 `k` 参数对返回文档数量的影响不适用。 -* `query`：（推荐参数）搜索查询，可以是： - - 文本字符串：如果字段配置了自动嵌入，则自动转换为嵌入向量。如果字段没有自动嵌入，将返回错误。 - - 向量数组：与 `query_vector` 功能相同。 -* `query_vector`：（遗留参数）作为数字数组的搜索向量。为向后兼容仍然支持。 - **注意：** 在同一请求中使用 `query` 或 `query_vector` 中的一个，不要同时使用。 -* `ef`：搜索过程中使用的动态列表大小的可选参数。`ef` 越大，搜索越准确但越慢。 -* `rescore`：启用 KNN 重新评分（默认禁用）。在 SQL 中设置为 `1`，在 JSON 中设置为 `true` 以启用重新评分。KNN 搜索完成后，使用量化向量（可能带有过采样）进行距离计算，然后用原始（全精度）向量重新计算距离并重新排序结果，以提高排名准确性。 -* `oversampling`：设置一个因子（浮点值），在执行 KNN 搜索时将 `k` 乘以该因子，导致使用量化向量检索的候选项多于所需数量。默认不应用过采样。如果启用重新评分，这些候选项可以稍后重新评估。过采样也适用于非量化向量。由于它增加了 `k`，影响 HNSW 索引的工作方式，可能会导致结果准确性略有变化。 - -文档始终按与搜索向量的距离排序。您指定的任何额外排序条件将在此主要排序条件之后应用。要获取距离，有一个内置函数叫做 [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29)。 +The parameters are: +* `field`: This is the name of the float vector attribute containing vector data. +* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable. +* `query`: (Recommended parameter) The search query, which can be either: + - Text string: Automatically converted to embeddings if the field has auto-embeddings configured. Will return an error if the field doesn't have auto-embeddings. + - Vector array: Works the same as `query_vector`. +* `query_vector`: (Legacy parameter) The search vector as an array of numbers. Still supported for backward compatibility. + **Note:** Use either `query` or `query_vector`, not both in the same request. +* `ef`: optional size of the dynamic list used during the search. A higher `ef` leads to more accurate but slower search. +* `rescore`: Enables KNN rescoring (disabled by default). Set to `1` in SQL or `true` in JSON to enable rescoring. After the KNN search is completed using quantized vectors (with possible oversampling), distances are recalculated with the original (full-precision) vectors and results are re-sorted to improve ranking accuracy. +* `oversampling`: Sets a factor (float value) by which `k` is multiplied when executing the KNN search, causing more candidates to be retrieved than needed using quantized vectors. No oversampling is applied by default. These candidates can be re-evaluated later if rescoring is enabled. Oversampling also works with non-quantized vectors. Since it increases `k`, which affects how the HNSW index works, it may cause a small change in result accuracy. + +Documents are always sorted by their distance to the search vector. Any additional sorting criteria you specify will be applied after this primary sort condition. For retrieving the distance, there is a built-in function called [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29). ##### SQL: @@ -419,14 +477,14 @@ POST /search -### 向量量化 +### Vector quantization -HNSW 索引需要完全加载到内存中以执行 KNN 搜索，这可能导致显著的内存消耗。为了减少内存使用，可以应用标量量化——一种通过用有限数量的离散值表示每个分量（维度）来压缩高维向量的技术。Manticore 支持 8 位和 1 位量化，意味着每个向量分量从 32 位浮点压缩到 8 位甚至 1 位，分别减少了 4 倍或 32 倍的内存使用。这些压缩表示还允许更快的距离计算，因为可以在单个 SIMD 指令中处理更多的向量分量。虽然标量量化引入了一些近似误差，但通常是在搜索准确性和资源效率之间值得的权衡。为了获得更好的准确性，量化可以与重新评分和过采样结合使用：检索的候选项多于请求的数量，并使用原始 32 位浮点向量重新计算这些候选项的距离。 +HNSW indexes need to be fully loaded into memory to perform KNN search, which can lead to significant memory consumption. To reduce memory usage, scalar quantization can be applied - a technique that compresses high-dimensional vectors by representing each component (dimension) with a limited number of discrete values. Manticore supports 8-bit and 1-bit quantization, meaning each vector component is compressed from a 32-bit float to 8 bits or even 1 bit, reducing memory usage by 4x or 32x, respectively. These compressed representations also allow for faster distance calculations, as more vector components can be processed in a single SIMD instruction. Although scalar quantization introduces some approximation error, it is often a worthwhile trade-off between search accuracy and resource efficiency. For even better accuracy, quantization can be combined with rescoring and oversampling: more candidates are retrieved than requested, and distances for these candidates are recalculated using the original 32-bit float vectors. -支持的量化类型包括： -* `8bit`：每个向量分量量化为 8 位。 -* `1bit`：每个向量分量量化为 1 位。使用非对称量化，查询向量量化为 4 位，存储向量量化为 1 位。这种方法比简单方法提供更高的精度，但性能有所折衷。 -* `1bitsimple`：每个向量分量量化为 1 位。此方法比 `1bit` 更快，但通常准确性较低。 +Supported quantization types include: +* `8bit`: Each vector component is quantized to 8 bits. +* `1bit`: Each vector component is quantized to 1 bit. Asymmetric quantization is used, with query vectors quantized to 4 bits and stored vectors to 1 bit. This approach offers greater precision than simpler methods, though with some performance trade-off. +* `1bitsimple`: Each vector component is quantized to 1 bit. This method is faster than `1bit`, but typically less accurate. ##### SQL: @@ -441,6 +499,27 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di ```sql Query OK, 0 rows affected (0.01 sec) ``` + + +##### JSON: + + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' quantization='1bit');" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + @@ -449,7 +528,7 @@ Query OK, 0 rows affected (0.01 sec) > 注意：通过 id 查找相似文档需要 [Manticore Buddy](../Installation/Manticore_Buddy.md)。如果无法使用，请确保已安装 Buddy。 -基于特定文档的唯一ID查找相似文档是一项常见任务。例如，当用户查看某个特定项目时，Manticore Search 可以高效地识别并显示在向量空间中与其最相似的项目列表。操作方法如下： +根据唯一 ID 查找类似文档是一项常见任务。例如，当用户查看某个特定条目时，Manticore Search 可以高效地识别并显示与该条目在向量空间中最相似的项目列表。操作方式如下： - SQL: `select ... from
where knn ( , , )` - JSON: @@ -467,9 +546,9 @@ Query OK, 0 rows affected (0.01 sec) ``` 参数说明： -* `field`：这是包含向量数据的浮点向量属性的名称。 -* `k`：表示返回的文档数量，是分层可导航小世界（HNSW）索引的关键参数。它指定单个 HNSW 索引应返回的文档数量。然而，最终结果中包含的文档实际数量可能会有所不同。例如，如果系统处理的是分割成磁盘块的实时表，每个块可能返回 `k` 个文档，导致总数超过指定的 `k`（因为累计数量为 `num_chunks * k`）。另一方面，如果在请求了 `k` 个文档后，根据特定属性过滤掉了一些文档，最终文档数量可能少于 `k`。需要注意的是，参数 `k` 不适用于 ramchunks。在 ramchunks 的上下文中，检索过程不同，因此 `k` 参数对返回文档数量的影响不适用。 -* `document id`：用于 KNN 相似度搜索的文档ID。 +* `field`：这是包含向量数据的浮点向量属性名称。 +* `k`：代表返回的文档数量，是层次导航小世界（HNSW）索引的一个关键参数。它指定单个 HNSW 索引应返回的文档数量。但最终结果中包含的文档数量可能会有所不同。例如，当系统处理分为磁盘块的实时表时，每个块都可能返回 `k` 个文档，导致总数超过指定的 `k`（因为总计为 `num_chunks * k`）。另一方面，如果请求了 `k` 个文档后，部分文档被基于特定属性过滤掉，则最终文档数可能少于 `k`。需要注意的是，参数 `k` 不适用于 ramchunks。在 ramchunks 的上下文中，检索过程不同，因此 `k` 参数对返回文档数量的影响不适用。 +* `document id`：用于 KNN 相似搜索的文档 ID。 @@ -542,7 +621,7 @@ POST /search ### 过滤 KNN 向量搜索结果 -Manticore 还支持通过全文匹配、属性过滤或两者结合，对 KNN 搜索返回的文档进行额外过滤。 +Manticore 还支持对 KNN 搜索返回的文档进行额外过滤，过滤方式可以是全文匹配、属性过滤，或两者结合。 ##### SQL: diff --git a/manual/chinese/Searching/Multi-queries.md b/manual/chinese/Searching/Multi-queries.md index 01ec59ae98..a3220ea348 100644 --- a/manual/chinese/Searching/Multi-queries.md +++ b/manual/chinese/Searching/Multi-queries.md @@ -4,16 +4,16 @@ 👍 为什么使用多查询？ -主要原因是性能。通过批量发送请求给 Manticore，而不是逐个发送，您可以通过减少网络往返时间来节省时间。此外，批量发送查询允许 Manticore 执行某些内部优化。如果无法应用批量优化，查询将被单独处理。 +主要原因是性能。通过批量发送请求给 Manticore，而不是一条条发送，您可以通过减少网络往返时间来节省时间。此外，批量发送查询还允许 Manticore 执行某些内部优化。如果无法应用批处理优化，查询将被单独处理。 -⛔ 何时不使用多查询？ +⛔ 什么时候不使用多查询？ -多查询要求批处理中的所有搜索查询相互独立，但情况并非总是如此。有时查询 B 依赖于查询 A 的结果，这意味着查询 B 只能在执行查询 A 后设置。例如，您可能只想在主表中未找到结果时显示来自辅助索引的结果，或者您可能想根据第一个结果集中的匹配数指定第二个结果集的偏移量。在这些情况下，您需要使用单独的查询（或单独的批处理）。 +多查询要求批处理中所有搜索查询相互独立，但情况并非总是如此。有时查询 B 依赖于查询 A 的结果，也就是说查询 B 只能在执行查询 A 后才能设置。例如，您可能想在主表中没有找到结果时，显示来自辅助索引的结果，或者您可能想基于第一个结果集中的匹配数，指定第二个结果集的偏移量。在这些情况下，您需要使用单独的查询（或单独的批处理）。 -您可以通过用分号分隔多个搜索查询来运行多查询。当 Manticore 从客户端接收到这样格式的查询时，将应用所有语句间的优化。 +您可以通过用分号分隔多个搜索查询来使用 SQL 运行多查询。当 Manticore 从客户端接收到这样格式的查询时，所有语句间的优化都将被应用。 -多查询不支持带有 `FACET` 的查询。单个批处理中的多查询数量不应超过 [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries)。 +多查询不支持带 `FACET` 的查询。单个批处理中的多查询数量不应超过 [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries)。 @@ -26,15 +26,25 @@ SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; S ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price ASC" +``` + + ## 多查询优化 -需要注意两种主要优化：公共查询优化和公共子树优化。 +主要有两种需要注意的优化：公共查询优化和公共子树优化。 -**公共查询优化** 意味着 `searchd` 会识别批处理中所有仅排序和分组设置不同的查询，并且*只执行一次搜索*。例如，如果一个批处理包含 3 个查询，它们都是针对“ipod nano”的，但第一个查询请求按价格排序的前 10 个结果，第二个查询按供应商 ID 分组并请求按评分排序的前 5 个供应商，第三个查询请求最大价格，则全文搜索“ipod nano”只会执行一次，其结果将被重用以构建 3 个不同的结果集。 +**公共查询优化** 意味着 `searchd` 会识别批处理中所有仅排序和分组设置不同的查询，并*只执行一次搜索*。例如，如果批处理中有 3 个查询，它们都是针对 "ipod nano" 的，但第一个查询请求按价格排序的前 10 条结果，第二个查询按供应商 ID 分组并请求按评分排序的前 5 个供应商，第三个查询请求最大价格，则全文搜索 "ipod nano" 只会执行一次，其结果将被重用以构建这 3 个不同的结果集。 -[分面搜索](../Searching/Faceted_search.md) 是特别受益于此优化的一个重要案例。实际上，分面搜索可以通过运行多个查询来实现，一个用于检索搜索结果本身，其他几个使用相同的全文查询但不同的分组设置来检索所有所需的结果组（前 3 名作者，前 5 名供应商等）。只要全文查询和过滤设置保持不变，公共查询优化就会触发，并大大提高性能。 +[分面搜索](../Searching/Faceted_search.md) 是特别受益于此优化的一个重要案例。事实上，分面搜索可以通过运行多个查询来实现，一个查询检索搜索结果本身，几个其他查询使用相同的全文查询但不同的分组设置，以检索所有所需的结果组（前 3 名作者，前 5 名供应商等）。只要全文查询和过滤设置保持相同，公共查询优化便会被触发，大幅提升性能。 -**公共子树优化** 更加有趣。它允许 `searchd` 利用批量全文查询之间的相似性。它识别所有查询中的公共全文查询部分（子树）并在查询之间缓存它们。例如，考虑以下查询批处理： +**公共子树优化** 则更加有趣。它允许 `searchd` 利用批量全文查询之间的相似性。它识别所有查询中的公共全文查询部分（子树），并在查询间缓存它们。例如，考虑以下查询批处理： ```bash donald trump president @@ -42,12 +52,12 @@ donald trump barack obama john mccain donald trump speech ``` -有一个公共的两词部分 `donald trump`，只需计算一次，然后缓存并在查询间共享。公共子树优化正是这样做的。每个查询的缓存大小由 [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) 和 [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) 指令严格控制（以防缓存*所有*匹配“i am”的十六亿亿文档耗尽内存并立即导致服务器崩溃）。 +这里存在一个共同的两词部分 `donald trump`，只需计算一次，然后缓存并在查询间共享。公共子树优化就是这样工作的。每个查询的缓存大小由 [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) 和 [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) 指令严格控制（以防缓存 *所有* 匹配 “i am” 的十六亿兆文档耗尽内存并立即使服务器崩溃）。 -如何判断批处理中的查询是否真的被优化了？如果是，相关的查询日志将有一个“multiplier”字段，指定一起处理了多少个查询： +怎么判断批处理中的查询是否确实被优化了？如果是，相关查询日志将包含一个 "multiplier" 字段，指定一起处理了多少个查询： -注意“x3”字段。这意味着该查询被优化并在一个包含 3 个查询的子批处理中处理。 +注意 "x3" 字段。这意味着此查询被优化，并在一个包含 3 个查询的子批处理中处理。 @@ -76,7 +86,7 @@ donald trump speech ``` -注意多查询情况下每个查询的时间提升了 1.5 倍到 2.3 倍，具体取决于排序模式。 +注意多查询情况下每个查询的时间提升了 1.5 到 2.3 倍，具体取决于排序模式。 diff --git a/manual/chinese/Searching/Options.md b/manual/chinese/Searching/Options.md index 7270c6f1df..401025956f 100644 --- a/manual/chinese/Searching/Options.md +++ b/manual/chinese/Searching/Options.md @@ -285,20 +285,20 @@ IDF 标志可以组合使用；`plain` 和 `normalized` 互斥；`tfidf_unnormal 请注意，如果该阈值设置过高，会导致内存消耗增加和整体性能下降。 -您还可以使用[accurate_aggregation](../Searching/Options.md#accurate_aggregation)选项强制执行保证的groupby/聚合准确模式。 +您还可以使用[accurate_aggregation](../Searching/Options.md#accurate_aggregation) 选项强制保证 groupby/聚合的准确模式。 ### max_query_time -设置最大搜索查询时间，单位为毫秒。必须是非负整数。默认值为0，表示“不限制”。本地搜索查询将在指定时间到达后停止。请注意，如果您执行的是查询多个本地表的搜索，则此限制分别适用于每个表。请注意，由于不断跟踪是否该停止查询，这可能会略微增加查询的响应时间。 +设置最大搜索查询时间，单位为毫秒。必须为非负整数。默认值为 0，表示“不限制”。本地搜索查询将在达到指定时间后停止。请注意，如果您执行的是查询多个本地表的搜索，此限制对每个表分别适用。请注意，由于需要不断跟踪是否到达停止查询时间，这可能会略微增加查询的响应时间。 ### max_predicted_time 整数。最大预测搜索时间；参见[predicted_time_costs](../Server_settings/Searchd.md#predicted_time_costs)。 ### morphology -`none`允许将所有查询词替换为其精确形式，前提是表是在启用[index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words)的情况下构建的。这对于防止查询词的词干提取或词形还原非常有用。 +`none` 允许在表使用了 [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words) 时，将所有查询词替换为其精确形式。这对于防止查询词的词干化或词形还原非常有用。 ### not_terms_only_allowed -`0`或`1`允许查询中独立的[否定](../Searching/Full_text_matching/Operators.md#Negation-operator)。默认值为0。另请参见相应的[全局设置](../Server_settings/Searchd.md#not_terms_only_allowed)。 +`0` 或 `1` 允许查询中独立的[否定](../Searching/Full_text_matching/Operators.md#Negation-operator)。默认值为0。另请参见对应的[全局设置](../Server_settings/Searchd.md#not_terms_only_allowed)。 ```sql @@ -311,10 +311,62 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all | 1658178727135150081 | smth else | +---------------------+-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select * from tbl where match('-d');" +{ + "error": "table t: query error: query is non-computable (single NOT operator)" +} + +POST /sql?mode=raw -d "select * from t where match('-d') option not_terms_only_allowed=1;" +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "c", + "f2": 3 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ### ranker -可从以下选项中选择： +可选以下排名器： * `proximity_bm25` * `bm25` * `none` @@ -326,10 +378,10 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all * `expr` * `export` -有关每个排序器的更多详细信息，请参阅[搜索结果排名](../Searching/Sorting_and_ranking.md#Available-built-in-rankers)。 +关于每个排名器的详细信息，请参考[搜索结果排名](../Searching/Sorting_and_ranking.md#Available-built-in-rankers)。 ### rand_seed -允许您为`ORDER BY RAND()`查询指定特定的整数种子值，例如：`... OPTION rand_seed=1234`。默认情况下，每个查询都会自动生成一个新的不同的种子值。 +允许您为 `ORDER BY RAND()` 查询指定特定的整数种子值，例如：`... OPTION rand_seed=1234`。默认情况下，每个查询都会自动生成一个新的不同的种子值。 ### retry_count 整数。分布式重试次数。 @@ -343,32 +395,32 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all ### sort_method * `pq` - 优先队列，默认设置 -* `kbuffer` - 为已预排序数据提供更快的排序，例如按id排序的表数据 -两种情况下的结果集相同；选择其中一个选项可能仅仅是提高（或降低）性能。 +* `kbuffer` - 为已经预排序的数据提供更快的排序，例如按 id 排序的表数据 +两种方式结果集相同；选择其中一个选项可能仅影响性能的提升或降低。 ### threads -限制当前查询处理使用的最大线程数。默认 - 无限制（查询可以占用全局定义的所有[线程](../Server_settings/Searchd.md#threads)）。 -对于一批查询，该选项必须附加到批次中的第一个查询，然后在创建工作队列时应用，并对整个批次生效。此选项与选项[max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query)含义相同，但仅应用于当前查询或查询批次。 +限制当前查询处理使用的最大线程数。默认不限制（查询可占用全局定义的所有[线程](../Server_settings/Searchd.md#threads)）。 +对于一批查询，该选项必须附加在批次中的第一个查询上，并在创建工作队列时生效，对整个批次有效。该选项与选项[max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query)含义相同，但仅应用于当前查询或查询批次。 ### token_filter -带引号的、用冒号分隔的字符串，格式为`library name:plugin name:optional string of settings`。每当涉及的每个表调用全文搜索时，都会为每次搜索创建一个查询时令牌过滤器，允许您实现根据自定义规则生成令牌的自定义分词器。 +引号包围的，并用冒号分隔的字符串格式为 `库名:插件名:可选的设置字符串`。查询时的令牌过滤器在每个涉及的表调用全文索引时创建，允许您实现根据自定义规则生成令牌的自定义分词器。 ```sql SELECT * FROM index WHERE MATCH ('yes@no') OPTION token_filter='mylib.so:blend:@' ``` ### expansion_limit -限制单个通配符展开的最大关键字数，默认值为0表示无限制。更多详情请参阅[expansion_limit](../Server_settings/Searchd.md#expansion_limit)。 +限制单个通配符所展开的最大关键词数，默认值为0表示不限制。有关详细信息，请参阅[expansion_limit](../Server_settings/Searchd.md#expansion_limit)。 ## 查询优化器提示 -在极少数情况下，Manticore内置的查询分析器可能无法正确理解查询并确定应使用docid索引、二级索引还是列扫描。要覆盖查询优化器的决策，您可以在查询中使用以下提示： +在极少数情况下，Manticore 内置的查询分析器可能无法正确理解查询，也可能无法正确决定应使用 docid 索引、二级索引还是列式扫描。要覆盖查询优化器的决定，可以在查询中使用以下提示： -* `/*+ DocidIndex(id) */` 强制使用docid索引，`/*+ NO_DocidIndex(id) */` 告诉优化器忽略它 +* `/*+ DocidIndex(id) */` 强制使用 docid 索引，`/*+ NO_DocidIndex(id) */` 告诉优化器忽略它 * `/*+ SecondaryIndex([, ]) */` 强制使用二级索引（如果可用），`/*+ NO_SecondaryIndex(id) */` 告诉优化器忽略它 -* `/*+ ColumnarScan([, ]) */` 强制使用列扫描（如果属性是列式的），`/*+ NO_ColumnarScan(id) */` 告诉优化器忽略它 +* `/*+ ColumnarScan([, ]) */` 强制使用列式扫描（如果属性是列式的），`/*+ NO_ColumnarScan(id) */` 告诉优化器忽略它 -请注意，在执行带过滤器的全文查询时，查询优化器会决定是将全文树结果与过滤器结果相交，还是使用标准的先匹配后过滤方法。指定*任何*提示都会强制守护进程使用执行全文树结果与过滤器结果相交的代码路径。 +请注意，在执行带过滤器的全文查询时，查询优化器会决定是将全文树结果与过滤结果求交叉还是使用标准的匹配后过滤方法。指定*任何*提示都会强制守护进程使用执行全文树结果与过滤结果交集的代码路径。 有关查询优化器工作原理的更多信息，请参阅[基于成本的优化器](../Searching/Cost_based_optimizer.md)页面。 @@ -378,10 +430,16 @@ SELECT * FROM index WHERE MATCH ('yes@no') OPTION token_filter='mylib.so:blend:@ SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */" +``` + -使用MySQL/MariaDB客户端时，请确保包含`--comments`标志以启用查询中的提示。 +使用 MySQL/MariaDB 客户端时，确保包含 `--comments` 标志以启用查询中的提示。 ```bash diff --git a/manual/chinese/Searching/Percolate_query.md b/manual/chinese/Searching/Percolate_query.md index eca1b37785..89b5ab7728 100644 --- a/manual/chinese/Searching/Percolate_query.md +++ b/manual/chinese/Searching/Percolate_query.md @@ -890,7 +890,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -##### 我想知道与我的文档匹配的完整 PQ 规则 +##### 我想知道完全匹配我文档的 PQ 规则 SQL: @@ -1263,7 +1263,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -##### 多个文档怎么样？ +##### 多文档情况如何处理？ 请注意，使用 `CALL PQ`，您可以通过不同方式提供多个文档： @@ -1785,7 +1785,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc ##### 我想知道哪些文档匹配哪些规则 -使用选项 `1 as docs` 可以让您看到提供的文档中哪些匹配哪些规则。 +使用选项 `1 as docs` 允许您查看提供的文档中哪些匹配了哪些规则。 SQL: @@ -2280,10 +2280,10 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -#### 静态 id -默认情况下，匹配的文档 id 对应于您提供列表中的相对编号。但是，在某些情况下，每个文档已经有自己的 id。对于这种情况，`CALL PQ` 有一个选项 `'id field name' as docs_id`。 +#### 静态 ID +默认情况下，匹配文档的 ID 对应于您提供列表中的相对编号。但是，在某些情况下，每个文档已经有自己的 ID。对于这种情况，`CALL PQ` 有一个选项 `'id field name' as docs_id`。 -请注意，如果通过提供的字段名找不到 id，则 PQ 规则不会显示在结果中。 +请注意，如果通过提供的字段名找不到 ID，则结果中不会显示该 PQ 规则。 此选项仅适用于通过 SQL 使用 `CALL PQ`。 @@ -2305,12 +2305,76 @@ CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue" | 1657852401006149666 | 123 | @title shoes | | color IN ('blue, 'green') | +---------------------+-----------+--------------+------+---------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue"}, {"id": 456, "title": "beautiful bag"}]', 1 as query, 'id' as docs_id, 1 as docs);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "documents": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149664, + "documents": 456, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149666, + "documents": 123, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### 我可能有无效的 JSON，请跳过它们 -当使用带有独立 JSON 的 CALL PQ 时，您可以使用选项 1 作为 skip_bad_json 来跳过输入中的任何无效 JSON。在下面的示例中，第 2 个查询由于无效的 JSON 而失败，但第 3 个查询通过使用 1 作为 skip_bad_json 避免了错误。请记住，当通过 HTTP 发送 JSON 查询时，此选项不可用，因为在这种情况下整个 JSON 查询必须是有效的。 +当使用带有独立 JSON 的 CALL PQ 时，您可以使用选项 1 作为 skip_bad_json 来跳过输入中的任何无效 JSON。下面的示例中，第 2 个查询由于无效的 JSON 而失败，但第 3 个查询通过使用 1 作为 skip_bad_json 避免了错误。请记住，当通过 HTTP 发送 JSON 查询时，此选项不可用，因为此时整个 JSON 查询必须有效。 SQL: @@ -2342,15 +2406,77 @@ ERROR 1064 (42000): Bad JSON objects in strings: 2 +---------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'), 1 as skip_bad_json);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + }, + { + "id": 1657852401006149637 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] + +{ + "error": "Bad JSON objects in strings: 1" +} + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -##### 我想要更高性能的 percolate 查询 -Percolate 查询是为高吞吐量和大数据量设计的。为了优化性能以实现更低的延迟和更高的吞吐量，请考虑以下内容。 +##### 我想获得更高性能的 percolate 查询 +Percolate 查询设计时考虑了高吞吐量和大数据量。为了优化性能，实现更低延迟和更高吞吐量，请考虑以下几点。 -percolate 表有两种分布模式，以及 percolate 查询如何针对它工作： +Percolate 表有两种分布模式，以及 percolate 查询如何针对它们工作： -* **稀疏（默认）。** 适用于：大量文档，镜像 PQ 表。当您的文档集很大但存储在 PQ 表中的查询集较小时，稀疏模式是有益的。在此模式下，您传递的文档批次将被分配给多个代理，因此每个节点只处理请求中文档的一部分。Manticore 会拆分您的文档集并在镜像之间分发块。一旦代理完成查询处理，Manticore 会收集并合并结果，返回一个最终的查询集，就像它来自单个表一样。使用[复制](../References.md#Replication)来辅助此过程。 -* **分片。** 适用于：大量 PQ 规则，规则分布在多个 PQ 表中。在此模式下，整个文档集会广播到分布式 PQ 表的所有表，而不会初始拆分文档。当推送的文档集相对较小时，但存储的查询数量很大时，这种方式是有益的。在这种情况下，更适合在每个节点上只存储部分 PQ 规则，然后合并从处理相同文档集但针对不同 PQ 规则集的节点返回的结果。此模式必须显式设置，因为它意味着网络负载增加，并且期望表具有不同的 PQ，这一点是[复制](../References.md#Replication)无法开箱即用实现的。 +* **稀疏（默认）。** 适用于：大量文档，镜像 PQ 表。当您的文档集很大但存储在 PQ 表中的查询集很小时，稀疏模式是有益的。在此模式中，您传递的文档批次将被分配到多个代理数量中，因此每个节点只处理请求中文档的一部分。Manticore 将您的文档集拆分并分发给镜像。一旦代理完成查询处理，Manticore 会收集并合并结果，返回一个就像来自单一表的最终查询集。使用[复制](../References.md#Replication)来辅助该过程。 +* **分片。** 适用于：大量 PQ 规则，规则分散在多个 PQ 表中。在此模式下，整个文档集会广播到分布式 PQ 表的所有表中，而不是最初拆分文档。当推送的文档集相对较小时，但存储的查询数量很大时，这种方式更合适。在这种情况下，更合适是在每个节点只存储部分 PQ 规则，然后合并从不同节点处理同一文档集但针对不同 PQ 规则集返回的结果。该模式必须明确设置，因为它意味着网络负载增加，并且期望表具有不同的 PQ，这超出了[复制](../References.md#Replication)的默认能力。 假设您有定义为： @@ -2364,7 +2490,7 @@ table pq_d2 ``` -“pq”和“ptitle”各自包含： +'pq' 和 'ptitle' 分别包含： @@ -2755,7 +2881,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -然后您在分布式表上执行 `CALL PQ`，并传入几个文档。 +并且您用几个文档对分布式表执行 `CALL PQ`。 @@ -3212,7 +3338,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -在前面的示例中，我们使用了默认的 **稀疏** 模式。为了演示 **分片** 模式，让我们创建一个由 2 个本地 PQ 表组成的分布式 PQ 表，并向 "products1" 添加 2 个文档，向 "products2" 添加 1 个文档： +在上一个示例中，我们使用了默认的**稀疏**模式。为了演示**分片**模式，我们创建一个由两个本地 PQ 表组成的分布式 PQ 表，并向 "products1" 添加 2 个文档，向 "products2" 添加 1 个文档： ```sql create table products1(title text, color string) type='pq'; create table products2(title text, color string) type='pq'; @@ -3224,7 +3350,7 @@ INSERT INTO products2(query,filters) values('@title shoes', 'color in (\'blue\', ``` -现在，如果您向 `CALL PQ` 添加 `'sharded' as mode`，它将把文档发送到所有代理的表（在此情况下仅本地表，但它们可以是远程的以利用外部硬件）。此模式通过 JSON 接口不可用。 +现在，如果您在 `CALL PQ` 中加入 `'sharded' as mode`，它将把文档发送到所有代理的表（在本例中仅本地表，但它们也可以是远程的，以利用外部硬件）。此模式在 JSON 接口中不可用。 SQL: @@ -3244,16 +3370,71 @@ CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue +---------------------+--------------+------+---------------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'), 'sharded' as mode, 1 as query);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149639, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149643, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -请注意，配置中代理镜像的语法（当一个 `agent` 行分配了多个主机，用 `|` 分隔）与 `CALL PQ` 查询模式无关。每个 `agent` 始终代表**一个**节点，无论为该代理指定了多少 HA 镜像。 +请注意，配置中代理镜像的语法（当多个主机分配给一条 `agent` 线路且以 `|` 分隔时）与 `CALL PQ` 查询模式无关。每个 `agent` 始终代表**一个**节点，无论该代理指定了多少 HA 镜像。 -##### 我如何了解更多关于性能的信息？ -在某些情况下，您可能想要获取有关 percolate 查询性能的更多详细信息。为此，有一个选项 `1 as verbose`，该选项仅通过 SQL 可用，允许您保存更多性能指标。您可以使用 `SHOW META` 查询查看它们，该查询可以在 `CALL PQ` 之后运行。有关更多信息，请参见 [SHOW META](../Node_info_and_management/SHOW_META.md)。 +##### 我如何能了解更多关于性能的信息？ +在某些情况下，您可能想要获得有关穿透查询性能的更多详细信息。为此，有一个选项 `1 as verbose`，该选项仅通过 SQL 可用，允许您保存更多的性能指标。您可以使用 `SHOW META` 查询查看它们，该查询可以在 `CALL PQ` 之后运行。更多信息请参见 [SHOW META](../Node_info_and_management/SHOW_META.md)。 -1 as verbose: +1 as verbose： ```sql @@ -3284,7 +3465,7 @@ CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"titl +-------------------------+-----------+ ``` -0 as verbose (default): +0 as verbose（默认）： ```sql diff --git a/manual/chinese/Searching/Search_results.md b/manual/chinese/Searching/Search_results.md index 8290dc231b..32ac137866 100644 --- a/manual/chinese/Searching/Search_results.md +++ b/manual/chinese/Searching/Search_results.md @@ -3,7 +3,7 @@ ## SQL -当您通过 MySQL 协议运行 SQL 查询时，您将收到请求的列作为结果，如果未找到任何内容，则返回空结果集。 +当您通过 MySQL 协议运行 SQL 查询时，您将收到请求的列作为结果，如果未找到任何内容，则返回一个空结果集。 ```sql @@ -21,10 +21,62 @@ SELECT * FROM tbl; +------+------+--------+ 3 rows in set (0.00 sec) ``` + + +```JSON +POST /sql -d "SELECT * FROM tbl;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "age": { + "type": "long" + } + }, + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "age": "joe", + "name": 25 + }, + { + "id": 2, + "age": "mary", + "name": 255 + }, + { + "id": 3, + "age": "albert", + "name": 33 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] + +``` + -此外，您可以使用 [SHOW META](../Node_info_and_management/SHOW_META.md) 调用查看有关最新查询的额外元信息。 +此外，您可以使用 [SHOW META](../Node_info_and_management/SHOW_META.md) 调用来查看有关最新查询的额外元信息。 ```sql @@ -52,10 +104,86 @@ SELECT id,story_author,comment_author FROM hn_small WHERE story_author='joe' LIM +----------------+-------+ 4 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id,f1,f2 FROM t WHERE f2=2 LIMIT 1; SHOW META;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "gte" + }, + { + "Variable_name": "time", + "Value": "0.000" + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + -在某些情况下，例如执行[分面搜索](../Searching/Faceted_search.md)时，您可能会收到多个结果集作为 SQL 查询的响应。 +在某些情况下，例如执行 [分面搜索](../Searching/Faceted_search.md) 时，您可能会收到多个结果集作为对您的 SQL 查询的响应。 ```sql @@ -78,6 +206,75 @@ SELECT * FROM tbl WHERE MATCH('joe') FACET age; +------+----------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM tbl WHERE MATCH('b') FACET f2;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 2, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "f2": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "f2": 2, + "count(*)": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -103,10 +300,74 @@ SELECT * from tbl where match('"joe"/3'); show warnings; +---------+------+--------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('\"a\"/3'); show warnings;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f2": { + "type": "long" + } + }, + { + "f1": { + "type": "string" + } + } + ], + "data": [], + "total": 0, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Level": { + "type": "string" + } + }, + { + "Code": { + "type": "decimal" + } + }, + { + "Message": { + "type": "string" + } + } + ], + "data": [ + { + "Level": "warning", + "Code": "1000", + "Message": "table t: quorum threshold too high (words=1, thresh=3); replacing quorum operator with AND operator" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -如果查询失败，您将收到错误信息： +如果您的查询失败，您将收到一个错误： ```sql @@ -118,12 +379,24 @@ SELECT * from tbl where match('@surname joe'); ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema ``` + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('@surname joe');" +``` + + +```JSON +{ + "error": "table t: query error: no field 'surname' found in schema" +} +``` + ## HTTP -通过 HTTP JSON 接口，查询结果以 JSON 文档的形式发送。示例： +通过 HTTP JSON 接口，查询结果以 JSON 文档格式发送。示例： ```json { @@ -149,23 +422,23 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema } ``` -* `took`：执行搜索所花费的时间，单位为毫秒 +* `took`：执行搜索所用时间，单位为毫秒 * `timed_out`：查询是否超时 * `hits`：搜索结果，包含以下属性： - `total`：匹配文档的总数 - `hits`：包含匹配项的数组 -查询结果还可以包含查询分析信息。请参见 [查询分析](../Node_info_and_management/Profiling/Query_profile.md)。 +查询结果还可以包含查询配置文件信息。参见 [查询配置文件](../Node_info_and_management/Profiling/Query_profile.md)。 `hits` 数组中的每个匹配项具有以下属性： * `_id`：匹配 ID -* `_score`：匹配权重，由排序器计算 -* `_source`：包含该匹配项属性的数组 +* `_score`：匹配权重，由排序器计算得出 +* `_source`：包含此匹配项属性的数组 ### 源选择 -默认情况下，所有属性都会在 `_source` 数组中返回。您可以在请求负载中使用 `_source` 属性选择要包含在结果集中的字段。示例： +默认情况下，所有属性都返回在 `_source` 数组中。您可以在请求负载中使用 `_source` 属性选择要包含在结果集中的字段。示例： ```json { @@ -175,9 +448,9 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema } ``` -您可以将要包含在查询结果中的属性指定为字符串（`"_source": "attr*"`）或字符串数组（`"_source": [ "attr1", "attri*" ]"`）。每个条目可以是属性名或通配符（支持 `*`、`%` 和 `?` 符号）。 +您可以将要包含在查询结果中的属性指定为字符串 (`"_source": "attr*"`) 或字符串数组 (`"_source": [ "attr1", "attri*" ]`)。每个条目可以是属性名称或通配符（支持 `*`、`%` 和 `?` 符号）。 -您还可以使用 `includes` 和 `excludes` 属性显式指定要包含和排除的属性： +您还可以使用 `includes` 和 `excludes` 属性显式指定您希望包含或从结果集中排除的属性： ```json "_source": @@ -187,7 +460,7 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema } ``` -空的 includes 列表被解释为“包含所有属性”，而空的 excludes 列表不匹配任何内容。如果某个属性同时匹配 includes 和 excludes，则以 excludes 为准。 +空的 includes 列表被解释为“包含所有属性”，而空的 excludes 列表不会匹配任何内容。如果一个属性同时匹配 includes 和 excludes，则以 excludes 为准。 diff --git a/manual/chinese/Searching/Sorting_and_ranking.md b/manual/chinese/Searching/Sorting_and_ranking.md index 46a31b2d67..1e1e5ea328 100644 --- a/manual/chinese/Searching/Sorting_and_ranking.md +++ b/manual/chinese/Searching/Sorting_and_ranking.md @@ -1,14 +1,14 @@ # 排序和排名 -查询结果可以按全文排名权重、一个或多个属性或表达式进行排序。 +查询结果可以按全文排名权重、一个或多个属性或表达式排序。 -**全文** 查询默认返回排序的匹配项。如果未指定任何内容，则按相关性排序，这相当于 SQL 格式中的 `ORDER BY weight() DESC`。 +**全文** 查询默认返回排序后的匹配项。如果没有指定任何内容，则按相关性排序，这相当于 SQL 格式中的 `ORDER BY weight() DESC` 。 -**非全文** 查询默认不执行任何排序。 +**非全文** 查询默认不进行任何排序。 ## 高级排序 -当您通过添加 SQL 格式的 `ORDER BY` 子句或通过 HTTP JSON 使用 `sort` 选项显式提供排序规则时，自动启用扩展模式。 +当您显式通过添加 SQL 格式的 `ORDER BY` 子句或通过 HTTP JSON 使用 `sort` 选项提供排序规则时，扩展模式会自动启用。 ### 通过 SQL 排序 @@ -22,7 +22,7 @@ SELECT ... ORDER BY -在排序子句中，您可以使用最多 5 列的任意组合，每列后跟 `asc` 或 `desc`。函数和表达式不允许作为排序子句的参数，除了 `weight()` 和 `random()` 函数（后者只能通过 SQL 以 `ORDER BY random()` 形式使用）。但是，您可以在 SELECT 列表中使用任何表达式，并按其别名排序。 +在排序子句中，您可以使用最多 5 列的任意组合，每列后跟 `asc` 或 `desc`。不允许将函数和表达式作为排序子句的参数，除了 `weight()` 和 `random()` 函数（后者只能以 `ORDER BY random()` 形式通过 SQL 使用）。但是，您可以在 SELECT 列表中使用任何表达式，并按其别名排序。 ```sql @@ -38,12 +38,64 @@ select *, a + b alias from test order by alias desc; +------+------+------+----------+-------+ ``` + +```JSON +POST /sql?mode=raw -d "select *, a + b alias from test order by alias desc;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "a": { + "type": "long" + } + }, + { + "b": { + "type": "long" + } + }, + { + "f": { + "type": "string" + } + }, + { + "alias": { + "type": "long" + } + } + ], + "data": [ + { + "id": 1, + "a": 2, + "b": 3, + "f": document, + "alias": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## 通过 JSON 排序 -`"sort"` 指定一个数组，其中每个元素可以是属性名，或者如果您想按匹配权重排序则为 `_score`，如果想要随机匹配顺序则为 `_random`。在这种情况下，属性的排序顺序默认为升序，`_score` 默认为降序。 +`"sort"` 指定了一个数组，每个元素可以是属性名，若想按匹配权重排序则使用 `_score`，若想随机匹配顺序则使用 `_random`。在这种情况下，属性默认为升序排序，`_score` 默认为降序排序。 @@ -219,8 +271,8 @@ searchRequest.SetSort(sort) 您也可以显式指定排序顺序： -* `asc`：升序排序 -* `desc`：降序排序 +* `asc`：按升序排序 +* `desc`：按降序排序 @@ -414,7 +466,7 @@ searchRequest.SetSort(sort) -您还可以使用另一种语法，通过 `order` 属性指定排序顺序： +您也可以使用另一种语法，通过 `order` 属性指定排序顺序： @@ -602,7 +654,7 @@ searchRequest.SetSort(sort) -JSON 查询中也支持按 MVA 属性排序。排序模式可以通过 `mode` 属性设置。支持以下模式： +JSON 查询也支持按 MVA 属性排序。排序模式可以通过 `mode` 属性设置。支持以下模式： * `min`：按最小值排序 * `max`：按最大值排序 @@ -793,7 +845,7 @@ searchRequest.SetSort(sort) -当按属性排序时，默认禁用匹配权重（分数）计算（不使用排名器）。您可以通过将 `track_scores` 属性设置为 `true` 来启用权重计算： +当按某个属性排序时，匹配权重（分数）计算默认被禁用（不使用排名器）。您可以通过将 `track_scores` 属性设置为 `true` 来启用权重计算： @@ -992,49 +1044,49 @@ searchRequest.SetSort(sort) ## 排名概述 -排名（也称为加权）搜索结果可以定义为一个过程，即针对每个匹配的文档计算所谓的相关性（权重），以对应匹配它的查询。因此，相关性最终只是附加到每个文档上的一个数字，用于估计该文档与查询的相关程度。然后可以基于该数字和/或一些附加参数对搜索结果进行排序，使得最受关注的结果出现在结果页的更高位置。 +排名（也称为加权）搜索结果可以定义为对每个匹配的文档相对于匹配它的查询计算所谓相关性（权重）的过程。 因此，相关性最终只是附加到每个文档上的一个数字，用于估计该文档与查询的相关程度。然后可以基于该数字和/或一些附加参数对搜索结果进行排序，以便最受关注的结果出现在结果页的较高位置。 -没有一种适用于所有场景的单一标准排名方法。更重要的是，永远不可能有这样的方式，因为相关性是*主观的*。也就是说，对你来说相关的内容，对我来说可能不相关。因此，在一般情况下，相关性不仅难以计算；从理论上讲是不可能的。 +没有单一通用的标准方法可以在任何场景中对任何文档进行排名。更重要的是，这样的方法永远不可能存在，因为相关性是*主观的*。换句话说，对你而言相关的东西对我而言可能不相关。因此，在一般情况下，不仅很难计算；从理论上讲是不可能的。 -所以 Manticore 中的排名是可配置的。它有一个所谓的**ranker**（排名器）的概念。排名器可以形式化定义为一个函数，输入为文档和查询，输出为相关性值。通俗地说，排名器控制 Manticore 使用哪种具体算法来为文档分配权重。 +所以 Manticore 中的排序是可配置的。它有一个所谓的**排序器**的概念。排序器可以形式上定义为一个函数，它以文档和查询为输入，输出一个相关性值。通俗来说，排序器控制着 Manticore 使用哪种具体算法为文档分配权重。 -## 可用的内置排名器 +## 内置排序器 -Manticore 附带了几个适用于不同用途的内置排名器。它们中的许多使用两个因素：短语接近度（也称为 LCS）和 BM25。短语接近度基于关键词位置，而 BM25 基于关键词频率。基本上，文档正文与查询之间的短语匹配程度越好，短语接近度越高（当文档包含整个查询的逐字引用时达到最大值）。而 BM25 在文档包含更多稀有词时更高。详细讨论留待后面。 +Manticore 提供了几种适用于不同用途的内置排序器。它们中的许多使用两个因素：短语接近度（也称为 LCS）和 BM25。短语接近度依赖关键词的位置，BM25 依赖关键词频率。本质上，文档正文与查询之间短语匹配程度越高，短语接近度越高（当文档包含查询的完整逐字引用时，达到最大值）。BM25 在文档包含更多稀有词时更高。详细讨论稍后再讲。 -当前实现的排名器有： +当前实现的排序器有： -* `proximity_bm25`，默认排名模式，结合使用短语接近度和 BM25 排名。 -* `bm25`，统计排名模式，仅使用 BM25 排名（类似大多数其他全文引擎）。此模式更快，但对于包含多个关键词的查询可能导致质量较差。 -* `none`，无排名模式。此模式显然是最快的。所有匹配赋予权重 1。有时称为布尔搜索，只匹配文档但不排名。 -* `wordcount`，按关键词出现次数排名。该排名器计算每个字段的关键词出现次数，然后乘以字段权重，最后求和。 -* `proximity` 返回原始短语接近度值。此模式内部用于模拟 `SPH_MATCH_ALL` 查询。 -* `matchany` 返回之前在 `SPH_MATCH_ANY` 模式下计算的排名，内部用于模拟 `SPH_MATCH_ANY` 查询。 -* `fieldmask` 返回一个 32 位掩码，第 N 位对应第 N 个全文字段（从 0 开始编号）。只有当相应字段有满足查询的关键词出现时，该位才会被设置。 -* `sph04` 通常基于默认的 `proximity_bm25` 排名器，但额外提升匹配出现在文本字段开头或结尾的权重。因此，如果字段等于精确查询，`sph04` 应该将其排名高于包含精确查询但不完全相等的字段。（例如，当查询为“Hyde Park”时，标题为“Hyde Park”的文档应排名高于标题为“Hyde Park, London”或“The Hyde Park Cafe”的文档。） -* `expr` 允许你在运行时指定排名公式。它暴露了几个内部文本因素，并允许你定义如何从这些因素计算最终权重。你可以在[下面的小节](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors)中找到其语法和可用因素的参考详情。 +* `proximity_bm25`，默认排序模式，结合使用短语接近度和 BM25 排名。 +* `bm25`，只使用 BM25 排名的统计排序模式（类似于大多数其他全文搜索引擎）。该模式较快，但在查询包含多个关键词时可能导致质量下降。 +* `none`，无排序模式。该模式显然是最快的。所有匹配均赋值权重为 1。有时称为布尔搜索，只匹配文档但不排序。 +* `wordcount`，按关键词出现次数排名。该排序器计算每个字段的关键词出现次数，然后乘以字段权重，并将结果相加。 +* `proximity` 返回原始短语接近度值。该模式内部用于模拟 `SPH_MATCH_ALL` 查询。 +* `matchany` 返回在早期 `SPH_MATCH_ANY` 模式下计算的排名，内部用于模拟 `SPH_MATCH_ANY` 查询。 +* `fieldmask` 返回一个 32 位掩码，其中第 N 位对应第 N 个全文字段（从 0 开始编号）。只有当相应字段包含满足查询的关键词时，该位才会被置位。 +* `sph04` 通常基于默认的 `proximity_bm25` 排序器，但额外提升在文本字段开头或末尾出现的匹配。因此，如果一个字段与准确查询相等，`sph04` 会将其排名高于包含该查询但不相等的字段。（例如查询为 "Hyde Park"，标题为 "Hyde Park" 的文档应排名高于标题为 "Hyde Park, London" 或 "The Hyde Park Cafe" 的文档。） +* `expr` 允许你在运行时指定排序公式。它暴露了若干内部文本因素，并允许你定义如何由这些因素计算最终权重。你可以在[下面的小节](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors)中找到关于语法及可用因素的详细信息和参考。 -排名器名称不区分大小写。示例： +排序器名称不区分大小写。示例： ```sql SELECT ... OPTION ranker=sph04; ``` -## 排名因素快速总结 - -| 名称 | 级别 | 类型 | 概要 | -| ----------------------- | --------- | ----- | ------------------------------------------------------------------------------------------------------------------ | -| max_lcs | query | int | 当前查询的最大可能 LCS 值 | -| bm25 | document | int | BM25(1.2, 0) 的快速估计 | -| bm25a(k1, b) | document | int | 具有可配置 K1、B 常数和语法支持的精确 BM25() 值 | -| bm25f(k1, b, {field=weight, ...}) | document | int | 具有额外可配置字段权重的精确 BM25F() 值 | -| field_mask | document | int | 匹配字段的位掩码 | -| query_word_count | document | int | 查询中唯一包含的关键词数量 | -| doc_word_count | document | int | 文档中匹配的唯一关键词数量 | -| lcs | field | int | 查询与文档之间的最长公共子序列（以词为单位） | -| user_weight | field | int | 用户字段权重 | -| hit_count | field | int | 关键词出现的总次数 | -| word_count | field | int | 匹配的唯一关键词数量 | +## 排序因素简要汇总 + +| 名称 | 级别 | 类型 | 说明 | +| ----------------------- | ---------- | ----- | ------------------------------------------------------------------------------------------------------------------ | +| max_lcs | 查询 | int | 当前查询的最大可能 LCS 值 | +| bm25 | 文档 | int | BM25(1.2, 0) 的快速估计 | +| bm25a(k1, b) | 文档 | int | 具有可配置 K1、B 常数和语法支持的精确 BM25() 值 | +| bm25f(k1, b, {field=weight, ...}) | 文档 | int | 具有额外可配置字段权重的精确 BM25F() 值 | +| field_mask | 文档 | int | 匹配字段的位掩码 | +| query_word_count | 文档 | int | 查询中包含的唯一关键词数量 | +| doc_word_count | 文档 | int | 文档中匹配到的唯一关键词数量 | +| lcs | 字段 | int | 查询与文档之间最长公共子序列（以单词计） | +| user_weight | 字段 | int | 用户字段权重 | +| hit_count | 字段 | int | 关键词出现总次数 | +| word_count | 字段 | int | 匹配到的唯一关键词数量 | | tf_idf | field | float | 匹配关键词的 sum(tf*idf) == 出现次数的 sum(idf) | | min_hit_pos | field | int | 第一个匹配出现位置，按词计，基于1 | | min_best_span_pos | field | int | 第一个最大 LCS 区间位置，按词计，基于1 | @@ -1066,49 +1118,49 @@ SELECT ... OPTION ranker=sph04; * `user_weight`（整数），用户指定的每字段权重（参见 SQL 中的 [OPTION field_weights](../Searching/Options.md#field_weights)）。如果未显式指定，权重默认为1。 * `hit_count`（整数），字段中匹配的关键词出现次数。注意单个关键词可能出现多次。例如，“hello”在字段中出现3次，“world”出现5次，则 `hit_count` 为8。 * `word_count`（整数），字段中匹配的唯一关键词数量。例如，“hello”和“world”任意出现，`word_count` 为2，无论两者出现多少次。 -* `tf_idf` (浮点数)，字段中所有匹配关键词的 TF/IDF 之和。IDF 是逆文档频率，是一个介于 0 和 1 之间的浮点值，用来描述关键词的频率（基本上，对于出现在所有索引文档中的关键词，IDF 为 0；对于只出现在单个文档中的唯一关键词，IDF 为 1）。TF 是词频，表示字段中匹配关键词出现的次数。顺便提一下，`tf_idf` 实际上是通过对所有匹配出现的 IDF 求和计算得出的。这在构造上等同于对所有匹配关键词求和 TF*IDF。 -* `min_hit_pos` (整数)，第一个匹配关键词出现的位置，按词数计数 +* `tf_idf`（浮点数），字段中所有匹配关键词的TF/IDF之和。IDF是逆文档频率，是介于0和1之间的浮点值，用来描述关键词的频率（基本上，一个在每个被索引文档中都出现的关键词IDF为0，一个只出现在单个文档中的唯一关键词IDF为1）。TF是词频，表示字段中匹配关键词的出现次数。顺便说一句，`tf_idf` 实际上是通过对所有匹配出现的IDF求和计算的。从构造上讲，这等价于对所有匹配关键词求和TF*IDF。 +* `min_hit_pos`（整数），第一个匹配关键词出现的位置，按词数计数 - 因此，这是一个相对低级的“原始”因子，您可能需要在用于排序之前对其进行*调整*。具体调整高度依赖于您的数据和最终公式，但这里有一些起点建议：（a）当 word_count<2 时，可以简单忽略任何基于 min_gaps 的提升； + 因此，这是一个相对低级的、“原始”的因子，您很可能想在使用它进行排序之前进行*调整*。具体的调整很大程度上取决于您的数据和最终的公式，但这里有一些起步的想法：（a）当 word_count<2 时，可以简单忽略任何基于 min_gaps 的加分； - （b）非平凡的 min_gaps 值（即 word_count>=2 时）可以用某个“最坏情况”常数进行限制，而平凡值（即 min_gaps=0 且 word_count<2 时）可以用该常数替代； + （b）非平凡的 min_gaps 值（即当 word_count>=2 时）可以被限制在一个“最坏情况”的常数内，而平凡值（即当 min_gaps=0 且 word_count<2）可以被该常数替换； - （c）可以应用类似 1/(1+min_gaps) 的传递函数（这样更好、更小的 min_gaps 值会使其最大化，而更差、更大的 min_gaps 值会缓慢下降）；等等。 -* `lccs` (整数)。最长公共连续子序列。查询和文档之间最长的公共子短语长度，以关键词计。 + （c）可以使用类似 1/(1+min_gaps) 的传递函数（这样更好、更小的 min_gaps 值会最大化它，而更差、更大的 min_gaps 值会缓慢递减）；等等。 +* `lccs`（整数）。最长公共连续子序列。查询与文档之间最长公共子短语的长度，按关键词计算。 - LCCS 因子与 LCS 有些相似，但更具限制性。虽然即使没有两个查询词相邻匹配，LCS 也可以大于 1，但只有当文档中存在*完全*连续的查询子短语时，LCCS 才会大于 1。例如，查询 `(one two three four five)` 与文档 `(one hundred three hundred five hundred)` 的 lcs=3，但 lccs=1，因为虽然三个关键词（one、three、five）在查询和文档中的相对位置匹配，但没有两个匹配位置是相邻的。 + LCCS 因子与 LCS 有些相似，但更具限制性。即使没有两个查询词是相邻匹配的，LCS 也可以大于1，而 LCCS 只有当文档中存在*完全相同*且连续的查询子短语时才会大于1。例如，查询（one two three four five）与文档（one hundred three hundred five hundred）会产生 lcs=3，但 lccs=1，因为虽然3个关键词（one、three、five）在查询和文档中的相对位置匹配，但没有两个匹配位置实际上是相邻的。 - 注意 LCCS 仍然不区分频繁和稀有关键词；有关这点，请参见 WLCCS。 -* `wlccs` (浮点数)。加权最长公共连续子序列。查询和文档之间最长公共子短语中关键词的 IDF 之和。 + 注意，LCCS 仍然不区分频繁和稀有关键词；关于这一点，请参见 WLCCS。 +* `wlccs`（浮点数）。加权最长公共连续子序列。查询和文档之间最长公共子短语中关键词的 IDF 之和。 - WLCCS 的计算方式类似于 LCCS，但每个“合适”的关键词出现会按关键词 IDF 增加，而不是像 LCS 和 LCCS 那样仅增加 1。这允许将稀有且更重要的关键词序列排名高于频繁关键词序列，即使后者更长。例如，查询 `(Zanzibar bed and breakfast)` 对文档 `(hotels of Zanzibar)` 的 lccs=1，但对 `(London bed and breakfast)` 的 lccs=3，尽管“Zanzibar”实际上比整个“bed and breakfast”短语更稀有。WLCCS 因子通过使用关键词频率解决了这个问题。 -* `atc` (浮点数)。聚合词语接近度。基于接近度的度量，当文档包含更多更紧密且更重要（稀有）的查询关键词组时，该值增加。 + WLCCS 的计算方式与 LCCS 相似，但每个“合适”的关键词出现均由关键词的 IDF 增加，而非仅仅增加1（如 LCS 和 LCCS）。这允许对由较稀有和重要关键词组成的序列进行更高的排名，而不是由频繁关键词组成的更长序列。例如，查询 `(Zanzibar bed and breakfast)` 对文档 `(hotels of Zanzibar)` 会得到 lccs=1，但对于 `(London bed and breakfast)` 会得到 lccs=3，尽管“Zanzibar”实际上比整个“bed and breakfast”短语更稀有。WLCCS 因子通过使用关键词频率解决了这个问题。 +* `atc`（浮点数）。聚合词项接近度。基于接近度的度量，文档中包含更多更密集且更重要（稀有）查询关键词组时值更高。 - **警告：** 您应当使用 OPTION idf='plain,tfidf_unnormalized'（见[下文](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)）；否则，可能会得到意外结果。 + **警告：** 应该在 OPTION idf='plain,tfidf_unnormalized' 条件下使用 ATC（见[下文](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)）；否则，可能会得到意外结果。 - ATC 的基本操作如下。对于文档中的每个关键词*出现*，计算所谓的*词语接近度*。为此，我们检查该出现左右两侧所有查询关键词的最近出现（包括该关键词本身），计算距离衰减系数 k = pow(distance, -1.75)，并对衰减后的 IDF 求和。结果是，对于每个关键词的每个出现，我们得到一个描述该出现“邻居”的“接近度”值。然后将这些每次出现的接近度乘以对应关键词的 IDF，求和后取对数。 + ATC 的工作原理基本如下。对于文档中每个关键词*出现*，计算所谓的*词项接近度*。为此，我们检查该出现位置左右的所有其它最接近的查询关键词出现位置（包括该关键词本身），计算距离衰减系数 k = pow(distance, -1.75)，并对衰减后的 IDF 求和。结果，对每个关键词出现，我们获得一个描述该出现“邻居”情况的“接近度”值。然后将这些每次出现的接近度乘以对应关键词的 IDF，将它们相加，最后计算该和的对数。 -换句话说，我们处理文档中最佳（最近）的匹配关键词对，计算它们的成对“接近度”，即它们 IDF 的乘积乘以距离系数： +换句话说，我们处理文档中最好（最近）的匹配关键词对，并计算它们的两两“接近度”，作为它们的 IDF 乘积再乘以距离系数： ``` pair_tc = idf(pair_word1) * idf(pair_word2) * pow(pair_distance, -1.75) ``` -然后我们对这些接近度求和，并计算最终的对数衰减 ATC 值： +然后我们将这些接近度求和，并计算最终的带对数衰减的 ATC 值： ``` atc = log(1+sum(pair_tc)) ``` -注意，这个最终的衰减对数正是您应使用 OPTION idf=plain 的原因，因为没有它，log() 内的表达式可能为负。 +注意，这个最终衰减的对数正是你应使用 OPTION idf=plain 的原因；否则，log() 内的表达式可能为负。 -关键词出现越接近，对 ATC 的贡献*远远*大于关键词出现越频繁。实际上，当关键词紧挨着时，distance=1，k=1；中间隔一个词时，distance=2，k=0.297；中间隔两个词时，distance=3，k=0.146，依此类推。与此同时，IDF 衰减较慢。例如，在一百万文档集合中，匹配 10、100 和 1000 个文档的关键词的 IDF 分别为 0.833、0.667 和 0.500。因此，一个由两个相当稀有的关键词组成的关键词对（每个只出现在 10 个文档中），但中间隔两个词，会产生 pair_tc = 0.101，几乎抵消了一个由一个匹配 100 个文档和一个匹配 1000 个文档的关键词组成的关键词对（中间隔一个词），其 pair_tc = 0.099。此外，一对两个*唯一*、只出现在 1 个文档中的关键词，中间隔三个词，pair_tc = 0.088，会输给一对两个紧挨着的匹配 1000 个文档的关键词，pair_tc = 0.25。因此，基本上，虽然 ATC 结合了关键词频率和接近度，但它仍然更偏向于接近度。 +关键词出现越接近，对 ATC 的贡献越大，远远大于关键词频率的影响。实际上，当关键词相邻时，distance=1，k=1；中间隔1个词时，distance=2，k=0.297，中间隔2个词时，distance=3，k=0.146，依此类推。与此同时，IDF 衰减速度较慢。例如，在一百万文档的集合中，分别匹配 10、100 和 1000 个文档的关键词的 IDF 值分别为 0.833、0.667 和 0.500。因此，一个两个都只出现于10篇文档的较稀有关键词对，中间隔两个词，其 pair_tc=0.101，稍微超过一个频率分别为100和1000篇文档的关键词对，中间隔一个词，pair_tc=0.099。此外，两个各自只出现在1篇文档的*唯一*关键词对，中间隔3个词，pair_tc=0.088，会输给一对两个频率为1000篇文档的紧邻关键词对，后者 pair_tc=0.25。所以，基本上，虽然 ATC 结合了关键词频率和接近度，但仍略偏向接近度。 -### 排序因子聚合函数 +### 排名因子聚合函数 -**字段聚合函数**是一个单参数函数，接受包含字段级因子的表达式，遍历所有匹配字段，并计算最终结果。目前实现的字段聚合函数包括： +**字段聚合函数**是单参数函数，接受带有字段级因子的表达式，遍历所有匹配字段，并计算最终结果。当前实现的字段聚合函数包括： -* `sum`，对所有匹配字段的参数表达式求和。例如，`sum(1)` 应返回匹配字段的数量。 +* `sum`，对所有匹配字段的参数表达式求和。例如 `sum(1)` 应返回匹配字段的数量。 * `top`，返回所有匹配字段中参数的最高值。 * `max_window_hits`，管理一个滑动窗口的命中位置，以跟踪指定窗口大小内的最大命中数。它会移除超出窗口范围的过时命中，并添加最新命中，更新该窗口内发现的最大命中数。 diff --git a/manual/chinese/Securing_and_compacting_a_table/Compacting_a_table.md b/manual/chinese/Securing_and_compacting_a_table/Compacting_a_table.md index cd703ac2b3..a232870a09 100644 --- a/manual/chinese/Securing_and_compacting_a_table/Compacting_a_table.md +++ b/manual/chinese/Securing_and_compacting_a_table/Compacting_a_table.md @@ -1,8 +1,8 @@ -# 紧凑表 +# 压缩表 -随着时间的推移，RT 表可能会碎片化成多个磁盘块和/或被已删除但未清除的数据污染，影响搜索性能。在这些情况下，需要进行优化。基本上，优化过程是将成对的磁盘块合并，移除之前通过 DELETE 语句删除的文档。 +随着时间的推移，RT 表可能会分散成多个磁盘块和/或被删除但未清除的数据污染，从而影响搜索性能。在这种情况下，有必要进行优化。基本上，优化过程是将成对的磁盘块合并，移除先前通过 DELETE 语句删除的文档。 -从 Manticore 4 开始，这个过程默认[自动进行](../Server_settings/Searchd.md#auto_optimize)。但是，你也可以使用以下命令手动启动表的紧凑。 +从 Manticore 4 开始，这一过程[默认自动进行](../Server_settings/Searchd.md#auto_optimize)。不过，你也可以使用以下命令手动启动表压缩。 ## OPTIMIZE TABLE @@ -21,20 +21,30 @@ OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]] ```sql OPTIMIZE TABLE rt; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt;" +``` + ### 优化后的磁盘块数量 -默认情况下，OPTIMIZE 会将 RT 表的磁盘块合并到不超过逻辑 CPU 核心数乘以 2 的数量。 +默认情况下，OPTIMIZE 会将 RT 表的磁盘块合并到小于或等于逻辑 CPU 核心数乘以 2 的数量。 -但是，如果表中有带 KNN 索引的属性，这个阈值会不同。在这种情况下，阈值设置为物理 CPU 核心数除以 2，以提升 KNN 搜索性能。 +但是，如果表中带有带有 KNN 索引的属性，则该阈值不同。在这种情况下，它设置为物理 CPU 核心数除以 2，以提升 KNN 搜索性能。 -你也可以使用 `cutoff` 选项手动控制优化后的磁盘块数量。 +你也可以使用 `cutoff` 选项手动控制优化后磁盘块的数量。 其他选项包括： -* 服务器设置 [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) 用于覆盖默认阈值 +* 覆盖默认阈值的服务器设置 [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) * 每表设置 [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff) @@ -45,13 +55,23 @@ OPTIMIZE TABLE rt; ```sql OPTIMIZE TABLE rt OPTION cutoff=4; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION cutoff=4;" +``` + ### 前台运行 -使用 `OPTION sync=1`（默认值为 0）时，命令会等待优化过程完成后才返回。如果连接中断，优化仍会在服务器上继续运行。 +使用 `OPTION sync=1`（默认值为 0）时，命令将在返回之前等待优化过程完成。如果连接中断，优化将在服务器上继续运行。 ##### SQL: @@ -61,19 +81,29 @@ OPTIMIZE TABLE rt OPTION cutoff=4; ```sql OPTIMIZE TABLE rt OPTION sync=1; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION sync=1;" +``` + ### 限制 IO 影响 -优化可能是一个耗时且 IO 密集的过程。为了减少影响，所有实际的合并工作都在一个特殊的后台线程中串行执行，`OPTIMIZE` 语句只是将任务添加到其队列中。优化线程可以进行 IO 限速，你可以通过 [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) 和 [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) 指令分别控制每秒最大 IO 数和最大 IO 大小。 +优化可能是一个漫长且 I/O 密集的过程。为了减少影响，所有实际的合并工作都在一个特殊的后台线程中串行执行，而 `OPTIMIZE` 语句仅将任务加入其队列。优化线程可以进行 I/O 限速，你可以通过[rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) 和 [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) 指令分别控制最大每秒 I/O 数和最大 I/O 大小。 -在优化过程中，被优化的 RT 表几乎始终在线且可用于搜索和更新。只有在成功合并一对磁盘块时，表会被短暂锁定，以便重命名旧文件和新文件并更新表头。 +优化期间，被优化的 RT 表几乎始终在线且可供搜索和更新使用。只有在一对磁盘块成功合并时，会短暂锁定，以便重命名旧文件和新文件并更新表头。 ### 优化集群表 -只要没有禁用 [auto_optimize](../Server_settings/Searchd.md#auto_optimize)，表会自动优化。 +只要未禁用[auto_optimize](../Server_settings/Searchd.md#auto_optimize)，表将自动优化。 -如果你遇到意外的 SST 文件，或者希望集群中所有节点的表二进制完全一致，你需要： +如果你遇到意外的 SSTs，或者希望所有节点上的表二进制完全一致，则需要： 1. 禁用 [auto_optimize](../Server_settings/Searchd.md#auto_optimize)。 2. 手动优化表： @@ -82,6 +112,10 @@ OPTIMIZE TABLE rt OPTION sync=1; ```sql ALTER CLUSTER mycluster DROP myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster DROP myindex;" +``` 优化表： @@ -89,6 +123,10 @@ ALTER CLUSTER mycluster DROP myindex; ```sql OPTIMIZE TABLE myindex; ``` + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE myindex;" +``` 将表重新添加到集群： @@ -96,19 +134,23 @@ OPTIMIZE TABLE myindex; ```sql ALTER CLUSTER mycluster ADD myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster ADD myindex;" +``` -当表被重新添加时，优化过程中创建的新文件会被复制到集群中的其他节点。 -其他节点上对表的任何本地更改都会丢失。 +当表被重新添加后，优化过程中产生的新文件将被复制到集群中的其他节点。 +在其他节点对该表做的任何本地更改将丢失。 表数据的修改（插入、替换、删除、更新）应当： -1. 延后执行，或 +1. 被推迟，或者 2. 定向到正在运行优化过程的节点。 -注意，在表不在集群中时，插入/替换/删除/更新命令应当不带集群名称前缀（对于 SQL 语句或 HTTP JSON 请求中的 cluster 属性），否则会失败。 -一旦表重新加入集群，必须恢复对表的写操作并再次包含集群名称前缀，否则操作会失败。 +请注意，在表不在集群时，插入/替换/删除/更新命令应当不带集群名称前缀（对 SQL 语句或 HTTP JSON 请求中的 cluster 属性），否则将失败。 +一旦表被重新添加到集群，必须恢复对表的写操作并重新包含集群名称前缀，否则操作将失败。 -在此过程中，任何节点上的搜索操作照常可用。 +在此过程中，任一节点上的搜索操作正常可用。 diff --git a/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md b/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md index bdd5fa923b..c7a7d0204f 100644 --- a/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md +++ b/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md @@ -1,4 +1,4 @@ -# 将 RAM 块刷新到新的磁盘块 +# 刷新 RAM 块到新的磁盘块 ## FLUSH RAMCHUNK @@ -8,9 +8,9 @@ FLUSH RAMCHUNK rt_table ``` -`FLUSH RAMCHUNK` 命令在 RT 表中创建一个新的磁盘块。 +`FLUSH RAMCHUNK` 命令会在 RT 表中创建一个新的磁盘块。 -通常，当满足某个[特殊条件](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions)时，RT 表会自动刷新并将 RAM 块的内容转换为新的磁盘块。但在某些情况下，您可能希望手动触发刷新——`FLUSH RAMCHUNK` 语句允许您这样做。 +通常，当满足某个[特殊条件](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions)时，RT 表会自动刷新并将 RAM 块的内容转换成新的磁盘块。不过，在某些情况下，您可能想手动触发刷新 — `FLUSH RAMCHUNK` 语句可以让您做到这一点。 ##### SQL: @@ -24,6 +24,26 @@ FLUSH RAMCHUNK rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH RAMCHUNK rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md b/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md index ac6d0e0df9..70e58622b8 100644 --- a/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md +++ b/manual/chinese/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md @@ -1,4 +1,4 @@ -# 将 RAM 块刷新到磁盘 +# 将RAM块刷新到磁盘 ## FLUSH TABLE @@ -8,11 +8,11 @@ FLUSH TABLE rt_table ``` -`FLUSH TABLE` 强制将 RT 表的 RAM 块内容刷新到磁盘。 +`FLUSH TABLE` 强制将RT表的RAM块内容刷新到磁盘。 -实时表的 [RAM 块](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) 会在干净关闭时自动刷新到磁盘，或者每隔 [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) 秒定期刷新。 +实时表的 [RAM块](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) 会在正常关闭时自动刷新到磁盘，或每隔 [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) 秒周期性刷新。 -执行 `FLUSH TABLE` 命令不仅强制将 RAM 块内容写入磁盘，还会触发二进制日志文件的清理。 +执行 `FLUSH TABLE` 命令不仅强制将RAM块内容写入磁盘，还会触发二进制日志文件的清理。 ##### SQL: @@ -26,6 +26,25 @@ FLUSH TABLE rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH TABLE rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` diff --git a/manual/english/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md b/manual/english/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md index 52518c6e14..a0bba409f1 100755 --- a/manual/english/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md +++ b/manual/english/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md @@ -112,6 +112,11 @@ In most cases, the above is sufficient when there is a single replication cluste ```sql JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path ``` + + +```JSON +POST /sql?mode=raw -d "JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path" +``` A node joins a cluster by obtaining data from a specified node and, if successful, updates the node lists across all other cluster nodes in the same way as if it was done manually through [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). This list is used to re-join nodes to the cluster upon restart. diff --git a/manual/english/Creating_a_table/Data_types.md b/manual/english/Creating_a_table/Data_types.md index e1f03f8c71..34d33e124a 100755 --- a/manual/english/Creating_a_table/Data_types.md +++ b/manual/english/Creating_a_table/Data_types.md @@ -2569,6 +2569,25 @@ CREATE TABLE products_all_fields ( ); ``` + +##### JSON: + + +Using [sentence-transformers model](https://huggingface.co/sentence-transformers/models) (no API key needed) +```JSON +POST /sql?mode=raw -d "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');" +``` + +Using OpenAI model (requires API_KEY parameter) +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_openai (title TEXT, content TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine' MODEL_NAME='openai/text-embedding-ada-002' FROM='title,content' API_KEY='');" +``` + +Using all text fields for embeddings (FROM is empty) +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_all_fields (title TEXT, description TEXT, tags TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2' MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='');" +``` + #### FROM parameter usage diff --git a/manual/english/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md b/manual/english/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md index 02ef11fc76..5ff1dcd1a4 100755 --- a/manual/english/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md +++ b/manual/english/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md @@ -682,6 +682,23 @@ This creates the "products" table with three fields: * "title" is indexed, but not stored. * "description" is stored, but not indexed. * "author" is both stored and indexed. + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE products (title text, price float) morphology='stem_en';" +``` + +This creates the "products" table with two fields: "title" (full-text) and "price" (float), and sets the "morphology" to "stem_en". + +```JSON +POST /sql?mode=raw -d "CREATE TABLE products (title text indexed, description text stored, author text, price float);" +``` +This creates the "products" table with three fields: +* "title" is indexed, but not stored. +* "description" is stored, but not indexed. +* "author" is both stored and indexed. + diff --git a/manual/english/Creating_a_table/Local_tables/Real-time_table.md b/manual/english/Creating_a_table/Local_tables/Real-time_table.md index 5e7804a6d7..a055d80ea0 100755 --- a/manual/english/Creating_a_table/Local_tables/Real-time_table.md +++ b/manual/english/Creating_a_table/Local_tables/Real-time_table.md @@ -266,6 +266,19 @@ create table products LIKE old_products; create table products LIKE old_products WITH DATA; ``` + + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products;" +``` + + +##### JSON example (WITH DATA): + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products WITH DATA;" +``` + ### 👍 What you can do with a real-time table: diff --git a/manual/english/Creating_a_table/NLP_and_tokenization/Wordforms.md b/manual/english/Creating_a_table/NLP_and_tokenization/Wordforms.md index 87d5398c57..acaa227338 100755 --- a/manual/english/Creating_a_table/NLP_and_tokenization/Wordforms.md +++ b/manual/english/Creating_a_table/NLP_and_tokenization/Wordforms.md @@ -182,6 +182,12 @@ create table tbl1 ... wordforms='/tmp/wf*' create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2' ``` + +```JSON +POST /sql?mode=raw -d "create table tbl1 ... wordforms='/tmp/wf*'" +POST /sql?mode=raw -d "create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2'" +``` + ```ini wordforms=/tmp/wf diff --git a/manual/english/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md b/manual/english/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md index 95205be89d..336d410d7d 100755 --- a/manual/english/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md +++ b/manual/english/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md @@ -381,6 +381,76 @@ SELECT * FROM pq; | 2810855531667783689 | @title shoes | Louis Vuitton | | +---------------------+--------------+---------------+---------+ ``` + + + +```JSON +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', '', '');" +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', 'Louis Vuitton', '');" +POST /sql?mode=raw -d "SELECT * FROM pq;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "Louis Vuitton", + "filters": "" + }, + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "", + "filters": "" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Data_creation_and_modification/Deleting_documents.md b/manual/english/Data_creation_and_modification/Deleting_documents.md index 2ceb53a680..80a6f90736 100755 --- a/manual/english/Data_creation_and_modification/Deleting_documents.md +++ b/manual/english/Data_creation_and_modification/Deleting_documents.md @@ -547,6 +547,64 @@ Query OK, 4 rows affected (0.00 sec) +------+------+-------------+------+ 6 rows in set (0.00 sec) ``` + + + +```JSON +POST /sql?mode=raw -d "DELETE FROM TEST WHERE MATCH ('test document') AND ( mva1>206 or mva1 in (100, 103) );" + +POST /sql?mode=raw -d "SELECT * FROM TEST;" +``` + + +```JSON +[ + { + "total": 4, + "error": "", + "warning": "" + } +] + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "mva1": { + "type": "long" + } + }, + { + "mva2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "gid": "1001", + "mva1": 101,102, + "mva2": 101 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Extensions/FEDERATED.md b/manual/english/Extensions/FEDERATED.md index eaa790275b..1259fc6aa6 100755 --- a/manual/english/Extensions/FEDERATED.md +++ b/manual/english/Extensions/FEDERATED.md @@ -34,6 +34,20 @@ CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies'; ```sql Query OK, 0 rows affected (0.00 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE t1 (id INTEGER UNSIGNED NOT NULL, year INTEGER NOT NULL, rating FLOAT, query VARCHAR(1024) NOT NULL, INDEX(query)) ENGINE=FEDERATED DEFAULT CHARSET=utf8 CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies';" +``` + + +```JSON +``` + diff --git a/manual/english/Extensions/SphinxSE.md b/manual/english/Extensions/SphinxSE.md index e539733978..b0e1e8b830 100755 --- a/manual/english/Extensions/SphinxSE.md +++ b/manual/english/Extensions/SphinxSE.md @@ -84,6 +84,65 @@ mysql> show engines; 13 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "show engines;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Engine": { + "type": "string" + } + }, + { + "Support": { + "type": "string" + } + }, + { + "Comment": { + "type": "string" + } + }, + { + "Transactions": { + "type": "string" + } + }, + { + "XA": { + "type": "string" + } + }, + { + "Savepoints": { + "type": "string" + } + } + ], + "data": [ + { + "Engine": "MyISAM", + "Support": "DEFAULT", + "Comment": "MyISAM storage engine", + "Transactions": "NO", + "XA": "NO", + "Savepoints": "NO" + } + ] + } +] +``` + ## Using SphinxSE @@ -261,6 +320,80 @@ min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT *, WEIGHT(), RANKFACTORS() FROM myindex WHERE MATCH('dog') OPTION ranker=export('100*bm25');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "published": { + "type": "long long" + } + }, + { + "channel_id": { + "type": "long long" + } + }, + { + "title": { + "type": "long long" + } + }, + { + "content": { + "type": "long long" + } + }, + { + "weight()": { + "type": "long long" + } + }, + { + "rankfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 555617, + "published": 1110067331, + "channel_id": 1059819, + "title": 7, + "content": 428, + "weight()": 69900, + "rankfactors()": "bm25=699, bm25a=0.666478, field_mask=2, doc_word_count=1, field1=(lcs=1, hit_count=4, word_count=1, tf_idf=1.038127, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=120, min_best_span_pos=120, exact_hit=0, max_window_hits=1), word1=(tf=4, idf=0.259532)" + }, + { + "id": 555313, + "published": 1108438365, + "channel_id": 1058561, + "title": 8, + "content": 249, + "weight()": 68500, + "rankfactors()": "bm25=685, bm25a=0.675213, field_mask=3, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.259532, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=8, min_best_span_pos=8, exact_hit=0, max_window_hits=1), field1=(lcs=1, hit_count=2, word_count=1, tf_idf=0.519063, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=36, min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532)" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + * geoanchor - geodistance anchor. Learn more about Geo-search [in this section](../Searching/Geo_search.md). Takes 4 parameters, which are the latitude and longitude attribute names, and anchor point coordinates, respectively: @@ -312,6 +445,52 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 25, total found: 25, time: 126, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + @@ -339,6 +518,57 @@ mysql> SHOW STATUS LIKE 'sphinx_%'; 5 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SHOW STATUS LIKE 'sphinx_%';" +``` + + +```JSON +[ + { + "total": 5, + "error": "", + "warning": "", + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "sphinx_total", + "Value": "25" + }, + { + "Variable_name": "sphinx_total_found", + "Value": "25" + }, + { + "Variable_name": "sphinx_time", + "Value": "126" + }, + { + "Variable_name": "sphinx_word_count", + "Value": "2" + }, + { + "Variable_name": "sphinx_words", + "Value": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + @@ -376,6 +606,85 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT content, date_added FROM test.documents docs JOIN t1 ON (docs.id=t1.id) WHERE query="one document;mode=any";" + +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "content": { + "type": "string" + } + }, + { + "docdate": { + "type": "string" + } + } + ], + "data": [ + { + "content": "this is my test document number two", + "docdate": "2006-06-17 14:04:28" + }, + { + "content": "this is my test document number one", + "docdate": "2006-06-17 14:04:28" + } + ] + } +] + +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 2, total found: 2, time: 0, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "one:1:2 document:2:2" + } + ] + } +] +``` + ## Building snippets via MySQL diff --git a/manual/english/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md b/manual/english/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md index 2c1629f5f3..4a1d241aac 100755 --- a/manual/english/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md +++ b/manual/english/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md @@ -16,12 +16,21 @@ ENABLE BUDDY PLUGIN This command reactivates a previously disabled Buddy plugin, allowing it to process your requests again. -### Example +### SQL Example ```sql ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` + + +### JSON Example + + +```JSON +POST /sql?mode=raw -d "ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + @@ -34,13 +43,21 @@ DISABLE BUDDY PLUGIN This command deactivates an active Buddy plugin, preventing it from processing any further requests. -### Example +### SQL Example ```sql DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` + +### JSON Example + + +```JSON +POST /sql?mode=raw -d "DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + After disabling, if you try the `SHOW QUERIES` command, you'll encounter an error because the plugin is disabled. diff --git a/manual/english/Functions/Date_and_time_functions.md b/manual/english/Functions/Date_and_time_functions.md index bbd3bf92f6..2e299b5ed9 100755 --- a/manual/english/Functions/Date_and_time_functions.md +++ b/manual/english/Functions/Date_and_time_functions.md @@ -18,6 +18,34 @@ select NOW(); | 1615788407 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select NOW();" +``` + +```JSON +[ + { + "columns": [ + { + "now()": { + "type": "long" + } + } + ], + "data": [ + { + "now()": 1615788407 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURTIME() @@ -36,6 +64,34 @@ select CURTIME(); | 07:06:30 | +-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURTIME();" +``` + +```JSON +[ + { + "columns": [ + { + "CURTIME()": { + "type": "string" + } + } + ], + "data": [ + { + "CURTIME()": "07:06:30" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURDATE() @@ -54,6 +110,33 @@ select curdate(); | 2023-08-02 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURDATE();" +``` + +```JSON +[ + { + "columns": [ + { + "CURDATE()": { + "type": "string" + } + } + ], + "data": [ + { + "CURDATE()": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIME() @@ -72,6 +155,33 @@ select UTC_TIME(); | 06:06:18 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIME();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIME()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIME()": "06:06:18" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIMESTAMP() @@ -90,6 +200,33 @@ select UTC_TIMESTAMP(); | 2021-03-15 06:06:03 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIMESTAMP();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIMESTAMP()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIMESTAMP()": "2021-03-15 06:06:0" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### SECOND() @@ -108,6 +245,33 @@ select second(now()); | 52 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select second(now());" +``` + +```JSON +[ + { + "columns": [ + { + "second(now())": { + "type": "long" + } + } + ], + "data": [ + { + "second(now())": 52 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MINUTE() @@ -126,6 +290,33 @@ select minute(now()); | 5 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select minute(now());" +``` + +```JSON +[ + { + "columns": [ + { + "minute(now())": { + "type": "long" + } + } + ], + "data": [ + { + "minute(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### HOUR() @@ -144,6 +335,33 @@ select hour(now()); | 7 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "hour(now())" +``` + +```JSON +[ + { + "columns": [ + { + "hour(now())": { + "type": "long" + } + } + ], + "data": [ + { + "hour(now())": 7 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAY() @@ -162,6 +380,33 @@ select day(now()); | 15 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select day(now());" +``` + +```JSON +[ + { + "columns": [ + { + "day(now())": { + "type": "long" + } + } + ], + "data": [ + { + "day(now())": 15 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTH() @@ -180,6 +425,33 @@ select month(now()); | 3 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select month(now());" +``` + +```JSON +[ + { + "columns": [ + { + "month(now())": { + "type": "long" + } + } + ], + "data": [ + { + "month(now())": 3 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### QUARTER() @@ -198,6 +470,33 @@ select quarter(now()); | 2 | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select quarter(now());" +``` + +```JSON +[ + { + "columns": [ + { + "quarter(now())": { + "type": "long" + } + } + ], + "data": [ + { + "quarter(now())": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEAR() @@ -216,6 +515,33 @@ select year(now()); | 2024 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select year(now());" +``` + +```JSON +[ + { + "columns": [ + { + "year(now())": { + "type": "long" + } + } + ], + "data": [ + { + "year(now())": 2024 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYNAME() @@ -234,6 +560,33 @@ select dayname(now()); | Wednesday | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayname(now());" +``` + +```JSON +[ + { + "columns": [ + { + "dayname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "dayname(now())": "Wednesday" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTHNAME() @@ -252,6 +605,33 @@ select monthname(now()); | August | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select monthname(now())" +``` + +```JSON +[ + { + "columns": [ + { + "monthname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "monthname(now())": "August" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFWEEK() @@ -271,6 +651,33 @@ select dayofweek(now()); | 5 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofweek(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofweek(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFYEAR() @@ -289,6 +696,33 @@ select dayofyear(now()); | 214 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofyear(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofyear(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofyear(now())": 214 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARWEEK() @@ -307,6 +741,33 @@ select yearweek(now()); | 2023211 | +-----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearweek(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearweek(now())": 2023211 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTH() @@ -325,6 +786,33 @@ select yearmonth(now()); | 202103 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonth(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonth(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonth(now())": 202103 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTHDAY() @@ -343,6 +831,33 @@ select yearmonthday(now()); | 20210315 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonthday(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonthday(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonthday(now())": 20210315 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIMEDIFF() @@ -361,6 +876,33 @@ select timediff(1615787586, 1613787583); | 555:33:23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select timediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "timediff(1615787586, 1613787583)": { + "type": "string" + } + } + ], + "data": [ + { + "timediff(1615787586, 1613787583)": "555:33:23" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATEDIFF() @@ -379,6 +921,33 @@ select datediff(1615787586, 1613787583); | 23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select datediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "datediff(1615787586, 1613787583)": { + "type": "long long" + } + } + ], + "data": [ + { + "datediff(1615787586, 1613787583)": 23 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE() @@ -397,6 +966,33 @@ select date(now()); | 2023-08-02 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select date(now());" +``` + +```JSON +[ + { + "columns": [ + { + "date(now())": { + "type": "string" + } + } + ], + "data": [ + { + "date(now())": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIME() @@ -415,6 +1011,33 @@ select time(now()); | 15:21:27 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select time(now());" +``` + +```JSON +[ + { + "columns": [ + { + "time(now())": { + "type": "string" + } + } + ], + "data": [ + { + "time(now())": "15:21:27" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE_FORMAT() @@ -443,6 +1066,33 @@ SELECT DATE_FORMAT(NOW(), 'year %Y and time %T'); | year 2023 and time 11:54:52 | +------------------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select DATE_FORMAT(NOW(), 'year %Y and time %T');" +``` + +```JSON +[ + { + "columns": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": { + "type": "string" + } + } + ], + "data": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": "year 2023 and time 11:54:52" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` This example formats the current date and time, displaying the four-digit year and the time in 24-hour format. diff --git a/manual/english/Integration/Kafka.md b/manual/english/Integration/Kafka.md index 3ad6f79810..6dce6dbe3f 100755 --- a/manual/english/Integration/Kafka.md +++ b/manual/english/Integration/Kafka.md @@ -61,6 +61,28 @@ batch=50 Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE SOURCE kafka (id bigint, term text, abbrev '$abbrev' text, GlossDef json) type='kafka' broker_list='kafka:9092' topic_list='my-data' consumer_group='manticore' num_consumers='2' batch=50" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + #### Options @@ -98,6 +120,28 @@ CREATE TABLE destination_kafka Query OK, 0 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE destination_kafka (id bigint, name text, short_name text, received_at text, size multi)" +``` + + + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + ### Materialized view @@ -134,6 +178,28 @@ SELECT id, term as name, abbrev as short_name, Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + Data is transferred from Kafka to Manticore Search in batches, which are cleared after each run. For calculations across batches, such as AVG, use caution, as these may not work as expected due to batch-by-batch processing. @@ -181,6 +247,40 @@ SHOW SOURCES +-------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCES" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "kafka" + } + ] + } +] +``` + @@ -212,6 +312,46 @@ SHOW SOURCE kafka; +--------+-------------------------------------------------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCE kafka" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Source": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + } + ], + "data": [ + { + "Source": "kafka", + "Create Table": "CREATE SOURCE kafka \n(id bigint, term text, abbrev '' text, GlossDef json)\ntype='kafka'\nbroker_list='kafka:9092'\ntopic_list='my-data'\nconsumer_group='manticore'\nnum_consumers='2'\n batch=50" + } + ] + } +] +``` + @@ -236,6 +376,40 @@ SHOW MVS +------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW MVS" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "view_table" + } + ] + } +] +``` + @@ -262,6 +436,52 @@ SHOW MV view_table +------------+--------------------------------------------------------------------------------------------------------+-----------+ ``` + + +##### JSON: + + + +```sql +POST /sql?mode=raw -d "SHOW MV view_table" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "View": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + }, + { + "suspended": { + "type": "string" + } + } + ], + "data": [ + { + "View": "view_table", + "Create Table": "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka", + "suspended": 0 + } + ] + } +] +``` + ### Altering materialized views @@ -290,6 +510,28 @@ ALTER MATERIALIZED VIEW view_table suspended=1 Query OK (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "ALTER MATERIALIZED VIEW view_table suspended=1" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + ### Sharding with Kafka diff --git a/manual/english/Listing_tables.md b/manual/english/Listing_tables.md index dbade3cf02..075dda1fde 100755 --- a/manual/english/Listing_tables.md +++ b/manual/english/Listing_tables.md @@ -40,6 +40,56 @@ SHOW TABLES; 5 rows in set (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW TABLES" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "dist", + "Type": "distributed" + }, + { + "Table": "plain", + "Type": "local" + }, + { + "Table": "pq", + "Type": "percolate" + },{ + "Table": "rt", + "Type": "rt" + },{ + "Table": "template", + "Type": "template" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] + +``` + + ```php @@ -181,6 +231,41 @@ SHOW TABLES LIKE 'pro%'; 1 row in set (0.00 sec) ``` + + +```sql +POST /sql?mode=raw -d "SHOW TABLES LIKE 'pro%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "products", + "Type": "distributed" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ```php @@ -340,6 +425,24 @@ select * from tbl.@table where type='text'; 1 row in set (0.00 sec) ``` + +```sql +POST /sql?mode=raw -d "select * from tbl.@table where type='text';" +``` + + +```JSON +[{ +"columns":[{"id":{"type":"long long"}},{"field":{"type":"string"}},{"type":{"type":"string"}},{"properties":{"type":"string"}}], +"data":[ +{"id":2,"field":"title","type":"text","properties":"indexed stored"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + @@ -354,6 +457,14 @@ select field, properties from tbl.@table where type in ('text', 'uint'); select * from tbl.@table where properties any ('stored'); ``` + + +```JSON +POST /sql?mode=raw -d "select field from tbl.@table;" +POST /sql?mode=raw -d "select field, properties from tbl.@table where type in ('text', 'uint');" +POST /sql?mode=raw -d "select * from tbl.@table where properties any ('stored');" +``` + ## SHOW CREATE TABLE @@ -381,6 +492,28 @@ f text indexed stored ) charset_table='non_cont,cont' morphology='icu_chinese' 1 row in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW CREATE TABLE tbl;" +``` + + +```JSON +[{ +"columns":[{"Table":{"type":"string"}},{"Create Table":{"type":"string"}}], +"data":[ +{"Table":"tbl","Create Table":"CREATE TABLE tbl (\nf text)"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + ### Percolate table schemas diff --git a/manual/english/Node_info_and_management/KILL.md b/manual/english/Node_info_and_management/KILL.md index c8a45318c0..588fa8f9c8 100755 --- a/manual/english/Node_info_and_management/KILL.md +++ b/manual/english/Node_info_and_management/KILL.md @@ -13,6 +13,18 @@ mysql> KILL 4; Query OK, 1 row affected (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "KILL 4" +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Node_info_and_management/Node_status.md b/manual/english/Node_info_and_management/Node_status.md index 754761dfae..44dc4d0d62 100755 --- a/manual/english/Node_info_and_management/Node_status.md +++ b/manual/english/Node_info_and_management/Node_status.md @@ -16,12 +16,12 @@ The easiest way to view high-level information about your Manticore node is by r * Number of jobs in queue and number of tasks, normalized by the number of threads -```sql +```mysql mysql> status ``` -```sql +```mysql -------------- mysql Ver 14.14 Distrib 5.7.30, for Linux (x86_64) using EditLine wrapper @@ -151,6 +151,339 @@ SHOW STATUS; +-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+ ``` + +##### JSON: + + +```JSON +SHOW STATUS; +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "uptime", + "Value": "107191" + }, + { + "Counter": "connections", + "Value": "214577" + }, + { + "Counter": "maxed_out", + "Value": "0" + }, + { + "Counter": "version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1) (buddy v3.35.1+25090418-41d9811f-dev)" + }, + { + "Counter": "mysql_version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1)" + }, + { + "Counter": "command_search", + "Value": "47" + }, + { + "Counter": "command_excerpt", + "Value": "3" + }, + { + "Counter": "command_update", + "Value": "0" + }, + { + "Counter": "command_keywords", + "Value": "0" + }, + { + "Counter": "command_persist", + "Value": "0" + }, + { + "Counter": "command_status", + "Value": "361" + }, + { + "Counter": "command_flushattrs", + "Value": "0" + }, + { + "Counter": "command_sphinxql", + "Value": "0" + }, + { + "Counter": "command_ping", + "Value": "0" + }, + { + "Counter": "command_delete", + "Value": "1" + }, + { + "Counter": "command_set", + "Value": "0" + }, + { + "Counter": "command_insert", + "Value": "13" + }, + { + "Counter": "command_replace", + "Value": "0" + }, + { + "Counter": "command_commit", + "Value": "0" + }, + { + "Counter": "command_suggest", + "Value": "0" + }, + { + "Counter": "command_json", + "Value": "0" + }, + { + "Counter": "command_callpq", + "Value": "8" + }, + { + "Counter": "command_cluster", + "Value": "0" + }, + { + "Counter": "command_getfield", + "Value": "0" + }, + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "agent_connect", + "Value": "0" + }, + { + "Counter": "agent_tfo", + "Value": "0" + }, + { + "Counter": "agent_retry", + "Value": "0" + }, + { + "Counter": "queries", + "Value": "44" + }, + { + "Counter": "dist_queries", + "Value": "0" + }, + { + "Counter": "workers_total", + "Value": "8" + }, + { + "Counter": "workers_active", + "Value": "3" + }, + { + "Counter": "workers_clients", + "Value": "1" + }, + { + "Counter": "workers_clients_vip", + "Value": "0" + }, + { + "Counter": "workers_clients_buddy", + "Value": "1" + }, + { + "Counter": "work_queue_length", + "Value": "8" + }, + { + "Counter": "load", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_primary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_secondary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "query_wall", + "Value": "0.007" + }, + { + "Counter": "query_cpu", + "Value": "OFF" + }, + { + "Counter": "dist_wall", + "Value": "0.000" + }, + { + "Counter": "dist_local", + "Value": "0.000" + }, + { + "Counter": "dist_wait", + "Value": "0.000" + }, + { + "Counter": "query_reads", + "Value": "OFF" + }, + { + "Counter": "query_readkb", + "Value": "OFF" + }, + { + "Counter": "query_readtime", + "Value": "OFF" + }, + { + "Counter": "avg_query_wall", + "Value": "0.000" + }, + { + "Counter": "avg_query_cpu", + "Value": "OFF" + }, + { + "Counter": "avg_dist_wall", + "Value": "0.000" + }, + { + "Counter": "avg_dist_local", + "Value": "0.000" + }, + { + "Counter": "avg_dist_wait", + "Value": "0.000" + }, + { + "Counter": "avg_query_reads", + "Value": "OFF" + }, + { + "Counter": "avg_query_readkb", + "Value": "OFF" + }, + { + "Counter": "avg_query_readtime", + "Value": "OFF" + }, + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 75, + "error": "", + "warning": "" + } +] +``` + @@ -177,6 +510,61 @@ SHOW STATUS LIKE 'qcache%'; +-----------------------+-------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE 'qcache%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + ```sql @@ -206,6 +594,96 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` ### Query Time Statistics @@ -256,6 +734,97 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` + ## SHOW SETTINGS @@ -298,6 +867,83 @@ SHOW SETTINGS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Setting_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Setting_name": "configuration_file", + "Value": "/etc/manticoresearch/manticore.conf.sh" + }, + { + "Setting_name": "worker_pid", + "Value": 1 + }, + { + "Setting_name": "searchd.listen", + "Value": "9306:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "/var/run/mysqld/mysqld.sock:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "9308:http" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9312" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9315-9325:replication" + }, + { + "Setting_name": "searchd.pid_file", + "Value": "/run/manticore/searchd.pid" + }, + { + "Setting_name": "searchd.data_dir", + "Value": "/var/lib/manticore" + }, + { + "Setting_name": "searchd.binlog_path", + "Value": "/var/lib/manticore/binlog" + }, + { + "Setting_name": "common.plugin_dir", + "Value": "/usr/local/lib/manticore" + } + ], + "total": 11, + "error": "", + "warning": "" + } +] +``` + ## SHOW AGENT STATUS @@ -378,6 +1024,47 @@ SHOW AGENT STATUS; 50 rows in set (0.01 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "status_period_seconds", + "Value": "60" + }, + { + "Key": "status_stored_periods", + "Value": "15" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1044,6 +1731,51 @@ SHOW AGENT STATUS LIKE '%5period%msec%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS LIKE '%5period%msec%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "ag_0_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_1_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_2_5periods_msecsperquery", + "Value": "234.72" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1295,6 +2027,76 @@ SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%'; 9 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql? mode=raw -d "SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "agent_15periods_query_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_failures", + "Value": "0" + }, + { + "Key": "agent_15periods_network_errors", + "Value": "0" + }, + { + "Key": "agent_15periods_wrong_replies", + "Value": "0" + }, + { + "Key": "agent_15periods_unexpected_closings", + "Value": "0" + }, + { + "Key": "agent_15periods_warnings", + "Value": "0" + }, + { + "Key": "agent_15periods_succeeded_queries", + "Value": "439" + }, + { + "Key": "agent_15periods_msecsperquery", + "Value": "231.73" + } + ], + "total": 9, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1615,6 +2417,91 @@ SHOW AGENT dist_index STATUS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT dist_index STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "dstindex_1_is_ha", + "Value": "1" + }, + { + "Key": "dstindex_1mirror1_id", + "Value": "192.168.0.202:6713:loc" + }, + { + "Key": "dstindex_1mirror1_probability_weight", + "Value": "0.372864" + }, + { + "Key": "dstindex_1mirror1_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror1_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_id", + "Value": "192.168.0.202:6714:loc" + }, + { + "Key": "dstindex_1mirror2_probability_weight", + "Value": "0.3746350" + }, + { + "Key": "dstindex_1mirror2_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_id", + "Value": "dev1.manticoresearch.com:6714:loc" + }, + { + "Key": "dstindex_1mirror3_probability_weight", + "Value": "0.252501" + }, + { + "Key": "dstindex_1mirror3_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_is_persistent", + "Value": "0" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/english/Node_info_and_management/SHOW_META.md b/manual/english/Node_info_and_management/SHOW_META.md index 42ce1a36c3..c8c3fa2492 100755 --- a/manual/english/Node_info_and_management/SHOW_META.md +++ b/manual/english/Node_info_and_management/SHOW_META.md @@ -66,6 +66,136 @@ show meta; 14 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +SELECT id, story_author FROM hn_small WHERE MATCH('one|two|three') and comment_ranking > 2 limit 5; +show meta; +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 151171, + "story_author": "anewkid" + }, + { + "id": 302758, + "story_author": "bks" + }, + { + "id": 805806, + "story_author": "drRoflol" + }, + { + "id": 1099245, + "story_author": "tnorthcutt" + }, + { + "id": 303252, + "story_author": "whiten" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "2308" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + }, + { + "Variable_name": "index", + "Value": "comment_ranking:SecondaryIndex (100%)" + } + ], + "total": 14, + "error": "", + "warning": "" + } +] +``` + @@ -129,6 +259,187 @@ SHOW META; 27 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,channel_id FROM records WHERE MATCH('one|two|three') limit 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "cpu_time", + "Value": "18.004" + }, + { + "Variable_name": "agents_cpu_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_ops", + "Value": "0" + }, + { + "Variable_name": "io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "io_write_ops", + "Value": "0" + }, + { + "Variable_name": "io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_read_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_write_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 27, + "error": "", + "warning": "" + } +] +``` + @@ -183,6 +494,147 @@ mysql> show meta; 17 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') limit 5 option max_predicted_time=100; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.012" + }, + { + "Variable_name": "local_fetched_docs", + "Value": "307212" + }, + { + "Variable_name": "local_fetched_hits", + "Value": "407390" + }, + { + "Variable_name": "local_fetched_skips", + "Value": "24" + }, + { + "Variable_name": "predicted_time", + "Value": "56" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 17, + "error": "", + "warning": "" + } +] +``` + @@ -231,6 +683,131 @@ SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.011" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + @@ -258,6 +835,52 @@ SHOW META LIKE 'total%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW META LIKE 'total%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ## SHOW META and facets @@ -310,6 +933,134 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 1, + "count(*)": 7 + } + ... + ], + "total": 658, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": 10, + "count(*)": 2436 + } + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## SHOW META and query optimizer @@ -344,6 +1095,77 @@ SHOW META; 5 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT count(*) FROM taxi1 WHERE tip_amount = 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "count(*)": 1 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.016" + }, + { + "Variable_name": "index", + "Value": "tip_amount:SecondaryIndex (100%)" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + ## SHOW META for PQ tables diff --git a/manual/english/Node_info_and_management/SHOW_QUERIES.md b/manual/english/Node_info_and_management/SHOW_QUERIES.md index d15e7c9002..299a10edf0 100755 --- a/manual/english/Node_info_and_management/SHOW_QUERIES.md +++ b/manual/english/Node_info_and_management/SHOW_QUERIES.md @@ -32,6 +32,66 @@ mysql> SHOW QUERIES; 2 rows in set (0.61 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW QUERIES;" +``` + + +``` +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "time": { + "type": "string" + } + }, + { + "protocol": { + "type": "string" + } + }, + { + "host": { + "type": "string" + } + } + ], + "data": [ + { + "id": 111, + "query": "select", + "time": "5ms ago", + "protocol": "http", + "host": "127.0.0.1:58986" + }, + { + "id": 96, + "query": "SHOW QUERIES", + "time": "255us", + "protocol": "mysql", + "host": "127.0.0.1:33616" + } + ] + } +] + +``` + Refer to [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md) if you'd like to gain insight from the perspective of the threads themselves. diff --git a/manual/english/Node_info_and_management/SHOW_VERSION.md b/manual/english/Node_info_and_management/SHOW_VERSION.md index 77f7e1b384..f01ae8438f 100755 --- a/manual/english/Node_info_and_management/SHOW_VERSION.md +++ b/manual/english/Node_info_and_management/SHOW_VERSION.md @@ -19,17 +19,71 @@ mysql> SHOW VERSION; ``` +```sql ++------------+-------------------------------------+ +| Component | Version | ++------------+-------------------------------------+ +| Daemon | 13.13.4 0bc5a9641@25101507 dev | +| Columnar | columnar 8.1.0 e1522a2@25100213 | +| Secondary | secondary 8.1.0 e1522a2@25100213 | +| Knn | knn 8.1.0 e1522a2@25100213 | +| Embeddings | embeddings 1.0.1 | +| Buddy | buddy v3.35.1+25090418-41d9811f-dev | ++------------+-------------------------------------+ +``` + + +```JSON +POST /sql?mode=raw -d "SHOW VERSION" ``` -+------------+--------------------------------+ -| Component | Version | -+------------+--------------------------------+ -| Daemon | 6.2.13 61cfe38d2@24011520 dev | -| Columnar | columnar 2.2.5 214ce90@240115 | -| Secondary | secondary 2.2.5 214ce90@240115 | -| Knn | knn 2.2.5 214ce90@240115 | -| Embeddings | embeddings 1.0.0 | -| Buddy | buddy v2.0.11 | -+------------+--------------------------------+ + + +```JSON +[ + { + "total": 6, + "error": "", + "warning": "", + "columns": [ + { + "Component": { + "type": "string" + } + }, + { + "Version": { + "type": "string" + } + } + ], + "data": [ + { + "Component": "Daemon", + "Version": "13.13.4 0bc5a9641@25101507 dev" + }, + { + "Component": "Columnar", + "Version": "columnar 8.1.0 e1522a2@25100213" + }, + { + "Component": "Secondary", + "Version": "secondary 8.1.0 e1522a2@25100213" + }, + { + "Component": "Knn", + "Version": "knn 8.1.0 e1522a2@25100213" + }, + { + "Component": "Embeddings", + "Version": "embeddings 1.0.1" + }, + { + "Component": "Buddy", + "Version": "buddy v3.35.1+25090418-41d9811f-dev" + } + ] + } +] ``` diff --git a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md index d34ed0a8cb..254fc49b72 100755 --- a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md +++ b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md @@ -64,5 +64,224 @@ SHOW TABLE test INDEXES; +------------------------------+--------+---------+---------+ 29 rows in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE test INDEXES;" +``` + + + +```JSON +[ + { + "columns": [ + { + "Name": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + }, + { + "Enabled": { + "type": "string" + } + }, + { + "Percent": { + "type": "string" + } + } + ], + "data": [ + { + "Name": "j['addresses']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['factor']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['int_arr']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "id", + "Type": "int64", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['price']", + "Type": "float", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['arr']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['str']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['1']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['2']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['3']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + } + ], + "total": 29, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md index 12aada0f10..0a7f604946 100755 --- a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md +++ b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md @@ -31,6 +31,43 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE forum SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -56,6 +93,43 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```sql +POST /sql?mode=raw -d "SHOW TABLE forum CHUNK 0 SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md index 6e236877e5..e320cf0d59 100755 --- a/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md +++ b/manual/english/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md @@ -129,6 +129,271 @@ mysql> SHOW TABLE statistic STATUS; 29 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE t STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "table_type", + "Value": "rt" + }, + { + "Variable_name": "indexed_documents", + "Value": "5" + }, + { + "Variable_name": "indexed_bytes", + "Value": "28" + }, + { + "Variable_name": "ram_bytes", + "Value": "23400" + }, + { + "Variable_name": "disk_bytes", + "Value": "1969" + }, + { + "Variable_name": "disk_mapped", + "Value": "196" + }, + { + "Variable_name": "disk_mapped_cached", + "Value": "16384" + }, + { + "Variable_name": "disk_mapped_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_hitlists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_hitlists", + "Value": "0" + }, + { + "Variable_name": "killed_documents", + "Value": "0" + }, + { + "Variable_name": "killed_rate", + "Value": "0.00%" + }, + { + "Variable_name": "ram_chunk", + "Value": "0" + }, + { + "Variable_name": "ram_chunk_segments_count", + "Value": "0" + }, + { + "Variable_name": "disk_chunks", + "Value": "1" + }, + { + "Variable_name": "mem_limit", + "Value": "134217728" + }, + { + "Variable_name": "mem_limit_rate", + "Value": "95.00%" + }, + { + "Variable_name": "ram_bytes_retired", + "Value": "0" + }, + { + "Variable_name": "optimizing", + "Value": "0" + }, + { + "Variable_name": "locked", + "Value": "0" + }, + { + "Variable_name": "tid", + "Value": "7" + }, + { + "Variable_name": "tid_saved", + "Value": "7" + }, + { + "Variable_name": "query_time_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_total", + "Value": "{\"queries\":30, \"avg_sec\":0.324, \"min_sec\":0.051, \"max_sec\":1.718, \"pct95_sec\":1.017, \"pct99_sec\":1.718}" + }, + { + "Variable_name": "found_rows_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_total", + "Value": "{\"queries\":30, \"avg\":2, \"min\":0, \"max\":5, \"pct95\":5, \"pct99\":5}" + }, + { + "Variable_name": "command_search", + "Value": "30" + }, + { + "Variable_name": "command_excerpt", + "Value": "3" + }, + { + "Variable_name": "command_update", + "Value": "0" + }, + { + "Variable_name": "command_keywords", + "Value": "0" + }, + { + "Variable_name": "command_status", + "Value": "1" + }, + { + "Variable_name": "command_delete", + "Value": "1" + }, + { + "Variable_name": "command_insert", + "Value": "6" + }, + { + "Variable_name": "command_replace", + "Value": "0" + }, + { + "Variable_name": "command_commit", + "Value": "0" + }, + { + "Variable_name": "command_suggest", + "Value": "0" + }, + { + "Variable_name": "command_callpq", + "Value": "0" + }, + { + "Variable_name": "command_getfield", + "Value": "0" + }, + { + "Variable_name": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 58, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/english/Searching/Faceted_search.md b/manual/english/Searching/Faceted_search.md index b2c581b341..e0c9c00db5 100755 --- a/manual/english/Searching/Faceted_search.md +++ b/manual/english/Searching/Faceted_search.md @@ -803,6 +803,90 @@ SELECT * FROM facetdemo FACET brand_name by brand_id; 10 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name, brand_id FROM facetdemo FACET brand_name by brand_id;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "brand_id": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Ten", + "brand_id": 10 + }, + ... + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Nine", + "brand_id": 9 + } + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "count(*)": 1013 + }, + { + "brand_name": "Brand Ten", + "count(*)": 998 + }, + { + "brand_name": "Brand Eight", + "count(*)": 1033 + }, + { + "brand_name": "Brand Seven", + "count(*)": 965 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + @@ -1563,6 +1647,90 @@ FACET price_range AS price_range,brand_name ORDER BY brand_name asc; | 1 | Brand Four | 195 | ... ``` + + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name,INTERVAL(price,200,400,600,800) AS price_range FROM facetdemo +FACET price_range AS price_range,brand_name ORDER BY brand_name asc;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "price_range": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "price_range": 1 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "fprice_range": { + "type": "long" + } + }, + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "fprice_range": 1, + "brand_name": "Brand Eight", + "count(*)": 197 + }, + { + "fprice_range": 4, + "brand_name": "Brand Eight", + "count(*)": 235 + }, + ... + { + "fprice_range": 0, + "brand_name": "Brand Five", + "count(*)": 183 + }, + { + "fprice_range": 1, + "brand_name": "Brand Four", + "count(*)": 195 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + @@ -2870,6 +3038,132 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 306, + "count(*)": 7 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": "10,11", + "count(*)": 2436 + }, + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Searching/Full_text_matching/Basic_usage.md b/manual/english/Searching/Full_text_matching/Basic_usage.md index 7fb60c6ae3..dc21df8465 100755 --- a/manual/english/Searching/Full_text_matching/Basic_usage.md +++ b/manual/english/Searching/Full_text_matching/Basic_usage.md @@ -52,6 +52,52 @@ SELECT * FROM myindex WHERE MATCH('"find me fast"/2'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM myindex WHERE MATCH('"find me fast"/2');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "gid": 11, + "title": "first find me" + }, + { + "id": 1, + "gid": 12, + "title": "second find me" + }, + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + An example of a more complex query using MATCH with WHERE filters. diff --git a/manual/english/Searching/Full_text_matching/Profiling.md b/manual/english/Searching/Full_text_matching/Profiling.md index 9b33ee95a6..f092b41a08 100755 --- a/manual/english/Searching/Full_text_matching/Profiling.md +++ b/manual/english/Searching/Full_text_matching/Profiling.md @@ -1201,6 +1201,43 @@ Variable: transformed_tree AND(fields=(title), KEYWORD(running, querypos=1, morphed)))) AND(fields=(body), KEYWORD(dog, querypos=2, morphed))) ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY t '@title a'" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "AND(fields=(title), KEYWORD(a, querypos=1))" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] + +``` + @@ -1236,6 +1273,42 @@ Variable: transformed_tree 4 [shape=record label="me | { querypos=2 }"] } ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY tbl '@title a' option format=dot" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "digraph \"transformed_tree\" {\n\n0 [shape=record,style=filled label=\"AND | { fields=(title) }\"]\n0 -> 1\n1 [shape=record label=\"a | { qp=1 }\"]\n}" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## Viewing the match factors values @@ -1271,6 +1344,41 @@ packedfactors(): bm25=569, bm25a=0.617197, field_mask=2, doc_word_count=2, word1=(tf=1, idf=0.215338) 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id, PACKEDFACTORS() FROM test1 WHERE MATCH('test one') OPTION ranker=expr('1')" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "packedfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "packedfactors()": "bm25=500, bm25a=0.500000, field_mask=1, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.000000, min_idf=0.000000, max_idf=0.000000, sum_idf=0.000000, min_hit_pos=1, min_best_span_pos=1, exact_hit=1, max_window_hits=1, min_gaps=0, exact_order=1, lccs=1, wlccs=0.000000, atc=0.000000), word0=(tf=1, idf=0.000000)" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Searching/Grouping.md b/manual/english/Searching/Grouping.md index 67fcf3ea2f..75405a743b 100755 --- a/manual/english/Searching/Grouping.md +++ b/manual/english/Searching/Grouping.md @@ -79,6 +79,46 @@ SELECT release_year FROM films GROUP BY release_year LIMIT 5; | 2000 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year FROM films GROUP BY release_year LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2004 + }, + { + "release_year": 2002 + }, + { + "release_year": 2001 + }, + { + "release_year": 2005 + }, + { + "release_year": 2000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + In most cases, however, you'll want to obtain some aggregated data for each group, such as: @@ -523,6 +563,56 @@ SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_ | 2004 | 108 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_year asc limit 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2000, + "count(*)": 97 + }, + { + "release_year": 2001, + "count(*)": 91 + }, + { + "release_year": 2002, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2004, + "count(*)": 108 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + Alternatively, you can sort by the aggregation: @@ -567,6 +657,56 @@ SELECT release_year, AVG(rental_rate) avg FROM films GROUP BY release_year ORDER | 2008 | 2.99000049 | +--------------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year ORDER BY count(*) desc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2006, + "count(*)": 103 + }, + { + "release_year": 2008, + "count(*)": 102 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + @@ -710,6 +850,60 @@ SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_y | 2007 | ARACHNOPHOBIA ROLLERCOASTER | +--------------+-----------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_year DESC LIMIT 6;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "ALICE FANTASIA" + }, + { + "release_year": 2009, + "title": "ALIEN CENTER" + }, + { + "release_year": 2008, + "title": "AMADEUS HOLY" + }, + { + "release_year": 2008, + "title": "ANACONDA CONFESSIONS" + }, + { + "release_year": 2007, + "title": "ANGELS LIFE" + }, + { + "release_year": 2007, + "title": "ARACHNOPHOBIA ROLLERCOASTER" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + @@ -741,6 +935,66 @@ SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN | 2005 | AIRPLANE SIERRA | 4.990000 | +--------------+------------------+-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN GROUP ORDER BY rental_rate DESC ORDER BY release_year DESC LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + }, + { + "rental_rate": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "AMERICAN CIRCUS", + "rental_rate": 4.990000 + }, + { + "release_year": 2009, + "title": "ANTHEM LUKE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ATTACKS HATE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ALADDIN CALENDAR", + "rental_rate": 4.990000 + }, + { + "release_year": 2007, + "title": "AIRPLANE SIERRA", + "rental_rate": 4.990000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + @@ -765,6 +1019,51 @@ SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVIN | 2006 | 3.26184368 | +--------------+------------+ ``` + +```JSON +POST /sql?mode=raw -d "SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVING avg > 3;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "avg": 3.08259249 + }, + { + "release_year": 2001, + "avg": 3.09989142 + }, + { + "release_year": 2000, + "avg": 3.17556739 + }, + { + "release_year": 2006, + "avg": 3.26184368 + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + @@ -791,6 +1090,44 @@ SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() | 2000 | 97 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() IN (2000, 2002);" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "count": 108 + }, + { + "release_year": 2000, + "count": 97 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### Grouping by MVA (multi-value attributes) @@ -1550,6 +1887,56 @@ SELECT major, count(*), count(distinct age) FROM students GROUP BY major; | cs | 2 | 2 | +----------+----------+---------------------+ ``` + + +```JSON +POST /sql?mode=raw - d "SELECT major, count(*), count(distinct age) FROM students GROUP BY major;" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + @@ -1576,6 +1963,64 @@ SELECT major, count(*), count(distinct age), group_concat(age) FROM students GRO | cs | 2 | 2 | 21,22 | +----------+----------+---------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT major, count(*), count(distinct age), group_concat(age) FROM students GROUP BY major" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + }, + { + "group_concat(age)": { + "type": "string" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1, + "group_concat(age)": 21,21 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1, + "group_concat(age)": 22 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2, + "group_concat(age)": 21,22 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### SUM(), MIN(), MAX(), AVG() @@ -1600,6 +2045,86 @@ SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental | 2004 | 300.920044 | 0.990000 | 4.990000 | 2.78629661 | +------+------------+----------+----------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental_rate) max, avg(rental_rate) avg FROM films GROUP BY release_year ORDER BY year asc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "sum": { + "type": "long long" + } + }, + { + "min": { + "type": "long long" + } + }, + { + "max": { + "type": "long long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2000, + "sum": 308.030029, + "min": 0.990000, + "max": 4.990000, + "avg": 3.17556739 + }, + { + "year": 2001, + "sum": 282.090118, + "min": 0.990000, + "max": 4.990000, + "avg": 3.09989142 + }, + { + "year": 2002, + "sum": 332.919983, + "min": 0.99, + "max": 4.990000, + "avg": 3.08259249 + }, + { + "year": 2003, + "sum": 310.940063, + "min": 0.990000, + "max": 4.990000, + "avg": 2.93339682 + }, + { + "year": 2004, + "sum": 300.920044, + "min": 0.990000, + "max": 4.990000, + "avg": 2.78629661 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + @@ -1653,6 +2178,143 @@ MySQL [(none)]> SELECT release_year year, count(*) FROM films GROUP BY year limi | 2001 | 91 | +------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + }, + { + "year": 2005, + "count(*)": 93 + }, + { + "year": 2000, + "count(*)": 97 + }, + ], + "total": 5, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=1;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=2;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + }, + { + "year": 2002, + "count(*)": 74 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=3;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Searching/Highlighting.md b/manual/english/Searching/Highlighting.md index 1b382079e4..d7c82a4967 100755 --- a/manual/english/Searching/Highlighting.md +++ b/manual/english/Searching/Highlighting.md @@ -860,6 +860,38 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('before'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('before');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "A door opened before them, revealing a small room." + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -885,6 +917,38 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```json +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "Book one" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -909,6 +973,36 @@ SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHE 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": "Book [match]one[/match]" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + + @@ -935,6 +1029,39 @@ SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title,content')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title,content')": "Book one | They followed Bander. The robots remained at a polite distance, but their presence was a constantly felt threat." + }, + { + "highlight({},'title,content')": "Bander ushered all three into the room. One of the robots followed as well. Bander gestured the other robots away and entered itself. The door closed behind it." + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + + @@ -961,6 +1088,38 @@ SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},title)": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},title)": "Book one" + }, + { + "highlight({},title)": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + @@ -987,6 +1146,38 @@ SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title', 'five')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title', 'five')": "Book one" + }, + { + "highlight({},'title', 'five')": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + @@ -1012,6 +1203,35 @@ SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": { + "type": "string" + } + } + ], + "data": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": "some text to highlight" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + Several options are relevant only when generating a single string as a result (not an array of snippets). This applies exclusively to the SQL `HIGHLIGHT()` function: @@ -3790,6 +4010,38 @@ CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', ' 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', 'is text', 5 AS around, 200 AS limit);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + Most options are the same as in the [HIGHLIGHT() function](../Searching/Highlighting.md). There are, however, several options that can only be used with `CALL SNIPPETS`. @@ -3824,6 +4076,38 @@ CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_f 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_files);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Searching/KNN.md b/manual/english/Searching/KNN.md index 6a74cbc564..6ede37bdf1 100755 --- a/manual/english/Searching/KNN.md +++ b/manual/english/Searching/KNN.md @@ -38,6 +38,24 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di Query OK, 0 rows affected (0.01 sec) ``` + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' );" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + + ##### Plain mode (using configuration file): @@ -110,6 +128,26 @@ CREATE TABLE products_all ( ); ``` + +##### JSON: + + + +Using sentence-transformers (no API key needed) +```json +POST /sql?mode=raw -d "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');" +``` + +Using OpenAI (requires API_KEY parameter) +```json +POST /sql?mode=raw -d "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='...');" +``` + +Using all text fields for embeddings (FROM is empty) +```json +POST /sql?mode=raw -d "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='');" +``` + ##### Inserting data with auto embeddings @@ -143,6 +181,26 @@ INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ()); ``` + +##### JSON: + + + +Insert text data only - embeddings generated automatically +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title) VALUES ('machine learning artificial intelligence'),('banana fruit sweet yellow');" +``` + +Insert multiple fields - both used for embedding if FROM='title,description' +```JSON +POST /sql?mode=raw -d "INSERT INTO products_openai (title, description) VALUES ('smartphone', 'latest mobile device with advanced features'), ('laptop', 'portable computer for work and gaming');" +``` + +Insert empty vector (document excluded from vector search) +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ());" +``` + ##### Searching with auto embeddings @@ -441,6 +499,27 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di ```sql Query OK, 0 rows affected (0.01 sec) ``` + + +##### JSON: + + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' quantization='1bit');" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Searching/Multi-queries.md b/manual/english/Searching/Multi-queries.md index bdb75e0f3a..d9598013a8 100755 --- a/manual/english/Searching/Multi-queries.md +++ b/manual/english/Searching/Multi-queries.md @@ -26,6 +26,16 @@ SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; S ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price ASC" +``` + + ## Multi-queries optimizations There are two major optimizations to be aware of: common query optimization and common subtree optimization. diff --git a/manual/english/Searching/Options.md b/manual/english/Searching/Options.md index fe25e5d4e3..7292ad0144 100755 --- a/manual/english/Searching/Options.md +++ b/manual/english/Searching/Options.md @@ -311,6 +311,58 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all | 1658178727135150081 | smth else | +---------------------+-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select * from tbl where match('-d');" +{ + "error": "table t: query error: query is non-computable (single NOT operator)" +} + +POST /sql?mode=raw -d "select * from t where match('-d') option not_terms_only_allowed=1;" +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "c", + "f2": 3 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ### ranker @@ -378,6 +430,12 @@ For more information on how the query optimizer works, refer to the [Cost based SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */" +``` + diff --git a/manual/english/Searching/Percolate_query.md b/manual/english/Searching/Percolate_query.md index 4a12d8d6cd..c69c6098c0 100755 --- a/manual/english/Searching/Percolate_query.md +++ b/manual/english/Searching/Percolate_query.md @@ -2305,6 +2305,70 @@ CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue" | 1657852401006149666 | 123 | @title shoes | | color IN ('blue, 'green') | +---------------------+-----------+--------------+------+---------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue"}, {"id": 456, "title": "beautiful bag"}]', 1 as query, 'id' as docs_id, 1 as docs);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "documents": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149664, + "documents": 456, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149666, + "documents": 123, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + @@ -2342,6 +2406,68 @@ ERROR 1064 (42000): Bad JSON objects in strings: 2 +---------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'), 1 as skip_bad_json);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + }, + { + "id": 1657852401006149637 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] + +{ + "error": "Bad JSON objects in strings: 1" +} + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ##### I want higher performance of a percolate query @@ -3244,6 +3370,61 @@ CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue +---------------------+--------------+------+---------------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'), 'sharded' as mode, 1 as query);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149639, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149643, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + Note that the syntax of agent mirrors in the configuration (when several hosts are assigned to one `agent` line, separated with `|`) has nothing to do with the `CALL PQ` query mode. Each `agent` always represents **one** node, regardless of the number of HA mirrors specified for that agent. diff --git a/manual/english/Searching/Search_results.md b/manual/english/Searching/Search_results.md index 00d7feb605..bbe581f2d5 100755 --- a/manual/english/Searching/Search_results.md +++ b/manual/english/Searching/Search_results.md @@ -21,6 +21,58 @@ SELECT * FROM tbl; +------+------+--------+ 3 rows in set (0.00 sec) ``` + + +```JSON +POST /sql -d "SELECT * FROM tbl;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "age": { + "type": "long" + } + }, + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "age": "joe", + "name": 25 + }, + { + "id": 2, + "age": "mary", + "name": 255 + }, + { + "id": 3, + "age": "albert", + "name": 33 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] + +``` + @@ -52,6 +104,82 @@ SELECT id,story_author,comment_author FROM hn_small WHERE story_author='joe' LIM +----------------+-------+ 4 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id,f1,f2 FROM t WHERE f2=2 LIMIT 1; SHOW META;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "gte" + }, + { + "Variable_name": "time", + "Value": "0.000" + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + @@ -78,6 +206,75 @@ SELECT * FROM tbl WHERE MATCH('joe') FACET age; +------+----------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM tbl WHERE MATCH('b') FACET f2;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 2, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "f2": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "f2": 2, + "count(*)": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -103,6 +300,70 @@ SELECT * from tbl where match('"joe"/3'); show warnings; +---------+------+--------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('\"a\"/3'); show warnings;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f2": { + "type": "long" + } + }, + { + "f1": { + "type": "string" + } + } + ], + "data": [], + "total": 0, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Level": { + "type": "string" + } + }, + { + "Code": { + "type": "decimal" + } + }, + { + "Message": { + "type": "string" + } + } + ], + "data": [ + { + "Level": "warning", + "Code": "1000", + "Message": "table t: quorum threshold too high (words=1, thresh=3); replacing quorum operator with AND operator" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -118,6 +379,18 @@ SELECT * from tbl where match('@surname joe'); ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema ``` + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('@surname joe');" +``` + + +```JSON +{ + "error": "table t: query error: no field 'surname' found in schema" +} +``` + diff --git a/manual/english/Searching/Sorting_and_ranking.md b/manual/english/Searching/Sorting_and_ranking.md index 38a4fb1710..64f7e8c057 100755 --- a/manual/english/Searching/Sorting_and_ranking.md +++ b/manual/english/Searching/Sorting_and_ranking.md @@ -38,6 +38,58 @@ select *, a + b alias from test order by alias desc; +------+------+------+----------+-------+ ``` + +```JSON +POST /sql?mode=raw -d "select *, a + b alias from test order by alias desc;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "a": { + "type": "long" + } + }, + { + "b": { + "type": "long" + } + }, + { + "f": { + "type": "string" + } + }, + { + "alias": { + "type": "long" + } + } + ], + "data": [ + { + "id": 1, + "a": 2, + "b": 3, + "f": document, + "alias": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## Sorting via JSON diff --git a/manual/english/Securing_and_compacting_a_table/Compacting_a_table.md b/manual/english/Securing_and_compacting_a_table/Compacting_a_table.md index 98e38f5d35..f7580a5f9d 100755 --- a/manual/english/Securing_and_compacting_a_table/Compacting_a_table.md +++ b/manual/english/Securing_and_compacting_a_table/Compacting_a_table.md @@ -21,6 +21,16 @@ OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]] ```sql OPTIMIZE TABLE rt; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt;" +``` + ### Number of optimized disk chunks @@ -45,6 +55,16 @@ Additional options include: ```sql OPTIMIZE TABLE rt OPTION cutoff=4; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION cutoff=4;" +``` + ### Running in foreground @@ -61,6 +81,16 @@ When using `OPTION sync=1` (0 by default), the command will wait for the optimiz ```sql OPTIMIZE TABLE rt OPTION sync=1; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION sync=1;" +``` + ### Throttling the IO impact @@ -82,6 +112,10 @@ On one of the nodes, drop the table from the cluster: ```sql ALTER CLUSTER mycluster DROP myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster DROP myindex;" +``` Optimize the table: @@ -89,6 +123,10 @@ Optimize the table: ```sql OPTIMIZE TABLE myindex; ``` + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE myindex;" +``` Add back the table to the cluster: @@ -96,6 +134,10 @@ Add back the table to the cluster: ```sql ALTER CLUSTER mycluster ADD myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster ADD myindex;" +``` When the table is added back, the new files created by the optimization process will be replicated to the other nodes in the cluster. Any local changes made to the table on other nodes will be lost. diff --git a/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md b/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md index 2cbec18583..223de73049 100755 --- a/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md +++ b/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md @@ -24,6 +24,26 @@ FLUSH RAMCHUNK rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH RAMCHUNK rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md b/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md index d18f4d1582..74ca683224 100755 --- a/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md +++ b/manual/english/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md @@ -26,6 +26,25 @@ FLUSH TABLE rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH TABLE rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` diff --git a/manual/russian/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md b/manual/russian/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md index ca2919953e..404983d0e6 100644 --- a/manual/russian/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md +++ b/manual/russian/Creating_a_cluster/Setting_up_replication/Joining_a_replication_cluster.md @@ -1,7 +1,7 @@ # Присоединение к кластеру репликации -Чтобы присоединиться к существующему кластеру, необходимо указать как минимум: +Чтобы присоединиться к существующему кластеру, вы должны указать как минимум: * [имя](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) кластера * `host:port` другого узла в кластере, к которому вы присоединяетесь @@ -106,24 +106,29 @@ utils_api.sql("JOIN CLUSTER posts AT '10.12.1.35:9312'", Some(true)).await; -В большинстве случаев вышеуказанного достаточно, если существует один кластер репликации. Однако, если вы создаёте несколько кластеров репликации, необходимо также задать [путь](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) и убедиться, что директория доступна. +В большинстве случаев вышеуказанного достаточно, если имеется один кластер репликации. Однако, если вы создаёте несколько кластеров репликации, необходимо также задать [путь](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) и обеспечить доступность директории. ```sql JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path ``` + + +```JSON +POST /sql?mode=raw -d "JOIN CLUSTER c2 at '127.0.0.1:10201' 'c2' as path" +``` -Узел присоединяется к кластеру, получая данные от указанного узла и, в случае успеха, обновляет списки узлов на всех остальных узлах кластера так же, как если бы это было сделано вручную через [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Этот список используется для повторного присоединения узлов к кластеру при перезапуске. +Узел присоединяется к кластеру, получая данные от указанного узла и, в случае успеха, обновляет списки узлов по всем остальным узлам кластера так же, как если бы это было сделано вручную с помощью [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Этот список используется для повторного присоединения узлов к кластеру при перезапуске. Существует два списка узлов: -1.`cluster__nodes_set`: используется для повторного присоединения узлов к кластеру при перезапуске. Он обновляется на всех узлах так же, как это делает [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Команда `JOIN CLUSTER` выполняет это обновление автоматически. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_set`. -2. `cluster__nodes_view`: этот список содержит все активные узлы, используемые для репликации, и не требует ручного управления. [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) фактически копирует этот список узлов в список узлов, используемых для повторного присоединения при перезапуске. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_view`. +1. `cluster__nodes_set`: используется для повторного присоединения узлов к кластеру при перезапуске. Он обновляется на всех узлах так же, как это делает [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). Команда `JOIN CLUSTER` выполняет это обновление автоматически. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_set`. +2. `cluster__nodes_view`: этот список содержит все активные узлы, используемые для репликации, и не требует ручного управления. [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md) фактически копирует этот список узлов в список узлов для повторного присоединения при перезапуске. [Статус кластера](../../Creating_a_cluster/Setting_up_replication/Replication_cluster_status.md) отображает этот список как `cluster__nodes_view`. -Когда узлы расположены в разных сетевых сегментах или дата-центрах, опция [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) может быть задана явно. Это минимизирует трафик между узлами и использует шлюзовые узлы для межсоединения между дата-центрами. Следующий код присоединяется к существующему кластеру с использованием опции [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster). +Когда узлы расположены в разных сетевых сегментах или дата-центрах, опция [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster) может задаваться явно. Это минимизирует трафик между узлами и использует шлюзовые узлы для межцентровой связи. Следующий код присоединяет существующий кластер, используя опцию [nodes](../../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster). -> **Примечание:** список кластера `cluster__nodes_set` не обновляется автоматически при использовании этого синтаксиса. Для его обновления используйте [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). +> **Примечание:** список кластера `cluster__nodes_set` не обновляется автоматически при использовании этого синтаксиса. Для обновления используйте [ALTER CLUSTER ... UPDATE nodes](../../Creating_a_cluster/Setting_up_replication/Managing_replication_nodes.md). @@ -227,6 +232,6 @@ utils_api.sql("JOIN CLUSTER click_query 'clicks_mirror1:9312;clicks_mirror2:9312 Команда `JOIN CLUSTER` работает синхронно и завершается, как только узел получает все данные от других узлов кластера и синхронизируется с ними. -Операция `JOIN CLUSTER` может завершиться с ошибкой, указывающей на дублирование [server_id](../../Server_settings/Searchd.md#server_id). Это происходит, когда присоединяющийся узел имеет такой же `server_id`, как и существующий узел в кластере. Чтобы решить эту проблему, убедитесь, что каждый узел в кластере репликации имеет уникальный [server_id](../../Server_settings/Searchd.md#server_id). Вы можете изменить значение по умолчанию [server_id](../../Server_settings/Searchd.md#server_id) в разделе "searchd" вашего конфигурационного файла на уникальное значение перед попыткой присоединения к кластеру. +Операция `JOIN CLUSTER` может завершиться с ошибкой, указывающей на дублирование [server_id](../../Server_settings/Searchd.md#server_id). Это происходит, когда присоединяемый узел имеет тот же `server_id`, что и уже существующий узел в кластере. Для решения этой проблемы убедитесь, что у каждого узла в кластере репликации уникальный [server_id](../../Server_settings/Searchd.md#server_id). Вы можете изменить значение по умолчанию [server_id](../../Server_settings/Searchd.md#server_id) в разделе "searchd" вашего конфигурационного файла на уникальное значение до попытки присоединения к кластеру. diff --git a/manual/russian/Creating_a_table/Data_types.md b/manual/russian/Creating_a_table/Data_types.md index 078a7bd160..013b96a645 100644 --- a/manual/russian/Creating_a_table/Data_types.md +++ b/manual/russian/Creating_a_table/Data_types.md @@ -2485,60 +2485,60 @@ let search_res = search_api.search(search_req).await; -Атрибуты векторных чисел с плавающей запятой позволяют хранить списки переменной длины из чисел с плавающей запятой, преимущественно используемые для приложений машинного обучения и поиска по сходству. Этот тип отличается от [мультизначных атрибутов](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) (MVA) по нескольким важным аспектам: +Атрибуты векторных чисел с плавающей запятой позволяют хранить списки чисел с плавающей запятой переменной длины, в основном используемые для приложений машинного обучения и поиска по сходству. Этот тип отличается от [мультизначных атрибутов](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) (MVA) несколькими важными аспектами: - Сохраняет точный порядок значений (в отличие от MVA, которые могут менять порядок) -- Сохраняет дублирующиеся значения (в отличие от MVA, которые удаляют дубликаты) -- Нет дополнительной обработки при вставке (в отличие от MVA, которые сортируют и удаляют дубликаты) +- Сохраняет повторяющиеся значения (в отличие от MVA, которые устраняют дубликаты) +- Нет дополнительной обработки при вставке (в отличие от MVA, которые сортируют и устраняют дубликаты) -Атрибуты векторных чисел с плавающей запятой позволяют хранить списки переменной длины из чисел с плавающей запятой, преимущественно используемые для приложений машинного обучения и поиска по сходству. +Атрибуты векторных чисел с плавающей запятой позволяют хранить списки чисел с плавающей запятой переменной длины, в основном используемые для приложений машинного обучения и поиска по сходству. ### Использование и ограничения - В настоящее время поддерживаются только в таблицах реального времени -- Могут использоваться только в поисках KNN (k-ближайших соседей) +- Могут использоваться только в KNN (k-ближайших соседей) поисках - Не поддерживаются в обычных таблицах или других функциях/выражениях - При использовании с настройками KNN нельзя `UPDATE` значения `float_vector`. Используйте `REPLACE` - При использовании без настроек KNN можно `UPDATE` значения `float_vector` -- Векторы с плавающей запятой нельзя использовать в обычных фильтрах или сортировке +- Векторы с плавающей запятой не могут использоваться в обычных фильтрах или сортировках - Единственный способ фильтровать по значениям `float_vector` — через операции векторного поиска (KNN) -### Распространённые случаи использования -- Текстовые эмбеддинги для семантического поиска +### Основные случаи использования +- Встраивания текста для семантического поиска - Векторы рекомендательных систем -- Эмбеддинги изображений для поиска по сходству +- Встраивания изображений для поиска по сходству - Векторы признаков для машинного обучения -** Имейте в виду, что тип данных `float_vector` несовместим с механизмом [Auto schema](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema). ** +** Учтите, что тип данных `float_vector` несовместим с механизмом [Auto schema](../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-schema). ** -Для получения подробной информации о настройке векторов с плавающей запятой и их использовании в поисках смотрите [KNN search](../Searching/KNN.md). +Подробнее о настройке векторов с плавающей запятой и использовании их в поисках смотрите в разделе [KNN search](../Searching/KNN.md). -### Автоматические эмбеддинги (рекомендуется) +### Авто встраивания (рекомендуется) -Самый удобный способ работы с векторами с плавающей запятой — использование **автоматических эмбеддингов**. Эта функция автоматически генерирует эмбеддинги из ваших текстовых данных с помощью моделей машинного обучения, устраняя необходимость вручную вычислять и вставлять векторы. +Самый удобный способ работы с векторами с плавающей запятой — использование **авто встраиваний**. Эта функция автоматически генерирует встраивания из вашего текстового контента с помощью моделей машинного обучения, избавляя от необходимости вручную вычислять и вставлять векторы. -#### Преимущества автоматических эмбеддингов -- **Упрощённый рабочий процесс**: Просто вставляйте текст, эмбеддинги генерируются автоматически -- **Нет необходимости вручную вычислять векторы**: Не нужно запускать отдельные модели эмбеддингов -- **Последовательные эмбеддинги**: Одна и та же модель обеспечивает согласованное представление векторов +#### Преимущества авто встраиваний +- **Упрощенный процесс**: Просто вставляйте текст, встраивания генерируются автоматически +- **Нет необходимости вручную считать векторы**: Не нужно запускать отдельные модели встраивания +- **Единообразные встраивания**: Одна и та же модель обеспечивает согласованные векторные представления - **Поддержка нескольких моделей**: Выбор из моделей [sentence-transformers](https://huggingface.co/sentence-transformers/models), OpenAI, Voyage и Jina -- **Гибкий выбор полей**: Контроль над тем, какие поля используются для генерации эмбеддингов +- **Гибкий выбор полей**: Контроль над тем, какие поля используются для генерации встраиваний -#### Создание таблиц с автоматическими эмбеддингами +#### Создание таблиц с авто встраиваниями -При создании таблицы с автоматическими эмбеддингами укажите следующие дополнительные параметры: -- `MODEL_NAME`: модель эмбеддингов для автоматической генерации векторов -- `FROM`: какие поля использовать для генерации эмбеддингов (пустая строка означает все текстовые/строковые поля) +При создании таблицы с авто встраиваниями указывайте следующие дополнительные параметры: +- `MODEL_NAME`: модель встраивания, используемая для автоматической генерации векторов +- `FROM`: какие поля использовать для генерации встраиваний (пустая строка означает все текстовые/строковые поля) -**Поддерживаемые модели эмбеддингов:** -- **Sentence Transformers**: Любая [подходящая модель BERT на Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — API ключ не требуется. Manticore загружает модель при создании таблицы. -- **OpenAI**: Модели эмбеддингов OpenAI, например `openai/text-embedding-ada-002` — требует параметр `API_KEY=''` -- **Voyage**: Модели эмбеддингов Voyage AI — требует параметр `API_KEY=''` -- **Jina**: Модели эмбеддингов Jina AI — требует параметр `API_KEY=''` +**Поддерживаемые модели встраивания:** +- **Sentence Transformers**: Любая [подходящая модель на базе BERT с Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — не требуется ключ API. Manticore скачивает модель при создании таблицы. +- **OpenAI**: модели встраивания OpenAI, например `openai/text-embedding-ada-002` — требуется параметр `API_KEY=''` +- **Voyage**: модели встраивания Voyage AI — требуется параметр `API_KEY=''` +- **Jina**: модели встраивания Jina AI — требуется параметр `API_KEY=''` ##### SQL: -Использование модели [sentence-transformers](https://huggingface.co/sentence-transformers/models) (API ключ не требуется) +Использование модели [sentence-transformers](https://huggingface.co/sentence-transformers/models) (ключ API не нужен) ```sql CREATE TABLE products ( title TEXT, @@ -2558,7 +2558,7 @@ CREATE TABLE products_openai ( ); ``` -Использование всех текстовых полей для эмбеддингов (FROM пустой) +Использование всех текстовых полей для встраиваний (FROM пустой) ```sql CREATE TABLE products_all_fields ( title TEXT, @@ -2569,20 +2569,39 @@ CREATE TABLE products_all_fields ( ); ``` + +##### JSON: + + +Использование модели [sentence-transformers](https://huggingface.co/sentence-transformers/models) (ключ API не нужен) +```JSON +POST /sql?mode=raw -d "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');" +``` + +Использование модели OpenAI (требуется параметр API_KEY) +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_openai (title TEXT, content TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine' MODEL_NAME='openai/text-embedding-ada-002' FROM='title,content' API_KEY='');" +``` + +Использование всех текстовых полей для встраиваний (FROM пустой) +```JSON +POST /sql?mode=raw -d "CREATE TABLE products_all_fields (title TEXT, description TEXT, tags TEXT, embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2' MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='');" +``` + #### Использование параметра FROM -Параметр `FROM` контролирует, какие поля используются для генерации эмбеддингов: +Параметр `FROM` контролирует, какие поля используются для генерации встраиваний: - **Конкретные поля**: `FROM='title'` — используется только поле title - **Несколько полей**: `FROM='title,description'` — объединяются и используются поля title и description -- **Все текстовые поля**: `FROM=''` (пусто) — используются все поля типа `text` (полнотекстовые поля) и `string` (строковые атрибуты) в таблице -- **Пустые векторы**: Можно вставлять пустые векторы с помощью `()`, чтобы исключить документы из векторного поиска +- **Все текстовые поля**: `FROM=''` (пустое) — используются все поля `text` (полнотекстовое поле) и `string` (строковые атрибуты) таблицы +- **Пустые векторы**: Вы всё равно можете вставлять пустые векторы при помощи `()` для исключения документов из векторного поиска -#### Вставка данных с автоматическими эмбеддингами +#### Вставка данных с авто встраиваниями -При использовании автоматических эмбеддингов **не указывайте поле вектора** в ваших операторах INSERT. Эмбеддинги автоматически генерируются из указанных текстовых полей: +При использовании авто встраиваний **не указывайте поле вектора** в операторах INSERT. Встраивания автоматически генерируются из указанных текстовых полей: ```sql -- Insert text data - embeddings generated automatically @@ -2598,7 +2617,7 @@ INSERT INTO products (title, description, embedding_vector) VALUES ### Ручное использование векторов с плавающей запятой -В качестве альтернативы можно работать с вручную вычисленными векторами с плавающей запятой. +Альтернативно, можно работать с вручную вычисленными векторами с плавающей запятой. ##### SQL: @@ -2708,7 +2727,7 @@ table products -Мультизначные атрибуты позволяют хранить списки переменной длины из 32-битных беззнаковых целых чисел. Это может быть полезно для хранения числовых значений один-ко-многим, таких как теги, категории продуктов и свойства. +Мультизначные атрибуты позволяют хранить списки 32-битных беззнаковых целых чисел переменной длины. Это полезно для хранения числовых значений "один ко многим", таких как теги, категории товаров и свойства. ##### SQL: diff --git a/manual/russian/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md b/manual/russian/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md index b3c04be5c1..911a8b9fc0 100644 --- a/manual/russian/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md +++ b/manual/russian/Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md @@ -609,10 +609,10 @@ source = srcpart3 killlist_target = main:kl ```ini -Этот параметр определяет таблицу(ы), к которым будет применяться kill-list. Совпадения в целевой таблице, которые обновляются или удаляются в текущей таблице, будут подавлены. В режиме `:kl` документы для подавления берутся из [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md). В режиме `:id` все идентификаторы документов из текущей таблицы подавляются в целевой. Если ни один из режимов не указан, будут применяться оба режима. [Подробнее о kill-list здесь](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md) +Этот параметр определяет таблицу(ы), к которой будет применяться kill-list. Совпадения в целевой таблице, которые обновляются или удаляются в текущей таблице, будут подавляться. В режиме `:kl` документы для подавления берутся из [kill-list](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md). В режиме `:id` все идентификаторы документов из текущей таблицы подавляются в целевой. Если ни один режим не указан, будут применяться оба режима. [Узнайте больше о kill-list здесь](../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md) ``` -Значение: **не указано** (по умолчанию), target_table_name:kl, target_table_name:id, target_table_name. Допускается несколько значений +Значение: **не указано** (по умолчанию), target_table_name:kl, target_table_name:id, target_table_name. Разрешено использовать несколько значений #### columnar_attrs @@ -623,19 +623,19 @@ columnar_attrs = id, attr1, attr2, attr3 Этот параметр конфигурации определяет, какие атрибуты должны храниться в [колоночном хранилище](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) вместо построчного хранилища. ``` -Вы можете установить `columnar_attrs = *`, чтобы хранить все поддерживаемые типы данных в колоночном хранилище. +Вы можете задать `columnar_attrs = *`, чтобы хранить все поддерживаемые типы данных в колоночном хранилище. -Кроме того, `id` является поддерживаемым атрибутом для хранения в колоночном хранилище. +Кроме того, атрибут `id` поддерживается для хранения в колоночном хранилище. #### columnar_strings_no_hash columnar_strings_no_hash = attr1, attr2, attr3 ```ini -По умолчанию все строковые атрибуты, хранящиеся в колоночном хранилище, сохраняют предварительно вычисленные хэши. Эти хэши используются для группировки и фильтрации. Однако они занимают дополнительное место, и если вам не нужно группировать по этому атрибуту, вы можете сэкономить место, отключив генерацию хэшей. +По умолчанию все строковые атрибуты, хранящиеся в колоночном хранилище, хранят предварительно вычисленные хеши. Эти хеши используются для группировки и фильтрации. Однако они занимают дополнительное пространство, и если вам не нужно группировать по этому атрибуту, вы можете сэкономить место, отключив генерацию хешей. ``` -### Создание таблицы реального времени онлайн через CREATE TABLE +### Создание таблицы в реальном времени через CREATE TABLE ##### Общий синтаксис CREATE TABLE @@ -646,31 +646,31 @@ CREATE TABLE [IF NOT EXISTS] name ( [data type op ##### Типы данных: ``` -Для получения дополнительной информации о типах данных смотрите [подробнее о типах данных здесь](../../Creating_a_table/Data_types.md). +Для получения дополнительной информации о типах данных смотрите [больше о типах данных здесь](../../Creating_a_table/Data_types.md). | Тип | Эквивалент в конфигурационном файле | Примечания | Псевдонимы | | - | - | - | - | -| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | Опции: indexed, stored. По умолчанию: **оба**. Чтобы сохранить текст хранимым, но индексированным, укажите только "stored". Чтобы сохранить текст только индексированным, укажите только "indexed". | string | +| [text](../../Creating_a_table/Data_types.md#Text) | [rt_field](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_field) | Опции: indexed, stored. По умолчанию: **оба**. Чтобы сохранить текст в хранилище, но без индексации, укажите только "stored". Чтобы сохранить только индексируемый текст, укажите только "indexed". | string | | [integer](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | целое число | int, uint | | [bigint](../../Creating_a_table/Data_types.md#Big-Integer) | [rt_attr_bigint](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bigint) | большое целое число | | | [float](../../Creating_a_table/Data_types.md#Float) | [rt_attr_float](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float) | число с плавающей точкой | | | [float_vector](../../Creating_a_table/Data_types.md#Float-vector) | [rt_attr_float_vector](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_float_vector) | вектор чисел с плавающей точкой | | -| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | мульти-целое число | | -| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | мульти-большое целое число | | +| [multi](../../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29) | [rt_attr_multi](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi) | множество целых чисел | | +| [multi64](../../Creating_a_table/Data_types.md#Multi-value-big-integer) | [rt_attr_multi_64](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_multi_64) | множество больших целых чисел | | | [bool](../../Creating_a_table/Data_types.md#Boolean) | [rt_attr_bool](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_bool) | булево значение | | | [json](../../Creating_a_table/Data_types.md#JSON) | [rt_attr_json](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_json) | JSON | | -| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | строка. Опция `indexed, attribute` сделает значение полнотекстово индексируемым и одновременно фильтруемым, сортируемым и группируемым | | -| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) | [rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | временная метка | | -| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N — максимальное количество бит для хранения | | -##### Примеры создания таблицы реального времени через CREATE TABLE +| [string](../../Creating_a_table/Data_types.md#String) | [rt_attr_string](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_string) | строка. Опция `indexed, attribute` позволит сделать значение полнотекстово индексируемым, а также фильтруемым, сортируемым и группируемым одновременно | | +| [timestamp](../../Creating_a_table/Data_types.md#Timestamps) | [rt_attr_timestamp](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_timestamp) | метка времени | | +| [bit(n)](../../Creating_a_table/Data_types.md#Integer) | [rt_attr_uint field_name:N](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_attr_uint) | N — максимальное количество бит, которое нужно сохранить | | +##### Примеры создания таблицы в реальном времени через CREATE TABLE CREATE TABLE products (title text, price float) morphology='stem_en' ```sql -Это создаёт таблицу "products" с двумя полями: "title" (полнотекстовый) и "price" (число с плавающей точкой), и устанавливает "morphology" в "stem_en". +Это создаёт таблицу "products" с двумя полями: "title" (полнотекстовое) и "price" (float) и устанавливает "morphology" на "stem_en". ``` CREATE TABLE products (title text indexed, description text stored, author text, price float) @@ -678,10 +678,27 @@ CREATE TABLE products (title text indexed, description text stored, author text, ```sql Это создаёт таблицу "products" с тремя полями: ``` -* "title" индексируется, но не хранится. -* "description" хранится, но не индексируется. -* "author" хранится и индексируется одновременно. +* "title" индексируется, но не сохраняется. +* "description" сохраняется, но не индексируется. +* "author" сохраняется и индексируется одновременно. +POST /sql?mode=raw -d "CREATE TABLE products (title text, price float) morphology='stem_en';" + + + +```JSON +Это создаёт таблицу "products" с двумя полями: "title" (полнотекстовое) и "price" (float) и устанавливает "morphology" на "stem_en". +``` + +POST /sql?mode=raw -d "CREATE TABLE products (title text indexed, description text stored, author text, price float);" + +```JSON +Это создаёт таблицу "products" с тремя полями: +``` +* "title" индексируется, но не сохраняется. +* "description" сохраняется, но не индексируется. +* "author" сохраняется и индексируется одновременно. ## Engine + @@ -689,72 +706,72 @@ create table ... engine='columnar'; ```ini create table ... engine='rowwise'; -Параметр engine изменяет стандартное [хранилище атрибутов](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) для всех атрибутов в таблице. Вы также можете указать `engine` [отдельно для каждого атрибута](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages). +Параметр engine изменяет стандартное [хранение атрибутов](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) для всех атрибутов в таблице. Также можно указать `engine` [отдельно для каждого атрибута](../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages). ``` -Для информации о том, как включить колоночное хранилище для простой таблицы, смотрите [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs). +Для информации о том, как включить колоночное хранение для простой таблицы, смотрите [columnar_attrs](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#columnar_attrs) . Значения: -* columnar - Включает колоночное хранилище для всех атрибутов таблицы, кроме [json](../../Creating_a_table/Data_types.md#JSON) -* **rowwise (по умолчанию)** - Не изменяет ничего и использует традиционное построчное хранилище для таблицы. +* columnar — Включает колоночное хранение для всех атрибутов таблицы, кроме [json](../../Creating_a_table/Data_types.md#JSON) +* **rowwise (по умолчанию)** — Ничего не меняет и использует традиционное построчное хранение для таблицы. ## Другие настройки -Следующие настройки применимы как для таблиц реального времени, так и для простых таблиц, независимо от того, указаны ли они в конфигурационном файле или установлены онлайн с помощью команды `CREATE` или `ALTER`. -### Связанные с производительностью +Следующие настройки применимы как к таблицам реального времени, так и к обычным таблицам, вне зависимости от того, указаны ли они в конфигурационном файле или установлены онлайн с помощью команды `CREATE` или `ALTER`. +### Настройки, связанные с производительностью -#### Доступ к файлам таблицы +#### Доступ к файлам таблиц -Manticore поддерживает два режима доступа для чтения данных таблицы: seek+read и mmap. -В режиме seek+read сервер использует системный вызов `pread` для чтения списков документов и позиций ключевых слов, представленных файлами `*.spd` и `*.spp`. Сервер использует внутренние буферы чтения для оптимизации процесса чтения, и размер этих буферов можно настроить с помощью опций [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits). Также существует опция [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen), которая контролирует, как Manticore открывает файлы при запуске. +Manticore поддерживает два режима доступа для чтения данных таблиц: seek+read и mmap. +В режиме seek+read сервер использует системный вызов `pread` для чтения списков документов и позиций ключевых слов, которые представлены файлами `*.spd` и `*.spp`. Сервер использует внутренние буферы чтения для оптимизации процесса чтения, и размер этих буферов можно регулировать с помощью опций [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits). Также существует опция [preopen](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#preopen), которая управляет тем, как Manticore открывает файлы при старте. -В режиме доступа mmap поисковый сервер отображает файл таблицы в память с помощью системного вызова `mmap`, а ОС кэширует содержимое файла. Опции [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) не влияют на соответствующие файлы в этом режиме. mmap-ридер также может заблокировать данные таблицы в памяти с помощью привилегированного вызова `mlock`, что предотвращает выгрузку кэшированных данных на диск ОС. +В режиме mmap сервер поиска отображает файл таблицы в память с помощью системного вызова `mmap`, а ОС кэширует содержимое файла. Опции [read_buffer_docs](../../Server_settings/Searchd.md#read_buffer_docs) и [read_buffer_hits](../../Server_settings/Searchd.md#read_buffer_hits) не влияют на соответствующие файлы в этом режиме. mmap-читалка также может заблокировать данные таблицы в памяти с помощью привилегированного вызова `mlock`, что предотвращает выгрузку кэшированных данных на диск. Для управления используемым режимом доступа доступны опции **access_plain_attrs**, **access_blob_attrs**, **access_doclists**, **access_hitlists** и **access_dict** со следующими значениями: | Значение | Описание | | - | - | -| file | сервер читает файлы таблицы с диска с помощью seek+read, используя внутренние буферы при доступе к файлу | -| mmap | сервер отображает файлы таблицы в память, и ОС кэширует их содержимое при доступе к файлу | -| mmap_preread | сервер отображает файлы таблицы в память, и фоновый поток один раз читает их для прогрева кэша | -| mlock | сервер отображает файлы таблицы в память, а затем выполняет системный вызов mlock() для кэширования содержимого файла и блокировки его в памяти, чтобы предотвратить выгрузку | +| file | сервер читает файлы таблиц с диска с помощью seek+read, используя внутренние буферы при доступе к файлу | +| mmap | сервер отображает файлы таблиц в память, а ОС кэширует их содержимое при доступе к файлу | +| mmap_preread | сервер отображает файлы таблиц в память, а фоновый поток один раз читает их для прогрева кэша | +| mlock | сервер отображает файлы таблиц в память и затем выполняет системный вызов mlock() для кэширования содержимого файла и блокировки его в памяти, чтобы избежать выгрузки | | Настройка | Значения | Описание | | - | - | - | -| access_plain_attrs | mmap, **mmap_preread** (по умолчанию), mlock | контролирует, как будут читаться `*.spa` (простые атрибуты), `*.spe` (skip lists), `*.spt` (lookups), `*.spm` (killed docs) | -| access_blob_attrs | mmap, **mmap_preread** (по умолчанию), mlock | контролирует, как будут читаться `*.spb` (blob-атрибуты) (строковые, MVA и JSON атрибуты) | -| access_doclists | **file** (по умолчанию), mmap, mlock | контролирует, как будут читаться данные `*.spd` (списки документов) | -| access_hitlists | **file** (по умолчанию), mmap, mlock | контролирует, как будут читаться данные `*.spp` (списки попаданий) | -| access_dict | mmap, **mmap_preread** (по умолчанию), mlock | контролирует, как будет читаться `*.spi` (словарь) | -Ниже приведена таблица, которая поможет выбрать желаемый режим: +| access_plain_attrs | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будут читаться файлы `*.spa` (простые атрибуты), `*.spe` (списки пропусков), `*.spt` (поисковые обращения), `*.spm` (удалённые документы) | +| access_blob_attrs | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будут читаться файлы `*.spb` (blob-атрибуты) (строковые, мульти-значения и json атрибуты) | +| access_doclists | **file** (по умолчанию), mmap, mlock | управляет тем, как будут читаться данные `*.spd` (списки документов) | +| access_hitlists | **file** (по умолчанию), mmap, mlock | управляет тем, как будут читаться данные `*.spp` (списки попаданий) | +| access_dict | mmap, **mmap_preread** (по умолчанию), mlock | управляет тем, как будет читаться файл `*.spi` (словарь) | +Ниже представлена таблица, которая поможет вам выбрать желаемый режим: -| часть таблицы | оставлять на диске | хранить в памяти | кэшировать в памяти при запуске сервера | блокировать в памяти | +| часть таблицы | хранить на диске | хранить в памяти | кэшировать в памяти при старте сервера | блокировать в памяти | | - | - | - | - | - | -| простые атрибуты в [построчном](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) (не колоночном) хранении, skip lists, списки слов, lookups, killed docs | mmap | mmap | **mmap_preread** (по умолчанию) | mlock | -| построчные строковые, мультизначные атрибуты (MVA) и JSON атрибуты | mmap | mmap | **mmap_preread** (по умолчанию) | mlock | -| [колоночные](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) числовые, строковые и мультизначные атрибуты | всегда | только средствами ОС | нет | не поддерживается | +| простые атрибуты в [построчном](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) (неколоночном) хранении, списки пропусков, словари, поисковые обращения, удалённые документы | mmap | mmap | **mmap_preread** (по умолчанию) | mlock | +| построчные строковые, мульти-значимые атрибуты (MVA) и json атрибуты | mmap | mmap | **mmap_preread** (по умолчанию) | mlock | +| [колоночные](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages) числовые, строковые и мульти-значимые атрибуты | всегда | только средствами ОС | нет | не поддерживается | | списки документов | **file** (по умолчанию) | mmap | нет | mlock | | списки попаданий | **file** (по умолчанию) | mmap | нет | mlock | | словарь | mmap | mmap | **mmap_preread** (по умолчанию) | mlock | ##### Рекомендации: -* Для **максимально быстрого времени отклика поиска** и достаточного объема памяти используйте [построчные](../../Creating_a_table/Data_types.md#JSON) атрибуты и блокируйте их в памяти с помощью `mlock`. Дополнительно используйте mlock для doclists/hitlists. +* Для **максимально быстрого отклика поиска** при достаточном объёме памяти используйте [построчные](../../Creating_a_table/Data_types.md#JSON) атрибуты и блокируйте их в памяти с помощью `mlock`. Также применяйте mlock для списков документов и списков попаданий. -* Если вы отдаёте предпочтение тому, что **нельзя допустить снижение производительности после запуска** и готовы принять более длительное время запуска, используйте опцию [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options). Если вы хотите более быстрый перезапуск searchd, придерживайтесь опции по умолчанию `mmap_preread`. -* Если вы хотите **экономить память**, при этом имея достаточно памяти для всех атрибутов, избегайте использования `mlock`. Операционная система сама определит, что следует держать в памяти, исходя из частоты чтения с диска. +* Если для вас важен **обеспеченный старт с максимальной производительностью** и вы готовы пожертвовать временем запуска, используйте параметр [--force-preread](../../Starting_the_server/Manually.md#searchd-command-line-options). Если хотите более быстрый перезапуск searchd, придерживайтесь опции по умолчанию `mmap_preread`. +* Если вы стремитесь **экономить память**, но при этом достаточно памяти для всех атрибутов, пропустите использование `mlock`. Операционная система сама определит, что должно оставаться в памяти, исходя из частоты чтения с диска. * Если построчные атрибуты **не помещаются в память**, выберите [колоночные атрибуты](../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages). -* Если производительность полнотекстового поиска **не является приоритетом**, и вы хотите сэкономить память, используйте `access_doclists/access_hitlists=file`. -Режим по умолчанию предлагает баланс: +* Если производительность полнотекстового поиска **не критична**, и вы хотите экономить память, используйте `access_doclists/access_hitlists=file`. +Режим по умолчанию обеспечивает баланс между: * mmap, -* предварительное чтение неколоночных атрибутов, -* seek+read колоночных атрибутов без предварительного чтения, -* seek+read doclists/hitlists без предварительного чтения. -Это обеспечивает достойную производительность поиска, оптимальное использование памяти и более быстрый перезапуск searchd в большинстве сценариев. +* предварительным чтением неколоночных атрибутов, +* чтением и поиском построчных атрибутов без предварительного чтения, +* чтением списков документов и списков попаданий без предварительного чтения. +Это обеспечивает достойную производительность поиска, оптимальное использование памяти и более быстрый перезапуск searchd в большинстве случаев. ### Другие настройки, связанные с производительностью @@ -763,7 +780,7 @@ Manticore поддерживает два режима доступа для ч attr_update_reserve = 256k ```ini -Эта настройка резервирует дополнительное пространство для обновлений blob-атрибутов, таких как мультизначные атрибуты (MVA), строки и JSON. Значение по умолчанию — 128k. При обновлении этих атрибутов их длина может изменяться. Если обновленная строка короче предыдущей, она перезапишет старые данные в файле `*.spb`. Если обновленная строка длиннее, она будет записана в конец файла `*.spb`. Этот файл отображается в память, что делает изменение его размера потенциально медленным процессом, в зависимости от реализации отображения файлов в память в операционной системе. Чтобы избежать частого изменения размера, можно использовать эту настройку для резервирования дополнительного пространства в конце файла .spb. +Эта настройка резервирует дополнительное пространство для обновлений blob-атрибутов, таких как мульти-значимые атрибуты (MVA), строки и JSON. Значение по умолчанию — 128k. При обновлении этих атрибутов их длина может изменяться. Если обновлённая строка короче предыдущей, она перезапишет старые данные в файле `*.spb`. Если обновлённая строка длиннее, она будет записана в конец файла `*.spb`. Этот файл отображается в память, что делает изменение размера потенциально медленным процессом в зависимости от реализации памяти отображаемых файлов операционной системой. Чтобы избежать частого изменения размера файла, можно использовать эту настройку для резервирования дополнительного пространства в конце файла .spb. ``` Значение: размер, по умолчанию **128k**. @@ -773,62 +790,62 @@ attr_update_reserve = 256k docstore_block_size = 32k ```ini -This setting controls the size of blocks used by the document storage. The default value is 16kb. When original document text is stored using stored_fields or stored_only_fields, it is stored within the table and compressed for efficiency. To optimize disk access and compression ratios for small documents, these documents are concatenated into blocks. The indexing process collects documents until their total size reaches the threshold specified by this option. At that point, the block of documents is compressed. This option can be adjusted to achieve better compression ratios (by increasing the block size) or faster access to document text (by decreasing the block size). +Этот параметр контролирует размер блоков, используемых хранилищем документов. Значение по умолчанию — 16 Кб. Когда текст оригинального документа сохраняется с использованием stored_fields или stored_only_fields, он хранится внутри таблицы и сжимается для повышения эффективности. Для оптимизации доступа к диску и коэффициентов сжатия для малых документов эти документы конкатенируются в блоки. Процесс индексации собирает документы, пока их общий размер не достигнет порога, указанного этим параметром. В этот момент блок документов сжимается. Этот параметр можно настроить для достижения лучшего коэффициента сжатия (увеличением размера блока) или более быстрого доступа к тексту документа (уменьшением размера блока). ``` -Value: size, default **16k**. +Значение: size, по умолчанию **16k**. #### docstore_compression docstore_compression = lz4hc ```ini -This setting determines the type of compression used for compressing blocks of documents stored in document storage. If stored_fields or stored_only_fields are specified, the document storage stores compressed document blocks. 'lz4' offers fast compression and decompression speeds, while 'lz4hc' (high compression) sacrifices some compression speed for a better compression ratio. 'none' disables compression completely. +Этот параметр определяет тип сжатия, используемый для сжатия блоков документов, хранящихся в документном хранилище. Если указаны stored_fields или stored_only_fields, хранилище документов сохраняет сжатые блоки документов. 'lz4' предлагает высокую скорость сжатия и распаковки, тогда как 'lz4hc' (высокое сжатие) жертвует некоторой скоростью сжатия ради лучшего коэффициента сжатия. 'none' полностью отключает сжатие. ``` -Values: **lz4** (default), lz4hc, none. +Значения: **lz4** (по умолчанию), lz4hc, none. #### docstore_compression_level docstore_compression_level = 12 ```ini -The compression level used when 'lz4hc' compression is applied in document storage. By adjusting the compression level, you can find the right balance between performance and compression ratio when using 'lz4hc' compression. Note that this option is not applicable when using 'lz4' compression. +Уровень сжатия, используемый при применении сжатия 'lz4hc' в документном хранилище. Настройка уровня сжатия позволяет подобрать оптимальный баланс между производительностью и коэффициентом сжатия при использовании сжатия 'lz4hc'. Обратите внимание, что этот параметр не применяется при использовании сжатия 'lz4'. ``` -Value: An integer between 1 and 12, with a default of **9**. +Значение: целое число от 1 до 12, по умолчанию **9**. #### preopen preopen = 1 ```ini -This setting indicates that searchd should open all table files on startup or rotation, and keep them open while running. By default, the files are not pre-opened. Pre-opened tables require a few file descriptors per table, but they eliminate the need for per-query open() calls and are immune to race conditions that might occur during table rotation under high load. However, if you are serving many tables, it may still be more efficient to open them on a per-query basis in order to conserve file descriptors. +Этот параметр указывает, что searchd должен открыть все файлы таблиц при запуске или ротации и удерживать их открытыми во время работы. По умолчанию файлы не открываются заранее. Предварительно открытые таблицы требуют нескольких дескрипторов файлов на таблицу, но устраняют необходимость вызовов open() для каждого запроса и защищены от условий гонки, которые могут возникнуть при ротации таблиц под высокой нагрузкой. Однако, если обслуживается много таблиц, может быть эффективнее открывать их по запросу, чтобы экономить дескрипторы файлов. ``` -Value: **0** (default), or 1. +Значение: **0** (по умолчанию) или 1. #### read_buffer_docs read_buffer_docs = 1M ```ini -Buffer size for storing the list of documents per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time. +Размер буфера для хранения списка документов для каждого ключевого слова. Увеличение этого значения приведет к большему использованию памяти во время выполнения запроса, но может уменьшить время ввода-вывода. ``` -Value: size, default **256k**, minimum value is 8k. +Значение: size, по умолчанию **256k**, минимальное значение 8k. #### read_buffer_hits read_buffer_hits = 1M ```ini -Buffer size for storing the list of hits per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time. +Размер буфера для хранения списка попаданий для каждого ключевого слова. Увеличение этого значения приведет к большему использованию памяти во время выполнения запроса, но может уменьшить время ввода-вывода. ``` -Value: size, default **256k**, minimum value is 8k. +Значение: size, по умолчанию **256k**, минимальное значение 8k. -### Plain table disk footprint settings +### Настройки отслеживания размера плоской таблицы на диске #### inplace_enable @@ -837,14 +854,14 @@ inplace_enable = {0|1} ```ini -Enables in-place table inversion. Optional, default is 0 (uses separate temporary files). +Включает инверсию таблицы на месте. Опционально, по умолчанию 0 (используются отдельные временные файлы). ``` -The `inplace_enable` option reduces the disk footprint during indexing of plain tables, while slightly slowing down indexing (it uses approximately 2 times less disk, but yields around 90-95% of the original performance). +Опция `inplace_enable` уменьшает размер дискового пространства, занятого при индексации плоских таблиц, слегка замедляя индексацию (использует примерно в 2 раза меньше диска, но показывает около 90–95% от исходной производительности). -Indexing is comprised of two primary phases. During the first phase, documents are collected, processed, and partially sorted by keyword, and the intermediate results are written to temporary files (.tmp*). During the second phase, the documents are fully sorted and the final table files are created. Rebuilding a production table on-the-fly requires approximately 3 times the peak disk footprint: first for the intermediate temporary files, second for the newly constructed copy, and third for the old table that will be serving production queries in the meantime. (Intermediate data is comparable in size to the final table.) This may be too much disk footprint for large data collections, and the `inplace_enable` option can be used to reduce it. When enabled, it reuses the temporary files, outputs the final data back to them, and renames them upon completion. However, this may require additional temporary data chunk relocation, which is where the performance impact comes from. +Индексация состоит из двух основных фаз. На первой фазе документы собираются, обрабатываются и частично сортируются по ключевому слову, а промежуточные результаты записываются во временные файлы (.tmp*). Во второй фазе документы полностью сортируются и создаются конечные файлы таблицы. Перестройка рабочей таблицы в реальном времени требует примерно в 3 раза больше пикового объема дискового пространства: сначала для промежуточных временных файлов, затем для вновь созданной копии, и ещё для старой таблицы, которая в это время обрабатывает производственные запросы. (Промежуточные данные сравнимы по размеру с конечной таблицей.) Это может быть слишком большой расход дискового пространства для больших коллекций данных, и опция `inplace_enable` может использоваться для его сокращения. При включении она переиспользует временные файлы, выводит в них конечные данные и переименовывает их по завершении. Однако это может потребовать дополнительной релокации блоков временных данных, что и объясняет снижение производительности. -This directive has no effect on [searchd](../../Starting_the_server/Manually.md), it only affects the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). +Эта директива не влияет на [searchd](../../Starting_the_server/Manually.md), она применяется только к инструменту [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). ##### CONFIG: @@ -869,10 +886,10 @@ inplace_hit_gap = size ```ini -The option [In-place inversion](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable) fine-tuning option. Controls preallocated hitlist gap size. Optional, default is 0. +Опция тонкой настройки [инверсии на месте](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable). Управляет размером заранее выделенного пространства для пропусков в списках попаданий. Опционально, по умолчанию 0. ``` -This directive only affects the [searchd](../../Starting_the_server/Manually.md) tool, and does not have any impact on the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). +Эта директива влияет только на инструмент [searchd](../../Starting_the_server/Manually.md) и не оказывает воздействия на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). ##### CONFIG: @@ -897,10 +914,10 @@ inplace_reloc_factor = 0.1 ```ini -The inplace_reloc_factor setting determines the size of the relocation buffer within the memory arena used during indexing. The default value is 0.1. +Параметр inplace_reloc_factor определяет размер буфера для релокации внутри арены памяти, используемой во время индексации. Значение по умолчанию — 0.1. ``` -This option is optional and only affects the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) tool, not the [searchd](../../Starting_the_server/Manually.md) server. +Эта опция опциональна и влияет только на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool), а не на сервер [searchd](../../Starting_the_server/Manually.md). ##### CONFIG: @@ -925,10 +942,10 @@ inplace_write_factor = 0.1 ```ini -Controls the size of the buffer used for in-place writing during indexing. Optional, with a default value of 0.1. +Контролирует размер буфера, используемого для записи на месте во время индексации. Опционально, значение по умолчанию 0.1. ``` -It's important to note that this directive only impacts the [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) tool and not the [searchd](../../Starting_the_server/Manually.md) server. +Важно отметить, что эта директива влияет только на инструмент [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool) и не затрагивает сервер [searchd](../../Starting_the_server/Manually.md). ##### CONFIG: diff --git a/manual/russian/Creating_a_table/Local_tables/Real-time_table.md b/manual/russian/Creating_a_table/Local_tables/Real-time_table.md index d625ce6be2..a6d42ab13d 100644 --- a/manual/russian/Creating_a_table/Local_tables/Real-time_table.md +++ b/manual/russian/Creating_a_table/Local_tables/Real-time_table.md @@ -1,17 +1,17 @@ # Таблица в реальном времени -**Таблица в реальном времени** — это основной тип таблицы в Manticore. Она позволяет добавлять, обновлять и удалять документы, и вы можете видеть эти изменения сразу же. Вы можете настроить таблицу в реальном времени в конфигурационном файле или использовать команды, такие как `CREATE`, `UPDATE`, `DELETE` или `ALTER`. +**Таблица в реальном времени** — это основной тип таблицы в Manticore. Она позволяет добавлять, обновлять и удалять документы, при этом вы сразу же видите эти изменения. Вы можете настроить таблицу в реальном времени в конфигурационном файле или использовать команды вроде `CREATE`, `UPDATE`, `DELETE` или `ALTER`. -Внутри таблица в реальном времени состоит из одной или нескольких [простых таблиц](../../Creating_a_table/Local_tables/Plain_table.md), называемых **чанками**. Существуют два типа чанков: +Внутри таблица в реальном времени состоит из одного или нескольких [plain tables](../../Creating_a_table/Local_tables/Plain_table.md), называемых **чанками**. Существуют два типа чанков: -* несколько **дисковых чанков** — они сохраняются на диске и структурированы как [простая таблица](../../Creating_a_table/Local_tables/Plain_table.md). +* несколько **дисковых чанков** — они сохраняются на диске и имеют структуру, похожую на [plain table](../../Creating_a_table/Local_tables/Plain_table.md). * один **RAM-чанк** — хранится в памяти и собирает все изменения. -Размер RAM-чанка контролируется настройкой [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit). Как только этот лимит достигается, RAM-чанк переносится на диск как дисковый чанк. Если дисковых чанков становится слишком много, Manticore [объединяет некоторые из них](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) для улучшения производительности. +Размер RAM-чанка контролируется настройкой [rt_mem_limit](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#rt_mem_limit). Когда этот лимит достигается, RAM-чанк переносится на диск как дисковый чанк. Если дисковых чанков становится слишком много, Manticore [объединяет часть из них](../../Securing_and_compacting_a_table/Compacting_a_table.md#Number-of-optimized-disk-chunks) для повышения производительности. ### Создание таблицы в реальном времени: -Вы можете создать новую таблицу в реальном времени двумя способами: с помощью команды `CREATE TABLE` или через [_mapping endpoint](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:) HTTP JSON API. +Вы можете создать новую таблицу в реальном времени двумя способами: используя команду `CREATE TABLE` или через [_mapping endpoint](../../Creating_a_table/Local_tables/Real-time_table.md#_mapping-API:) HTTP JSON API. #### Команда CREATE TABLE: @@ -33,7 +33,7 @@ Query OK, 0 rows affected (0.00 sec) ``` -##### Создание таблицы в реальном времени через JSON по HTTP: +##### Создание таблицы в реальном времени через JSON поверх HTTP: ```JSON @@ -142,13 +142,13 @@ table products { #### _mapping API: -> ПРИМЕЧАНИЕ: API `_mapping` требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если он не работает, убедитесь, что Buddy установлен. +> ПРИМЕЧАНИЕ: API `_mapping` требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. В качестве альтернативы вы можете создать новую таблицу через endpoint `_mapping`. Этот endpoint позволяет определить структуру таблицы, похожую на Elasticsearch, которая будет преобразована в таблицу Manticore. -Тело вашего запроса должно иметь следующую структуру: +Тело запроса должно иметь следующую структуру: ```json "properties" @@ -243,13 +243,13 @@ POST /your_table_name/_mapping -d ' -Вы можете создать копию таблицы в реальном времени, с данными или без них. Обратите внимание, что если таблица большая, копирование с данными может занять некоторое время. Копирование работает в синхронном режиме, но если соединение прервется, оно продолжится в фоновом режиме. +Вы можете создать копию таблицы в реальном времени с данными или без них. Обратите внимание, что если таблица большая, копирование с данными может занять некоторое время. Копирование работает в синхронном режиме, но если соединение прервано, процесс продолжится в фоне. ```sql CREATE TABLE [IF NOT EXISTS] table_name LIKE old_table_name [WITH DATA] ``` -> ПРИМЕЧАНИЕ: Копирование таблицы требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если оно не работает, убедитесь, что Buddy установлен. +> ПРИМЕЧАНИЕ: Копирование таблицы требует [Manticore Buddy](Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. ##### Пример: @@ -266,33 +266,46 @@ create table products LIKE old_products; create table products LIKE old_products WITH DATA; ``` + + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products;" +``` + + +##### Пример JSON (С ДАННЫМИ): + +```JSON +POST /sql?mode=raw -d "create table products LIKE old_products WITH DATA;" +``` + -### 👍 Что вы можете делать с таблицей в реальном времени: +### 👍 Что можно делать с таблицей в реальном времени: * [Добавлять документы](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md). -* Обновлять атрибуты и полнотекстовые поля с помощью процесса [Update](../../Quick_start_guide.md#Update). +* Обновлять атрибуты и полнотекстовые поля через процесс [Update](../../Quick_start_guide.md#Update). * [Удалять документы](../../Quick_start_guide.md#Delete). * [Очищать таблицу](../../Emptying_a_table.md). -* Изменять схему онлайн с помощью команды `ALTER`, как описано в разделе [Изменение схемы онлайн](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode). -* Определять таблицу в конфигурационном файле, как подробно описано в разделе [Определение таблицы](../../Creating_a_table/Local_tables/Real-time_table.md). -* Использовать функцию [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) для автоматического присвоения ID. +* Менять схему онлайн с помощью команды `ALTER`, как описано в [Изменении схемы онлайн](../../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode). +* Определять таблицу в конфигурационном файле, подробно описано в [Определение таблицы](../../Creating_a_table/Local_tables/Real-time_table.md). +* Использовать функцию [UUID](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID) для автоматической генерации ID. -### ⛔ Что вы не можете делать с таблицей в реальном времени: -* Загружать данные с помощью функции [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). -* Подключать её к [источникам](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) для удобного индексирования из внешнего хранилища. +### ⛔ Что нельзя делать с таблицей в реальном времени: +* Загружать данные с помощью [indexer](../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md#Indexer-tool). +* Подключите его к [источникам](../../Data_creation_and_modification/Adding_data_from_external_storages/Fetching_from_databases/Execution_of_fetch_queries.md) для удобного индексирования из внешнего хранилища. * Обновите [killlist_target](../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#killlist_target), так как он автоматически управляется таблицей реального времени. #### Структура файлов таблицы реального времени -В следующей таблице приведены различные расширения файлов и их описания в таблице реального времени: +В следующей таблице приведены различные расширения файлов и их описание в таблице реального времени: | Extension | Description | | - | - | -| `.lock` | Файл блокировки, который гарантирует, что только один процесс может получить доступ к таблице одновременно. | +| `.lock` | Файл блокировки, который гарантирует, что к таблице одновременно может получить доступ только один процесс. | | `.ram` | RAM-чанк таблицы, хранящийся в памяти и используемый как аккумулятор изменений. | -| `.meta` | Заголовки таблицы реального времени, определяющие её структуру и настройки. | -| `.*.sp*` | Дисковые чанки, которые хранятся на диске в том же формате, что и обычные таблицы. Они создаются, когда размер RAM-чанка превышает rt_mem_limit.| +| `.meta` | Заголовки таблицы реального времени, которые определяют её структуру и настройки. | +| `.*.sp*` | Дисковые чанки, которые хранятся на диске в том же формате, что и простые таблицы. Они создаются, когда размер RAM чанка превышает rt_mem_limit.| - Для получения дополнительной информации о структуре дисковых чанков обратитесь к [структуре файлов обычной таблицы](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure). + Для получения дополнительной информации о структуре дисковых чанков обратитесь к [структуре файлов простой таблицы](../../Creating_a_table/Local_tables/Plain_table.md#Plain-table-files-structure). diff --git a/manual/russian/Creating_a_table/NLP_and_tokenization/Wordforms.md b/manual/russian/Creating_a_table/NLP_and_tokenization/Wordforms.md index 38addd7e83..cfe946760c 100644 --- a/manual/russian/Creating_a_table/NLP_and_tokenization/Wordforms.md +++ b/manual/russian/Creating_a_table/NLP_and_tokenization/Wordforms.md @@ -1,6 +1,6 @@ # Формы слов -Формы слов применяются после токенизации входящего текста по правилам [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table). Они по сути позволяют заменить одно слово другим. Обычно это используется для приведения различных форм слова к одной нормальной форме (например, нормализация всех вариантов таких как "walks", "walked", "walking" к нормальной форме "walk"). Также это может использоваться для реализации исключений [стемминга](../../Creating_a_table/NLP_and_tokenization/Morphology.md), поскольку стемминг не применяется к словам, найденным в списке форм. +Формы слов применяются после разбиения входящего текста на токены по правилам [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table). Они по сути позволяют заменить одно слово другим. Обычно это используется для приведения разных форм слова к единой нормальной форме (например, для нормализации всех вариантов таких как "walks", "walked", "walking" к нормальной форме "walk"). Также это может использоваться для реализации исключений при [стемминге](../../Creating_a_table/NLP_and_tokenization/Morphology.md), поскольку стемминг не применяется к словам, найденным в списке форм. ## wordforms @@ -13,7 +13,7 @@ wordforms = path/to/dict*.txt Словарь форм слов. Опционально, по умолчанию пустой. -Словари форм слов используются для нормализации входящих слов как при индексации, так и при поиске. Поэтому, когда речь идет о [plain table](../../Creating_a_table/Local_tables/Plain_table.md), требуется выполнить ротацию таблицы, чтобы применить изменения в файле форм слов. +Словари форм слов используются для нормализации входящих слов как при индексации, так и при поиске. Поэтому, когда речь идет о [plain table](../../Creating_a_table/Local_tables/Plain_table.md), требуется ротация таблицы, чтобы применились изменения в файле форм слов. ##### SQL: @@ -98,7 +98,7 @@ utils_api.sql("CREATE TABLE products(title text, price float) wordforms = '/var/ ``` -##### Пример в Plain режиме: +##### Пример в режиме Plain: @@ -116,10 +116,10 @@ table products { ``` -Поддержка форм слов в Manticore разработана для эффективной работы с большими словарями. Они умеренно влияют на скорость индексации; например, словарь с 1 миллионом записей замедляет полнотекстовую индексацию примерно в 1.5 раза. Скорость поиска при этом не страдает. Дополнительное потребление RAM примерно равно размеру файла словаря, и словари разделяются между таблицами. Например, если один и тот же файл форм слов размером 50 МБ указан для 10 разных таблиц, дополнительное потребление RAM `searchd` будет около 50 МБ. +Поддержка форм слов в Manticore спроектирована для эффективной работы с большими словарями. Они умеренно влияют на скорость индексации; например, словарь с 1 миллионом записей замедляет полнотекстовую индексацию примерно в 1.5 раза. Скорость поиска при этом не ухудшается. Дополнительное использование RAM примерно равно размеру файла словаря, а словари используются совместно между таблицами. Например, если один и тот же файл форм слов размером 50 МБ задан для 10 разных таблиц, дополнительное потребление оперативной памяти `searchd` составит около 50 МБ. -Файл словаря должен быть в простом текстовом формате. Каждая строка должна содержать исходную и целевую формы слова в кодировке UTF-8, разделённые знаком "больше" (>). Правила из [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) будут применены при загрузке файла. Поэтому, если вы не изменяете `charset_table`, ваши формы слов будут нечувствительны к регистру, как и остальные данные, индексируемые полнотекстово. Ниже приведён пример содержимого файла: +Файл словаря должен быть в простом текстовом формате. Каждая строка должна содержать исходную и конечную форму слова в кодировке UTF-8, разделённые знаком больше (>). Правила из [charset_table](../../Creating_a_table/NLP_and_tokenization/Low-level_tokenization.md#charset_table) применяются при загрузке файла. Следовательно, если вы не изменяете `charset_table`, ваши формы слов будут регистронезависимыми, как и другие полнотекстовые данные. Ниже приведён пример содержимого файла: ```ini @@ -129,12 +129,12 @@ walking > walk ``` -В комплекте есть утилита [Spelldump](../../Miscellaneous_tools.md#spelldump), которая помогает создать файл словаря в формате, читаемом Manticore. Утилита может читать исходные файлы словарей `.dict` и `.aff` в формате `ispell` или `MySpell`, как в комплекте с OpenOffice. +Существует утилита [Spelldump](../../Miscellaneous_tools.md#spelldump), которая помогает создавать файл словаря в формате, читаемом Manticore. Утилита может читать исходные файлы словарей `.dict` и `.aff` в форматах `ispell` или `MySpell`, поставляемые с OpenOffice. -Вы можете сопоставить несколько исходных слов с одним целевым словом. Процесс происходит на уровне токенов, а не исходного текста, поэтому различия в пробелах и разметке игнорируются. +Вы можете отображать несколько исходных слов на одно целевое. Процесс происходит на уровне токенов, а не исходного текста, так что различия в пробелах и разметке игнорируются. -Вы можете использовать символ `=>` вместо `>`. Также допускаются комментарии (начинающиеся с `#`). Наконец, если строка начинается с тильды (`~`), форма слова будет применена после морфологии, а не до (обратите внимание, что в этом случае поддерживается только одно исходное и одно целевое слово). +Вы можете использовать символ `=>` вместо `>`. Также разрешены комментарии (начинающиеся с `#`). Наконец, если строка начинается с тильды (`~`), форма слова будет применена после морфологического анализа, а не до него (обратите внимание, что в таком случае поддерживается только одна исходная и одна конечная форма слова). ```ini @@ -146,7 +146,7 @@ core 2duo => c2d # Some people write '2duo' together... -Если вам нужно использовать `>`, `=` или `~` как обычные символы, вы можете экранировать их, предваряя обратным слэшем (`\`). И `>`, и `=` должны быть экранированы таким образом. Вот пример: +Если вам нужно использовать `>`, `=` или `~` как обычные символы, их можно экранировать, поставив перед каждым обратный слеш (`\`). И `>`, и `=` следует экранировать именно так. Вот пример: ```ini @@ -160,7 +160,7 @@ c\=\> => cde -Вы можете указать несколько целевых токенов: +Можно указать несколько целевых токенов: ```ini @@ -170,11 +170,11 @@ s3 e3 > season 3 episode 3 -Вы можете указать несколько файлов, а не только один. Маски могут использоваться как шаблоны, и все подходящие файлы будут обработаны в простом порядке возрастания: +Вы можете указать несколько файлов, а не только один. Маски могут использоваться в качестве шаблона, и все подходящие файлы будут обработаны в простом порядке возрастания: -В режиме RT допускаются только абсолютные пути. +В режиме RT разрешены только абсолютные пути. -Если используются многобайтовые кодировки и имена файлов содержат нелатинские символы, итоговый порядок может быть не совсем алфавитным. Если одно и то же определение формы слова встречается в нескольких файлах, используется последнее, переопределяющее предыдущие. +Если используются многобайтовые кодировки и в именах файлов есть нелатинские символы, итоговый порядок может быть не совсем алфавитным. Если одно и то же определение формы слова встречается в нескольких файлах, используется последнее, переопределяющее предыдущие. ```sql @@ -182,6 +182,12 @@ create table tbl1 ... wordforms='/tmp/wf*' create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2' ``` + +```JSON +POST /sql?mode=raw -d "create table tbl1 ... wordforms='/tmp/wf*'" +POST /sql?mode=raw -d "create table tbl2 ... wordforms='/tmp/wf, /tmp/wf2'" +``` + ```ini wordforms=/tmp/wf diff --git a/manual/russian/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md b/manual/russian/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md index 3e18c856ef..0d1042d483 100644 --- a/manual/russian/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md +++ b/manual/russian/Data_creation_and_modification/Adding_documents_to_a_table/Adding_rules_to_a_percolate_table.md @@ -1,18 +1,18 @@ -# Добавление правил в таблицу перколяции +# Добавление правил в таблицу percolate -В [таблице перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) хранятся документы, которые являются правилами запроса перколяции и должны строго соответствовать схеме из четырёх полей: +В [таблице percolate](../../Creating_a_table/Local_tables/Percolate_table.md) хранятся документы с правилами перколяции, и они должны строго соответствовать схеме из четырёх полей: | поле | тип | описание | | - | - | - | -| id | bigint | идентификатор правила PQ (если не указан, будет назначен автоматически) | -| query | string | полнотекстовый запрос (может быть пустым), совместимый с [таблицей перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) | -| filters | string | дополнительные фильтры по полям, не являющимся полнотекстовыми (может быть пустым), совместимые с [таблицей перколяции](../../Creating_a_table/Local_tables/Percolate_table.md) | -| tags | string | строка с одним или несколькими тегами, разделёнными запятыми, которые могут использоваться для выборочного отображения/удаления сохранённых запросов | +| id | bigint | Идентификатор правила PQ (если не указан, будет назначен автоматически) | +| query | string | Полнотекстовый запрос (может быть пустым), совместимый с [таблицей percolate](../../Creating_a_table/Local_tables/Percolate_table.md) | +| filters | string | Дополнительные фильтры по не полнотекстовым полям (может быть пустым), совместимый с [таблицей percolate](../../Creating_a_table/Local_tables/Percolate_table.md) | +| tags | string | Строка с одним или несколькими тегами, разделёнными запятыми, которые могут использоваться для выборочного отображения/удаления сохранённых запросов | Любые другие имена полей не поддерживаются и вызовут ошибку. -**Внимание:** Вставка/замена правил PQ в формате JSON через SQL не сработает. Другими словами, операторы, специфичные для JSON (`match` и т.п.), будут рассматриваться просто как части текста правила, которые должны совпадать с документами. Если вы предпочитаете синтаксис JSON, используйте HTTP-эндпоинт вместо `INSERT`/`REPLACE`. +**Внимание:** Вставка/замена правил PQ в формате JSON через SQL не сработает. Другими словами, специализированные операторы JSON (`match` и др.) будут рассматриваться просто как части текста правила, с которыми должны совпадать документы. Если вы предпочитаете синтаксис JSON, используйте HTTP-эндпоинт вместо `INSERT`/`REPLACE`. ##### SQL @@ -36,7 +36,7 @@ SELECT * FROM pq; ##### JSON -Существует два способа добавить запрос перколяции в таблицу перколяции: +Существует два способа добавить запрос percolate в таблицу percolate: * Запрос в формате JSON, совместимом с /search, описанном в [json/search](../../Searching/Full_text_matching/Basic_usage.md#HTTP-JSON) ```json PUT /pq/pq_table/doc/1 @@ -55,7 +55,7 @@ PUT /pq/pq_table/doc/1 } ``` -* Запрос в формате SQL, описанном в [синтаксисе запросов search](../../Searching/Filters.md#Queries-in-SQL-format) +* Запрос в формате SQL, описанный в [синтаксисе поискового запроса](../../Searching/Filters.md#Queries-in-SQL-format) ```json PUT /pq/pq_table/doc/2 { @@ -161,9 +161,9 @@ let insert_res = index_api.insert(insert_req).await; -## Автоматическое назначение ID +## Автоматическое присвоение ID -Если вы не указываете ID, он будет назначен автоматически. Подробнее об авто-ID можно прочитать [здесь](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID). +Если вы не укажете ID, он будет назначен автоматически. Подробнее об авто-ID можно прочитать [здесь](../../Data_creation_and_modification/Adding_documents_to_a_table/Adding_documents_to_a_real-time_table.md#Auto-ID). ##### SQL: @@ -358,11 +358,11 @@ let insert_res = index_api.insert(insert_req).await; ## Отсутствие схемы в SQL -Если в SQL-команде `INSERT` опустить схему, ожидаются следующие параметры: -1. ID. Можно использовать `0` в качестве ID, чтобы вызвать автоматическую генерацию ID. -2. Query - полнотекстовый запрос. -3. Tags - строка тегов правила PQ. -4. Filters - дополнительные фильтры по атрибутам. +Если схема в SQL-команде `INSERT` опущена, ожидаются следующие параметры: +1. ID. Можно использовать `0` в качестве ID, чтобы инициировать автоматическую генерацию ID. +2. Query — Полнотекстовый запрос. +3. Tags — строка тегов правила PQ. +4. Filters — дополнительные фильтры по атрибутам. @@ -381,12 +381,82 @@ SELECT * FROM pq; | 2810855531667783689 | @title shoes | Louis Vuitton | | +---------------------+--------------+---------------+---------+ ``` + + + +```JSON +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', '', '');" +POST /sql?mode=raw -d "INSERT INTO pq VALUES (0, '@title shoes', 'Louis Vuitton', '');" +POST /sql?mode=raw -d "SELECT * FROM pq;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "Louis Vuitton", + "filters": "" + }, + { + "id": 724024784404348900, + "query": "@title shoes", + "tags": "", + "filters": "" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ## Замена правил в таблице PQ -Чтобы заменить существующее правило PQ новым в SQL, просто используйте обычную команду [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md). Существует специальный синтаксис `?refresh=1` для замены правила PQ **определённого в JSON-режиме** через HTTP JSON интерфейс. +Для замены существующего правила PQ на новое в SQL просто используйте обычную команду [REPLACE](../../Data_creation_and_modification/Updating_documents/REPLACE.md). Существует особый синтаксис `?refresh=1` для замены правила PQ **определённого в JSON-режиме** через HTTP JSON интерфейс. diff --git a/manual/russian/Data_creation_and_modification/Deleting_documents.md b/manual/russian/Data_creation_and_modification/Deleting_documents.md index 812a90fab2..a1f7539c1c 100644 --- a/manual/russian/Data_creation_and_modification/Deleting_documents.md +++ b/manual/russian/Data_creation_and_modification/Deleting_documents.md @@ -1,21 +1,21 @@ # Удаление документов Удаление документов поддерживается только в [RT режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode) для следующих типов таблиц: -* [RT](../Creating_a_table/Local_tables/Real-time_table.md) таблицы -* [Percolate](../Creating_a_table/Local_tables/Percolate_table.md) таблицы -* Распределённые таблицы, которые содержат только RT таблицы в качестве локальных или удалённых агентов. +* [Таблицы Real-time](../Creating_a_table/Local_tables/Real-time_table.md) +* [Таблицы Percolate](../Creating_a_table/Local_tables/Percolate_table.md) +* Распределённые таблицы, содержащие только RT таблицы в качестве локальных или удалённых агентов. -Вы можете удалить существующие документы из таблицы, основываясь либо на их ID, либо на определённых условиях. +Вы можете удалить существующие документы из таблицы на основе их ID или определённых условий. Также доступно [массовое удаление](../Data_creation_and_modification/Deleting_documents.md#Bulk-deletion) для удаления нескольких документов. -Удаление документов можно выполнить как через SQL, так и через JSON интерфейсы. +Удаление документов может быть выполнено как через SQL, так и через интерфейсы JSON. -Для SQL ответ о успешной операции будет содержать количество удалённых строк. +Для SQL ответ для успешной операции будет содержать количество удалённых строк. -Для JSON используется endpoint `json/delete`. Сервер ответит JSON объектом, указывающим, была ли операция успешной и сколько строк удалено. +Для JSON используется endpoint `json/delete`. Сервер ответит JSON-объектом, указывающим, была ли операция успешной, и числом удалённых строк. -Рекомендуется использовать [очистку таблицы](../Emptying_a_table.md) вместо удаления для удаления всех документов из таблицы, так как это гораздо более быстрая операция. +Рекомендуется использовать [очистку таблицы](../Emptying_a_table.md) вместо удаления для удаления всех документов из таблицы, так как это значительно более быстрая операция. @@ -73,7 +73,7 @@ POST /delete -d ' }' ``` -* `query` для JSON содержит условие полнотекстового поиска; синтаксис такой же, как в [JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON). +* `query` для JSON содержит условие полнотекстового поиска; синтаксис совпадает с [JSON/update](../Data_creation_and_modification/Updating_documents/UPDATE.md#Updates-via-HTTP-JSON). @@ -280,7 +280,7 @@ POST /delete -d ' }' ``` -* `id` для JSON — это `id` строки, которую нужно удалить. +* `id` для JSON — это ID строки, которую необходимо удалить. @@ -451,10 +451,10 @@ deleteRequest.SetId(1) -Здесь удаляются документы с `id`, совпадающими со значениями из таблицы с именем `test`: +Здесь удаляются документы с `id`, совпадающим со значениями из таблицы с именем `test`: -Обратите внимание, что формы удаления с `id=N` или `id IN (X,Y)` самые быстрые, так как они удаляют документы без выполнения поиска. -Также обратите внимание, что ответ содержит только id первого удалённого документа в соответствующем поле `_id`. +Обратите внимание, что формы удаления с `id=N` или `id IN (X,Y)` являются самыми быстрыми, так как удаляют документы без выполнения поиска. +Также учтите, что в ответе содержится только id первого удалённого документа в соответствующем поле `_id`. ##### SQL: @@ -516,9 +516,9 @@ Array( -Manticore SQL позволяет использовать сложные условия для оператора `DELETE`. +В Manticore SQL разрешено использовать сложные условия для оператора `DELETE`. -Например, здесь мы удаляем документы, которые соответствуют полнотекстовому запросу `test document` и имеют атрибут `mva1` со значением больше 206 или значения `mva1` равные 100 или 103 из таблицы с именем `test`: +Например, здесь мы удаляем документы, которые соответствуют полнотекстовому запросу `test document` и имеют атрибут `mva1` со значением больше 206 или значения `mva1` равны 100 или 103 из таблицы с именем `test`: @@ -547,10 +547,68 @@ Query OK, 4 rows affected (0.00 sec) +------+------+-------------+------+ 6 rows in set (0.00 sec) ``` + + + +```JSON +POST /sql?mode=raw -d "DELETE FROM TEST WHERE MATCH ('test document') AND ( mva1>206 or mva1 in (100, 103) );" + +POST /sql?mode=raw -d "SELECT * FROM TEST;" +``` + + +```JSON +[ + { + "total": 4, + "error": "", + "warning": "" + } +] + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "mva1": { + "type": "long" + } + }, + { + "mva2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "gid": "1001", + "mva1": 101,102, + "mva2": 101 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -Вот пример удаления документов в таблице `test` кластера `cluster`. Обратите внимание, что необходимо указать свойство кластера вместе со свойством таблицы, чтобы удалить строку из таблицы внутри репликационного кластера: +Пример удаления документов в таблице `test` кластера `cluster`. Обратите внимание, что необходимо указать свойство кластера вместе с таблицей для удаления строки из таблицы внутри репликационного кластера: @@ -571,7 +629,7 @@ POST /delete -d ' "id": 100 }' ``` -* `cluster` для JSON — это имя [репликационного кластера](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster), который содержит нужную таблицу +* `cluster` для JSON — это имя [репликационного кластера](../Creating_a_cluster/Setting_up_replication/Setting_up_replication.md#Replication-cluster), содержащего нужную таблицу ##### PHP: @@ -735,11 +793,11 @@ deleteRequest.SetId(1) -## Массовое удаление +## Bulk deletion -Вы также можете выполнить несколько операций удаления за один вызов, используя конечную точку `/bulk`. Эта конечная точка работает только с данными, у которых `Content-Type` установлен в `application/x-ndjson`. Данные должны быть отформатированы как JSON, разделённый переводами строк (NDJSON). По сути, это означает, что каждая строка должна содержать ровно одно JSON-выражение и заканчиваться переводом строки `\n` и, возможно, `\r`. +You can also perform multiple delete operations in a single call using the `/bulk` endpoint. This endpoint only works with data that has `Content-Type` set to `application/x-ndjson`. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline `\n` and, possibly, a `\r`. diff --git a/manual/russian/Extensions/FEDERATED.md b/manual/russian/Extensions/FEDERATED.md index 4e1518e2a2..30798d193f 100644 --- a/manual/russian/Extensions/FEDERATED.md +++ b/manual/russian/Extensions/FEDERATED.md @@ -4,12 +4,12 @@ ## Использование FEDERATED -Непосредственно запрос Manticore нельзя использовать с движком FEDERATED из-за ограничений FEDERATED и того факта, что Manticore реализует собственный синтаксис, например, оператор [MATCH](../Searching/Full_text_matching/Basic_usage.md). +Непосредственно запрос Manticore нельзя использовать с движком FEDERATED, его нужно "проксиировать" (отправлять в виде строки в столбце) из-за ограничений движка FEDERATED и того, что Manticore использует нестандартный синтаксис, например, оператор [MATCH](../Searching/Full_text_matching/Basic_usage.md). -Для поиска через `FEDERATED` сначала нужно создать таблицу с движком FEDERATED. Запрос Manticore будет включён в столбец `query` в операторе `SELECT`, выполняемом по таблице FEDERATED. +Чтобы выполнять поиск через `FEDERATED`, сначала нужно создать таблицу с движком FEDERATED. Запрос Manticore будет включён в столбец `query` внутри оператора `SELECT`, выполняемого по таблице FEDERATED. -Создание таблицы MySQL, совместимой с FEDERATED: +Создание совместимой с FEDERATED таблицы MySQL: @@ -34,10 +34,24 @@ CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies'; ```sql Query OK, 0 rows affected (0.00 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE t1 (id INTEGER UNSIGNED NOT NULL, year INTEGER NOT NULL, rating FLOAT, query VARCHAR(1024) NOT NULL, INDEX(query)) ENGINE=FEDERATED DEFAULT CHARSET=utf8 CONNECTION='mysql://FEDERATED@127.0.0.1:9306/DB/movies';" +``` + + +```JSON +``` + -Запрос к таблице, совместимой с FEDERATED: +Запрос к таблице совместимой с FEDERATED: @@ -61,35 +75,35 @@ SELECT * FROM t1 WHERE query='SELECT * FROM movies WHERE MATCH (\'pie\')'; ``` -Единственное фиксированное сопоставление — это столбец `query`. Он обязателен и должен быть единственным столбцом, связанным с таблицей. +Единственное жёсткое сопоставление – это столбец `query`. Он обязателен и должен быть единственным столбцом, к которому привязана таблица. -Таблица Manticore, связанная через `FEDERATED`, **должна** быть физической таблицей (обычной или реального времени). +Таблица Manticore, связанная через `FEDERATED`, **должна** быть физической таблицей (обычной или в режиме реального времени). -Таблица FEDERATED должна иметь столбцы с такими же именами, как атрибуты удалённой таблицы Manticore, поскольку они будут связаны с атрибутами, предоставленными в наборе результатов Manticore по имени. Однако может быть сопоставлена только часть атрибутов, а не все. +Таблица FEDERATED должна содержать столбцы с такими же именами, как атрибуты удалённой таблицы Manticore, так как они будут связаны с атрибутами из результата Manticore по именам. Однако может быть сопоставлена не вся таблица, а лишь некоторые атрибуты. -Сервер Manticore идентифицирует запрос от клиента FEDERATED по имени пользователя "FEDERATED". Параметр строки `CONNECTION` используется для указания хоста Manticore, SQL-порта и таблиц для запросов, поступающих через соединение. Синтаксис строки соединения следующий: +Сервер Manticore идентифицирует запросы от клиента FEDERATED по имени пользователя "FEDERATED". Параметр строки `CONNECTION` используется для указания хоста Manticore, SQL-порта и таблиц для запросов, поступающих через соединение. Синтаксис строки подключения следующий: ```ini CONNECTION="mysql://FEDERATED@HOST:PORT/DB/TABLENAME" ``` -Поскольку в Manticore нет понятия базы данных, строка `DB` может быть произвольной, так как она будет игнорироваться Manticore, но MySQL требует значение в определении строки `CONNECTION`. Как видно из примера, полный SQL-запрос `SELECT` должен быть помещён в условие WHERE по столбцу `query`. +Поскольку в Manticore нет понятия базы данных, значение `DB` может быть произвольным, так как оно будет игнорироваться Manticore, но MySQL требует, чтобы в строке `CONNECTION` было указано значение. Как показано в примере, полный SQL-запрос `SELECT` должен быть помещён в условие WHERE к столбцу `query`. -Поддерживается только оператор `SELECT`, не поддерживаются `INSERT`, `REPLACE`, `UPDATE` или `DELETE`. +Поддерживается только оператор `SELECT`, а не `INSERT`, `REPLACE`, `UPDATE` или `DELETE`. ### Советы по FEDERATED -Очень **важно** отметить, что гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и нарезку набора результатов, чем увеличивать максимальное количество совпадений и использовать условия WHERE, ORDER BY и LIMIT на стороне MySQL. Это по двум причинам. Во-первых, Manticore реализует ряд оптимизаций и работает лучше MySQL для этих задач. Во-вторых, меньше данных нужно упаковывать searchd, передавать и распаковывать между Manticore и MySQL. +Очень **важно** понимать, что гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и выборку частей результата, чем увеличивать максимальное число совпадений и использовать WHERE, ORDER BY и LIMIT на стороне MySQL. Это связано с двумя причинами. Во-первых, Manticore реализует множество оптимизаций и работает лучше MySQL для этих задач. Во-вторых, меньше данных передаётся, упаковывается и распаковывается между searchd и MySQL. -JOIN можно выполнять между таблицей FEDERATED и другими таблицами MySQL. Это можно использовать для получения информации, которая не хранится в таблице Manticore. +Можно выполнять операции JOIN между таблицей FEDERATED и другими таблицами MySQL. Это позволяет получать информацию, не хранящуюся в таблице Manticore. ##### SQL: -##### Запрос для объединения таблицы MySQL с таблицей FEDERATED, обслуживаемой Manticore: +##### Запрос, который соединяет таблицу MySQL с таблицей FEDERATED, обслуживаемой Manticore: ```sql SELECT t1.id, t1.year, comments.comment FROM t1 JOIN comments ON t1.id=comments.post_id WHERE query='SELECT * FROM movies WHERE MATCH (\'pie\')'; diff --git a/manual/russian/Extensions/SphinxSE.md b/manual/russian/Extensions/SphinxSE.md index 6d8f6d66d9..18c3a370e9 100644 --- a/manual/russian/Extensions/SphinxSE.md +++ b/manual/russian/Extensions/SphinxSE.md @@ -1,13 +1,13 @@ # SphinxSE -SphinxSE — это движок хранения MySQL, который можно скомпилировать в серверы MySQL/MariaDB, используя их модульную архитектуру. +SphinxSE — это движок хранения MySQL, который можно скомпилировать в серверы MySQL/MariaDB с использованием их архитектуры с плагинами. -Несмотря на своё название, SphinxSE *не* хранит данные самостоятельно. Вместо этого он служит встроенным клиентом, который позволяет серверу MySQL взаимодействовать с `searchd`, выполнять поисковые запросы и получать результаты поиска. Вся индексация и поиск происходят вне MySQL. +Несмотря на своё название, SphinxSE *не* хранит данные самостоятельно. Вместо этого он служит встроенным клиентом, позволяющим серверу MySQL взаимодействовать с `searchd`, выполнять поисковые запросы и получать результаты поиска. Всё индексирование и поиск происходят вне MySQL. -Некоторые распространённые применения SphinxSE включают: +Некоторые типичные применения SphinxSE включают: * Упрощение переноса приложений MySQL Full-Text Search (FTS) на Manticore; -* Обеспечение использования Manticore с языками программирования, для которых нативные API ещё не доступны; -* Предоставление оптимизаций, когда требуется дополнительная обработка результатов Manticore на стороне MySQL (например, JOIN с оригинальными таблицами документов или дополнительная фильтрация на стороне MySQL). +* Возможность использования Manticore с языками программирования, для которых нативные API ещё не доступны; +* Предоставление оптимизаций при необходимости дополнительной обработки результатов Manticore на стороне MySQL (например, JOIN с таблицами оригинальных документов или дополнительная фильтрация на стороне MySQL). ## Установка SphinxSE @@ -15,16 +15,16 @@ SphinxSE — это движок хранения MySQL, который можн ### Компиляция MySQL 5.0.x с SphinxSE -1. скопируйте патч-файл `sphinx.5.0.yy.diff` в директорию с исходниками MySQL и выполните +1. скопируйте патч `sphinx.5.0.yy.diff` в директорию с исходниками MySQL и выполните ```bash $ patch -p1 < sphinx.5.0.yy.diff ``` -Если нет .diff файла именно для нужной версии: сборки, попробуйте применить .diff с ближайшими номерами версий. Важно, чтобы патч применился без конфликтов. -2. в директории с исходниками MySQL выполните +Если нет .diff файла именно для версии, которую нужно собрать, попробуйте применить .diff для самой близкой версии. Важно, чтобы патч применился без отклонённых изменений. +2. в директории с исходниками MySQL запустите ```bash $ sh BUILD/autorun.sh ``` -3. в директории с исходниками MySQL создайте каталог `sql/sphinx` и скопируйте туда все файлы из каталога `mysqlse` исходников Manticore. Пример: +3. в директории с исходниками MySQL создайте папку `sql/sphinx` и скопируйте туда все файлы из папки `mysqlse` из исходников Manticore. Пример: ```bash $ cp -R /root/builds/sphinx-0.9.7/mysqlse /root/builds/mysql-5.0.24/sql/sphinx ``` @@ -40,7 +40,7 @@ $ make install ### Компиляция MySQL 5.1.x с SphinxSE -1. В директории с исходниками MySQL создайте каталог `storage/sphinx` и скопируйте все файлы из каталога `mysqlse` исходников Manticore в это новое место. Например: +1. В директории с исходниками MySQL создайте каталог `storage/sphinx` и скопируйте туда все файлы из каталога `mysqlse` исходников Manticore. Например: ```bash $ cp -R /root/builds/sphinx-0.9.7/mysqlse /root/builds/mysql-5.1.14/storage/sphinx ``` @@ -63,7 +63,7 @@ $ make install -Чтобы убедиться, что SphinxSE успешно скомпилирован в MySQL, запустите вновь собранный сервер, выполните клиент MySQL и выполните запрос `SHOW ENGINES`. Вы должны увидеть список всех доступных движков. Manticore должен присутствовать, а в столбце "Support" должно быть "YES": +Чтобы убедиться, что SphinxSE успешно собран в MySQL, запустите недавно собранный сервер, выполните клиент MySQL и выполните запрос `SHOW ENGINES`. Вы увидите список всех доступных движков. В списке должен присутствовать Manticore с указанным "Support" значением "YES": @@ -84,13 +84,72 @@ mysql> show engines; 13 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "show engines;" +``` + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Engine": { + "type": "string" + } + }, + { + "Support": { + "type": "string" + } + }, + { + "Comment": { + "type": "string" + } + }, + { + "Transactions": { + "type": "string" + } + }, + { + "XA": { + "type": "string" + } + }, + { + "Savepoints": { + "type": "string" + } + } + ], + "data": [ + { + "Engine": "MyISAM", + "Support": "DEFAULT", + "Comment": "MyISAM storage engine", + "Transactions": "NO", + "XA": "NO", + "Savepoints": "NO" + } + ] + } +] +``` + ## Использование SphinxSE -Для поиска с помощью SphinxSE необходимо создать специальную "поисковую таблицу" с ENGINE=SPHINX, а затем использовать оператор `SELECT` с полнотекстовым запросом, помещённым в условие `WHERE` для колонки запроса. +Для поиска с помощью SphinxSE необходимо создать специальную "таблицу поиска" с ENGINE=SPHINX, а затем выполнить `SELECT` с полным текстовым запросом, размещённым в условии `WHERE` для колонки запроса. -Вот пример оператора создания и поискового запроса: +Пример CREATE-запроса и поискового запроса: ```sql CREATE TABLE t1 @@ -105,77 +164,77 @@ CREATE TABLE t1 SELECT * FROM t1 WHERE query='test it;mode=any'; ``` -В поисковой таблице первые три колонки *должны* иметь следующие типы: `INTEGER UNSIGNED` или `BIGINT` для первой колонки (ID документа), `INTEGER` или `BIGINT` для второй колонки (вес совпадения) и `VARCHAR` или `TEXT` для третьей колонки (ваш запрос). Это сопоставление фиксировано; нельзя пропускать какие-либо из этих трёх обязательных колонок, менять их порядок или типы. Кроме того, колонка запроса должна быть индексирована, а все остальные — не индексированы. Имена колонок игнорируются, поэтому можно использовать любые произвольные имена. +В таблице поиска первые три столбца *должны* иметь следующие типы: `INTEGER UNSIGNED` или `BIGINT` для первого столбца (id документа), `INTEGER` или `BIGINT` для второго (вес совпадения), и `VARCHAR` или `TEXT` для третьего (текст запроса). Это сопоставление фиксированное; вы не можете пропустить ни один из этих трёх обязательных столбцов, изменять их порядок или типы. Кроме того, колонка с запросом должна быть проиндексирована, а остальные — без индекса. Имена столбцов игнорируются, можно использовать любые имена. -Дополнительные колонки должны быть одного из типов: `INTEGER`, `TIMESTAMP`, `BIGINT`, `VARCHAR` или `FLOAT`. Они будут связаны с атрибутами, предоставленными в наборе результатов Manticore по имени, поэтому их имена должны совпадать с именами атрибутов, указанными в `sphinx.conf`. Если в результатах поиска Manticore нет соответствующего имени атрибута, в колонке будут значения `NULL`. +Дополнительные столбцы должны иметь типы `INTEGER`, `TIMESTAMP`, `BIGINT`, `VARCHAR` или `FLOAT`. Они будут соответствовать атрибутам из результата Manticore по имени, поэтому их имена должны совпадать с именами атрибутов, указанными в `sphinx.conf`. Если для конкретного столбца нет подходящего атрибута в результатах поиска Manticore, в этом столбце будут `NULL` значения. -Специальные "виртуальные" имена атрибутов также могут быть связаны с колонками SphinxSE. Для этого используйте `_sph_` вместо `@`. Например, чтобы получить значения виртуальных атрибутов `@groupby`, `@count` или `@distinct`, используйте имена колонок `_sph_groupby`, `_sph_count` или `_sph_distinct` соответственно. +Специальные "виртуальные" имена атрибутов также могут быть связаны с колонками SphinxSE. Для этого используйте вместо `@` префикс `_sph_`. Например, чтобы получить значения виртуальных атрибутов `@groupby`, `@count` или `@distinct`, используйте названия колонок `_sph_groupby`, `_sph_count` и `_sph_distinct` соответственно. -Параметр строки `CONNECTION` используется для указания хоста, порта и таблицы Manticore. Если в `CREATE TABLE` не указана строка подключения, предполагается имя таблицы `*` (т.е. поиск по всем таблицам) и `localhost:9312`. Синтаксис строки подключения следующий: +Параметр строки `CONNECTION` используется для указания хоста, порта и таблицы Manticore. Если в `CREATE TABLE` параметр соединения не задан, используется имя таблицы `*` (т.е. поиск по всем таблицам) и `localhost:9312`. Синтаксис строки соединения следующий: ``` CONNECTION="sphinx://HOST:PORT/TABLENAME" ``` -Вы можете изменить строку подключения по умолчанию позже: +Позже строку соединения можно изменить: ```sql mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ``` -Также эти параметры можно переопределить для каждого запроса. +Также эти параметры можно переопределять в каждом конкретном запросе. -Как показано в примере, и текст запроса, и параметры поиска должны быть помещены в условие `WHERE` для колонки поискового запроса (т.е. третьей колонки). Опции разделяются точкой с запятой, а имена опций отделяются от значений знаком равенства. Можно указать любое количество опций. Доступные опции: +Как показано в примере, и текст запроса, и опции поиска должны располагаться в условии `WHERE` по колонке запроса (т.е. третьей колонке). Опции разделяются точкой с запятой, а имя опции и её значение — знаком равенства. Можно указать любое количество опций. Доступные опции: * query - текст запроса; -* mode - режим сопоставления. Должен быть одним из "all", "any", "phrase", "boolean" или "extended". По умолчанию "all"; -* sort - режим сортировки совпадений. Должен быть одним из "relevance", "attr_desc", "attr_asc", "time_segments" или "extended". Во всех режимах, кроме "relevance", после двоеточия требуется имя атрибута (или сортировочное выражение для "extended"): +* mode - режим сопоставления. Должен быть одним из: "all", "any", "phrase", "boolean", или "extended". По умолчанию "all"; +* sort - режим сортировки совпадений. Должен быть одним из: "relevance", "attr_desc", "attr_asc", "time_segments" или "extended". Во всех режимах кроме "relevance" после двоеточия нужно указать имя атрибута (или выражение сортировки для "extended"): ``` ... WHERE query='test;sort=attr_asc:group_id'; ... WHERE query='test;sort=extended:@weight desc, group_id asc'; ``` * offset - смещение в наборе результатов; по умолчанию 0; -* limit - количество совпадений для извлечения из набора результатов; по умолчанию 20; +* limit - число совпадений для извлечения из набора; по умолчанию 20; * index - имена таблиц для поиска: ```sql ... WHERE query='test;index=test1;'; ... WHERE query='test;index=test1,test2,test3;'; ``` -* minid, maxid - минимальный и максимальный ID документа для совпадения; -* weights - список весов, разделённых запятыми, которые будут назначены полнотекстовым полям Manticore: +* minid, maxid - минимальный и максимальный id документа для поиска; +* weights - список весов через запятую для полей полнотекстового анализа Manticore: ```sql ... WHERE query='test;weights=1,2,3;'; ``` -* filter, !filter - имя атрибута и набор значений для фильтрации, разделённые запятыми: +* filter, !filter - имя атрибута и набор значений для фильтрации через запятую: ```sql # only include groups 1, 5 and 19 ... WHERE query='test;filter=group_id,1,5,19;'; # exclude groups 3 and 11 ... WHERE query='test;!filter=group_id,3,11;'; ``` -* range, !range - имя атрибута Manticore (integer или bigint) и минимальное и максимальное значения для фильтрации, разделённые запятыми: +* range, !range - имя атрибута (integer или bigint) и минимальное и максимальное значения для диапазона: ```sql # include groups from 3 to 7, inclusive ... WHERE query='test;range=group_id,3,7;'; # exclude groups from 5 to 25 ... WHERE query='test;!range=group_id,5,25;'; ``` -* floatrange, !floatrange - имя атрибута Manticore (с плавающей точкой) и минимальное и максимальное значения для фильтрации, разделённые запятыми: +* floatrange, !floatrange - имя атрибута с плавающей точкой и минимальное и максимальное значения для диапазона: ```sql # filter by a float size ... WHERE query='test;floatrange=size,2,3;'; # pick all results within 1000 meter from geoanchor ... WHERE query='test;floatrange=@geodist,0,1000;'; ``` -* maxmatches - максимальное количество совпадений для запроса, как в [опции поиска max_matches](../Searching/Options.md#max_matches): +* maxmatches - максимальное число совпадений на запрос, как в [max_matches опции поиска](../Searching/Options.md#max_matches): ```sql ... WHERE query='test;maxmatches=2000;'; ``` -* cutoff - максимальное допустимое количество совпадений, как в [опции поиска cutoff](../Searching/Options.md#cutoff): +* cutoff - максимальное допустимое число совпадений, как в [cutoff опции поиска](../Searching/Options.md#cutoff): ```sql ... WHERE query='test;cutoff=10000;'; ``` -* maxquerytime - максимальное допустимое время выполнения запроса (в миллисекундах), как в [опции поиска max_query_time](../Searching/Options.md#max_query_time): +* maxquerytime - максимально допустимое время выполнения запроса (в миллисекундах), как в [опции поиска max_query_time](../Searching/Options.md#max_query_time): ```sql ... WHERE query='test;maxquerytime=1000;'; ``` @@ -184,23 +243,23 @@ mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ... WHERE query='test;groupby=day:published_ts;'; ... WHERE query='test;groupby=attr:group_id;'; ``` -* groupsort - условие сортировки групп: +* groupsort - параметр сортировки при группировке: ```sql ... WHERE query='test;groupsort=@count desc;'; ``` -* distinct - атрибут для вычисления [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) при выполнении группировки: +* distinct - атрибут для вычисления [COUNT(DISTINCT)](../Searching/Grouping.md#COUNT%28DISTINCT-field%29) при группировке: ```sql ... WHERE query='test;groupby=attr:country_id;distinct=site_id'; ``` -* indexweights - список через запятую имён таблиц и весов, используемых при поиске по нескольким таблицам: +* indexweights - список имён таблиц и весов через запятую для использования при поиске по нескольким таблицам: ```sql ... WHERE query='test;indexweights=tbl_exact,2,tbl_stemmed,1;'; ``` -* fieldweights - список через запятую весов для каждого поля, которые могут использоваться ранжировщиком: +* fieldweights - список весов по полям через запятую, которые может использовать ранкер: ```sql ... WHERE query='test;fieldweights=title,10,abstract,3,content,1;'; ``` -* comment - строка для пометки этого запроса в журнале запросов, как в [опции поиска comment](../Searching/Options.md#comment): +* comment - строка для пометки запроса в журнале запросов, как в [опции поиска comment](../Searching/Options.md#comment): ```sql ... WHERE query='test;comment=marker001;'; ``` @@ -212,12 +271,12 @@ mysql> ALTER TABLE t1 CONNECTION="sphinx://NEWHOST:NEWPORT/NEWTABLENAME"; ```sql ... WHERE query='test;host=sphinx-test.loc;port=7312;'; ``` -* ranker - функция ранжирования для использования с режимом "extended" сопоставления, как в [ranker](../Searching/Options.md#ranker). Известные значения: "proximity_bm25", "bm25", "none", "wordcount", "proximity", "matchany", "fieldmask", "sph04", синтаксис "expr:EXPRESSION" для поддержки ранжировщика на основе выражений (где EXPRESSION следует заменить вашей конкретной формулой ранжирования), и "export:EXPRESSION": +* ranker - функция ранжирования для использования в режиме "extended" соответствия, как в [ranker](../Searching/Options.md#ranker). Известные значения: "proximity_bm25", "bm25", "none", "wordcount", "proximity", "matchany", "fieldmask", "sph04", синтаксис "expr:EXPRESSION" для поддержки ранжирования на основе выражений (где EXPRESSION заменяется вашей конкретной формулой ранжирования), и "export:EXPRESSION": ```sql ... WHERE query='test;mode=extended;ranker=bm25;'; ... WHERE query='test;mode=extended;ranker=expr:sum(lcs);'; ``` -Ранжировщик "export" работает аналогично ranker=expr, но сохраняет значения факторов для каждого документа, в то время как ranker=expr отбрасывает их после вычисления итогового значения `WEIGHT()`. Имейте в виду, что ranker=export предназначен для редкого использования, например, для обучения функции машинного обучения (ML) или ручного определения собственной функции ранжирования, и не должен использоваться в реальной эксплуатации. При использовании этого ранжировщика, скорее всего, вам захочется изучить вывод функции `RANKFACTORS()`, которая генерирует строку, содержащую все факторы на уровне полей для каждого документа. +Ранкер "export" работает аналогично ranker=expr, но сохраняет значения факторов для каждого документа, тогда как ranker=expr отбрасывает их после вычисления итогового значения `WEIGHT()`. Имейте в виду, что ranker=export предназначен для случайного использования, например, для обучения функции машинного обучения (ML) или ручного определения собственной функции ранжирования, и не должен применяться в продакшене. При использовании этого ранкера обычно полезно изучать вывод функции `RANKFACTORS()`, которая генерирует строку со всеми значениями факторов по полям для каждого документа. @@ -261,38 +320,112 @@ min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT *, WEIGHT(), RANKFACTORS() FROM myindex WHERE MATCH('dog') OPTION ranker=export('100*bm25');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "published": { + "type": "long long" + } + }, + { + "channel_id": { + "type": "long long" + } + }, + { + "title": { + "type": "long long" + } + }, + { + "content": { + "type": "long long" + } + }, + { + "weight()": { + "type": "long long" + } + }, + { + "rankfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 555617, + "published": 1110067331, + "channel_id": 1059819, + "title": 7, + "content": 428, + "weight()": 69900, + "rankfactors()": "bm25=699, bm25a=0.666478, field_mask=2, doc_word_count=1, field1=(lcs=1, hit_count=4, word_count=1, tf_idf=1.038127, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=120, min_best_span_pos=120, exact_hit=0, max_window_hits=1), word1=(tf=4, idf=0.259532)" + }, + { + "id": 555313, + "published": 1108438365, + "channel_id": 1058561, + "title": 8, + "content": 249, + "weight()": 68500, + "rankfactors()": "bm25=685, bm25a=0.675213, field_mask=3, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.259532, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=8, min_best_span_pos=8, exact_hit=0, max_window_hits=1), field1=(lcs=1, hit_count=2, word_count=1, tf_idf=0.519063, min_idf=0.259532, max_idf=0.259532, sum_idf=0.259532, min_hit_pos=36, min_best_span_pos=36, exact_hit=0, max_window_hits=1), word1=(tf=3, idf=0.259532)" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -* geoanchor - якорь геодистанции. Подробнее о геопоиске [в этом разделе](../Searching/Geo_search.md). Принимает 4 параметра: имена атрибутов широты и долготы, а также координаты якорной точки соответственно: +* geoanchor - якорь для георасстояния. Подробнее о геопоиске [в этом разделе](../Searching/Geo_search.md). Принимает 4 параметра: имена атрибутов широты и долготы, и координаты якорной точки соответственно: ```sql ... WHERE query='test;geoanchor=latattr,lonattr,0.123,0.456'; ``` -Очень **важное** замечание: **гораздо** эффективнее позволить Manticore выполнять сортировку, фильтрацию и нарезку набора результатов, чем увеличивать максимальное количество совпадений и использовать `WHERE`, `ORDER BY` и `LIMIT` на стороне MySQL. Это связано с двумя причинами. Во-первых, Manticore применяет различные оптимизации и выполняет эти задачи лучше, чем MySQL. Во-вторых, меньше данных нужно упаковывать searchd, передавать и распаковывать SphinxSE. +Очень **важное** замечание: гораздо эффективнее позволить Manticore выполнять сортировку, фильтрацию и нарезку результата, чем увеличивать количество максимальных совпадений и использовать в MySQL `WHERE`, `ORDER BY` и `LIMIT`. Это связано с двумя причинами. Во-первых, Manticore применяет множество оптимизаций и выполняет эти операции эффективнее, чем MySQL. Во-вторых, меньше данных нужно упаковывать searchd, передавать и распаковывать SphinxSE. ### Важное замечание о сохранённых полях при использовании SphinxSE -Начиная с версии 5.0.0, Manticore по умолчанию сохраняет все поля. При использовании Manticore вместе с MySQL или MariaDB через SphinxSE обычно нет смысла сохранять все поля, так как оригиналы уже хранятся в MySQL/MariaDB. В таких конфигурациях рекомендуется явно отключить сохранение полей для соответствующей таблицы Manticore, установив: +Начиная с версии 5.0.0, Manticore по умолчанию сохраняет все поля. Когда Manticore используется вместе с MySQL или MariaDB через SphinxSE, обычно сохранение всех полей не имеет смысла, потому что оригиналы уже хранятся в MySQL/MariaDB. В таких конфигурациях рекомендуется явно отключить сохранение полей для соответствующей таблицы Manticore, задав: ``` stored_fields = ``` -См. справочник по настройке: [stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields). +Смотрите справочник по настройке: [stored_fields](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#stored_fields). -Если оставить значение по умолчанию (все поля сохранены) и затем выбрать много документов одновременно через SphinxSE, может быть превышен внутренний лимит движка, и вы получите ошибку вида: +Если вы оставите настройку по умолчанию (сохранять все поля) и выберете много документов через SphinxSE, в движке может быть превышен внутренний лимит, и вы получите ошибку вида: "bad searchd response length" -Установка `stored_fields =` предотвращает отправку больших сохранённых данных обратно в MySQL/MariaDB и предотвращает эту ошибку в типичных интеграциях SphinxSE. +Установка `stored_fields =` позволяет избежать передачи больших хранимых данных обратно в MySQL/MariaDB и предотвращает эту ошибку в типичных интеграциях SphinxSE. ### SHOW ENGINE SPHINX STATUS -Вы можете получить дополнительную информацию, связанную с результатами запроса, используя оператор `SHOW ENGINE SPHINX STATUS`: +Вы можете получить дополнительную информацию по результатам запроса с помощью оператора `SHOW ENGINE SPHINX STATUS`: @@ -312,12 +445,58 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 25, total found: 25, time: 126, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + -Также эту информацию можно получить через переменные состояния. Учтите, что для этого способа не требуются права суперпользователя. +Также эти данные можно получить через переменные статуса. Учтите, что этот способ не требует привилегий суперпользователя. @@ -339,12 +518,63 @@ mysql> SHOW STATUS LIKE 'sphinx_%'; 5 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SHOW STATUS LIKE 'sphinx_%';" +``` + + +```JSON +[ + { + "total": 5, + "error": "", + "warning": "", + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "sphinx_total", + "Value": "25" + }, + { + "Variable_name": "sphinx_total_found", + "Value": "25" + }, + { + "Variable_name": "sphinx_time", + "Value": "126" + }, + { + "Variable_name": "sphinx_word_count", + "Value": "2" + }, + { + "Variable_name": "sphinx_words", + "Value": "sphinx:591:1256 soft:11076:15945" + } + ] + } +] +``` + -Таблицы поиска SphinxSE можно объединять с таблицами, использующими другие движки. Вот пример с таблицей "documents" из example.sql: +Таблицы поиска SphinxSE могут объединяться с таблицами, использующими другие движки. Вот пример с таблицей "documents" из example.sql: @@ -376,24 +606,103 @@ mysql> SHOW ENGINE SPHINX STATUS; 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT content, date_added FROM test.documents docs JOIN t1 ON (docs.id=t1.id) WHERE query="one document;mode=any";" + +POST /sql?mode=raw -d "SHOW ENGINE SPHINX STATUS;" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "content": { + "type": "string" + } + }, + { + "docdate": { + "type": "string" + } + } + ], + "data": [ + { + "content": "this is my test document number two", + "docdate": "2006-06-17 14:04:28" + }, + { + "content": "this is my test document number one", + "docdate": "2006-06-17 14:04:28" + } + ] + } +] + +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "Type": { + "type": "string" + } + }, + { + "Name": { + "type": "string" + } + }, + { + "Status": { + "type": "string" + } + } + ], + "data": [ + { + "Type": "SPHINX", + "Name": "stats", + "Status": "total: 2, total found: 2, time: 0, words: 2" + }, + { + "Type": "SPHINX", + "Name": "words", + "Status": "one:1:2 document:2:2" + } + ] + } +] +``` + ## Создание сниппетов через MySQL -SphinxSE также содержит функцию UDF, которая позволяет создавать сниппеты с помощью MySQL. Эта функциональность похожа на [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting), но доступна через MySQL+SphinxSE. +SphinxSE также поддерживает UDF-функцию, которая позволяет создавать сниппеты через MySQL. Эта функциональность похожа на [HIGHLIGHT()](../Searching/Highlighting.md#Highlighting), но доступна через связку MySQL+SphinxSE. -Бинарный файл, предоставляющий UDF, называется `sphinx.so` и должен автоматически собираться и устанавливаться в нужное место вместе с SphinxSE. Если по какой-то причине он не устанавливается автоматически, найдите `sphinx.so` в каталоге сборки и скопируйте его в каталог плагинов вашей MySQL. После этого зарегистрируйте UDF следующей командой: +Бинарный файл UDF называется `sphinx.so` и должен автоматически собираться и устанавливаться в соответствующем месте вместе с SphinxSE. Если по какой-то причине он не установился автоматически, найдите `sphinx.so` в каталоге сборки и скопируйте его в директорию плагинов вашего MySQL. Затем зарегистрируйте UDF следующей командой: ```sql CREATE FUNCTION sphinx_snippets RETURNS STRING SONAME 'sphinx.so'; ``` -Имя функции *должно* быть sphinx_snippets; нельзя использовать произвольное имя. Аргументы функции следующие: +Имя функции *должно* быть sphinx_snippets; нельзя использовать произвольное имя. Аргументы функции: **Прототип:** function sphinx_snippets ( document, table, words [, options] ); -Аргументы document и words могут быть строками или столбцами таблицы. Опции должны задаваться так: `'value' AS option_name`. Для списка поддерживаемых опций смотрите раздел [Highlighting](../Searching/Highlighting.md). Единственная дополнительная опция, специфичная для UDF, называется `sphinx` и позволяет указать расположение searchd (хост и порт). +Аргументы document и words могут быть строками или столбцами таблицы. Опции задаются так: `'value' AS option_name`. Список поддерживаемых опций смотрите в [разделе Highlighting](../Searching/Highlighting.md). Единственная дополнительная опция, специфичная для UDF, называется `sphinx` и позволяет указать расположение searchd (хост и порт). Примеры использования: diff --git a/manual/russian/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md b/manual/russian/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md index 8fcb47f4e5..bac53dae71 100644 --- a/manual/russian/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md +++ b/manual/russian/Extensions/UDFs_and_Plugins/Plugins/Enabling_and_disabling_buddy_plugins.md @@ -1,6 +1,6 @@ # Включение и отключение плагинов Buddy -Для упрощения управления плагинами Buddy, особенно при разработке нового или изменении существующего, предоставлены команды включения и отключения плагинов Buddy. Эти команды действуют временно во время выполнения и сбрасываются к значениям по умолчанию после перезапуска демона или выполнения сброса Buddy. Для постоянного отключения плагина его необходимо удалить. +Для упрощения управления плагинами Buddy, особенно при разработке нового или изменении существующего, предоставлены команды включения и отключения плагинов Buddy. Эти команды действуют временно во время выполнения и сбрасываются до настроек по умолчанию после перезапуска демона или выполнения сброса Buddy. Для постоянного отключения плагина его необходимо удалить. Для включения или отключения плагина требуется полное квалифицированное имя пакета плагина. Чтобы его найти, можно выполнить запрос `SHOW BUDDY PLUGINS` и посмотреть полное квалифицированное имя в поле `package`. Например, плагин `SHOW` имеет полное квалифицированное имя `manticoresoftware/buddy-plugin-show`. @@ -11,17 +11,26 @@ ENABLE BUDDY PLUGIN ``` -> ПРИМЕЧАНИЕ: `ENABLE BUDDY PLUGIN` требует [Manticore Buddy](../../../Installation/Manticore_Buddy.md). Если команда не работает, убедитесь, что Buddy установлен. +> ПРИМЕЧАНИЕ: `ENABLE BUDDY PLUGIN` требует [Manticore Buddy](../../../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. -Эта команда повторно активирует ранее отключённый плагин Buddy, позволяя ему снова обрабатывать ваши запросы. +Эта команда повторно активирует ранее отключенный плагин Buddy, позволяя ему снова обрабатывать ваши запросы. -### Пример +### Пример SQL ```sql ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` + + +### Пример JSON + + +```JSON +POST /sql?mode=raw -d "ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + @@ -31,16 +40,24 @@ ENABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show DISABLE BUDDY PLUGIN ``` -Эта команда деактивирует активный плагин Buddy, предотвращая его обработку дальнейших запросов. +Эта команда деактивирует активный плагин Buddy, препятствуя его дальнейшей обработке запросов. -### Пример +### Пример SQL ```sql DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show ``` -После отключения, если вы попробуете выполнить команду `SHOW QUERIES`, вы получите ошибку, так как плагин отключён. + +### Пример JSON + + +```JSON +POST /sql?mode=raw -d "DISABLE BUDDY PLUGIN manticoresoftware/buddy-plugin-show" +``` + +После отключения при попытке выполнить команду `SHOW QUERIES` возникнет ошибка, так как плагин отключен. diff --git a/manual/russian/Functions/Date_and_time_functions.md b/manual/russian/Functions/Date_and_time_functions.md index dd97d7a51e..81ebddd0ef 100644 --- a/manual/russian/Functions/Date_and_time_functions.md +++ b/manual/russian/Functions/Date_and_time_functions.md @@ -1,6 +1,6 @@ # Функции даты и времени -Обратите внимание, что `CURTIME()`, `UTC_TIME()`, `UTC_TIMESTAMP()`, и `TIMEDIFF()` могут быть преобразованы в числовые типы с помощью произвольных функций преобразования, таких как `BIGINT()`, `DOUBLE()` и т.д. +Обратите внимание, что `CURTIME()`, `UTC_TIME()`, `UTC_TIMESTAMP()`, и `TIMEDIFF()` могут быть приведены к числовым типам с помощью произвольных функций преобразования, таких как `BIGINT()`, `DOUBLE()` и других. ### NOW() @@ -18,6 +18,34 @@ select NOW(); | 1615788407 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select NOW();" +``` + +```JSON +[ + { + "columns": [ + { + "now()": { + "type": "long" + } + } + ], + "data": [ + { + "now()": 1615788407 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURTIME() @@ -36,6 +64,34 @@ select CURTIME(); | 07:06:30 | +-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURTIME();" +``` + +```JSON +[ + { + "columns": [ + { + "CURTIME()": { + "type": "string" + } + } + ], + "data": [ + { + "CURTIME()": "07:06:30" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ### CURDATE() @@ -54,6 +110,33 @@ select curdate(); | 2023-08-02 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select CURDATE();" +``` + +```JSON +[ + { + "columns": [ + { + "CURDATE()": { + "type": "string" + } + } + ], + "data": [ + { + "CURDATE()": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIME() @@ -72,6 +155,33 @@ select UTC_TIME(); | 06:06:18 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIME();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIME()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIME()": "06:06:18" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### UTC_TIMESTAMP() @@ -90,11 +200,38 @@ select UTC_TIMESTAMP(); | 2021-03-15 06:06:03 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select UTC_TIMESTAMP();" +``` + +```JSON +[ + { + "columns": [ + { + "UTC_TIMESTAMP()": { + "type": "string" + } + } + ], + "data": [ + { + "UTC_TIMESTAMP()": "2021-03-15 06:06:0" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### SECOND() -Возвращает целочисленное значение секунд (в диапазоне 0..59) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целую секунду (в диапазоне от 0 до 59) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -108,11 +245,38 @@ select second(now()); | 52 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select second(now());" +``` + +```JSON +[ + { + "columns": [ + { + "second(now())": { + "type": "long" + } + } + ], + "data": [ + { + "second(now())": 52 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MINUTE() -Возвращает целочисленное значение минут (в диапазоне 0..59) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целую минуту (в диапазоне от 0 до 59) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -126,11 +290,38 @@ select minute(now()); | 5 | +---------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select minute(now());" +``` + +```JSON +[ + { + "columns": [ + { + "minute(now())": { + "type": "long" + } + } + ], + "data": [ + { + "minute(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### HOUR() -Возвращает целочисленное значение часов (в диапазоне 0..23) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целый час (в диапазоне от 0 до 23) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -144,11 +335,38 @@ select hour(now()); | 7 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "hour(now())" +``` + +```JSON +[ + { + "columns": [ + { + "hour(now())": { + "type": "long" + } + } + ], + "data": [ + { + "hour(now())": 7 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAY() -Возвращает целочисленное значение дня месяца (в диапазоне 1..31) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целый день месяца (в диапазоне от 1 до 31) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -162,11 +380,38 @@ select day(now()); | 15 | +------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select day(now());" +``` + +```JSON +[ + { + "columns": [ + { + "day(now())": { + "type": "long" + } + } + ], + "data": [ + { + "day(now())": 15 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTH() -Возвращает целочисленное значение месяца (в диапазоне 1..12) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целый месяц (в диапазоне от 1 до 12) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -180,11 +425,38 @@ select month(now()); | 3 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select month(now());" +``` + +```JSON +[ + { + "columns": [ + { + "month(now())": { + "type": "long" + } + } + ], + "data": [ + { + "month(now())": 3 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### QUARTER() -Возвращает целочисленное значение квартала года (в диапазоне 1..4) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целый квартал года (в диапазоне от 1 до 4) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -198,11 +470,38 @@ select quarter(now()); | 2 | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select quarter(now());" +``` + +```JSON +[ + { + "columns": [ + { + "quarter(now())": { + "type": "long" + } + } + ], + "data": [ + { + "quarter(now())": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEAR() -Возвращает целочисленное значение года (в диапазоне 1969..2038) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целый год (в диапазоне от 1969 до 2038) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -216,11 +515,38 @@ select year(now()); | 2024 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select year(now());" +``` + +```JSON +[ + { + "columns": [ + { + "year(now())": { + "type": "long" + } + } + ], + "data": [ + { + "year(now())": 2024 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYNAME() -Возвращает название дня недели для заданного аргумента метки времени, согласно текущему часовому поясу. +Возвращает название дня недели для заданного аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -234,11 +560,38 @@ select dayname(now()); | Wednesday | +----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayname(now());" +``` + +```JSON +[ + { + "columns": [ + { + "dayname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "dayname(now())": "Wednesday" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### MONTHNAME() -Возвращает название месяца для заданного аргумента метки времени, согласно текущему часовому поясу. +Возвращает название месяца для заданного аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -252,11 +605,38 @@ select monthname(now()); | August | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select monthname(now())" +``` + +```JSON +[ + { + "columns": [ + { + "monthname(now())": { + "type": "string" + } + } + ], + "data": [ + { + "monthname(now())": "August" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFWEEK() -Возвращает целочисленный индекс дня недели (в диапазоне 1..7) для заданного аргумента метки времени, согласно текущему часовому поясу. +Возвращает целочисленный индекс дня недели (в диапазоне от 1 до 7) для заданного аргумента метки времени, в соответствии с текущим часовым поясом. Обратите внимание, что неделя начинается с воскресенья. @@ -271,11 +651,38 @@ select dayofweek(now()); | 5 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofweek(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofweek(now())": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DAYOFYEAR() -Возвращает целочисленное значение дня года (в диапазоне 1..366) для заданного аргумента метки времени, согласно текущему часовому поясу. +Возвращает целочисленный день года (в диапазоне от 1 до 366) для заданного аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -289,11 +696,38 @@ select dayofyear(now()); | 214 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select dayofyear(now())" +``` + +```JSON +[ + { + "columns": [ + { + "dayofyear(now())": { + "type": "long" + } + } + ], + "data": [ + { + "dayofyear(now())": 214 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARWEEK() -Возвращает целочисленное значение года и код дня первого дня текущей недели (в диапазоне 1969001..2038366) для заданного аргумента метки времени, согласно текущему часовому поясу. +Возвращает целочисленное значение года и кода дня первого дня текущей недели (в диапазоне от 1969001 до 2038366) для заданного аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -307,11 +741,38 @@ select yearweek(now()); | 2023211 | +-----------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearweek(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearweek(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearweek(now())": 2023211 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTH() -Возвращает целочисленное значение года и месяца (в диапазоне 196912..203801) из аргумента метки времени, согласно текущему часовому поясу. +Возвращает целочисленное значение года и месяца (в диапазоне от 196912 до 203801) из аргумента метки времени, в соответствии с текущим часовым поясом. ```sql @@ -325,11 +786,38 @@ select yearmonth(now()); | 202103 | +------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonth(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonth(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonth(now())": 202103 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### YEARMONTHDAY() -Возвращает целочисленное значение года, месяца и дня (в диапазоне от 19691231 до 20380119) на основе текущего часового пояса. +Возвращает целочисленный код года, месяца и дня (в диапазоне от 19691231 до 20380119) на основе текущего часового пояса. ```sql @@ -343,11 +831,38 @@ select yearmonthday(now()); | 20210315 | +---------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select yearmonthday(now());" +``` + +```JSON +[ + { + "columns": [ + { + "yearmonthday(now())": { + "type": "long" + } + } + ], + "data": [ + { + "yearmonthday(now())": 20210315 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIMEDIFF() -Вычисляет разницу между двумя метками времени в формате `hh:ii:ss`. +Calculates the difference between two timestamps in the format `hh:ii:ss`. ```sql @@ -361,11 +876,38 @@ select timediff(1615787586, 1613787583); | 555:33:23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select timediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "timediff(1615787586, 1613787583)": { + "type": "string" + } + } + ], + "data": [ + { + "timediff(1615787586, 1613787583)": "555:33:23" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATEDIFF() -Вычисляет количество дней между двумя заданными метками времени. +Calculates the number of days between two given timestamps. ```sql @@ -379,11 +921,38 @@ select datediff(1615787586, 1613787583); | 23 | +----------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select datediff(1615787586, 1613787583);" +``` + +```JSON +[ + { + "columns": [ + { + "datediff(1615787586, 1613787583)": { + "type": "long long" + } + } + ], + "data": [ + { + "datediff(1615787586, 1613787583)": 23 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE() -Форматирует часть даты из аргумента метки времени в строку в формате `YYYY-MM-DD`. +Formats the date part from a timestamp argument as a string in `YYYY-MM-DD` format. ```sql @@ -397,11 +966,38 @@ select date(now()); | 2023-08-02 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select date(now());" +``` + +```JSON +[ + { + "columns": [ + { + "date(now())": { + "type": "string" + } + } + ], + "data": [ + { + "date(now())": "2023-08-02" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### TIME() -Форматирует часть времени из аргумента метки времени в строку в формате `HH:MM:SS`. +Formats the time part from a timestamp argument as a string in `HH:MM:SS` format. ```sql @@ -415,21 +1011,48 @@ select time(now()); | 15:21:27 | +-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select time(now());" +``` + +```JSON +[ + { + "columns": [ + { + "time(now())": { + "type": "string" + } + } + ], + "data": [ + { + "time(now())": "15:21:27" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` ### DATE_FORMAT() -Возвращает отформатированную строку на основе предоставленных аргументов даты и формата. Аргумент формата использует те же спецификаторы, что и функция [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html). Для удобства, вот некоторые распространённые спецификаторы формата: +Returns a formatted string based on the provided date and format arguments. The format argument uses the same specifiers as the [strftime](https://man7.org/linux/man-pages/man3/strftime.3.html) function. For convenience, here are some common format specifiers: -- `%Y` - Год из четырёх цифр -- `%m` - Двухзначный месяц (01-12) -- `%d` - Двухзначный день месяца (01-31) -- `%H` - Двухзначный час (00-23) -- `%M` - Двухзначная минута (00-59) -- `%S` - Двухзначная секунда (00-59) -- `%T` - Время в 24-часовом формате (`%H:%M:%S`) +- `%Y` - Four-digit year +- `%m` - Two-digit month (01-12) +- `%d` - Two-digit day of the month (01-31) +- `%H` - Two-digit hour (00-23) +- `%M` - Two-digit minute (00-59) +- `%S` - Two-digit second (00-59) +- `%T` - Time in 24-hour format (`%H:%M:%S`) -Обратите внимание, что это не полный список спецификаторов. Пожалуйста, обратитесь к документации по `strftime()` для вашей операционной системы, чтобы получить полный список. +Note that this is not a complete list of the specifiers. Please consult the documentation for `strftime()` for your operating system to get the full list. ```sql @@ -443,36 +1066,63 @@ SELECT DATE_FORMAT(NOW(), 'year %Y and time %T'); | year 2023 and time 11:54:52 | +------------------------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "select DATE_FORMAT(NOW(), 'year %Y and time %T');" +``` + +```JSON +[ + { + "columns": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": { + "type": "string" + } + } + ], + "data": [ + { + "DATE_FORMAT(NOW(), 'year %Y and time %T')": "year 2023 and time 11:54:52" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` -Этот пример форматирует текущие дату и время, отображая четырехзначный год и время в 24-часовом формате. +This example formats the current date and time, displaying the four-digit year and the time in 24-hour format. ### DATE_HISTOGRAM() -`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` принимает размер корзины в виде названия единицы и возвращает номер корзины для значения. Значения округляются до ближайшей корзины. Ключевая функция: +`DATE_HISTOGRAM(expr, {calendar_interval='unit_name'})` Takes a bucket size as a unit name and returns the bucket number for the value. Values are rounded to the closest bucket. The key function is: ```sql key_of_the_bucket = interval * floor ( value / interval ) ``` -Интервалы могут быть указаны с помощью названия единицы, например `week`, или как одна единица, например `1M`. Однако множественные единицы, такие как `2d`, не поддерживаются с `calendar_interval`, но разрешены с `fixed_interval`. +Intervals can be specified using a unit name, like `week`, or as a single unit, such as `1M`. However, multiple units, like `2d`, are not supported with `calendar_interval` but are allowed with `fixed_interval`. -Допустимые интервалы для `calendar_interval`: +The valid intervals for `calendar_interval` are: - `minute`, `1m` - `hour`, `1h` - `day`, `1d` -- `week`, `1w` (неделя — это интервал между начальным днем недели, часом, минутой, секундой и следующей неделей, но в тот же день и время недели) +- `week`, `1w` (a week is the interval between the start day of the week, hour, minute, second and the next week but the same day and time of the week) - `month`, `1M` -- `year`, `1y` (год — это интервал между начальным днем месяца, временем и следующим годом, но в тот же день месяца и время) +- `year`, `1y` (a year is the interval between the start day of the month, time and the next year but the same day of the month, time) -Допустимые интервалы для `fixed_interval`: +The valid intervals for `fixed_interval` are: - `minute`, `2m` - `hour`, `3h` - `day`, `5d` -Используется в агрегациях, `FACET` и группировках. +Used in aggregation, `FACET`, and grouping. -Пример: +Example: ```sql SELECT COUNT(*), @@ -483,13 +1133,13 @@ GROUP BY months ORDER BY months ASC; ### DATE_RANGE() -`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` принимает набор диапазонов и возвращает номер корзины для значения. -Выражение включает значение `range_from` и исключает значение `range_to` для каждого диапазона. Диапазон может быть открытым — иметь только значение `range_from` или только `range_to`. -Отличие от функции [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) в том, что значения `range_from` и `range_to` могут быть выражены в выражениях [Date math](../Functions/Date_and_time_functions.md#Date-math). +`DATE_RANGE(expr, {range_from='date_math', range_to='date_math'})` takes a set of ranges and returns the bucket number for the value. +The expression includes the `range_from` value and excludes the `range_to` value for each range. The range can be open - having only the `range_from` or only the `range_to` value. +The difference between this and the [RANGE()](../Functions/Arrays_and_conditions_functions.md#RANGE%28%29) function is that the `range_from` and `range_to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions. -Используется в агрегациях, `FACET` и группировках. +Used in aggregation, `FACET`, and grouping. -Пример: +Example: ```sql SELECT COUNT(*), @@ -500,30 +1150,30 @@ GROUP BY points ORDER BY points ASC; ##### Date math -Date math позволяет работать с датами и временем непосредственно в ваших поисках. Это особенно полезно для обработки данных, которые меняются со временем. С помощью date math вы можете легко находить записи за определенный период, анализировать тенденции данных или управлять временем удаления информации. Это упрощает работу с датами, позволяя добавлять или вычитать время от заданной даты, округлять даты до ближайшей единицы времени и многое другое, всё это в рамках ваших поисковых запросов. - -Для использования date math вы начинаете с базовой даты, которая может быть: -- `now` для текущей даты и времени, -- или конкретной строкой даты, заканчивающейся на `||`. - -Затем вы можете модифицировать эту дату операциями, такими как: -- `+1y` чтобы добавить один год, -- `-1h` чтобы вычесть один час, -- `/m` чтобы округлить до ближайшего месяца. - -Вы можете использовать следующие единицы в операциях: -- `s` для секунд, -- `m` для минут, -- `h` (или `H`) для часов, -- `d` для дней, -- `w` для недель, -- `M` для месяцев, -- `y` для лет. - -Вот несколько примеров использования date math: -- `now+4h` означает четыре часа от текущего момента. -- `now-2d/d` — время два дня назад, округленное до ближайшего дня. -- `2010-04-20||+2M/d` — 20 июня 2010 года, округленное до ближайшего дня. +Date math lets you work with dates and times directly in your searches. It's especially useful for handling data that changes over time. With date math, you can easily do things like find entries from a certain period, analyze data trends, or manage when information should be removed. It simplifies working with dates by letting you add or subtract time from a given date, round dates to the nearest time unit, and more, all within your search queries. + +To use date math, you start with a base date, which can be: +- `now` for the current date and time, +- or a specific date string ending with `||`. + +Then, you can modify this date with operations like: +- `+1y` to add one year, +- `-1h` to subtract one hour, +- `/m` to round to the nearest month. + +You can use these units in your operations: +- `s` for seconds, +- `m` for minutes, +- `h` (or `H`) for hours, +- `d` for days, +- `w` for weeks, +- `M` for months, +- `y` for years. + +Here are some examples of how you might use date math: +- `now+4h` means four hours from now. +- `now-2d/d` is the time two days ago, rounded to the nearest day. +- `2010-04-20||+2M/d` is June 20, 2010, rounded to the nearest day. diff --git a/manual/russian/Integration/Kafka.md b/manual/russian/Integration/Kafka.md index 7cdf8fdeab..07bc774cde 100644 --- a/manual/russian/Integration/Kafka.md +++ b/manual/russian/Integration/Kafka.md @@ -2,12 +2,12 @@ > ПРИМЕЧАНИЕ: эта функциональность требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. -Manticore поддерживает интеграцию с [Apache Kafka](https://kafka.apache.org/) для потокового приема данных в реальном времени через источники Kafka и материализованные представления, что позволяет индексировать и искать данные в реальном времени. В настоящее время поддерживаются и протестированы версии **apache/kafka 3.7.0-4.1.0**. +Manticore поддерживает интеграцию с [Apache Kafka](https://kafka.apache.org/) для потокового сбора данных через Kafka источники и материализованные представления, позволяя индексировать и искать данные в реальном времени. В настоящее время тестируются и поддерживаются версии **apache/kafka 3.7.0-4.1.0**. -Чтобы начать, необходимо: -1. **Определить источник:** Указать тему Kafka, из которой Manticore Search будет читать сообщения. Эта настройка включает детали, такие как хост брокера, порт и имя темы. -2. **Настроить таблицу назначения:** Выбрать таблицу реального времени Manticore для хранения входящих данных из Kafka. -3. **Создать материализованное представление:** Настроить материализованное представление (`mv`) для обработки преобразования данных и сопоставления из Kafka в таблицу назначения Manticore Search. Здесь вы определите сопоставления полей, преобразования данных и любые фильтры или условия для входящего потока данных. +Чтобы начать, вам нужно: +1. **Определить источник:** Указать Kafka-топик, из которого Manticore Search будет считывать сообщения. В настройках указываются такие параметры, как хост брокера, порт и имя топика. +2. **Настроить целевую таблицу:** Выбрать таблицу типа real-time Manticore для хранения данных, поступающих из Kafka. +3. **Создать материализованное представление:** Настроить материализованное представление (`mv`) для обработки трансформации данных и сопоставления из Kafka в целевую таблицу Manticore Search. Здесь вы определяете поля, преобразования данных и любые фильтры или условия для входящего потока данных. ## Источник @@ -23,11 +23,11 @@ Manticore поддерживает интеграцию с [Apache Kafka](https: CREATE SOURCE [(column type, ...)] [source_options] ``` -Все ключи схемы нечувствительны к регистру, то есть `Products`, `products` и `PrOdUcTs` считаются одинаковыми. Все они преобразуются в нижний регистр. +Все ключи схемы нечувствительны к регистру, то есть `Products`, `products` и `PrOdUcTs` считаются одинаковыми. Они все преобразуются в нижний регистр. -Если имена ваших полей не соответствуют [синтаксису имен полей](../Creating_a_table/Data_types.md#Field-name-syntax), разрешенному в Manticore Search (например, содержат специальные символы или начинаются с цифр), необходимо определить сопоставление схемы. Например, `$keyName` или `123field` являются допустимыми ключами в JSON, но недопустимыми именами полей в Manticore Search. Если попытаться использовать недопустимые имена полей без правильного сопоставления, Manticore вернет ошибку, и создание источника не удастся. +Если имена полей не соответствуют [синтаксису имён полей](../Creating_a_table/Data_types.md#Field-name-syntax), допустимому в Manticore Search (например, содержат специальные символы или начинаются с цифр), необходимо определить маппинг схемы. Например, `$keyName` или `123field` являются допустимыми ключами в JSON, но недопустимыми именами полей в Manticore Search. Если попытаться использовать недопустимые имена без корректного маппинга, Manticore выдаст ошибку, и создание источника не удастся. -Для таких случаев используйте следующий синтаксис схемы для сопоставления недопустимых имен полей с допустимыми: +Для таких случаев используйте следующий синтаксис схемы для сопоставления недопустимых имён с валидными: ``` allowed_field_name 'original JSON key name with special symbols' type @@ -61,25 +61,47 @@ batch=50 Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE SOURCE kafka (id bigint, term text, abbrev '$abbrev' text, GlossDef json) type='kafka' broker_list='kafka:9092' topic_list='my-data' consumer_group='manticore' num_consumers='2' batch=50" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + #### Опции -| Опция | Допустимые значения | Описание | +| Опция | Допустимые значения | Описание | |-|----------------|---------------------------------------------------------------------------------------------------------------------| -| `type` | `kafka` | Устанавливает тип источника. В настоящее время поддерживается только `kafka` | -| `broker_list` | `host:port [, ...]` | Указывает URL брокеров Kafka | -| `topic_list` | `string [, ...]` | Список тем Kafka для потребления | -| `consumer_group`| `string` | Определяет группу потребителей Kafka, по умолчанию `manticore`. | -| `num_consumers` | `int` | Количество потребителей для обработки сообщений. | -| `partition_list` | `int [, ...]` | Список партиций для чтения [подробнее](../Integration/Kafka.md#Sharding-with-Kafka). | -| `batch` | `int` | Количество сообщений для обработки перед переходом к следующей партии. По умолчанию `100`; в противном случае обрабатывает оставшиеся сообщения по таймауту | +| `type` | `kafka` | Устанавливает тип источника. В настоящее время поддерживается только `kafka`. | +| `broker_list` | `host:port [, ...]` | Указывает URL брокеров Kafka | +| `topic_list` | `string [, ...]` | Список топиков Kafka для чтения | +| `consumer_group`| `string` | Определяет группу потребителей Kafka, по умолчанию `manticore`. | +| `num_consumers` | `int` | Количество потребителей для обработки сообщений. | +| `partition_list` | `int [, ...]` | Список разделов для чтения [подробнее](../Integration/Kafka.md#Sharding-with-Kafka). | +| `batch` | `int` | Количество сообщений для обработки перед переходом дальше. По умолчанию `100`; по таймауту обрабатывает оставшиеся сообщения. | -### Таблица назначения +### Целевая таблица -Таблица назначения — это обычная таблица реального времени, в которой хранятся результаты обработки сообщений Kafka. Эта таблица должна быть определена в соответствии с требованиями схемы входящих данных и оптимизирована для производительности запросов вашего приложения. Подробнее о создании таблиц реального времени читайте [здесь](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:). +Целевая таблица — обычная таблица real-time, в которую записываются результаты обработки сообщений из Kafka. Эта таблица должна быть определена в соответствии с требованиями схемы поступающих данных и оптимизирована под нужды производительности запросов вашего приложения. Подробнее о создании real-time таблиц читайте [здесь](../Creating_a_table/Local_tables/Real-time_table.md#Creating-a-real-time-table:). @@ -98,15 +120,37 @@ CREATE TABLE destination_kafka Query OK, 0 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE TABLE destination_kafka (id bigint, name text, short_name text, received_at text, size multi)" +``` + + + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + ### Материализованное представление -Материализованное представление позволяет преобразовывать данные из сообщений Kafka. Вы можете переименовывать поля, применять функции Manticore Search, выполнять сортировку, группировку и другие операции с данными. +Материализованное представление позволяет трансформировать данные из сообщений Kafka. Вы можете переименовывать поля, применять функции Manticore Search, выполнять сортировку, группировку и другие операции с данными. -Материализованное представление действует как запрос, который перемещает данные из источника Kafka в таблицу назначения, позволяя использовать синтаксис Manticore Search для настройки этих запросов. Убедитесь, что поля в `select` соответствуют полям источника. +Материализованное представление выступает в роли запроса, который перемещает данные из Kafka-источника в целевую таблицу, позволяя использовать синтаксис Manticore Search для настройки таких запросов. Убедитесь, что поля в `select` соответствуют полям источника. ``` CREATE MATERIALIZED VIEW @@ -134,25 +178,47 @@ SELECT id, term as name, abbrev as short_name, Query OK, 2 rows affected (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + -Данные передаются из Kafka в Manticore Search партиями, которые очищаются после каждого запуска. Для вычислений по партиям, таких как AVG, будьте осторожны, так как они могут работать не так, как ожидается, из-за обработки по партиям. +Данные передаются из Kafka в Manticore Search пакетами, которые очищаются после каждого запуска. Для вычислений на основе нескольких пакетов, например AVG, будьте осторожны, так как такие операции могут некорректно работать из-за обработки по пакетам. ### Сопоставление полей -Вот таблица сопоставления на основе приведенных выше примеров: +Вот таблица сопоставлений на основе вышеуказанных примеров: -| Kafka | Источник | Буфер | MV | Назначение | -|-----------------|----------|----------|-----------------------------------|-------------| -| `id` | `id` | `id` | `id` | `id` | -| `term` | `term` | `term` | `term as name` | `name` | -| `unnecessary_key`, который нас не интересует | - | - | | | -| `$abbrev` | `abbrev` | `abbrev` | `abbrev` as `short_name` | `short_name` | -| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at` | +| Kafka | Источник | Буфер | MV | Целевой пункт | +|-------------------------------------|----------|----------|----------------------------------------|---------------| +| `id` | `id` | `id` | `id` | `id` | +| `term` | `term` | `term` | `term as name` | `name` | +| `unnecessary_key`, который нас не интересует | - | - | | | +| `$abbrev` | `abbrev` | `abbrev` | `abbrev as short_name` | `short_name` | +| - | - | - | `UTC_TIMESTAMP() as received_at` | `received_at` | | `GlossDef` | `glossdef` | `glossdef` | `glossdef.size as size` | `size` | -### Просмотр +### Список @@ -181,6 +247,40 @@ SHOW SOURCES +-------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCES" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "kafka" + } + ] + } +] +``` + @@ -212,6 +312,46 @@ SHOW SOURCE kafka; +--------+-------------------------------------------------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW SOURCE kafka" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "Source": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + } + ], + "data": [ + { + "Source": "kafka", + "Create Table": "CREATE SOURCE kafka \n(id bigint, term text, abbrev '' text, GlossDef json)\ntype='kafka'\nbroker_list='kafka:9092'\ntopic_list='my-data'\nconsumer_group='manticore'\nnum_consumers='2'\n batch=50" + } + ] + } +] +``` + @@ -236,6 +376,40 @@ SHOW MVS +------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SHOW MVS" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "name": "view_table" + } + ] + } +] +``` + @@ -262,17 +436,63 @@ SHOW MV view_table +------------+--------------------------------------------------------------------------------------------------------+-----------+ ``` + + +##### JSON: + + + +```sql +POST /sql?mode=raw -d "SHOW MV view_table" +``` + + + +```JSON +[ + { + "total": 1, + "error": "", + "warning": "", + "columns": [ + { + "View": { + "type": "string" + } + }, + { + "Create Table": { + "type": "string" + } + }, + { + "suspended": { + "type": "string" + } + } + ], + "data": [ + { + "View": "view_table", + "Create Table": "CREATE MATERIALIZED VIEW view_table TO destination_kafka AS SELECT id, term as name, abbrev as short_name, UTC_TIMESTAMP() as received_at, GlossDef.size as size FROM kafka", + "suspended": 0 + } + ] + } +] +``` + ### Изменение материализованных представлений -Вы можете приостановить потребление данных, изменяя материализованные представления. +Вы можете приостановить потребление данных, изменив материализованные представления. -Если вы удалите `source`, не удаляя MV, оно автоматически приостанавливается. После воссоздания источника снимите приостановку MV вручную с помощью команды `ALTER`. +Если удалить `source`, не удаляя MV, оно автоматически приостанавливается. После воссоздания источника отмените приостановку MV вручную с помощью команды `ALTER`. -В настоящее время можно изменять только материализованные представления. Чтобы изменить параметры `source`, удалите и создайте источник заново. +В настоящее время изменять можно только материализованные представления. Чтобы изменить параметры `source`, удалите и создайте источник заново. @@ -290,13 +510,35 @@ ALTER MATERIALIZED VIEW view_table suspended=1 Query OK (0.02 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "ALTER MATERIALIZED VIEW view_table suspended=1" +``` + + + +```JSON +[ + { + "total": 2, + "error": "", + "warning": "" + } +] +``` + ### Шардинг с Kafka Вы также можете указать `partition_list` для каждой темы Kafka. Одним из основных преимуществ такого подхода является возможность реализовать `sharding` для вашей таблицы через Kafka. -Для этого следует создать отдельную цепочку `source` → `materialized view` → `destination table` для каждого шарда: +Для этого вы должны создать отдельную цепочку `source` → `materialized view` → `destination table` для каждого шарда: **Источники:** ```sql @@ -325,29 +567,29 @@ CREATE MATERIALIZED VIEW mv_2 TO destination_shard_2 AS SELECT id, term AS name #### ⚠️ Важные замечания: -* В этой конфигурации ребалансировка должна управляться вручную. -* По умолчанию Kafka не распределяет сообщения по принципу round-robin. -* Чтобы добиться распределения, похожего на round-robin при отправке данных, убедитесь, что ваш Kafka producer настроен с: +* В этой конфигурации балансировка нагрузки должна выполняться вручную. +* Kafka по умолчанию не распределяет сообщения по круговой (round-robin) стратегии. +* Чтобы добиться распределения, похожего на round-robin, при отправке данных, убедитесь, что ваш Kafka producer настроен с: * `parse.key=true` * `key.separator={your_delimiter}` -В противном случае Kafka будет распределять сообщения согласно своим внутренним правилам, что может привести к неравномерному распределению по партициям. +Иначе Kafka будет распределять сообщения по своим внутренним правилам, что может привести к неравномерному разбиению по партициям. ### Устранение неполадок #### Дублирование записей -Коммиты смещений Kafka происходят после каждой партии или при истечении времени обработки. Если процесс неожиданно остановится во время запроса к материализованному представлению, вы можете увидеть дублирующиеся записи. Чтобы этого избежать, включите поле `id` в вашу схему, что позволит Manticore Search предотвращать дублирование в таблице. +Фиксация offset’ов Kafka происходит после каждой партии или при таймауте обработки. Если процесс прервался неожиданно во время запроса к материализованному представлению, могут появиться дублирующиеся записи. Чтобы избежать этого, добавьте поле `id` в схему, что позволит Manticore Search предотвращать дубликаты в таблице. -### Как это работает внутри +### Как это работает внутренне -- **Инициализация воркера:** После настройки источника и материализованного представления Manticore Search запускает выделенного воркера для обработки данных из Kafka. +- **Инициализация рабочего процесса:** После настройки источника и материализованного представления Manticore Search запускает выделенного рабочего для обработки приема данных из Kafka. - **Отображение сообщений:** Сообщения сопоставляются согласно схеме конфигурации источника, преобразуясь в структурированный формат. -- **Группировка:** Сообщения группируются в партии для эффективной обработки. Размер партии можно настроить под ваши требования по производительности и задержке. -- **Буферизация:** Партии отображенных данных сохраняются в буферной таблице для эффективных пакетных операций. -- **Обработка материализованного представления:** Логика представления применяется к данным в буферной таблице, выполняя необходимые преобразования или фильтрацию. -- **Передача данных:** Обработанные данные затем передаются в целевую таблицу реального времени. -- **Очистка:** Буферная таблица очищается после каждой партии, чтобы быть готовой к следующему набору данных. +- **Формирование партий:** Сообщения группируются в партии для эффективной обработки. Размер партии можно настраивать в зависимости от требований к производительности и задержке. +- **Буферизация:** Партии отображенных данных сохраняются в буферной таблице для эффективных операций пакетной обработки. +- **Обработка материализованного представления:** К данным в буферной таблице применяется логика представления, выполняются необходимые преобразования и фильтрация. +- **Передача данных:** Обработанные данные передаются в целевую таблицу реального времени. +- **Очистка:** Буферная таблица очищается после каждой партии, готовясь к обработке следующего набора данных. diff --git a/manual/russian/Listing_tables.md b/manual/russian/Listing_tables.md index b70840222a..758197b890 100644 --- a/manual/russian/Listing_tables.md +++ b/manual/russian/Listing_tables.md @@ -2,7 +2,7 @@ Manticore Search имеет один уровень иерархии для таблиц. -В отличие от других СУБД, в Manticore нет концепции группировки таблиц в базы данных. Однако, для совместимости с диалектами SQL, Manticore принимает операторы `SHOW DATABASES` для совместимости с диалектом SQL, но оператор не возвращает никаких результатов. +В отличие от других СУБД, в Manticore отсутствует концепция группировки таблиц в базы данных. Тем не менее, для совместимости с диалектами SQL, Manticore принимает операторы `SHOW DATABASES`, но оператор не возвращает никаких результатов. ## SHOW TABLES @@ -13,7 +13,7 @@ Manticore Search имеет один уровень иерархии для та SHOW TABLES [ LIKE pattern ] ``` -Оператор `SHOW TABLES` выводит список всех активных в данный момент таблиц вместе с их типами. Существующие типы таблиц: `local`, `distributed`, `rt`, `percolate` и `template`. +Оператор `SHOW TABLES` выводит все текущие активные таблицы вместе с их типами. Существующие типы таблиц: `local`, `distributed`, `rt`, `percolate` и `template`. @@ -40,6 +40,56 @@ SHOW TABLES; 5 rows in set (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW TABLES" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "dist", + "Type": "distributed" + }, + { + "Table": "plain", + "Type": "local" + }, + { + "Table": "pq", + "Type": "percolate" + },{ + "Table": "rt", + "Type": "rt" + },{ + "Table": "template", + "Type": "template" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] + +``` + + ```php @@ -158,7 +208,7 @@ utils_api.sql("SHOW TABLES", Some(true)).await -Поддерживается необязательный оператор LIKE для фильтрации таблиц по имени. +Опциональное условие LIKE поддерживается для фильтрации таблиц по имени. @@ -181,6 +231,41 @@ SHOW TABLES LIKE 'pro%'; 1 row in set (0.00 sec) ``` + + +```sql +POST /sql?mode=raw -d "SHOW TABLES LIKE 'pro%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Table": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + } + ], + "data": [ + { + "Table": "products", + "Type": "distributed" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ```php @@ -302,7 +387,7 @@ utils_api.sql("SHOW TABLES LIKE 'pro%'", Some(true)).await {DESC | DESCRIBE} table_name [ LIKE pattern ] ``` -Оператор `DESCRIBE` выводит столбцы таблицы и их соответствующие типы. Столбцы включают ID документа, полнотекстовые поля и атрибуты. Порядок соответствует порядку, в котором поля и атрибуты ожидаются в операторах `INSERT` и `REPLACE`. Типы столбцов включают `field`, `integer`, `timestamp`, `ordinal`, `bool`, `float`, `bigint`, `string` и `mva`. Столбец ID будет иметь тип `bigint`. Пример: +Оператор `DESCRIBE` выводит столбцы таблицы и их сопутствующие типы. Столбцы — это идентификатор документа, полнотекстовые поля и атрибуты. Порядок совпадает с порядком, в котором поля и атрибуты ожидаются в операторах `INSERT` и `REPLACE`. Типы столбцов включают `field`, `integer`, `timestamp`, `ordinal`, `bool`, `float`, `bigint`, `string` и `mva`. Столбец ID будет иметь тип `bigint`. Пример: ```sql mysql> DESC rt; @@ -317,13 +402,13 @@ mysql> DESC rt; 4 rows in set (0.00 sec) ``` -Поддерживается необязательный оператор LIKE. Обратитесь к +Опциональное условие LIKE поддерживается. Обратитесь к [SHOW META](Node_info_and_management/SHOW_META.md) для деталей синтаксиса. ### SELECT FROM name.@table -Вы также можете просмотреть схему таблицы, выполнив запрос `select * from .@table`. Преимущество этого метода в том, что вы можете использовать оператор `WHERE` для фильтрации: +Вы также можете просмотреть схему таблицы, выполнив запрос `select * from .@table`. Преимущество этого метода в том, что вы можете использовать условие `WHERE` для фильтрации: ```sql @@ -340,11 +425,29 @@ select * from tbl.@table where type='text'; 1 row in set (0.00 sec) ``` + +```sql +POST /sql?mode=raw -d "select * from tbl.@table where type='text';" +``` + + +```JSON +[{ +"columns":[{"id":{"type":"long long"}},{"field":{"type":"string"}},{"type":{"type":"string"}},{"properties":{"type":"string"}}], +"data":[ +{"id":2,"field":"title","type":"text","properties":"indexed stored"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + -Вы также можете выполнять многие другие действия с `.@table`, рассматривая её как обычную таблицу Manticore с колонками, состоящими из целочисленных и строковых атрибутов. +Вы также можете выполнять многие другие действия с `.@table`, рассматривая его как обычную таблицу Manticore с колонками, состоящими из целочисленных и строковых атрибутов. @@ -354,6 +457,14 @@ select field, properties from tbl.@table where type in ('text', 'uint'); select * from tbl.@table where properties any ('stored'); ``` + + +```JSON +POST /sql?mode=raw -d "select field from tbl.@table;" +POST /sql?mode=raw -d "select field, properties from tbl.@table where type in ('text', 'uint');" +POST /sql?mode=raw -d "select * from tbl.@table where properties any ('stored');" +``` + ## SHOW CREATE TABLE @@ -381,11 +492,33 @@ f text indexed stored ) charset_table='non_cont,cont' morphology='icu_chinese' 1 row in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW CREATE TABLE tbl;" +``` + + +```JSON +[{ +"columns":[{"Table":{"type":"string"}},{"Create Table":{"type":"string"}}], +"data":[ +{"Table":"tbl","Create Table":"CREATE TABLE tbl (\nf text)"} +], +"total":1, +"error":"", +"warning":"" +}] +``` + ### Схемы таблиц Percolate -Если вы используете оператор `DESC` для таблицы percolate, он отобразит схему внешней таблицы, которая является схемой сохранённых запросов. Эта схема статична и одинакова для всех локальных таблиц percolate: +Если использовать оператор `DESC` для percolate-таблицы, будет показана схема внешней таблицы, которая представляет собой схему сохранённых запросов. Эта схема статична и одинакова для всех локальных percolate-таблиц: ```sql mysql> DESC pq; @@ -400,7 +533,7 @@ mysql> DESC pq; 4 rows in set (0.00 sec) ``` -Если вы хотите просмотреть ожидаемую схему документа, используйте следующую команду: +Если вы хотите посмотреть ожидаемую схему документа, используйте следующую команду: `DESC table`: ```sql diff --git a/manual/russian/Node_info_and_management/KILL.md b/manual/russian/Node_info_and_management/KILL.md index cdd51fefa0..dfccbb7d08 100644 --- a/manual/russian/Node_info_and_management/KILL.md +++ b/manual/russian/Node_info_and_management/KILL.md @@ -13,6 +13,18 @@ mysql> KILL 4; Query OK, 1 row affected (0.00 sec) ``` + +```JSON +POST /sql?mode=raw -d "KILL 4" +[ + { + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Node_info_and_management/Node_status.md b/manual/russian/Node_info_and_management/Node_status.md index be32b97abc..70646022ae 100644 --- a/manual/russian/Node_info_and_management/Node_status.md +++ b/manual/russian/Node_info_and_management/Node_status.md @@ -3,7 +3,7 @@ ## STATUS -Самый простой способ получить общую информацию о вашем узле Manticore — выполнить команду `status` в клиенте MySQL. Она отобразит информацию о различных аспектах, таких как: +Самый простой способ просмотреть основную информацию о вашем узле Manticore — выполнить команду `status` в клиенте MySQL. Она отобразит информацию о различных аспектах, таких как: * Текущая версия * Используется ли SSL или нет * Текущий TCP порт/Unix сокет @@ -13,15 +13,15 @@ * Количество подключений (`clients`) * Количество задач, обрабатываемых в данный момент * Количество выполненных запросов с момента запуска -* Количество заданий в очереди и количество задач, нормализованное по количеству потоков +* Количество заданий в очереди и количество задач, нормализованных по количеству потоков -```sql +```mysql mysql> status ``` -```sql +```mysql -------------- mysql Ver 14.14 Distrib 5.7.30, for Linux (x86_64) using EditLine wrapper @@ -58,7 +58,7 @@ SHOW STATUS [ LIKE pattern ] -`SHOW STATUS` — это SQL-запрос, который показывает различные полезные счетчики производительности. Счетчики ввода-вывода и CPU будут доступны только если `searchd` был запущен с ключами `--iostats` и `--cpustats` соответственно (или если они были включены через `SET GLOBAL iostats/cpustats=1`). +`SHOW STATUS` — это SQL-запрос, который отображает различные полезные счетчики производительности. Счетчики ввода-вывода и процессора будут доступны только если `searchd` был запущен с переключателями `--iostats` и `--cpustats` соответственно (или если они были включены через `SET GLOBAL iostats/cpustats=1`). ##### SQL: @@ -151,11 +151,344 @@ SHOW STATUS; +-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+ ``` + +##### JSON: + + +```JSON +SHOW STATUS; +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "uptime", + "Value": "107191" + }, + { + "Counter": "connections", + "Value": "214577" + }, + { + "Counter": "maxed_out", + "Value": "0" + }, + { + "Counter": "version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1) (buddy v3.35.1+25090418-41d9811f-dev)" + }, + { + "Counter": "mysql_version", + "Value": "13.13.4 0bc5a9641@25101507 dev (columnar 8.1.0 e1522a2@25100213) (secondary 8.1.0 e1522a2@25100213) (knn 8.1.0 e1522a2@25100213) (embeddings 1.0.1)" + }, + { + "Counter": "command_search", + "Value": "47" + }, + { + "Counter": "command_excerpt", + "Value": "3" + }, + { + "Counter": "command_update", + "Value": "0" + }, + { + "Counter": "command_keywords", + "Value": "0" + }, + { + "Counter": "command_persist", + "Value": "0" + }, + { + "Counter": "command_status", + "Value": "361" + }, + { + "Counter": "command_flushattrs", + "Value": "0" + }, + { + "Counter": "command_sphinxql", + "Value": "0" + }, + { + "Counter": "command_ping", + "Value": "0" + }, + { + "Counter": "command_delete", + "Value": "1" + }, + { + "Counter": "command_set", + "Value": "0" + }, + { + "Counter": "command_insert", + "Value": "13" + }, + { + "Counter": "command_replace", + "Value": "0" + }, + { + "Counter": "command_commit", + "Value": "0" + }, + { + "Counter": "command_suggest", + "Value": "0" + }, + { + "Counter": "command_json", + "Value": "0" + }, + { + "Counter": "command_callpq", + "Value": "8" + }, + { + "Counter": "command_cluster", + "Value": "0" + }, + { + "Counter": "command_getfield", + "Value": "0" + }, + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "agent_connect", + "Value": "0" + }, + { + "Counter": "agent_tfo", + "Value": "0" + }, + { + "Counter": "agent_retry", + "Value": "0" + }, + { + "Counter": "queries", + "Value": "44" + }, + { + "Counter": "dist_queries", + "Value": "0" + }, + { + "Counter": "workers_total", + "Value": "8" + }, + { + "Counter": "workers_active", + "Value": "3" + }, + { + "Counter": "workers_clients", + "Value": "1" + }, + { + "Counter": "workers_clients_vip", + "Value": "0" + }, + { + "Counter": "workers_clients_buddy", + "Value": "1" + }, + { + "Counter": "work_queue_length", + "Value": "8" + }, + { + "Counter": "load", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_primary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "load_secondary", + "Value": "0.00 0.00 0.00" + }, + { + "Counter": "query_wall", + "Value": "0.007" + }, + { + "Counter": "query_cpu", + "Value": "OFF" + }, + { + "Counter": "dist_wall", + "Value": "0.000" + }, + { + "Counter": "dist_local", + "Value": "0.000" + }, + { + "Counter": "dist_wait", + "Value": "0.000" + }, + { + "Counter": "query_reads", + "Value": "OFF" + }, + { + "Counter": "query_readkb", + "Value": "OFF" + }, + { + "Counter": "query_readtime", + "Value": "OFF" + }, + { + "Counter": "avg_query_wall", + "Value": "0.000" + }, + { + "Counter": "avg_query_cpu", + "Value": "OFF" + }, + { + "Counter": "avg_dist_wall", + "Value": "0.000" + }, + { + "Counter": "avg_dist_local", + "Value": "0.000" + }, + { + "Counter": "avg_dist_wait", + "Value": "0.000" + }, + { + "Counter": "avg_query_reads", + "Value": "OFF" + }, + { + "Counter": "avg_query_readkb", + "Value": "OFF" + }, + { + "Counter": "avg_query_readtime", + "Value": "OFF" + }, + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 75, + "error": "", + "warning": "" + } +] +``` + -Поддерживается необязательный оператор `LIKE`, позволяющий выбрать только переменные, соответствующие определенному шаблону. Синтаксис шаблона соответствует стандартным SQL-джокерам, где `%` означает любое количество любых символов, а `_` — один символ. +Поддерживается необязательный оператор `LIKE`, который позволяет выбрать только переменные, соответствующие определенному шаблону. Синтаксис шаблона соответствует стандартным SQL-символам подстановки, где `%` обозначает любое количество любых символов, а `_` — один символ. @@ -177,6 +510,61 @@ SHOW STATUS LIKE 'qcache%'; +-----------------------+-------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE 'qcache%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "qcache_max_bytes", + "Value": "16777216" + }, + { + "Counter": "qcache_thresh_msec", + "Value": "3000" + }, + { + "Counter": "qcache_ttl_sec", + "Value": "60" + }, + { + "Counter": "qcache_cached_queries", + "Value": "0" + }, + { + "Counter": "qcache_used_bytes", + "Value": "0" + }, + { + "Counter": "qcache_hits", + "Value": "0" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + ```sql @@ -206,26 +594,116 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` -### Статистика времени запросов +### Статистика времени выполнения запросов -Команда `SHOW STATUS` предоставляет подробный отчет о различных показателях производительности в Manticore, включая статистику времени запросов для insert/replace, search и update запросов. Эти статистики рассчитываются за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили времени запросов. +Команда `SHOW STATUS` предоставляет детальный отчет о различных показателях производительности в Manticore, включая статистику времени выполнения для запросов insert/replace, search и update. Эти статистики рассчитываются за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95%/99%-ные перцентили времени выполнения запросов. Эти метрики помогают отслеживать производительность за определенные интервалы времени, что облегчает выявление тенденций в времени отклика запросов и поиск возможных узких мест. Следующие метрики входят в вывод `SHOW STATUS`: -- `*_avg`: Среднее время запроса для каждого типа запросов за последние 1, 5 и 15 минут. -- `*_min`: Самое короткое время запроса, зафиксированное для каждого типа запросов. -- `*_max`: Самое длинное время запроса, зафиксированное для каждого типа запросов. -- `*_pct95`: Время, в течение которого выполняются 95% запросов. -- `*_pct99`: Время, в течение которого выполняются 99% запросов. +- `*_avg`: Среднее время выполнения запроса для каждого типа запросов за последние 1, 5 и 15 минут. +- `*_min`: Самое короткое время выполнения запроса для каждого типа запросов. +- `*_max`: Самое долгое время выполнения запроса для каждого типа запросов. +- `*_pct95`: Время, в течение которого выполнено 95% запросов. +- `*_pct99`: Время, в течение которого выполнено 99% запросов. -Эти статистики предоставляются отдельно для insert/replace (`insert_replace_stats_*`), search (`search_stats_*`) и update (`update_stats_*`) запросов, что дает детальное представление о производительности различных операций. +Эти статистики предоставляются отдельно для insert/replace (`insert_replace_stats_*`), search (`search_stats_*`) и update (`update_stats_*`) запросов, предоставляя исчерпывающую информацию о производительности различных операций. -Если в течение контролируемого интервала запросы не выполнялись, система отобразит `N/A`. +Если в течение контролируемого интервала не выполняются запросы, система отобразит `N/A`. @@ -256,13 +734,104 @@ SHOW STATUS LIKE '%stats_ms%'; +-------------------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SHOW STATUS LIKE '%stats_ms%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Counter": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Counter": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Counter": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 15, + "error": "", + "warning": "" + } +] +``` + ## SHOW SETTINGS -`SHOW SETTINGS` — это SQL-запрос, который отображает текущие настройки из вашего конфигурационного файла. Имена настроек представлены в формате: `'config_section_name'.'setting_name'` +`SHOW SETTINGS` — это SQL-запрос, который выводит текущие настройки из вашего конфигурационного файла. Имена настроек представлены в формате: `'config_section_name'.'setting_name'` Результат также включает два дополнительных значения: - `configuration_file` — путь к конфигурационному файлу @@ -298,6 +867,83 @@ SHOW SETTINGS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Setting_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Setting_name": "configuration_file", + "Value": "/etc/manticoresearch/manticore.conf.sh" + }, + { + "Setting_name": "worker_pid", + "Value": 1 + }, + { + "Setting_name": "searchd.listen", + "Value": "9306:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "/var/run/mysqld/mysqld.sock:mysql41" + }, + { + "Setting_name": "searchd.listen", + "Value": "9308:http" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9312" + }, + { + "Setting_name": "searchd.listen", + "Value": "172.17.0.2:9315-9325:replication" + }, + { + "Setting_name": "searchd.pid_file", + "Value": "/run/manticore/searchd.pid" + }, + { + "Setting_name": "searchd.data_dir", + "Value": "/var/lib/manticore" + }, + { + "Setting_name": "searchd.binlog_path", + "Value": "/var/lib/manticore/binlog" + }, + { + "Setting_name": "common.plugin_dir", + "Value": "/usr/local/lib/manticore" + } + ], + "total": 11, + "error": "", + "warning": "" + } +] +``` + ## SHOW AGENT STATUS @@ -307,7 +953,7 @@ SHOW AGENT ['agent_or_index'] STATUS [ LIKE pattern ] -`SHOW AGENT STATUS` отображает статистику [удаленных агентов](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) или распределенной таблицы. Включает такие значения, как время с последнего запроса, последнего ответа, количество различных типов ошибок и успешных операций и т.д. Статистика отображается для каждого агента за последние интервалы 1, 5 и 15, каждый из которых состоит из [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) секунд. +`SHOW AGENT STATUS` отображает статистику [удаленных агентов](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#agent) или распределенной таблицы. Включает такие значения, как возраст последнего запроса, последний ответ, количество различных типов ошибок и успешных ответов и так далее. Статистика отображается для каждого агента за последние интервалы в 1, 5 и 15, каждый из которых состоит из [ha_period_karma](../Server_settings/Searchd.md#ha_period_karma) секунд. ##### SQL: @@ -378,6 +1024,47 @@ SHOW AGENT STATUS; 50 rows in set (0.01 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "status_period_seconds", + "Value": "60" + }, + { + "Key": "status_stored_periods", + "Value": "15" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1022,7 +1709,7 @@ res := apiClient.UtilsAPI.Sql(context.Background()).Body("SHOW AGENT STATUS").Ex -Поддерживается необязательный оператор `LIKE`, синтаксис которого такой же, как в `SHOW STATUS`. +Поддерживается необязательный оператор `LIKE` с синтаксисом, аналогичным `SHOW STATUS`. ##### SQL: @@ -1044,6 +1731,51 @@ SHOW AGENT STATUS LIKE '%5period%msec%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT STATUS LIKE '%5period%msec%';" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "ag_0_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_1_5periods_msecsperquery", + "Value": "234.72" + }, + { + "Key": "ag_2_5periods_msecsperquery", + "Value": "234.72" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1295,6 +2027,76 @@ SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%'; 9 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql? mode=raw -d "SHOW AGENT '192.168.0.202:6714' STATUS LIKE '%15periods%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "agent_15periods_query_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_timeouts", + "Value": "0" + }, + { + "Key": "agent_15periods_connect_failures", + "Value": "0" + }, + { + "Key": "agent_15periods_network_errors", + "Value": "0" + }, + { + "Key": "agent_15periods_wrong_replies", + "Value": "0" + }, + { + "Key": "agent_15periods_unexpected_closings", + "Value": "0" + }, + { + "Key": "agent_15periods_warnings", + "Value": "0" + }, + { + "Key": "agent_15periods_succeeded_queries", + "Value": "439" + }, + { + "Key": "agent_15periods_msecsperquery", + "Value": "231.73" + } + ], + "total": 9, + "error": "", + "warning": "" + } +] +``` + ##### PHP: @@ -1615,6 +2417,91 @@ SHOW AGENT dist_index STATUS; 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW AGENT dist_index STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Key": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Key": "dstindex_1_is_ha", + "Value": "1" + }, + { + "Key": "dstindex_1mirror1_id", + "Value": "192.168.0.202:6713:loc" + }, + { + "Key": "dstindex_1mirror1_probability_weight", + "Value": "0.372864" + }, + { + "Key": "dstindex_1mirror1_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror1_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_id", + "Value": "192.168.0.202:6714:loc" + }, + { + "Key": "dstindex_1mirror2_probability_weight", + "Value": "0.3746350" + }, + { + "Key": "dstindex_1mirror2_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror2_is_persistent", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_id", + "Value": "dev1.manticoresearch.com:6714:loc" + }, + { + "Key": "dstindex_1mirror3_probability_weight", + "Value": "0.252501" + }, + { + "Key": "dstindex_1mirror3_is_blackhole", + "Value": "0" + }, + { + "Key": "dstindex_1mirror3_is_persistent", + "Value": "0" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/russian/Node_info_and_management/SHOW_META.md b/manual/russian/Node_info_and_management/SHOW_META.md index a906672a6b..16bbd7820d 100644 --- a/manual/russian/Node_info_and_management/SHOW_META.md +++ b/manual/russian/Node_info_and_management/SHOW_META.md @@ -5,20 +5,20 @@ SHOW META [ LIKE pattern ] ``` -`SHOW META` — это SQL-запрос, который отображает дополнительную метаинформацию о выполненном запросе, включая время выполнения запроса, статистику по ключевым словам и информацию о используемых вторичных индексах. Синтаксис: +`SHOW META` — это SQL-оператор, который отображает дополнительную мета-информацию о выполненном запросе, включая время выполнения запроса, статистику по ключевым словам и информацию о вторичных индексах, использованных в запросе. Синтаксис: Включённые элементы: -* `total`: Количество совпадений, которые фактически были извлечены и отправлены клиенту. Это значение обычно ограничивается опцией поиска [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results). +* `total`: Количество совпадений, которые были фактически извлечены и отправлены клиенту. Обычно это значение ограничивается опцией поиска [LIMIT/size](../Searching/Pagination.md#Pagination-of-search-results). * `total_found`: - - Оценочное общее количество совпадений для запроса в индексе. Если вам нужно точное количество совпадений, используйте `SELECT COUNT(*)` вместо опоры на это значение. - - Для запросов с `GROUP BY` `total_found` представляет количество групп, а не отдельных совпадений. - - Для запросов [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) `total_found` по-прежнему представляет количество групп, независимо от значения `N`. -* `total_relation`: Указывает, является ли значение `total_found` точным или оценочным. + - Оценочное общее количество совпадений для запроса в индексе. Если требуется точное количество совпадений, используйте `SELECT COUNT(*)`, вместо того чтобы полагаться на это значение. + - Для запросов с `GROUP BY`, `total_found` представляет количество групп, а не отдельных совпадений. + - Для запросов типа [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) `total_found` всё равно представляет количество групп, независимо от значения `N`. +* `total_relation`: Показывает, является ли значение `total_found` точным или оценочным. - Если Manticore не может определить точное значение `total_found`, в этом поле будет отображено `total_relation: gte`, что означает, что фактическое количество совпадений **больше или равно** указанному `total_found`. - - Если значение `total_found` точное, будет отображено `total_relation: eq`. + - Если значение `total_found` точно, будет отображено `total_relation: eq`. * `time`: Время (в секундах), затраченное на обработку поискового запроса. -* `keyword[N]`: n-й ключевой запрос, использованный в поисковом запросе. Обратите внимание, что ключевое слово может быть представлено с использованием подстановочного знака, например, `abc*`. -* `docs[N]`: Общее количество документов (или записей), содержащих n-й ключевой запрос из поискового запроса. Если ключевое слово представлено с подстановочным знаком, это значение представляет сумму документов для всех расширенных подзапросов, что может превышать фактическое количество совпавших документов. +* `keyword[N]`: n-й ключевой запрос, использованный в поиске. Обратите внимание, что ключевое слово может быть представлено с использованием подстановочного знака, например, `abc*`. +* `docs[N]`: Общее количество документов (или записей), содержащих n-ое ключевое слово из поискового запроса. Если ключевое слово представлено подстановочным знаком, это значение представляет сумму документов для всех расширенных подключей, что может превышать фактическое количество совпадающих документов. * `hits[N]`: Общее количество вхождений (или попаданий) n-го ключевого слова во всех документах. * `index`: Информация об используемом индексе (например, вторичном индексе). @@ -66,10 +66,140 @@ show meta; 14 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +SELECT id, story_author FROM hn_small WHERE MATCH('one|two|three') and comment_ranking > 2 limit 5; +show meta; +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 151171, + "story_author": "anewkid" + }, + { + "id": 302758, + "story_author": "bks" + }, + { + "id": 805806, + "story_author": "drRoflol" + }, + { + "id": 1099245, + "story_author": "tnorthcutt" + }, + { + "id": 303252, + "story_author": "whiten" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "2308" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + }, + { + "Variable_name": "index", + "Value": "comment_ranking:SecondaryIndex (100%)" + } + ], + "total": 14, + "error": "", + "warning": "" + } +] +``` + -`SHOW META` может отображать счётчики ввода-вывода и CPU, но они будут доступны только если searchd был запущен с переключателями `--iostats` и `--cpustats` соответственно. +`SHOW META` может показывать счётчики ввода/вывода и процессора, но они будут доступны только, если searchd был запущен с переключателями `--iostats` и `--cpustats` соответственно. ##### SQL: @@ -129,10 +259,191 @@ SHOW META; 27 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,channel_id FROM records WHERE MATCH('one|two|three') limit 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.001" + }, + { + "Variable_name": "cpu_time", + "Value": "18.004" + }, + { + "Variable_name": "agents_cpu_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "io_read_ops", + "Value": "0" + }, + { + "Variable_name": "io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "io_write_ops", + "Value": "0" + }, + { + "Variable_name": "io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_read_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_read_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_read_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "agent_io_write_time", + "Value": "0.000" + }, + { + "Variable_name": "agent_io_write_ops", + "Value": "0" + }, + { + "Variable_name": "agent_io_write_kbytes", + "Value": "0.0" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 27, + "error": "", + "warning": "" + } +] +``` + -Дополнительные значения, такие как `predicted_time`, `dist_predicted_time`, `local_fetched_docs`, `local_fetched_hits`, `local_fetched_skips` и их соответствующие аналоги `dist_fetched_*`, будут доступны только если `searchd` был настроен с [предсказанными затратами времени](../Server_settings/Searchd.md#predicted_time_costs) и запрос включал `predicted_time` в опции `OPTION`. +Дополнительные значения, такие как `predicted_time`, `dist_predicted_time`, `local_fetched_docs`, `local_fetched_hits`, `local_fetched_skips` и соответствующие им `dist_fetched_*` значения будут доступны только если `searchd` был сконфигурирован с [предсказанными временными затратами](../Server_settings/Searchd.md#predicted_time_costs) и запрос включал `predicted_time` в разделе `OPTION`. ##### SQL: @@ -183,11 +494,152 @@ mysql> show meta; 17 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') limit 5 option max_predicted_time=100; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.012" + }, + { + "Variable_name": "local_fetched_docs", + "Value": "307212" + }, + { + "Variable_name": "local_fetched_hits", + "Value": "407390" + }, + { + "Variable_name": "local_fetched_skips", + "Value": "24" + }, + { + "Variable_name": "predicted_time", + "Value": "56" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 17, + "error": "", + "warning": "" + } +] +``` + -`SHOW META` должен выполняться сразу после запроса в **той же** сессии. Поскольку некоторые MySQL-коннекторы/библиотеки используют пулы соединений, выполнение `SHOW META` в отдельном запросе может привести к неожиданным результатам, например, получению метаданных другого запроса. В таких случаях (и в общем случае рекомендуется) выполняйте множественный запрос, содержащий и сам запрос, и `SHOW META`. Некоторые коннекторы/библиотеки поддерживают мультизапросы в одном методе для одного запроса, в то время как другие могут требовать использования специального метода для мультизапросов или установки определённых опций при настройке соединения. +`SHOW META` должен выполняться сразу после запроса в **той же** сессии. Поскольку некоторые MySQL-коннекторы/библиотеки используют пулы соединений, выполнение `SHOW META` в отдельном операторе может привести к непредвиденным результатам, таким как получение метаданных другого запроса. В таких случаях (и вообще рекомендуется) выполняйте многооператорный запрос, содержащий и запрос, и `SHOW META`. Некоторые коннекторы/библиотеки поддерживают мультизапросы в пределах одного вызова метода, в то время как другим может потребоваться использовать специализированный метод для мультизапросов или настроить определённые параметры при установке соединения. ##### SQL: @@ -231,11 +683,136 @@ SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW 13 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT id,story_author FROM hn_small WHERE MATCH('one|two|three') LIMIT 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "story_author": { + "type": "string" + } + } + ], + "data": [ + { + "id": 300263, + "story_author": "throwaway37" + }, + { + "id": 713503, + "story_author": "mahmud" + }, + { + "id": 716804, + "story_author": "mahmud" + }, + { + "id": 776906, + "story_author": "jimbokun" + }, + { + "id": 753332, + "story_author": "foxhop" + } + ], + "total": 5, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.011" + }, + { + "Variable_name": "keyword[0]", + "Value": "one" + }, + { + "Variable_name": "docs[0]", + "Value": "224387" + }, + { + "Variable_name": "hits[0]", + "Value": "310327" + }, + { + "Variable_name": "keyword[1]", + "Value": "three" + }, + { + "Variable_name": "docs[1]", + "Value": "18181" + }, + { + "Variable_name": "hits[1]", + "Value": "21102" + }, + { + "Variable_name": "keyword[2]", + "Value": "two" + }, + { + "Variable_name": "docs[2]", + "Value": "63251" + }, + { + "Variable_name": "hits[2]", + "Value": "75961" + } + ], + "total": 13, + "error": "", + "warning": "" + } +] +``` + -Вы также можете использовать необязательное выражение LIKE, которое позволяет выбрать только переменные, соответствующие определённому шаблону. Синтаксис шаблона соответствует стандартным SQL-подстановочным знакам, где `%` обозначает любое количество любых символов, а `_` — один символ. +Вы также можете использовать необязательный оператор LIKE, который позволяет выбирать только переменные, соответствующие определённому шаблону. Синтаксис шаблона выполняется по стандартным SQL-подстановочным знакам, где `%` означает любое количество любых символов, а `_` соответствует одному символу. ##### SQL: @@ -258,13 +835,59 @@ SHOW META LIKE 'total%'; 3 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW META LIKE 'total%';" +``` + + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "5" + }, + { + "Variable_name": "total_found", + "Value": "266385" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ## SHOW META и фасеты -При использовании [фасетного поиска](../Searching/Faceted_search.md) вы можете проверить поле `multiplier` в выводе `SHOW META`, чтобы определить, сколько запросов было выполнено в оптимизированной группе. +При использовании [фасетного поиска](../Searching/Faceted_search.md) в выводе `SHOW META` вы можете посмотреть поле `multiplier`, чтобы узнать, сколько запросов было выполнено в оптимизированной группе. ##### SQL: @@ -310,15 +933,143 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + } + ... + ], + "total": 1013, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 1, + "count(*)": 7 + } + ... + ], + "total": 658, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": 10, + "count(*)": 2436 + } + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## SHOW META и оптимизатор запросов -Когда [оптимизатор запросов на основе стоимости](../Searching/Cost_based_optimizer.md) выбирает использование `DocidIndex`, `ColumnarScan` или `SecondaryIndex` вместо простого фильтра, это отражается в команде `SHOW META`. +Когда [оптимизатор запросов на основе стоимости](../Searching/Cost_based_optimizer.md) выбирает использовать `DocidIndex`, `ColumnarScan` или `SecondaryIndex` вместо простого фильтра, это отображается в команде `SHOW META`. -Переменная `index` отображает имена и типы вторичных индексов, использованных во время выполнения запроса. Процент указывает, сколько дисковых чанков (в случае RT-таблицы) или псевдо-шард (в случае простой таблицы) использовали вторичный индекс. +Переменная `index` показывает имена и типы вторичных индексов, использованных при выполнении запроса. Процент указывает, сколько дисковых чанков (для RT-таблицы) или псевдо-шард (для простой таблицы) использовали вторичный индекс. ##### SQL: @@ -344,21 +1095,92 @@ SHOW META; 5 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SELECT count(*) FROM taxi1 WHERE tip_amount = 5; SHOW META;" +``` + + + +```JSON +[ + { + "columns": [ + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "count(*)": 1 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "eq" + }, + { + "Variable_name": "time", + "Value": "0.016" + }, + { + "Variable_name": "index", + "Value": "tip_amount:SecondaryIndex (100%)" + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + ## SHOW META для PQ таблиц -`SHOW META` можно использовать после выполнения [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ), в этом случае он выдаёт другой вывод. +`SHOW META` может использоваться после выполнения оператора [CALL PQ](../Searching/Percolate_query.md#Performing-a-percolate-query-with-CALL-PQ), при этом он выводит другую информацию. -`SHOW META` после выполнения `CALL PQ` включает: +`SHOW META` после оператора `CALL PQ` включает: -* `total` — Общее время, затраченное на сопоставление документа(ов) -* `queries_matched` — Количество сохранённых запросов, которые совпали с документом(ами) -* `document_matches` — Количество документов, которые совпали с запросами, сохранёнными в таблице -* `total_queries_stored` — Общее количество запросов, сохранённых в таблице -* `term_only_queries` — Количество запросов в таблице, которые содержат термы; остальные запросы используют расширенный синтаксис запросов. +* `total` - Общее время, затраченное на сопоставление документа(ов) +* `queries_matched` - Количество сохранённых запросов, которые совпали с документом(ами) +* `document_matches` - Количество документов, которые совпали с запросами, сохранёнными в таблице +* `total_queries_stored` - Общее количество запросов, сохранённых в таблице +* `term_only_queries` - Количество запросов в таблице, которые содержат термы; остальные запросы используют расширенный синтаксис запросов. ##### SQL: @@ -396,13 +1218,13 @@ CALL PQ ('pq', ('{"title":"angry", "gid":3 }')); SHOW META; -Использование `CALL PQ` с опцией `verbose` предоставляет более подробный вывод. +Использование `CALL PQ` с опцией `verbose` даёт более подробный вывод. -Он включает следующие дополнительные записи: +Он включает следующие дополнительные поля: * `Setup` - Время, затраченное на начальную настройку процесса сопоставления, например, разбор документов и установку параметров -* `Queries failed` - Количество запросов, которые завершились с ошибкой -* `Fast rejected queries` - Количество запросов, которые не были полностью оценены, но быстро сопоставлены и отклонены с использованием фильтров или других условий +* `Queries failed` - Количество запросов, которые завершились ошибкой +* `Fast rejected queries` - Количество запросов, которые не были полностью оценены, но быстро сопоставлены и отброшены с использованием фильтров или других условий * `Time per query` - Подробное время для каждого запроса * `Time of matched queries` - Общее время, затраченное на запросы, которые совпали с любыми документами diff --git a/manual/russian/Node_info_and_management/SHOW_QUERIES.md b/manual/russian/Node_info_and_management/SHOW_QUERIES.md index 283fcb1a98..34d893b020 100644 --- a/manual/russian/Node_info_and_management/SHOW_QUERIES.md +++ b/manual/russian/Node_info_and_management/SHOW_QUERIES.md @@ -1,18 +1,18 @@ -# SHOW QUERIES +# ПОКАЗАТЬ ЗАПРОСЫ ```sql SHOW QUERIES ``` -> ПРИМЕЧАНИЕ: `SHOW QUERIES` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. +> ПРИМЕЧАНИЕ: `SHOW QUERIES` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если это не работает, убедитесь, что Buddy установлен. -`SHOW QUERIES` возвращает информацию обо всех текущих выполняющихся запросах. Вывод представляет собой таблицу со следующей структурой: +`SHOW QUERIES` возвращает информацию обо всех в данный момент выполняющихся запросах. Вывод представляет собой таблицу со следующей структурой: - `id`: ID запроса, который можно использовать в [KILL](../Node_info_and_management/KILL.md) для завершения запроса - `query`: Текст запроса или его часть -- `time`: Время выполнения команды или сколько времени назад был выполнен запрос (в этом случае значение будет содержать `ago`) -- `protocol`: [Протокол соединения](../Server_settings/Searchd.md#listen), возможные значения: `sphinx`, `mysql`, `http`, `ssl`, `compressed`, `replication` или их комбинации (например, `http,ssl` или `compressed,mysql`) +- `time`: Время выполнения команды или как давно был выполнен запрос (в этом случае значение будет содержать `ago`) +- `protocol`: [Протокол соединения](../Server_settings/Searchd.md#listen), возможные значения — `sphinx`, `mysql`, `http`, `ssl`, `compressed`, `replication` или их комбинации (например, `http,ssl` или `compressed,mysql`) - `host`: `ip:port` клиента @@ -32,6 +32,66 @@ mysql> SHOW QUERIES; 2 rows in set (0.61 sec) ``` + +```JSON +POST /sql?mode=raw -d "SHOW QUERIES;" +``` + + +``` +[ + { + "total": 2, + "error": "", + "warning": "", + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "time": { + "type": "string" + } + }, + { + "protocol": { + "type": "string" + } + }, + { + "host": { + "type": "string" + } + } + ], + "data": [ + { + "id": 111, + "query": "select", + "time": "5ms ago", + "protocol": "http", + "host": "127.0.0.1:58986" + }, + { + "id": 96, + "query": "SHOW QUERIES", + "time": "255us", + "protocol": "mysql", + "host": "127.0.0.1:33616" + } + ] + } +] + +``` + Обратитесь к [SHOW THREADS](../Node_info_and_management/SHOW_THREADS.md), если хотите получить информацию с точки зрения самих потоков. diff --git a/manual/russian/Node_info_and_management/SHOW_VERSION.md b/manual/russian/Node_info_and_management/SHOW_VERSION.md index 5bdf01fcbc..7c60fd4a9f 100644 --- a/manual/russian/Node_info_and_management/SHOW_VERSION.md +++ b/manual/russian/Node_info_and_management/SHOW_VERSION.md @@ -7,9 +7,9 @@ SHOW VERSION > ПРИМЕЧАНИЕ: `SHOW VERSION` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если команда не работает, убедитесь, что Buddy установлен. -`SHOW VERSION` предоставляет подробную информацию о версиях различных компонентов экземпляра Manticore Search. Эта команда особенно полезна администраторам и разработчикам, которым необходимо проверить версию Manticore Search, которую они используют, а также версии связанных компонентов. +`SHOW VERSION` предоставляет подробную информацию о версиях различных компонентов экземпляра Manticore Search. Эта команда особенно полезна администраторам и разработчикам, которым нужно проверить версию Manticore Search, которую они используют, а также версии связанных компонентов. -В таблице вывода две колонки: +Выходная таблица включает две колонки: - `Component`: В этой колонке указано название конкретного компонента Manticore Search. - `Version`: В этой колонке отображается информация о версии соответствующего компонента. @@ -19,17 +19,71 @@ mysql> SHOW VERSION; ``` +```sql ++------------+-------------------------------------+ +| Component | Version | ++------------+-------------------------------------+ +| Daemon | 13.13.4 0bc5a9641@25101507 dev | +| Columnar | columnar 8.1.0 e1522a2@25100213 | +| Secondary | secondary 8.1.0 e1522a2@25100213 | +| Knn | knn 8.1.0 e1522a2@25100213 | +| Embeddings | embeddings 1.0.1 | +| Buddy | buddy v3.35.1+25090418-41d9811f-dev | ++------------+-------------------------------------+ +``` + + +```JSON +POST /sql?mode=raw -d "SHOW VERSION" ``` -+------------+--------------------------------+ -| Component | Version | -+------------+--------------------------------+ -| Daemon | 6.2.13 61cfe38d2@24011520 dev | -| Columnar | columnar 2.2.5 214ce90@240115 | -| Secondary | secondary 2.2.5 214ce90@240115 | -| Knn | knn 2.2.5 214ce90@240115 | -| Embeddings | embeddings 1.0.0 | -| Buddy | buddy v2.0.11 | -+------------+--------------------------------+ + + +```JSON +[ + { + "total": 6, + "error": "", + "warning": "", + "columns": [ + { + "Component": { + "type": "string" + } + }, + { + "Version": { + "type": "string" + } + } + ], + "data": [ + { + "Component": "Daemon", + "Version": "13.13.4 0bc5a9641@25101507 dev" + }, + { + "Component": "Columnar", + "Version": "columnar 8.1.0 e1522a2@25100213" + }, + { + "Component": "Secondary", + "Version": "secondary 8.1.0 e1522a2@25100213" + }, + { + "Component": "Knn", + "Version": "knn 8.1.0 e1522a2@25100213" + }, + { + "Component": "Embeddings", + "Version": "embeddings 1.0.1" + }, + { + "Component": "Buddy", + "Version": "buddy v3.35.1+25090418-41d9811f-dev" + } + ] + } +] ``` diff --git a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md index ab0815388d..634f10ef8e 100644 --- a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md +++ b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_INDEXES.md @@ -1,7 +1,7 @@ -# SHOW TABLE INDEXES +# ПОКАЗАТЬ ИНДЕКСЫ ТАБЛИЦЫ -Оператор SQL `SHOW TABLE INDEXES` отображает доступные вторичные индексы для указанной таблицы вместе с их свойствами. [Вторичные индексы](../../Server_settings/Searchd.md#secondary_indexes) улучшают производительность запросов, создавая дополнительные структуры данных, которые ускоряют поиск по определённым столбцам. +Оператор SQL `SHOW TABLE INDEXES` отображает вторичные индексы, доступные для указанной таблицы, вместе с их свойствами. [Вторичные индексы](../../Server_settings/Searchd.md#secondary_indexes) улучшают производительность запросов, создавая дополнительные структуры данных, которые ускоряют поиск по определённым столбцам. Синтаксис: @@ -9,14 +9,14 @@ SHOW TABLE table_name INDEXES ``` -Отображаемые свойства включают следующие столбцы: +Отображаемые свойства включают в себя следующие столбцы: * **Name**: Имя вторичного индекса. Может использоваться в [подсказках оптимизатора запросов](../../Searching/Options.md#Query-optimizer-hints). -* **Type**: Тип данных, хранящихся во вторичном индексе. Для простых атрибутов он совпадает с типом исходного атрибута. Для вторичных индексов, созданных из JSON-атрибутов, тип определяется путём сканирования всех документов и определения типов всех JSON-свойств. +* **Type**: Тип данных, хранящихся во вторичном индексе. Для простых атрибутов он соответствует типу исходного атрибута. Для вторичных индексов, сгенерированных из JSON-атрибутов, тип определяется сканированием всех документов и определением типов всех свойств JSON. * **Enabled**: Указывает, включён ли индекс в данный момент и может ли использоваться для ускорения поиска. Когда атрибут обновляется, вторичный индекс для этого атрибута временно отключается до тех пор, пока индекс не будет перестроен. Вы можете перестроить отключённые индексы с помощью команды [ALTER TABLE ... REBUILD SECONDARY](../../Updating_table_schema_and_settings.md#Rebuilding-a-secondary-index). -* **Percent**: В RT-таблице разные дисковые чанки могут содержать разные вторичные индексы, особенно при использовании JSON-атрибутов. Этот процент показывает, сколько чанков имеют индекс с одинаковым именем, типом и состоянием включения. +* **Percent**: В RT-таблице разные дисковые чанки могут содержать разные вторичные индексы, особенно при использовании JSON-атрибутов. Этот процент показывает, в каком количестве чанков имеется индекс с одинаковым именем, типом и состоянием включения. -> **Примечание:** Для RT-таблиц вторичные индексы создаются только для дисковых чанков, а не для данных в RAM-сегментах. Когда вы впервые вставляете данные в RT-таблицу, они остаются в RAM, и вторичные индексы не отображаются. Индексы становятся видимыми только после сброса данных в дисковые чанки, что по умолчанию происходит автоматически, когда таблица становится активной (получает и вставки, и поисковые запросы). +> **Примечание:** Для RT-таблиц вторичные индексы создаются только для дисковых чанков, а не для данных в RAM-сегментах. При первом добавлении данных в RT-таблицу они остаются в RAM, и вторичные индексы отображаться не будут. Индексы становятся видимыми только после сброса данных в дисковые чанки, что по умолчанию происходит автоматически, когда таблица становится активной (получает как вставки, так и запросы). ##### SQL: @@ -64,5 +64,224 @@ SHOW TABLE test INDEXES; +------------------------------+--------+---------+---------+ 29 rows in set (0.00 sec) ``` + + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE test INDEXES;" +``` + + + +```JSON +[ + { + "columns": [ + { + "Name": { + "type": "string" + } + }, + { + "Type": { + "type": "string" + } + }, + { + "Enabled": { + "type": "string" + } + }, + { + "Percent": { + "type": "string" + } + } + ], + "data": [ + { + "Name": "j['addresses']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['factor']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['int_arr']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']", + "Type": "uint32", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "id", + "Type": "int64", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['price']", + "Type": "float", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a1']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a2']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a3']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a4']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a5']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['id']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['addresses']['a6']['name']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['arr']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['str']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['1']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['2']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + }, + { + "Name": "j['tags']['3']", + "Type": "string", + "Enabled": "1", + "Percent": 100 + } + ], + "total": 29, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md index 9007724b4b..57228b88c5 100644 --- a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md +++ b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_SETTINGS.md @@ -10,7 +10,7 @@ SHOW TABLE table_name[.N | CHUNK N] SETTINGS ``` -Вывод похож на опцию [--dumpconfig](../../Miscellaneous_tools.md#indextool) утилиты [indextool](../../Miscellaneous_tools.md#indextool). Отчет предоставляет подробный разбор всех настроек таблицы, включая параметры токенизатора и словаря. +Вывод похож на опцию [--dumpconfig](../../Miscellaneous_tools.md#indextool) утилиты [indextool](../../Miscellaneous_tools.md#indextool). В отчёте приводится разбивка всех настроек таблицы, включая опции токенизатора и словаря. ##### SQL: @@ -31,11 +31,48 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE forum SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -Вы также можете указать номер конкретного чанка, чтобы просмотреть настройки определенного чанка в RT-таблице. Нумерация начинается с 0. +Также можно указать номер конкретного чанка, чтобы просмотреть настройки определённого чанка в RT-таблице. Нумерация начинается с 0. ##### SQL: @@ -56,6 +93,43 @@ charset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430. 1 row in set (0.00 sec) ``` + +##### JSON: + + +```sql +POST /sql?mode=raw -d "SHOW TABLE forum CHUNK 0 SETTINGS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "settings", + "Value": "min_prefix_len = 3\ncharset_table = 0..9, A..Z->a..z, _, -, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md index 32d822ecd9..756991bbb4 100644 --- a/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md +++ b/manual/russian/Node_info_and_management/Table_settings_and_status/SHOW_TABLE_STATUS.md @@ -45,13 +45,13 @@ SHOW TABLE table_name STATUS * `max_stack_need`: объём стека, необходимый для вычисления самой сложной из сохранённых перколяторных запросов. Это динамическое значение, зависящее от деталей сборки, таких как компилятор, оптимизация, оборудование и т.д. * `average_stack_base`: объём стека, обычно занимаемый в начале вычисления перколяторного запроса. * `desired_thread_stack`: сумма вышеуказанных значений, округлённая до ближайшего значения, кратного 128 байтам. Если это значение больше `thread_stack`, выполнение `call pq` по этой таблице может быть невозможно, так как некоторые сохранённые запросы завершатся с ошибкой. Значение `thread_stack` по умолчанию — 1M (1048576); другие значения должны быть настроены. -* `tid` и `tid_saved`: представляют состояние сохранения таблицы. `tid` увеличивается с каждым изменением (транзакцией). `tid_saved` показывает максимальный `tid` состояния, сохраненного в RAM-чанк в файле `
.ram`. Когда числа отличаются, некоторые изменения существуют только в RAM и также поддерживаются binlog (если включен). Выполнение `FLUSH TABLE` или планирование периодической очистки сохраняет эти изменения. После очистки binlog очищается, и `tid_saved` представляет новое актуальное состояние. -* `query_time_*`, `exact_query_time_*`: статистика времени выполнения запросов за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные инкапсулированы в JSON-объект, включая количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентильные значения. -* `found_rows_*`: статистика найденных строк по запросам; предоставляется за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные инкапсулированы в JSON-объект, включая количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентильные значения. -* `command_*`: счетчики общего количества успешных выполнений конкретной команды для этой таблицы. -* `search_stats_ms_*`: статистика времени выполнения (в миллисекундах) поисковых запросов. * обозначает временное окно (например, 1min, 5min, 15min, total). Эти статистики рассчитываются за скользящие окна 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентильные значения времени запросов. -* `insert_replace_stats_ms_*`: статистика времени выполнения (в миллисекундах) запросов вставки и замены. * обозначает временное окно (например, 1min, 5min, 15min, total). Эти статистики рассчитываются за скользящие окна 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентильные значения времени запросов. -* `update_stats_ms_*`: статистика времени выполнения (в миллисекундах) запросов обновления. * обозначает временное окно (например, 1min, 5min, 15min, total). Эти статистики рассчитываются за скользящие окна 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентильные значения времени запросов. +* `tid` и `tid_saved`: представляют состояние сохранения таблицы. `tid` увеличивается с каждой изменением (транзакцией). `tid_saved` показывает максимальный `tid` состояния, сохранённого в RAM-чанке в файле `
.ram`. Когда значения отличаются, некоторые изменения существуют только в RAM и также поддерживаются binlog (если он включён). Выполнение `FLUSH TABLE` или планирование периодической очистки сохраняет эти изменения. После очистки binlog очищается, и `tid_saved` представляет новое фактическое состояние. +* `query_time_*`, `exact_query_time_*`: статистика времени выполнения запросов за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные представлены в виде JSON-объекта, включающего количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентили. +* `found_rows_*`: статистика найденных строк по запросам; предоставляется за последние 1 минуту, 5 минут, 15 минут и всего с момента запуска сервера; данные представлены в виде JSON-объекта, включающего количество запросов и минимальные, максимальные, средние, 95-й и 99-й перцентили. +* `command_*`: счётчики общего количества успешных выполнений определённой команды для этой таблицы. +* `search_stats_ms_*`: статистика времени выполнения (в миллисекундах) поисковых запросов. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов. +* `insert_replace_stats_ms_*`: статистика времени выполнения (в миллисекундах) вставки и замены записей. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов. +* `update_stats_ms_*`: статистика времени выполнения (в миллисекундах) обновляющих запросов. * обозначает временной промежуток (например, 1min, 5min, 15min, total). Эта статистика рассчитывается за скользящие окна в 1, 5 и 15 минут, показывая средние, минимальные, максимальные и 95-й/99-й перцентили значений времени запросов. ##### SQL: @@ -129,6 +129,271 @@ mysql> SHOW TABLE statistic STATUS; 29 rows in set (0.00 sec) ``` + +##### JSON: + + +```JSON +POST /sql?mode=raw -d "SHOW TABLE t STATUS;" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "table_type", + "Value": "rt" + }, + { + "Variable_name": "indexed_documents", + "Value": "5" + }, + { + "Variable_name": "indexed_bytes", + "Value": "28" + }, + { + "Variable_name": "ram_bytes", + "Value": "23400" + }, + { + "Variable_name": "disk_bytes", + "Value": "1969" + }, + { + "Variable_name": "disk_mapped", + "Value": "196" + }, + { + "Variable_name": "disk_mapped_cached", + "Value": "16384" + }, + { + "Variable_name": "disk_mapped_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_doclists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_hitlists", + "Value": "0" + }, + { + "Variable_name": "disk_mapped_cached_hitlists", + "Value": "0" + }, + { + "Variable_name": "killed_documents", + "Value": "0" + }, + { + "Variable_name": "killed_rate", + "Value": "0.00%" + }, + { + "Variable_name": "ram_chunk", + "Value": "0" + }, + { + "Variable_name": "ram_chunk_segments_count", + "Value": "0" + }, + { + "Variable_name": "disk_chunks", + "Value": "1" + }, + { + "Variable_name": "mem_limit", + "Value": "134217728" + }, + { + "Variable_name": "mem_limit_rate", + "Value": "95.00%" + }, + { + "Variable_name": "ram_bytes_retired", + "Value": "0" + }, + { + "Variable_name": "optimizing", + "Value": "0" + }, + { + "Variable_name": "locked", + "Value": "0" + }, + { + "Variable_name": "tid", + "Value": "7" + }, + { + "Variable_name": "tid_saved", + "Value": "7" + }, + { + "Variable_name": "query_time_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "query_time_total", + "Value": "{\"queries\":30, \"avg_sec\":0.324, \"min_sec\":0.051, \"max_sec\":1.718, \"pct95_sec\":1.017, \"pct99_sec\":1.718}" + }, + { + "Variable_name": "found_rows_1min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_5min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_15min", + "Value": "{\"queries\":0, \"avg\":\"-\", \"min\":\"-\", \"max\":\"-\", \"pct95\":\"-\", \"pct99\":\"-\"}" + }, + { + "Variable_name": "found_rows_total", + "Value": "{\"queries\":30, \"avg\":2, \"min\":0, \"max\":5, \"pct95\":5, \"pct99\":5}" + }, + { + "Variable_name": "command_search", + "Value": "30" + }, + { + "Variable_name": "command_excerpt", + "Value": "3" + }, + { + "Variable_name": "command_update", + "Value": "0" + }, + { + "Variable_name": "command_keywords", + "Value": "0" + }, + { + "Variable_name": "command_status", + "Value": "1" + }, + { + "Variable_name": "command_delete", + "Value": "1" + }, + { + "Variable_name": "command_insert", + "Value": "6" + }, + { + "Variable_name": "command_replace", + "Value": "0" + }, + { + "Variable_name": "command_commit", + "Value": "0" + }, + { + "Variable_name": "command_suggest", + "Value": "0" + }, + { + "Variable_name": "command_callpq", + "Value": "0" + }, + { + "Variable_name": "command_getfield", + "Value": "0" + }, + { + "Variable_name": "insert_replace_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "insert_replace_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "search_stats_ms_pct99", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_avg", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_min", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_max", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct95", + "Value": "N/A N/A N/A" + }, + { + "Variable_name": "update_stats_ms_pct99", + "Value": "N/A N/A N/A" + } + ], + "total": 58, + "error": "", + "warning": "" + } +] +``` + ##### PHP: diff --git a/manual/russian/Searching/Faceted_search.md b/manual/russian/Searching/Faceted_search.md index e942c942a7..fe41f3057c 100644 --- a/manual/russian/Searching/Faceted_search.md +++ b/manual/russian/Searching/Faceted_search.md @@ -1,28 +1,28 @@ -# Фасетный поиск +# Многофакторный поиск -Фасетный поиск так же важен для современного поискового приложения, как [автозаполнение](../Searching/Autocomplete.md), [исправление опечаток](../Searching/Spell_correction.md) и подсветка поисковых ключевых слов [highlighting](../Searching/Highlighting.md), особенно в продуктах электронной коммерции. +Многофакторный поиск так же важен для современного поискового приложения, как [автодополнение](../Searching/Autocomplete.md), [исправление орфографии](../Searching/Spell_correction.md) и подсветка поисковых ключевых слов [highlighting](../Searching/Highlighting.md), особенно в продуктах электронной коммерции. -![Faceted search](faceted.png) +![Многофакторный поиск](faceted.png) -Фасетный поиск полезен при работе с большими объемами данных и различными взаимосвязанными свойствами, такими как размер, цвет, производитель или другие факторы. При запросе больших объемов данных результаты поиска часто включают множество записей, которые не соответствуют ожиданиям пользователя. Фасетный поиск позволяет конечному пользователю явно определить критерии, которым должны удовлетворять результаты поиска. +Многофакторный поиск полезен при работе с большим объемом данных и различными взаимосвязанными свойствами, такими как размер, цвет, производитель или другие факторы. При запросе больших объемов данных результаты поиска часто содержат множество записей, которые не соответствуют ожиданиям пользователя. Многофакторный поиск позволяет конечному пользователю явно определить критерии, которым должны удовлетворять результаты его поиска. -В Manticore Search есть оптимизация, которая сохраняет набор результатов исходного запроса и повторно использует его для каждого вычисления фасета. Поскольку агрегации применяются к уже вычисленному подмножеству документов, они выполняются быстро, и общее время выполнения часто может быть лишь немного дольше, чем у первоначального запроса. Фасеты можно добавлять к любому запросу, и фасет может быть любым атрибутом или выражением. Результат фасета включает значения фасета и количество по фасету. К фасетам можно получить доступ с помощью SQL-запроса `SELECT`, объявляя их в самом конце запроса. +В Manticore Search есть оптимизация, которая сохраняет результат исходного запроса и повторно использует его для каждого расчета фактора. Поскольку агрегации применяются к уже вычисленному подмножеству документов, они работают быстро, и общее время выполнения часто бывает лишь немного больше времени первичного запроса. Факторы можно добавлять к любому запросу, и фактором может быть любой атрибут или выражение. Результат фактора включает значения фактора и количество по фактору. К факторам можно получить доступ, используя SQL-оператор `SELECT`, объявляя их в самом конце запроса. ## Агрегации ### SQL -Значения фасета могут исходить из атрибута, свойства JSON внутри JSON-атрибута или выражения. Значения фасета также могут иметь псевдонимы, но **псевдоним должен быть уникальным** во всех наборах результатов (основной набор результатов запроса и другие наборы результатов фасетов). Значение фасета выводится из агрегированного атрибута/выражения, но также может исходить из другого атрибута/выражения. +Значения фактора могут исходить из атрибута, свойства JSON внутри JSON-атрибута или выражения. Значения фактора также могут иметь псевдонимы, но **псевдоним должен быть уникальным** во всех наборах результатов (основной набор результатов запроса и другие наборы результатов факторов). Значение фактора получается из агрегированного атрибута/выражения, но также может браться из другого атрибута/выражения. ```sql FACET {expr_list} [BY {expr_list} ] [DISTINCT {field_name}] [ORDER BY {expr | FACET()} {ASC | DESC}] [LIMIT [offset,] count] ``` -Несколько объявлений фасетов должны разделяться пробелом. +Несколько объявлений факторов должны быть разделены пробелом. ### HTTP JSON -Фасеты можно определить в узле `aggs`: +Факторы могут быть определены в узле `aggs`: ``` json "aggs" : @@ -40,12 +40,12 @@ FACET {expr_list} [BY {expr_list} ] [DISTINCT {field_name}] [ORDER BY {expr | FA ``` где: -* `group name` — это псевдоним, присвоенный агрегации -* значение `field` должно содержать имя атрибута или выражения, по которому выполняется фасетирование -* необязательный параметр `size` указывает максимальное количество бакетов, включаемых в результат. Если не указан, наследует лимит основного запроса. Подробнее см. в разделе [Размер результата фасета](../Searching/Faceted_search.md#Size-of-facet-result). -* необязательный параметр `sort` задает массив атрибутов и/или дополнительных свойств с использованием того же синтаксиса, что и ["параметр sort в основном запросе"](../Searching/Sorting_and_ranking.md#Sorting-via-JSON). +* `group name` — псевдоним, присвоенный агрегации +* значение `field` должно содержать имя атрибута или выражения, по которому происходит факторинг +* необязательный `size` указывает максимальное количество корзин, включаемых в результат. Если не указано, наследует лимит основного запроса. Подробнее см. в разделе [Размер результата фактора](../Searching/Faceted_search.md#Size-of-facet-result). +* необязательный `sort` задает массив атрибутов и/или дополнительных свойств, используя такой же синтаксис, как параметр ["sort" в основном запросе](../Searching/Sorting_and_ranking.md#Sorting-via-JSON). -Набор результатов будет содержать узел `aggregations` с возвращенными фасетами, где `key` — агрегированное значение, а `doc_count` — количество в агрегации. +Набор результатов будет содержать узел `aggregations` с возвращаемыми факторами, где `key` — агрегированное значение, а `doc_count` — количество в агрегации. ``` json "aggregations": { @@ -759,9 +759,9 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -### Фасетирование по агрегации другого атрибута +### Факторинг по агрегации другого атрибута -Данные можно фасетировать, агрегируя другой атрибут или выражение. Например, если документы содержат как идентификатор бренда, так и его название, можно вернуть в фасете названия брендов, но агрегировать идентификаторы брендов. Это можно сделать с помощью `FACET {expr1} BY {expr2}` +Данные могут быть факторированы путем агрегации другого атрибута или выражения. Например, если в документах содержатся и id бренда, и название, мы можем вернуть в факторе названия брендов, но агрегировать id брендов. Это можно сделать с помощью конструкции `FACET {expr1} BY {expr2}` @@ -803,17 +803,101 @@ SELECT * FROM facetdemo FACET brand_name by brand_id; 10 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name, brand_id FROM facetdemo FACET brand_name by brand_id;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "brand_id": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Ten", + "brand_id": 10 + }, + ... + { + "brand_name": "Brand One", + "brand_id": 1 + }, + { + "brand_name": "Brand Nine", + "brand_id": 9 + } + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "count(*)": 1013 + }, + { + "brand_name": "Brand Ten", + "count(*)": 998 + }, + { + "brand_name": "Brand Eight", + "count(*)": 1033 + }, + { + "brand_name": "Brand Seven", + "count(*)": 965 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + -### Фасетирование без дубликатов +### Факторинг без дубликатов -Если нужно удалить дубликаты из бакетов, возвращаемых FACET, можно использовать `DISTINCT field_name`, где `field_name` — поле, по которому нужно выполнить дедупликацию. Это также может быть `id` (что является значением по умолчанию), если вы выполняете FACET-запрос к распределенной таблице и не уверены, что у вас уникальные идентификаторы в таблицах (таблицы должны быть локальными и иметь одинаковую схему). +Если необходимо удалить дубликаты из корзин, возвращаемых FACET, можно использовать `DISTINCT field_name`, где `field_name` — поле, по которому требуется выполнить дедупликацию. Это также может быть `id` (который является значением по умолчанию), если выполняется FACET-запрос к распределенной таблице и не уверены, есть ли уникальные идентификаторы в таблицах (таблицы должны быть локальными и иметь одинаковую схему). -Если в вашем запросе несколько объявлений FACET, `field_name` должен быть одинаковым во всех них. +Если в вашем запросе несколько объявлений FACET, `field_name` должен быть одинаковым во всех из них. -`DISTINCT` возвращает дополнительный столбец `count(distinct ...)` перед столбцом `count(*)`, что позволяет получить оба результата без необходимости делать дополнительный запрос. +`DISTINCT` возвращает дополнительный столбец `count(distinct ...)` перед столбцом `count(*)`, что позволяет получить оба результата без необходимости делать еще один запрос. ##### SQL: @@ -949,9 +1033,9 @@ POST /sql -d 'SELECT brand_name, property FROM facetdemo FACET brand_name distin -### Фасет по выражениям +### Факторинг по выражениям -Фасеты могут агрегировать по выражениям. Классический пример — сегментация цен по определенным диапазонам: +Факторы могут агрегировать по выражениям. Классический пример — сегментация цен по определенным диапазонам: @@ -1525,9 +1609,9 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -### Facet over multi-level grouping +### Фасет по многоуровневой группировке -Facets can aggregate over multi-level grouping, with the result set being the same as if the query performed a multi-level grouping: +Фасеты могут агрегировать по многоуровневой группировке, при этом результирующий набор будет таким же, как если бы запрос выполнял многоуровневую группировку: @@ -1563,20 +1647,104 @@ FACET price_range AS price_range,brand_name ORDER BY brand_name asc; | 1 | Brand Four | 195 | ... ``` + + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name,INTERVAL(price,200,400,600,800) AS price_range FROM facetdemo +FACET price_range AS price_range,brand_name ORDER BY brand_name asc;" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + }, + { + "price_range": { + "type": "long" + } + } + ], + "data": [ + { + "brand_name": "Brand One", + "price_range": 1 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "fprice_range": { + "type": "long" + } + }, + { + "brand_name": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "fprice_range": 1, + "brand_name": "Brand Eight", + "count(*)": 197 + }, + { + "fprice_range": 4, + "brand_name": "Brand Eight", + "count(*)": 235 + }, + ... + { + "fprice_range": 0, + "brand_name": "Brand Five", + "count(*)": 183 + }, + { + "fprice_range": 1, + "brand_name": "Brand Four", + "count(*)": 195 + } + ], + "total": 10, + "error": "", + "warning": "" + } +] +``` + -### Facet over histogram values +### Фасет по значениям гистограммы -Facets can aggregate over histogram values by constructing fixed-size buckets over the values. -The key function is: +Фасеты могут агрегировать по значениям гистограммы, создавая фиксированные интервалы (баки) по значениям. +Ключевая функция: ```sql key_of_the_bucket = interval + offset * floor ( ( value - offset ) / interval ) ``` -The histogram argument `interval` must be positive, and the histogram argument `offset` must be positive and less than `interval`. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys. +Аргумент `interval` гистограммы должен быть положительным, а аргумент `offset` должен быть положительным и меньше `interval`. По умолчанию баки возвращаются в виде массива. Аргумент гистограммы `keyed` делает ответ словарём с ключами баков. @@ -1708,17 +1876,17 @@ POST /search -d ' -### Facet over histogram date values +### Фасет по значениям гистограммы даты -Facets can aggregate over histogram date values, which is similar to the normal histogram. The difference is that the interval is specified using a date or time expression. Such expressions require special support because the intervals are not always of fixed length. Values are rounded to the closest bucket using the following key function: +Фасеты могут агрегировать по значениям гистограммы даты, что похоже на обычную гистограмму. Разница в том, что интервал указывается с помощью выражения даты или времени. Такие выражения требуют специальной поддержки, так как интервалы не всегда имеют фиксированную длину. Значения округляются до ближайшего бака с помощью следующей ключевой функции: ```sql key_of_the_bucket = interval * floor ( value / interval ) ``` -The histogram parameter `calendar_interval` understands months to have different amounts of days. -Unlike `calendar_interval`, the `fixed_interval` parameter uses a fixed number of units and does not deviate, regardless of where it falls on the calendar. However `fixed_interval` cannot process units such as months because a month is not a fixed quantity. Attempting to specify units like weeks or months for `fixed_interval` will result in an error. -The accepted intervals are described in the [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29) expression. By default, the buckets are returned as an array. The histogram argument `keyed` makes the response a dictionary with the bucket keys. +Параметр гистограммы `calendar_interval` учитывает, что в месяцах разное количество дней. +В отличие от `calendar_interval`, параметр `fixed_interval` использует фиксированное количество единиц и не отклоняется, независимо от положения в календаре. Однако `fixed_interval` не может обрабатывать такие единицы, как месяцы, поскольку месяц — это не фиксированный период. Попытка указать такие единицы, как недели или месяцы для `fixed_interval`, приведёт к ошибке. +Допустимые интервалы описаны в выражении [date_histogram](../Functions/Date_and_time_functions.md#DATE_HISTOGRAM%28%29). По умолчанию баки возвращаются в виде массива. Аргумент гистограммы `keyed` делает ответ словарём с ключами баков. @@ -1799,10 +1967,10 @@ POST /search -d ' -### Facet over set of ranges +### Фасет по набору диапазонов -Facets can aggregate over a set of ranges. The values are checked against the bucket range, where each bucket includes the `from` value and excludes the `to` value from the range. -Setting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array. +Фасеты могут агрегировать по набору диапазонов. Значения проверяются на принадлежность диапазону бака, при этом каждый бак включает значение `from` и исключает значение `to` из диапазона. +Установка свойства `keyed` в `true` делает ответ словарём с ключами баков вместо массива. @@ -1942,9 +2110,9 @@ POST /search -d ' -### Facet over set of date ranges +### Фасет по набору диапазонов дат -Facets can aggregate over a set of date ranges, which is similar to the normal range. The difference is that the `from` and `to` values can be expressed in [Date math](../Functions/Date_and_time_functions.md#Date-math) expressions. This aggregation includes the `from` value and excludes the `to` value for each range. Setting the `keyed` property to `true` makes the response a dictionary with the bucket keys rather than an array. +Фасеты могут агрегировать по набору диапазонов дат, что похоже на обычный диапазон. Разница в том, что значения `from` и `to` могут быть выражены с помощью выражений [Date math](../Functions/Date_and_time_functions.md#Date-math). Эта агрегация включает значение `from` и исключает значение `to` для каждого диапазона. Установка свойства `keyed` в `true` делает ответ словарём с ключами баков вместо массива. @@ -2035,9 +2203,9 @@ POST /search -d ' -### Ordering in facet result +### Сортировка в результате фасета -Facets support the `ORDER BY` clause just like a standard query. Each facet can have its own ordering, and the facet ordering doesn't affect the main result set's ordering, which is determined by the main query's `ORDER BY`. Sorting can be done on attribute name, count (using `COUNT(*)`, `COUNT(DISTINCT attribute_name)`), or the special `FACET()` function, which provides the aggregated data values. By default, a query with `ORDER BY COUNT(*)` will sort in descending order. +Фасеты поддерживают предложение `ORDER BY`, как и стандартный запрос. Каждый фасет может иметь свою собственную сортировку, и сортировка фасета не влияет на сортировку основного набора результатов, которая определяется `ORDER BY` основного запроса. Сортировка может осуществляться по имени атрибута, количеству (с помощью `COUNT(*)`, `COUNT(DISTINCT attribute_name)`) или специальной функции `FACET()`, которая предоставляет агрегированные значения. По умолчанию запрос с `ORDER BY COUNT(*)` сортирует результаты по убыванию. @@ -2220,11 +2388,11 @@ POST /search -d ' -### Size of facet result +### Размер результата фасета -By default, each facet result set is limited to 20 values. The number of facet values can be controlled with the `LIMIT` clause individually for each facet by providing either a number of values to return in the format `LIMIT count` or with an offset as `LIMIT offset, count`. +По умолчанию каждый результат фасета ограничен 20 значениями. Количество значений фасета можно контролировать с помощью предложения `LIMIT` отдельно для каждого фасета, указав либо количество возвращаемых значений в формате `LIMIT count`, либо с оффсетом в формате `LIMIT offset, count`. -The maximum facet values that can be returned is limited by the query's `max_matches` setting. If you want to implement dynamic `max_matches` (limiting `max_matches` to offset + per page for better performance), it must be taken into account that a too low `max_matches` value can affect the number of facet values. In this case, a minimum `max_matches` value should be used that is sufficient to cover the number of facet values. +Максимальное количество значений фасета ограничено настройкой `max_matches` запроса. Если вы хотите реализовать динамическое управление `max_matches` (ограничение `max_matches` значением offset + количество на страницу для лучшей производительности), необходимо учитывать, что слишком маленькое `max_matches` может повлиять на количество значений фасета. В этом случае следует использовать минимальное значение `max_matches`, достаточное для покрытия количества значений фасета. ##### SQL: @@ -2816,17 +2984,17 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea ``` -### Возвращаемый набор результатов +### Returned result set -При использовании SQL поиск с фасетами возвращает несколько наборов результатов. Клиент/библиотека/коннектор MySQL, используемый **должен** поддерживать несколько наборов результатов, чтобы получить доступ к наборам результатов фасетов. +When using SQL, a search with facets returns multiple result sets. The MySQL client/library/connector used **must** support multiple result sets in order to access the facet result sets. -### Производительность +### Performance -Внутренне `FACET` является сокращением для выполнения мультизапроса, где первый запрос содержит основной поисковый запрос, а остальные запросы в пакете имеют каждый свою кластеризацию. Как и в случае мультизапроса, общая оптимизация запросов может сработать для фасетного поиска, что означает, что поисковый запрос выполняется только один раз, а фасеты работают с результатом поискового запроса, при этом каждый фасет добавляет лишь часть времени к общему времени запроса. +Internally, the `FACET` is a shorthand for executing a multi-query where the first query contains the main search query and the rest of the queries in the batch have each a clustering. As in the case of multi-query, the common query optimization can kick in for a faceted search, meaning the search query is executed only once, and the facets operate on the search query result, with each facet adding only a fraction of time to the total query time. -Чтобы проверить, был ли фасетный поиск выполнен в оптимизированном режиме, вы можете посмотреть в [журнал запросов](../Logging/Query_logging.md), где все записанные запросы будут содержать строку `xN`, где `N` — количество запросов, выполненных в оптимизированной группе. Кроме того, вы можете проверить вывод оператора [SHOW META](../Node_info_and_management/SHOW_META.md), который отобразит метрику `multiplier`: +To check if the faceted search ran in an optimized mode, you can look in the [query log](../Logging/Query_logging.md), where all logged queries will contain an `xN` string, where `N` is the number of queries that ran in the optimized group. Alternatively, you can check the output of the [SHOW META](../Node_info_and_management/SHOW_META.md) statement, which will display a `multiplier` metric: @@ -2870,6 +3038,132 @@ SHOW META LIKE 'multiplier'; 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT brand_name FROM facetdemo FACET brand_id FACET price FACET categories; SHOW META LIKE 'multiplier';" +``` + + + +```JSON +[ + { + "columns": [ + { + "brand_name": { + "type": "string" + } + } + ], + "data": [ + { + "brand_name": "Brand One" + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "brand_id": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "brand_id": 1, + "count(*)": 1013 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "price": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "price": 306, + "count(*)": 7 + }, + ... + ], + "total": 20, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "categories": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "categories": "10,11", + "count(*)": 2436 + }, + ... + ], + "total": 15, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "multiplier", + "Value": "4" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Searching/Full_text_matching/Basic_usage.md b/manual/russian/Searching/Full_text_matching/Basic_usage.md index 961b88461c..7fcb14bbd1 100644 --- a/manual/russian/Searching/Full_text_matching/Basic_usage.md +++ b/manual/russian/Searching/Full_text_matching/Basic_usage.md @@ -1,22 +1,22 @@ # MATCH -Клауза `MATCH` позволяет выполнять полнотекстовый поиск в текстовых полях. Входная строка запроса [токенизируется](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md) с использованием тех же настроек, которые применялись к тексту при индексировании. Помимо токенизации входного текста, строка запроса поддерживает ряд [операторов полнотекстового поиска](../../Searching/Full_text_matching/Operators.md), которые задают различные правила того, как ключевые слова должны обеспечивать валидное совпадение. +Клауза `MATCH` позволяет выполнять полнотекстовый поиск в текстовых полях. Входящая строка запроса [токенизируется](../../Creating_a_table/NLP_and_tokenization/Data_tokenization.md) с использованием тех же настроек, которые применялись к тексту при индексировании. Помимо токенизации входного текста, строка запроса поддерживает ряд [операторов полнотекстового поиска](../../Searching/Full_text_matching/Operators.md), которые задают различные правила, с помощью которых ключевые слова должны обеспечивать валидное совпадение. -Клаузы полнотекстового поиска могут комбинироваться с атрибутными [фильтрами](../../Searching/Filters.md) как логическое И. **Логические ИЛИ между полнотекстовыми совпадениями и атрибутными фильтрами не поддерживаются**. +Клаузы полнотекстового сопоставления могут комбинироваться с [фильтрами](../../Searching/Filters.md) по атрибутам, используя логическое И (AND). **Отношения ИЛИ между полнотекстовыми совпадениями и атрибутными фильтрами не поддерживаются**. -Запрос с match всегда выполняется первым в процессе фильтрации, за ним следуют [атрибутные фильтры](../../Searching/Filters.md). Атрибутные фильтры применяются к результату запроса match. Запрос без клаузы match называется fullscan. +Запрос сопоставления всегда выполняется первым на этапе фильтрации, а затем применяются [фильтры атрибутов](../../Searching/Filters.md). Фильтры атрибутов применяются к результату запроса сопоставления. Запрос без клаузы match называется fullscan. -В `SELECT` должно быть не более одного `MATCH()`. +В клауза `SELECT` может присутствовать не более одной `MATCH()`. -Используя [синтаксис полнотекстового запроса](../../Searching/Full_text_matching/Operators.md), поиск выполняется по всем индексированным текстовым полям документа, если выражение не требует совпадения внутри поля (например, поиск фразы) или не ограничено операторами поля. +Используя [синтаксис полнотекстовых запросов](../../Searching/Full_text_matching/Operators.md), сопоставление выполняется по всем проиндексированным текстовым полям документа, если только выражение не требует совпадения в определённом поле (например, поиск фразы) или не ограничено операторами полей. -При использовании запросов с [JOIN](../../Searching/Joining.md), `MATCH()` может принимать необязательный второй параметр, который указывает, к какой таблице должен применяться полнотекстовый поиск. По умолчанию полнотекстовый запрос применяется к левой таблице в операции `JOIN`: +При использовании запросов с [JOIN](../../Searching/Joining.md), `MATCH()` может принимать необязательный второй параметр, который указывает таблицу, к которой следует применить полнотекстовый поиск. По умолчанию полнотекстовый запрос применяется к левой таблице в операции `JOIN`: ```sql SELECT * FROM table1 LEFT JOIN table2 ON table1.id = table2.id WHERE MATCH('search query', table2); ``` -Это позволяет выполнять полнотекстовый поиск по конкретным таблицам в операции соединения. Для получения дополнительной информации о использовании MATCH с JOIN смотрите раздел [Joining tables](../../Searching/Joining.md). +Это позволяет выполнять полнотекстовый поиск по конкретным таблицам в операции объединения. Для подробностей использования MATCH с JOIN смотрите раздел [Объединение таблиц](../../Searching/Joining.md). ## SQL @@ -26,10 +26,10 @@ SELECT * FROM table1 LEFT JOIN table2 ON table1.id = table2.id WHERE MATCH('sear MATCH('search query' [, table_name]) ``` - `'search query'`: Строка полнотекстового поискового запроса, которая может включать различные [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md). -- `table_name`: (Опционально) Имя таблицы, к которой применяется полнотекстовый поиск, используется в запросах с `JOIN` для указания таблицы, отличной от левой по умолчанию. +- `table_name`: (необязательно) Имя таблицы, к которой применяется полнотекстовый поиск, используется в запросах с `JOIN` для указания таблицы, отличной от левой по умолчанию. -Оператор [SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) использует клаузу [MATCH](../../Searching/Full_text_matching/Basic_usage.md), которая должна идти после WHERE, для выполнения полнотекстового поиска. `MATCH()` принимает входную строку, в которой доступны все [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md). +Оператор [SELECT](../../Searching/Full_text_matching/Basic_usage.md#SQL) использует клауза [MATCH](../../Searching/Full_text_matching/Basic_usage.md), который должен идти после WHERE, для выполнения полнотекстовых поисков. `MATCH()` принимает входную строку, в которой доступны все [операторы полнотекстового поиска](../../Searching/Full_text_matching/Operators.md). @@ -52,6 +52,52 @@ SELECT * FROM myindex WHERE MATCH('"find me fast"/2'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM myindex WHERE MATCH('"find me fast"/2');" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "gid": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "gid": 11, + "title": "first find me" + }, + { + "id": 1, + "gid": 12, + "title": "second find me" + }, + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + Пример более сложного запроса с использованием MATCH и фильтров WHERE. @@ -65,11 +111,11 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i -Полнотекстовый поиск доступен в эндпоинте `/search` и в HTTP-клиентах. Для выполнения полнотекстового поиска можно использовать следующие клаузы: +Полнотекстовое сопоставление доступно через эндпоинт `/search` и в HTTP-клиентах. Для полнотекстовых сопоставлений можно использовать следующие клаузы: ### match -"match" — это простой запрос, который ищет указанные ключевые слова в указанных полях. +"match" — простой запрос, который сопоставляет указанные ключевые слова в заданных полях. ```json "query": @@ -78,7 +124,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i } ``` -Вы можете указать список полей: +Можно указать список полей: ```json "match": @@ -88,7 +134,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ``` Или использовать `_all` или `*` для поиска по всем полям. -Вы можете искать по всем полям, кроме одного, используя "!field": +Можно искать по всем полям, кроме одного, используя "!field": ```json "match": @@ -96,7 +142,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i "!field1": "keyword" } ``` -По умолчанию ключевые слова объединяются оператором OR. Однако вы можете изменить это поведение с помощью клаузы "operator": +По умолчанию ключевые слова объединяются оператором OR. Однако это поведение можно изменить с помощью клаузы "operator": ```json "query": @@ -114,7 +160,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i "operator" может быть установлен в "or" или "and". -Также можно применить модификатор `boost`. Он повышает значение [IDF](../../Searching/Options.md#idf)_score слова на указанный коэффициент в рейтинговых оценках, которые учитывают IDF в своих вычислениях. Это не влияет на процесс сопоставления. +Также можно использовать модификатор `boost`. Он увеличивает значение [IDF](../../Searching/Options.md#idf)_оценки слова на указанный коэффициент в ранжировочных оценках, которые учитывают IDF при вычислениях. Это не влияет на процесс сопоставления. ```json "query": { @@ -131,7 +177,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ### match_phrase -"match_phrase" — это запрос, который ищет полную фразу. Он похож на оператор фразы в SQL. Пример: +"match_phrase" — запрос, который сопоставляет всю фразу целиком. Это похоже на оператор фразы в SQL. Пример: ```json "query": @@ -141,7 +187,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ``` ### query_string -"query_string" принимает входную строку в синтаксисе `MATCH()` для полнотекстового запроса. +"query_string" принимает входную строку в синтаксисе `MATCH()` и использует ее как полнотекстовый запрос. ```json "query": @@ -152,7 +198,7 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ### match_all -"match_all" принимает пустой объект и возвращает документы из таблицы без применения атрибутных фильтров или полнотекстового поиска. Альтернативно, можно просто опустить клаузу `query` в запросе, что даст тот же эффект. +"match_all" принимает пустой объект и возвращает документы из таблицы без применения фильтров по атрибутам или полнотекстового сопоставления. Альтернативно можно просто опустить клауза `query` в запросе — эффект будет тот же. ```json "query": @@ -162,9 +208,9 @@ SELECT * FROM myindex WHERE MATCH('cats|birds') AND (`title`='some title' AND `i ``` -### Комбинирование полнотекстовой фильтрации с другими фильтрами +### Комбинирование полнотекстового фильтра с другими фильтрами -Все клаузы полнотекстового поиска могут комбинироваться с операторами [must](../../Searching/Filters.md#must), [must_not](../../Searching/Filters.md#must_not) и [should](../../Searching/Filters.md#should) в [JSON `bool` запросе](../../Searching/Filters.md#bool-query). +Все клаузы полнотекстового сопоставления можно комбинировать с операторами [must](../../Searching/Filters.md#must), [must_not](../../Searching/Filters.md#must_not) и [should](../../Searching/Filters.md#should) JSON `bool` запроса [bool](../../Searching/Filters.md#bool-query). Примеры: diff --git a/manual/russian/Searching/Full_text_matching/Profiling.md b/manual/russian/Searching/Full_text_matching/Profiling.md index ac18aac8fc..f45b221b3f 100644 --- a/manual/russian/Searching/Full_text_matching/Profiling.md +++ b/manual/russian/Searching/Full_text_matching/Profiling.md @@ -1,19 +1,19 @@ -# Поиск с профилированием +# Профилирование поиска ## Как интерпретируется запрос -Рассмотрим этот пример сложного запроса: +Рассмотрим этот сложный пример запроса: ```sql "hello world" @title "example program"~5 @body python -(php|perl) @* code ``` Полное значение этого поиска: -* Найти слова 'hello' и 'world' рядом друг с другом в любом поле документа; -* Кроме того, в том же документе должны содержаться слова 'example' и 'program' в поле заголовка, с не более чем 5 словами между ними (не включая 5); (например, "example PHP program" подойдет, а "example script to introduce outside data into the correct context for your program" — нет, так как между двумя терминами 5 или более слов) -* Более того, в том же документе должно быть слово 'python' в поле body, при этом исключая 'php' или 'perl'; -* Наконец, в том же документе должно содержаться слово 'code' в любом поле. +* Найти слова «hello» и «world» рядом в любом поле внутри документа; +* Кроме того, в том же документе должны также содержаться слова «example» и «program» в поле заголовка, с не более чем 5 словами между ними, не включая эти слова; (Например, «example PHP program» будет подходить, но «example script to introduce outside data into the correct context for your program» — нет, поскольку между двумя терминами 5 или более слов) +* Более того, в том же документе должно быть слово «python» в поле body, при этом исключая «php» или «perl»; +* Наконец, тот же документ должен содержать слово «code» в любом поле. -Оператор OR имеет приоритет над AND, поэтому "looking for cat | dog | mouse" означает "looking for (cat | dog | mouse)", а не "(looking for cat) | dog | mouse". +Оператор OR имеет приоритет над AND, поэтому «looking for cat | dog | mouse» означает «looking for (cat | dog | mouse)», а не «(looking for cat) | dog | mouse». Чтобы понять, как будет выполняться запрос, Manticore Search предоставляет инструменты профилирования запросов для изучения дерева запроса, сгенерированного выражением запроса. @@ -21,25 +21,25 @@ ## Профилирование дерева запроса в SQL -Чтобы включить профилирование полнотекстового запроса с помощью SQL-запроса, необходимо активировать его перед выполнением нужного запроса: +Чтобы включить профилирование полнотекстового запроса с помощью SQL-запроса, необходимо активировать его до выполнения нужного запроса: ```sql SET profiling =1; SELECT * FROM test WHERE MATCH('@title abc* @body hey'); ``` -Чтобы просмотреть дерево запроса, выполните команду `SHOW PLAN` сразу после выполнения запроса: +Чтобы посмотреть дерево запроса, выполните команду `SHOW PLAN` сразу после выполнения запроса: ```sql SHOW PLAN; ``` -Эта команда вернет структуру выполненного запроса. Имейте в виду, что 3 оператора — SET profiling, сам запрос и SHOW — должны выполняться в одной сессии. +Эта команда вернёт структуру выполненного запроса. Учтите, что 3 оператора — SET profiling, запрос и SHOW — должны выполняться в одной сессии. -## Профилирование запроса в HTTP JSON +## Профилирование запроса через HTTP JSON -При использовании протокола HTTP JSON можно просто включить `"profile":true`, чтобы получить в ответе структуру дерева полнотекстового запроса. +При использовании протокола HTTP JSON можно просто включить `"profile":true`, чтобы в ответе получить структуру дерева полнотекстового запроса. ```json { @@ -51,24 +51,24 @@ SHOW PLAN; } } ``` -В ответе будет объект `profile`, содержащий член `query`. +В ответе будет объект `profile`, содержащий элемент `query`. Свойство `query` содержит преобразованное дерево полнотекстового запроса. Каждый узел состоит из: * `type`: тип узла, который может быть AND, OR, PHRASE, KEYWORD и т.д. -* `description`: поддерево запроса для этого узла, представленное в виде строки (в формате `SHOW PLAN`) -* `children`: дочерние узлы, если есть +* `description`: поддерево запроса для этого узла, представленное строкой (в формате `SHOW PLAN`) +* `children`: дочерние узлы, если они есть * `max_field_pos`: максимальная позиция в поле -У узла ключевого слова дополнительно будут: +У узла ключевого слова дополнительно есть: * `word`: преобразованное ключевое слово. * `querypos`: позиция этого ключевого слова в запросе. * `excluded`: ключевое слово исключено из запроса. -* `expanded`: ключевое слово добавлено расширением префикса. +* `expanded`: ключевое слово добавлено с помощью расширения префикса. * `field_start`: ключевое слово должно появиться в начале поля. * `field_end`: ключевое слово должно появиться в конце поля. -* `boost`: IDF ключевого слова будет умножен на это значение. +* `boost`: ИДФ ключевого слова будет умножен на это значение. @@ -507,7 +507,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -В некоторых случаях оцениваемое дерево запроса может значительно отличаться от исходного из-за расширений и других преобразований. +В некоторых случаях оцениваемое дерево запроса может существенно отличаться от исходного из-за расширений и других преобразований. ##### SQL: @@ -1177,7 +1177,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea ## Профилирование без выполнения запроса -SQL-оператор `EXPLAIN QUERY` позволяет отобразить дерево выполнения для заданного полнотекстового запроса без фактического выполнения поискового запроса по таблице. +SQL оператор `EXPLAIN QUERY` позволяет показать дерево выполнения для данного полнотекстового запроса без фактического выполнения поискового запроса по таблице. @@ -1201,10 +1201,47 @@ Variable: transformed_tree AND(fields=(title), KEYWORD(running, querypos=1, morphed)))) AND(fields=(body), KEYWORD(dog, querypos=2, morphed))) ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY t '@title a'" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "AND(fields=(title), KEYWORD(a, querypos=1))" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] + +``` + -`EXPLAIN QUERY ... option format=dot` позволяет отобразить дерево выполнения заданного полнотекстового запроса в иерархическом формате, подходящем для визуализации с помощью существующих инструментов, таких как https://dreampuf.github.io/GraphvizOnline: +`EXPLAIN QUERY ... option format=dot` позволяет вывести дерево выполнения переданного полнотекстового запроса в иерархическом формате, подходящем для визуализации с помощью существующих инструментов, таких как https://dreampuf.github.io/GraphvizOnline: ![EXPLAIN QUERY graphviz example](graphviz.png) @@ -1236,23 +1273,59 @@ Variable: transformed_tree 4 [shape=record label="me | { querypos=2 }"] } ``` + + + +```JSON +POST /sql?mode=raw -d "EXPLAIN QUERY tbl '@title a' option format=dot" +``` + + +```JSON +[ + { + "columns": [ + { + "Variable": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable": "transformed_tree", + "Value": "digraph \"transformed_tree\" {\n\n0 [shape=record,style=filled label=\"AND | { fields=(title) }\"]\n0 -> 1\n1 [shape=record label=\"a | { qp=1 }\"]\n}" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## Просмотр значений факторов совпадения -При использовании ранжировщика выражений можно вывести значения вычисленных факторов с помощью функции [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29). +При использовании ранжировщика выражений возможно получить значения вычисленных факторов с помощью функции [PACKEDFACTORS()](../../Functions/Searching_and_ranking_functions.md#PACKEDFACTORS%28%29). Функция возвращает: * Значения факторов на уровне документа (таких как bm25, field_mask, doc_word_count) -* Список каждого поля, которое сгенерировало совпадение (включая lcs, hit_count, word_count, sum_idf, min_hit_pos и т.д.) +* Список каждого поля, сгенерировавшего совпадение (включая lcs, hit_count, word_count, sum_idf, min_hit_pos и др.) * Список каждого ключевого слова из запроса вместе с их значениями tf и idf -Эти значения можно использовать для понимания, почему определённые документы получают более низкие или высокие оценки в поиске, или для уточнения существующего выражения ранжирования. +Эти значения могут быть использованы для понимания причин, по которым определённые документы получают более низкие или высокие оценки в поиске, или для уточнения существующего выражения ранжирования. -Example: +Пример: ```sql @@ -1271,6 +1344,41 @@ packedfactors(): bm25=569, bm25a=0.617197, field_mask=2, doc_word_count=2, word1=(tf=1, idf=0.215338) 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id, PACKEDFACTORS() FROM test1 WHERE MATCH('test one') OPTION ranker=expr('1')" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "packedfactors()": { + "type": "string" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "packedfactors()": "bm25=500, bm25a=0.500000, field_mask=1, doc_word_count=1, field0=(lcs=1, hit_count=1, word_count=1, tf_idf=0.000000, min_idf=0.000000, max_idf=0.000000, sum_idf=0.000000, min_hit_pos=1, min_best_span_pos=1, exact_hit=1, max_window_hits=1, min_gaps=0, exact_order=1, lccs=1, wlccs=0.000000, atc=0.000000), word0=(tf=1, idf=0.000000)" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Searching/Grouping.md b/manual/russian/Searching/Grouping.md index 2e82da2f72..41b110297e 100644 --- a/manual/russian/Searching/Grouping.md +++ b/manual/russian/Searching/Grouping.md @@ -1,7 +1,7 @@ # Группировка результатов поиска -Группировка результатов поиска часто полезна для получения количества совпадений по группам или других агрегатов. Например, это удобно для построения графика, иллюстрирующего количество совпадающих публикаций в блогах по месяцам, или для группировки результатов веб-поиска по сайту, сообщений форума по автору и т.д. +Группировка результатов поиска часто полезна для получения количества совпадений по каждой группе или других агрегатов. Например, это удобно для создания графика с количеством подходящих блог-постов по месяцам или группировки результатов веб-поиска по сайтам, форумных сообщений по авторам и т.д. Manticore поддерживает группировку результатов поиска по одному или нескольким столбцам и вычисляемым выражениям. Результаты могут: @@ -9,7 +9,7 @@ Manticore поддерживает группировку результатов * Возвращать более одной строки на группу * Фильтровать группы * Сортировать группы -* Агрегироваться с помощью [функций агрегации](../Searching/Grouping.md#Aggregation-functions) +* Агрегироваться с использованием [функций агрегации](../Searching/Grouping.md#Aggregation-functions) Общий синтаксис: @@ -29,7 +29,7 @@ where_condition: {aggregation expression alias | COUNT(*)} ``` -Формат JSON-запроса в настоящее время поддерживает базовую группировку, которая может получать агрегатные значения и их count(*). +Формат JSON-запроса на данный момент поддерживает базовую группировку, которая может извлекать агрегированные значения и их count(*). ```json { @@ -46,19 +46,19 @@ where_condition: {aggregation expression alias | COUNT(*)} } ``` -Стандартный вывод запроса возвращает набор результатов без группировки, который можно скрыть с помощью `limit` (или `size`). -Для агрегации необходимо установить `size` для размера результирующего набора групп. +Стандартный результат запроса возвращает набор без группировки, который можно скрыть с помощью `limit` (или `size`). +Для агрегации необходимо задать `size` в размере набора результатов для группы. ### Просто группировка -Группировка довольно проста — просто добавьте "GROUP BY smth" в конец вашего `SELECT` запроса. Что-то может быть: +Группировка достаточно проста - просто добавьте "GROUP BY smth" в конец вашего `SELECT` запроса. Что-то может быть: -* Любым нефулл-текстовым полем из таблицы: integer, float, string, MVA (атрибут с множественным значением) -* Или, если вы использовали псевдоним в списке `SELECT`, вы также можете использовать GROUP BY по нему +* Любым не полнотекстовым полем из таблицы: integer, float, string, MVA (мульти-значение атрибута) +* Или, если вы использовали псевдоним в списке `SELECT`, вы также можете группировать по нему -Вы можете опустить любые [функции агрегации](../Searching/Grouping.md#Aggregation-functions) в списке `SELECT`, и это все равно будет работать: +Вы можете опустить любые [функции агрегации](../Searching/Grouping.md#Aggregation-functions) в списке `SELECT`, и это продолжит работать: ##### Пример: @@ -79,14 +79,54 @@ SELECT release_year FROM films GROUP BY release_year LIMIT 5; | 2000 | +--------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year FROM films GROUP BY release_year LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2004 + }, + { + "release_year": 2002 + }, + { + "release_year": 2001 + }, + { + "release_year": 2005 + }, + { + "release_year": 2000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -В большинстве случаев, однако, вы захотите получить некоторую агрегированную информацию для каждой группы, например: +В большинстве случаев, однако, вы захотите получить некоторые агрегированные данные для каждой группы, такие как: -* `COUNT(*)` просто чтобы получить количество элементов в каждой группе +* `COUNT(*)`, чтобы просто получить количество элементов в каждой группе * или `AVG(field)`, чтобы вычислить среднее значение поля внутри группы -Для HTTP JSON-запросов использование одного бакета `aggs` с `limit=0` на уровне основного запроса работает аналогично SQL-запросу с `GROUP BY` и `COUNT(*)`, обеспечивая эквивалентное поведение и производительность. +Для HTTP JSON-запросов использование одного `aggs` bucket с `limit=0` на основном уровне запроса работает аналогично SQL запросу с `GROUP BY` и `COUNT(*)`, обеспечивая эквивалентное поведение и производительность. ##### Пример: @@ -502,7 +542,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea ##### Сортировка групп -По умолчанию группы не сортируются, и следующим обычно желаемым действием является их упорядочивание по чему-то, например, по полю, по которому происходит группировка: +По умолчанию группы не сортируются, и следующая типичная операция — отсортировать их по чему-либо, например, по полю, по которому ведется группировка: ##### Пример: @@ -523,12 +563,62 @@ SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_ | 2004 | 108 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_year asc limit 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2000, + "count(*)": 97 + }, + { + "release_year": 2001, + "count(*)": 91 + }, + { + "release_year": 2002, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2004, + "count(*)": 108 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -В качестве альтернативы, вы можете сортировать по агрегату: +Или же можно сортировать по агрегату: -* по `count(*)`, чтобы сначала показать группы с наибольшим количеством элементов -* по `avg(rental_rate)`, чтобы сначала показать фильмы с наивысшим рейтингом. Обратите внимание, что в примере это делается через псевдоним: `avg(rental_rate)` сначала сопоставлен с `avg` в списке `SELECT`, а затем мы просто делаем `ORDER BY avg` +* по `count(*)`, чтобы показывать группы с наибольшим количеством элементов первыми +* по `avg(rental_rate)`, чтобы показывать фильмы с самым высоким рейтингом первыми. Обратите внимание, что в примере это сделано через псевдоним: `avg(rental_rate)` сначала отображается в `avg` в списке `SELECT`, а потом мы просто делаем `ORDER BY avg` @@ -567,11 +657,61 @@ SELECT release_year, AVG(rental_rate) avg FROM films GROUP BY release_year ORDER | 2008 | 2.99000049 | +--------------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year ORDER BY count(*) desc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2004, + "count(*)": 108 + }, + { + "release_year": 2003, + "count(*)": 106 + }, + { + "release_year": 2006, + "count(*)": 103 + }, + { + "release_year": 2008, + "count(*)": 102 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + ##### GROUP BY по нескольким полям одновременно -В некоторых случаях вы можете захотеть группировать не только по одному полю, но по нескольким сразу, например, по категории фильма и году: +В некоторых случаях вы можете захотеть группировать не только по одному полю, но и по нескольким сразу, например, по категории фильма и году: ##### Пример: @@ -688,7 +828,7 @@ POST /search -d ' ##### Дайте мне N строк -Иногда полезно видеть не только один элемент на группу, но и несколько. Это легко достигается с помощью `GROUP N BY`. Например, в следующем случае мы получаем два фильма для каждого года вместо одного, который вернул бы простой `GROUP BY release_year`. +Иногда полезно видеть не только один элемент на группу, а несколько. Это легко достигается с помощью `GROUP N BY`. Например, в следующем случае мы получаем два фильма для каждого года вместо одного, что вернул бы простой `GROUP BY release_year`. ##### Пример: @@ -710,14 +850,68 @@ SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_y | 2007 | ARACHNOPHOBIA ROLLERCOASTER | +--------------+-----------------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_year DESC LIMIT 6;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "ALICE FANTASIA" + }, + { + "release_year": 2009, + "title": "ALIEN CENTER" + }, + { + "release_year": 2008, + "title": "AMADEUS HOLY" + }, + { + "release_year": 2008, + "title": "ANACONDA CONFESSIONS" + }, + { + "release_year": 2007, + "title": "ANGELS LIFE" + }, + { + "release_year": 2007, + "title": "ARACHNOPHOBIA ROLLERCOASTER" + } + ], + "total": 6, + "error": "", + "warning": "" + } +] +``` + ##### Сортировка внутри группы -Еще одно важное требование для аналитики — сортировка элементов внутри группы. Для этого используйте конструкцию `WITHIN GROUP ORDER BY ... {ASC|DESC}`. Например, получим фильм с наивысшим рейтингом для каждого года. Обратите внимание, что это работает параллельно с обычным `ORDER BY`: +Еще одно важное требование аналитики — сортировать элементы внутри группы. Для этого используйте конструкцию `WITHIN GROUP ORDER BY ... {ASC|DESC}`. Например, получим фильм с наивысшим рейтингом за каждый год. Обратите внимание, что это работает параллельно с обычным `ORDER BY`: * `WITHIN GROUP ORDER BY` сортирует результаты **внутри группы** -* а простой `GROUP BY` **сортирует сами группы** +* в то время как просто `GROUP BY` **сортирует сами группы** Эти два работают полностью независимо. @@ -741,11 +935,71 @@ SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN | 2005 | AIRPLANE SIERRA | 4.990000 | +--------------+------------------+-------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN GROUP ORDER BY rental_rate DESC ORDER BY release_year DESC LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "title": { + "type": "string" + } + }, + { + "rental_rate": { + "type": "long" + } + } + ], + "data": [ + { + "release_year": 2009, + "title": "AMERICAN CIRCUS", + "rental_rate": 4.990000 + }, + { + "release_year": 2009, + "title": "ANTHEM LUKE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ATTACKS HATE", + "rental_rate": 4.990000 + }, + { + "release_year": 2008, + "title": "ALADDIN CALENDAR", + "rental_rate": 4.990000 + }, + { + "release_year": 2007, + "title": "AIRPLANE SIERRA", + "rental_rate": 4.990000 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + ##### Фильтрация групп -`HAVING expression` — полезная конструкция для фильтрации групп. В то время как `WHERE` применяется до группировки, `HAVING` работает с уже сгруппированными данными. Например, оставим только те года, когда средний рейтинг аренды фильмов за этот год был выше 3. В итоге мы получаем только четыре года: +`HAVING expression` — полезный оператор для фильтрации групп. В то время как `WHERE` применяется до группировки, `HAVING` работает с группами. Например, оставим только те годы, когда средняя арендная ставка фильмов за этот год была выше 3. Мы получим только четыре года: ##### Пример: @@ -765,15 +1019,60 @@ SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVIN | 2006 | 3.26184368 | +--------------+------------+ ``` + +```JSON +POST /sql?mode=raw -d "SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVING avg > 3;" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "avg": 3.08259249 + }, + { + "release_year": 2001, + "avg": 3.09989142 + }, + { + "release_year": 2000, + "avg": 3.17556739 + }, + { + "release_year": 2006, + "avg": 3.26184368 + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + ##### GROUPBY() -Есть функция `GROUPBY()`, которая возвращает ключ текущей группы. Она полезна во многих случаях, особенно когда вы [GROUP BY по MVA](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29) или по [JSON значению](../Searching/Grouping.md#Grouping-by-a-JSON-node). +Существует функция `GROUPBY()`, которая возвращает ключ текущей группы. Она полезна во многих случаях, особенно когда вы [GROUP BY по MVA](../Searching/Grouping.md#Grouping-by-MVA-%28multi-value-attributes%29) или по [JSON значению](../Searching/Grouping.md#Grouping-by-a-JSON-node). Её также можно использовать в `HAVING`, например, чтобы оставить только годы 2000 и 2002. -Обратите внимание, что `GROUPBY()` не рекомендуется использовать, когда вы GROUP BY по нескольким полям одновременно. Она всё равно будет работать, но поскольку ключ группы в этом случае является составным из значений полей, он может не отображаться так, как вы ожидаете. +Обратите внимание, что `GROUPBY()` не рекомендуется использовать, когда вы группируете по нескольким полям одновременно. Она всё ещё будет работать, но поскольку ключ группы в этом случае является составным из значений полей, он может не отображаться так, как вы ожидаете. ##### Пример: @@ -791,15 +1090,53 @@ SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() | 2000 | 97 | +--------------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() IN (2000, 2002);" +``` + +```JSON +[ + { + "columns": [ + { + "release_year": { + "type": "long" + } + }, + { + "count": { + "type": "long long" + } + } + ], + "data": [ + { + "release_year": 2002, + "count": 108 + }, + { + "release_year": 2000, + "count": 97 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -##### Группировка по MVA (мультизначным атрибутам) -Manticore поддерживает группировку по [MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29). Чтобы показать, как это работает, давайте создадим таблицу "shoes" с MVA "sizes" и вставим в неё несколько документов: +##### Группировка по MVA (многозначные атрибуты) +Manticore поддерживает группировку по [MVA](../Creating_a_table/Data_types.md#Multi-value-integer-%28MVA%29). Чтобы показать, как это работает, создадим таблицу "shoes" с MVA "sizes" и вставим в неё несколько документов: ```sql create table shoes(title text, sizes multi); insert into shoes values(0,'nike',(40,41,42)),(0,'adidas',(41,43)),(0,'reebook',(42,43)); ``` -так что у нас есть: +таким образом у нас есть: ```sql SELECT * FROM shoes; +---------------------+----------+---------+ @@ -810,7 +1147,7 @@ SELECT * FROM shoes; | 1657851069130080267 | 42,43 | reebook | +---------------------+----------+---------+ ``` -Если теперь мы сделаем GROUP BY по "sizes", он обработает все наши мультизначные атрибуты и вернёт агрегацию для каждого, в данном случае просто количество: +Если теперь мы сделаем GROUP BY по "sizes", будут обработаны все наши многозначные атрибуты и возвращена агрегация для каждого, в данном случае просто количество: ##### Пример: @@ -1492,17 +1829,17 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -## Aggregation functions -Besides `COUNT(*)`, which returns the number of elements in each group, you can use various other aggregation functions: +## Функции агрегации +Кроме `COUNT(*)`, который возвращает количество элементов в каждой группе, вы можете использовать различные другие функции агрегации: ##### COUNT(DISTINCT field) -While `COUNT(*)` returns the number of all elements in the group, `COUNT(DISTINCT field)` returns the number of unique values of the field in the group, which may be completely different from the total count. For instance, you can have 100 elements in the group, but all with the same value for a certain field. `COUNT(DISTINCT field)` helps to determine that. To demonstrate this, let's create a table "students" with the student's name, age, and major: +В то время как `COUNT(*)` возвращает количество всех элементов в группе, `COUNT(DISTINCT field)` возвращает количество уникальных значений поля в группе, что может существенно отличаться от общего количества. Например, в группе может быть 100 элементов, но все с одинаковым значением определённого поля. `COUNT(DISTINCT field)` помогает это определить. Для демонстрации создадим таблицу "students" с именем студента, возрастом и специальностью: ```sql CREATE TABLE students(name text, age int, major string); INSERT INTO students values(0,'John',21,'arts'),(0,'William',22,'business'),(0,'Richard',21,'cs'),(0,'Rebecca',22,'cs'),(0,'Monica',21,'arts'); ``` -so we have: +так что у нас есть: ```sql MySQL [(none)]> SELECT * from students; @@ -1517,24 +1854,24 @@ MySQL [(none)]> SELECT * from students; +---------------------+------+----------+---------+ ``` -In the example, you can see that if we GROUP BY major and display both `COUNT(*)` and `COUNT(DISTINCT age)`, it becomes clear that there are two students who chose the major "cs" with two unique ages, but for the major "arts", there are also two students, yet only one unique age. +В примере видно, что если мы делаем GROUP BY по major и показываем одновременно `COUNT(*)` и `COUNT(DISTINCT age)`, становится ясно, что среди студентов, выбравших специальность "cs", двое и у них два уникальных возраста, а для специальности "arts" также двое студентов, но только один уникальный возраст. -There can be at most one `COUNT(DISTINCT)` per query. +В одном запросе может быть не более одного `COUNT(DISTINCT)`. -** By default, counts are approximate ** +**По умолчанию подсчёты приблизительные** -Actually, some of them are exact, while others are approximate. More on that below. +На самом деле, некоторые из них точные, а другие — приблизительные. Подробнее об этом ниже. -Manticore supports two algorithms for computing counts of distinct values. One is a legacy algorithm that uses a lot of memory and is usually slow. It collects `{group; value}` pairs, sorts them, and periodically discards duplicates. The benefit of this approach is that it guarantees exact counts within a plain table. You can enable it by setting the [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option to `0`. +Manticore поддерживает два алгоритма подсчёта количества уникальных значений. Один — устаревший алгоритм, который использует много памяти и обычно медленный. Он собирает пары `{group; value}`, сортирует их и периодически удаляет дубликаты. Преимущество этого подхода в том, что он гарантирует точный подсчёт для простой таблицы. Его можно включить, установив опцию [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) в значение `0`. -The other algorithm (enabled by default) loads counts into a hash table and returns its size. If the hash table becomes too large, its contents are moved into a `HyperLogLog`. This is where the counts become approximate since `HyperLogLog` is a probabilistic algorithm. The advantage is that the maximum memory usage per group is fixed and depends on the accuracy of the `HyperLogLog`. The overall memory usage also depends on the [max_matches](../Searching/Options.md#max_matches) setting, which reflects the number of groups. +Другой алгоритм (включён по умолчанию) загружает подсчёты в хеш-таблицу и возвращает её размер. Если хеш-таблица становится слишком большой, её содержимое переносится в `HyperLogLog`. Здесь подсчёты становятся приблизительными, поскольку `HyperLogLog` — вероятностный алгоритм. Преимущество в том, что максимальное использование памяти на группу фиксировано и зависит от точности `HyperLogLog`. Общее потребление памяти также зависит от настройки [max_matches](../Searching/Options.md#max_matches), отражающей количество групп. -The [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) option sets the threshold below which counts are guaranteed to be exact. The `HyperLogLog` accuracy setting and the threshold for the "hash table to HyperLogLog" conversion are derived from this setting. It's important to use this option with caution because doubling it will double the maximum memory required for count calculations. The maximum memory usage can be roughly estimated using this formula: `64 * max_matches * distinct_precision_threshold`. Note that this is the worst-case scenario, and in most cases, count calculations will use significantly less RAM. +Опция [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) задаёт порог, ниже которого подсчёты гарантированно точные. Настройки точности `HyperLogLog` и порог конверсии "хеш-таблица в HyperLogLog" выводятся из этой настройки. Важно с осторожностью использовать эту опцию, поскольку её удвоение приведёт к удвоению максимального объёма памяти, требуемой для подсчётов. Максимальное использование памяти примерно можно оценить формулой: `64 * max_matches * distinct_precision_threshold`. Учтите, что это наихудший сценарий, в большинстве случаев подсчёты используют существенно меньше оперативной памяти. -**`COUNT(DISTINCT)` against a distributed table or a real-time table consisting of multiple disk chunks may return inaccurate results**, but the result should be accurate for a distributed table consisting of local plain or real-time tables with the same schema (identical set/order of fields, but may have different tokenization settings). +**`COUNT(DISTINCT)` для распределённой таблицы или таблицы реального времени, состоящей из нескольких дисковых чанк, может возвращать неточные результаты**, но результат должен быть точным для распределённой таблицы, состоящей из локальных простых или таблиц реального времени с одинаковой схемой (идентичный набор/порядок полей, но настройки токенизации могут отличаться). -##### Example: +##### Пример: ```sql @@ -1550,17 +1887,67 @@ SELECT major, count(*), count(distinct age) FROM students GROUP BY major; | cs | 2 | 2 | +----------+----------+---------------------+ ``` + + +```JSON +POST /sql?mode=raw - d "SELECT major, count(*), count(distinct age) FROM students GROUP BY major;" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### GROUP_CONCAT(field) -Often, you want to better understand the contents of each group. You can use [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows) for that, but it would return additional rows you might not want in the output. `GROUP_CONCAT()` enriches your grouping by concatenating values of a specific field in the group. Let's take the previous example and improve it by displaying all the ages in each group. +Часто хочется лучше понять содержимое каждой группы. Для этого можно использовать [GROUP N BY](../Searching/Grouping.md#Give-me-N-rows), но он вернёт дополнительные строки, которых может не быть в выводе. `GROUP_CONCAT()` обогащает группировку, объединяя значения конкретного поля в группе. Возьмём предыдущий пример и улучшим его, отобразив все возраста в каждой группе. -`GROUP_CONCAT(field)` returns the list as comma-separated values. +`GROUP_CONCAT(field)` возвращает список через запятую. -##### Example: +##### Пример: ```sql @@ -1576,13 +1963,71 @@ SELECT major, count(*), count(distinct age), group_concat(age) FROM students GRO | cs | 2 | 2 | 21,22 | +----------+----------+---------------------+-------------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT major, count(*), count(distinct age), group_concat(age) FROM students GROUP BY major" +``` + +```JSON +[ + { + "columns": [ + { + "major": { + "type": "string" + } + }, + { + "count(*)": { + "type": "long long" + } + }, + { + "count(distinct age)": { + "type": "long long" + } + }, + { + "group_concat(age)": { + "type": "string" + } + } + ], + "data": [ + { + "major": "arts", + "count(*)": 2, + "count(distinct age)": 1, + "group_concat(age)": 21,21 + }, + { + "major": "business", + "count(*)": 1, + "count(distinct age)": 1, + "group_concat(age)": 22 + }, + { + "major": "cs", + "count(*)": 2, + "count(distinct age)": 2, + "group_concat(age)": 21,22 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ##### SUM(), MIN(), MAX(), AVG() -Of course, you can also obtain the sum, average, minimum, and maximum values within a group. +Разумеется, можно получить сумму, среднее, минимальное и максимальное значения в группе. -##### Example: +##### Пример: ```sql @@ -1600,21 +2045,101 @@ SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental | 2004 | 300.920044 | 0.990000 | 4.990000 | 2.78629661 | +------+------------+----------+----------+------------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, sum(rental_rate) sum, min(rental_rate) min, max(rental_rate) max, avg(rental_rate) avg FROM films GROUP BY release_year ORDER BY year asc LIMIT 5;" +``` + +```JSON +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "sum": { + "type": "long long" + } + }, + { + "min": { + "type": "long long" + } + }, + { + "max": { + "type": "long long" + } + }, + { + "avg": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2000, + "sum": 308.030029, + "min": 0.990000, + "max": 4.990000, + "avg": 3.17556739 + }, + { + "year": 2001, + "sum": 282.090118, + "min": 0.990000, + "max": 4.990000, + "avg": 3.09989142 + }, + { + "year": 2002, + "sum": 332.919983, + "min": 0.99, + "max": 4.990000, + "avg": 3.08259249 + }, + { + "year": 2003, + "sum": 310.940063, + "min": 0.990000, + "max": 4.990000, + "avg": 2.93339682 + }, + { + "year": 2004, + "sum": 300.920044, + "min": 0.990000, + "max": 4.990000, + "avg": 2.78629661 + } + ], + "total": 5, + "error": "", + "warning": "" + } +] +``` + -## Grouping accuracy +## Точность группировки -Grouping is done in fixed memory, which depends on the [max_matches](../Searching/Options.md#max_matches) setting. If `max_matches` allows for storage of all found groups, the results will be 100% accurate. However, if the value of `max_matches` is lower, the results will be less accurate. +Группировка выполняется в фиксированной памяти, которая зависит от настройки [max_matches](../Searching/Options.md#max_matches). Если `max_matches` позволяет сохранить все найденные группы, результаты будут 100% точными. Однако, если значение `max_matches` меньше, результаты будут менее точными. -When parallel processing is involved, it can become more complicated. When `pseudo_sharding` is enabled and/or when using an RT table with several disk chunks, each chunk or pseudo shard gets a result set that is no larger than `max_matches`. This can lead to inaccuracies in aggregates and group counts when the result sets from different threads are merged. To fix this, either a larger `max_matches` value or disabling parallel processing can be used. +При использовании параллельной обработки ситуация усложняется. При включённом `pseudo_sharding` и/или при использовании RT-таблицы с несколькими дисковыми чанками каждая часть или псевдо-шард получает набор результатов не больше чем `max_matches`. Это может привести к неточностям в агрегатах и подсчётах групп при объединении результатов из разных потоков. Чтобы исправить это, можно либо увеличить значение `max_matches`, либо отключить параллельную обработку. -Manticore will try to increase `max_matches` up to [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold) if it detects that groupby may return inaccurate results. Detection is based on the number of unique values of the groupby attribute, which is retrieved from secondary indexes (if present). +Manticore попробует увеличить `max_matches` до [max_matches_increase_threshold](../Searching/Options.md#max_matches_increase_threshold), если обнаружит, что groupby может возвращать неточные результаты. Обнаружение основывается на количестве уникальных значений атрибута groupby, которые извлекаются из вторичных индексов (если они присутствуют). -To ensure accurate aggregates and/or group counts when using RT tables or `pseudo_sharding`, `accurate_aggregation` can be enabled. This will try to increase `max_matches` up to the threshold, and if the threshold is not high enough, Manticore will disable parallel processing for the query. +Для обеспечения точных агрегатов и/или подсчёта групп при использовании RT таблиц или `pseudo_sharding` можно включить `accurate_aggregation`. Это попытается увеличить `max_matches` до порога, а если порог недостаточно высок, Manticore отключит параллельную обработку для запроса. -##### Example: +##### Пример: ```sql @@ -1653,6 +2178,143 @@ MySQL [(none)]> SELECT release_year year, count(*) FROM films GROUP BY year limi | 2001 | 91 | +------+----------+ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + }, + { + "year": 2005, + "count(*)": 93 + }, + { + "year": 2000, + "count(*)": 97 + }, + ], + "total": 5, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=1;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=2;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 76 + }, + { + "year": 2002, + "count(*)": 74 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +POST /sql?mode=raw -d "SELECT release_year year, count(*) FROM films GROUP BY year limit 5 option max_matches=3;" +[ + { + "columns": [ + { + "year": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "year": 2004, + "count(*)": 108 + }, + { + "year": 2002, + "count(*)": 108 + }, + { + "year": 2001, + "count(*)": 91 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Searching/Highlighting.md b/manual/russian/Searching/Highlighting.md index 196b1b2e72..8cc8cdf802 100644 --- a/manual/russian/Searching/Highlighting.md +++ b/manual/russian/Searching/Highlighting.md @@ -384,19 +384,19 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea Устанавливает начальное значение макроса `%SNIPPET_ID%` (который обнаруживается и расширяется в строках `before_match`, `after_match`). Значение по умолчанию — 1. #### html_strip_mode -Определяет режим удаления HTML. По умолчанию `index`, что означает использование настроек таблицы. Другие значения включают `none` и `strip`, которые принудительно пропускают или применяют удаление независимо от настроек таблицы; и `retain`, который сохраняет HTML-разметку и защищает её от подсветки. Режим `retain` можно использовать только при подсветке полных документов, поэтому требуется отсутствие ограничений на размер фрагментов. Допустимые строковые значения: `none`, `strip`, `index` и `retain`. +Определяет режим удаления HTML. По умолчанию `index`, что означает использование настроек таблицы. Другие значения включают `none` и `strip`, которые принудительно пропускают или применяют удаление независимо от настроек таблицы; и `retain`, который сохраняет HTML-разметку и защищает её от подсветки. Режим `retain` можно использовать только при подсветке полных документов, поэтому он требует отсутствия ограничений на размер фрагмента. Допустимые строковые значения: `none`, `strip`, `index` и `retain`. #### allow_empty -Разрешает возвращать пустую строку в качестве результата подсветки, если не удалось сгенерировать фрагменты в текущем поле (нет совпадений по ключевым словам или фрагменты не помещаются в лимит). По умолчанию возвращается начало исходного текста вместо пустой строки. Значение по умолчанию 0 (не разрешать пустой результат). +Разрешает возвращать пустую строку в качестве результата подсветки, если в текущем поле не удалось сгенерировать фрагменты (нет совпадений по ключевым словам или ни один фрагмент не помещается в лимит). По умолчанию возвращается начало исходного текста вместо пустой строки. Значение по умолчанию — 0 (не разрешать пустой результат). #### snippet_boundary -Обеспечивает, чтобы фрагменты не пересекали границы предложения, абзаца или зоны (при использовании с таблицей, у которой включены соответствующие настройки индексации). Допустимые значения: `sentence`, `paragraph` и `zone`. +Гарантирует, что фрагменты не будут пересекать границы предложения, абзаца или зоны (при использовании с таблицей, в которой включены соответствующие настройки индексирования). Допустимые значения: `sentence`, `paragraph` и `zone`. #### emit_zones -Вставляет HTML-тег с именем окружающей зоны перед каждым фрагментом. Значение по умолчанию 0 (не вставлять имена зон). +Вставляет HTML-тег с именем окружающей зоны перед каждым фрагментом. По умолчанию 0 (не вставлять имена зон). #### force_snippets -Определяет, следует ли принудительно генерировать фрагменты, даже если лимиты позволяют подсветить весь текст. Значение по умолчанию 0 (не принуждать генерацию фрагментов). +Определяет необходимость принудительной генерации фрагментов, даже если лимиты позволяют подсветить весь текст. По умолчанию 0 (не принуждать генерацию фрагментов). ##### SQL: @@ -839,7 +839,7 @@ HIGHLIGHT([options], [field_list], [query] ) ``` -По умолчанию работает без аргументов. +По умолчанию выполняется без аргументов. ##### SQL: @@ -860,11 +860,43 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('before'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('before');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "A door opened before them, revealing a small room." + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -`HIGHLIGHT()` извлекает все доступные полнотекстовые поля из хранилища документов и подсвечивает их по заданному запросу. Поддерживается синтаксис полей в запросах. Текст полей разделяется с помощью `field_separator`, который можно изменить в опциях. +`HIGHLIGHT()` извлекает все доступные полнотекстовые поля из хранилища документов и подсвечивает их относительно заданного запроса. В запросах поддерживается синтаксис поля. Текст поля разделяется с помощью `field_separator`, который можно изменить в опциях. ##### SQL: @@ -885,10 +917,42 @@ SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one'); 1 row in set (0.00 sec) ``` + +##### JSON: + + + +```json +POST /sql?mode=raw -d "SELECT HIGHLIGHT() FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight()": { + "type": "string" + } + } + ], + "data": [ + { + "highlight()": "Book one" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -Необязательный первый аргумент в `HIGHLIGHT()` — список опций. +Необязательный первый аргумент в `HIGHLIGHT()` — это список опций. ##### SQL: @@ -909,11 +973,41 @@ SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHE 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({before_match='[match]',after_match='[/match]'}) FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({before_match='[match]',after_match='[/match]'})": "Book [match]one[/match]" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + + -Необязательный второй аргумент — строка, содержащая одно поле или список полей, разделённых запятыми. Если этот аргумент присутствует, будут извлечены и подсвечены только указанные поля из хранилища документов. Пустая строка во втором аргументе означает «извлечь все доступные поля». +Необязательный второй аргумент — строка с одним полем или списком полей, разделённых запятыми. Если этот аргумент присутствует, будут извлечены и подсвечены только указанные поля из хранилища документов. Пустая строка в качестве второго аргумента означает «извлечь все доступные поля». ##### SQL: @@ -935,11 +1029,44 @@ SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title,content') FROM books WHERE MATCH('one|robots');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title,content')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title,content')": "Book one | They followed Bander. The robots remained at a polite distance, but their presence was a constantly felt threat." + }, + { + "highlight({},'title,content')": "Bander ushered all three into the room. One of the robots followed as well. Bander gestured the other robots away and entered itself. The door closed behind it." + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + + -В качестве альтернативы можно использовать второй аргумент для указания строкового атрибута или имени поля без кавычек. В этом случае переданная строка будет подсвечена по заданному запросу, но синтаксис полей игнорируется. +Кроме того, второй аргумент можно использовать для указания строкового атрибута или имени поля без кавычек. В этом случае переданная строка будет подсвечена относительно предоставленного запроса, но синтаксис поля игнорируется. ##### SQL: @@ -961,11 +1088,43 @@ SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({}, title) FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},title)": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},title)": "Book one" + }, + { + "highlight({},title)": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -Необязательный третий аргумент — запрос. Он используется для подсветки результатов поиска по запросу, отличному от того, что использовался для поиска. +Необязательный третий аргумент — запрос. Он используется для подсветки результатов поиска по запросу, отличному от использованного при поиске. ##### SQL: @@ -987,11 +1146,43 @@ SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one'); 2 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw - d "SELECT HIGHLIGHT({},'title', 'five') FROM books WHERE MATCH('one');" +``` + + +```JSON +[ + { + "columns": [ + { + "highlight({},'title', 'five')": { + "type": "string" + } + } + ], + "data": [ + { + "highlight({},'title', 'five')": "Book one" + }, + { + "highlight({},'title', 'five')": "Book five" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -Хотя `HIGHLIGHT()` предназначена для работы с сохранёнными полнотекстовыми полями и строковыми атрибутами, её также можно использовать для подсветки произвольного текста. Учтите, что если запрос содержит операторы поиска по полям (например, `@title hello @body world`), часть с полями в этом случае игнорируется. +Хотя `HIGHLIGHT()` предназначена для работы с сохранёнными полнотекстовыми полями и строковыми атрибутами, её также можно использовать для подсветки произвольного текста. Имейте в виду, что если запрос содержит операторы поиска по полям (например, `@title hello @body world`), часть с полями будет игнорироваться. ##### SQL: @@ -1012,24 +1203,53 @@ SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT HIGHLIGHT({},TO_STRING('some text to highlight'), 'highlight') FROM books WHERE MATCH('@title one');" +``` + + +```JSON +[ + { + "columns": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": { + "type": "string" + } + } + ], + "data": [ + { + " highlight({},TO_STRING('some text to highlight'), 'highlight')": "some text to highlight" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -Некоторые опции актуальны только при генерации одной строки в качестве результата (а не массива фрагментов). Это относится исключительно к SQL-функции `HIGHLIGHT()`: +Некоторые опции актуальны только при генерации одной строки в результате (не массива фрагментов). Это относится исключительно к SQL-функции `HIGHLIGHT()`: #### snippet_separator -Строка, вставляемая между фрагментами. Значение по умолчанию ` ... `. +Строка, вставляемая между фрагментами. Значение по умолчанию — ` ... `. #### field_separator -Строка, вставляемая между полями. Значение по умолчанию `|`. +Строка, вставляемая между полями. Значение по умолчанию — `|`. -Другой способ подсветки текста — использовать оператор [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS). Он в основном дублирует функциональность `HIGHLIGHT()`, но не может использовать встроенное хранилище документов. Однако может загружать исходный текст из файлов. +Другой способ подсветки текста — использование оператора [CALL SNIPPETS](../Searching/Highlighting.md#CALL-SNIPPETS). Он во многом дублирует функционал `HIGHLIGHT()`, но не может использовать встроенное хранилище документов. Вместо этого он может загружать исходный текст из файлов. -## Подсветка через HTTP +## Выделение через HTTP -Для подсветки результатов полнотекстового поиска в JSON-запросах через HTTP содержимое полей должно храниться в хранилище документов (включено по умолчанию). В примере полнотекстовые поля `content` и `title` извлекаются из хранилища документов и подсвечиваются по запросу, указанному в разделе `query`. +Для выделения результатов полнотекстового поиска в JSON-запросах через HTTP содержимое полей должно храниться в хранилище документов (включено по умолчанию). В примере полнотекстовые поля `content` и `title` извлекаются из хранилища документов и подсвечиваются по запросу, указанному в условии `query`. Подсвеченные фрагменты возвращаются в свойстве `highlight` массива `hits`. @@ -1360,7 +1580,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -Чтобы выделить все возможные поля, передайте пустой объект в качестве свойства `highlight`. +Для выделения всех возможных полей передайте пустой объект в свойстве `highlight`. ##### JSON: @@ -1692,19 +1912,19 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -В дополнение к общим опциям подсветки, для JSON-запросов через HTTP доступны несколько синонимов: +Кроме общих опций выделения, несколько синонимов доступны для JSON-запросов через HTTP: #### fields -Объект `fields` содержит имена атрибутов с опциями. Он также может быть массивом имен полей (без опций). +Объект `fields` содержит имена атрибутов с опциями. Также может быть массивом имен полей (без опций). -Обратите внимание, что по умолчанию подсветка пытается выделить результаты, соответствующие полнотекстовому запросу. В общем случае, если вы не указываете поля для подсветки, подсветка основана на вашем полнотекстовом запросе. Однако, если вы указываете поля для подсветки, выделение происходит только если полнотекстовый запрос совпадает с выбранными полями. +Обратите внимание, что по умолчанию выделение пытается подсветить результаты согласно полнотекстовому запросу. В общем случае, если вы не указываете поля для выделения, подсветка основана на вашем полнотекстовом запросе. Однако, если вы указываете поля для выделения, подсветка происходит только если полнотекстовый запрос совпадает с выбранными полями. #### encoder -`encoder` может быть установлен в `default` или `html`. При установке в `html` сохраняется HTML-разметка при подсветке. Это работает аналогично опции `html_strip_mode=retain`. +`encoder` может быть установлен в `default` или `html`. При установке в `html` сохраняется HTML-разметка при выделении. Это работает аналогично опции `html_strip_mode=retain`. #### highlight_query -Опция `highlight_query` позволяет выделять текст по запросу, отличному от вашего поискового запроса. Синтаксис такой же, как в основном `query`. +Опция `highlight_query` позволяет подсвечивать по запросу, отличному от вашего поискового. Синтаксис такой же, как в основном запросе `query`. ##### JSON: @@ -1975,7 +2195,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### pre_tags и post_tags -`pre_tags` и `post_tags` задают открывающие и закрывающие теги для выделенных фрагментов текста. Они работают аналогично опциям `before_match` и `after_match`. Эти параметры необязательны, значения по умолчанию — `` и ``. +`pre_tags` и `post_tags` задают открывающие и закрывающие теги для подсвечиваемых фрагментов текста. Они функционируют аналогично опциям `before_match` и `after_match`. Эти опции необязательны, значения по умолчанию — `` и ``. ##### JSON: @@ -2246,7 +2466,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### no_match_size -`no_match_size` работает аналогично опции `allow_empty`. Если установлено в 0, это эквивалентно `allow_empty=1`, позволяя возвращать пустую строку в качестве результата подсветки, если не удалось сгенерировать фрагмент. В противном случае возвращается начало поля. Параметр необязательный, значение по умолчанию — 1. +`no_match_size` работает аналогично опции `allow_empty`. Если установлено в 0, действует как `allow_empty=1`, позволяя возвращать пустую строку как результат подсветки, когда фрагмент не может быть сгенерирован. Иначе возвращается начало поля. Опционально, значение по умолчанию — 1. ##### JSON: @@ -2508,7 +2728,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### order -`order` задаёт порядок сортировки извлечённых фрагментов. Если установлено значение `"score"`, фрагменты сортируются по релевантности. Это опционально и работает аналогично опции `weight_order`. +`order` sets the sorting order of extracted snippets. If set to `"score"`, it sorts the extracted snippets in order of relevance. This is optional and works similarly to the `weight_order` option. ##### JSON: @@ -2770,7 +2990,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### fragment_size -`fragment_size` задаёт максимальный размер фрагмента в символах. Может быть глобальным или для каждого поля отдельно. Опции для поля переопределяют глобальные. Это опционально, значение по умолчанию — 256. Работает аналогично опции `limit`. +`fragment_size` sets the maximum snippet size in symbols. It can be global or per-field. Per-field options override global options. This is optional, with a default value of 256. It works similarly to the `limit` option. ##### JSON: @@ -3024,7 +3244,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### number_of_fragments -`number_of_fragments` ограничивает максимальное количество фрагментов в результате. Как и `fragment_size`, может быть глобальным или для каждого поля. Опционально, значение по умолчанию — 0 (без ограничений). Работает аналогично опции `limit_snippets`. +`number_of_fragments` limits the maximum number of snippets in the result. Like `fragment_size`, it can be global or per-field. This is optional, with a default value of 0 (no limit). It works similarly to the `limit_snippets` option. ##### JSON: @@ -3285,7 +3505,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### limit, limit_words, limit_snippets -Опции `limit`, `limit_words` и `limit_snippets` могут задаваться глобально или для каждого поля. Глобальные опции используются как лимиты для полей, если не переопределены опциями для конкретного поля. В примере поле `title` подсвечивается с настройками по умолчанию, а поле `content` использует другие лимиты. +Options like `limit`, `limit_words`, and `limit_snippets` can be set as global or per-field options. Global options are used as per-field limits unless per-field options override them. In the example, the `title` field is highlighted with default limit settings, while the `content` field uses a different limit. ##### JSON: @@ -3553,7 +3773,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea #### limits_per_field -Глобальные лимиты также можно задать, указав `limits_per_field=0`. Эта опция означает, что все объединённые результаты подсветки должны укладываться в заданные лимиты. Недостаток в том, что в одном поле может быть несколько подсвеченных фрагментов, а в другом — ни одного, если движок подсветки решит, что они более релевантны. +Global limits can also be enforced by specifying `limits_per_field=0`. Setting this option means that all combined highlighting results must be within the specified limits. The downside is that you may get several snippets highlighted in one field and none in another if the highlighting engine decides that they are more relevant. ##### JSON: @@ -3755,7 +3975,7 @@ res, _, _ := apiClient.SearchAPI.Search(context.Background()).SearchRequest(*sea -Оператор `CALL SNIPPETS` формирует фрагмент из предоставленных данных и запроса с использованием настроек указанной таблицы. Он не может получить доступ к встроенному хранилищу документов, поэтому рекомендуется использовать функцию [HIGHLIGHT()](../Searching/Highlighting.md). +Оператор `CALL SNIPPETS` формирует сниппет из предоставленных данных и запроса с использованием заданных настроек таблицы. Он не может получить доступ к встроенному хранилищу документов, поэтому рекомендуется использовать функцию [HIGHLIGHT()](../Searching/Highlighting.md). Синтаксис: @@ -3764,11 +3984,11 @@ CALL SNIPPETS(data, table, query[, opt_value AS opt_name[, ...]]) ``` #### data -`data` — источник, из которого извлекается фрагмент. Это может быть одна строка или список строк в фигурных скобках. +`data` служит источником, из которого извлекается сниппет. Это может быть либо одна строка, либо список строк, заключённых в фигурные скобки. #### table -`table` — имя таблицы, которая задаёт настройки обработки текста для генерации фрагмента. +`table` — имя таблицы, которая задаёт настройки обработки текста для генерации сниппетов. #### query -`query` — это полнотекстовый запрос, используемый для создания сниппетов. +`query` — полнотекстовый запрос, используемый для построения сниппетов. #### opt_value и opt_name `opt_value` и `opt_name` представляют собой [опции генерации сниппетов](../Searching/Highlighting.md). @@ -3790,20 +4010,52 @@ CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', ' 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('this is my document text','this is my another text'), 'forum', 'is text', 5 AS around, 200 AS limit);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -Большинство опций совпадает с опциями в [функции HIGHLIGHT()](../Searching/Highlighting.md). Однако есть несколько опций, которые можно использовать только с `CALL SNIPPETS`. +Большинство опций идентичны опциям функции [HIGHLIGHT()](../Searching/Highlighting.md). Однако существуют несколько опций, которые можно использовать только с `CALL SNIPPETS`. -Следующие опции можно использовать для подсветки текста, хранящегося в отдельных файлах: +Следующие опции могут использоваться для подсветки текста, хранящегося в отдельных файлах: #### load_files -Эта опция, при включении, рассматривает первый аргумент как имена файлов, а не как данные для извлечения сниппетов. Указанные файлы на стороне сервера будут загружены для получения данных. Для параллелизации работы при включенном флаге будет использовано до [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) рабочих потоков на запрос. По умолчанию 0 (без ограничений). Чтобы распределить генерацию сниппетов между удалёнными агентами, вызовите генерацию сниппетов в распределённой таблице, содержащей только одного(!) локального агента и нескольких удалённых. Опция [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) используется для генерации итогового имени файла. Например, если searchd настроен с `snippets_file_prefix = /var/data_` и в качестве имени файла передан `text.txt`, сниппеты будут сгенерированы из содержимого `/var/data_text.txt`. +При включении этой опции первый аргумент рассматривается как имена файлов, а не как данные для извлечения сниппетов. Указанные файлы на стороне сервера будут загружены для получения данных. Для параллелизации работы при включённом этом флаге на запрос будет выделено до [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) рабочих потоков. Значение по умолчанию — 0 (без ограничения). Чтобы распределить генерацию сниппетов между удалёнными агентами, вызовите генерацию сниппетов в распределённой таблице, содержащей только одного(!) локального агента и нескольких удалённых. Опция [snippets_file_prefix](../Creating_a_table/Creating_a_distributed_table/Remote_tables.md#snippets_file_prefix) используется для формирования конечного имени файла. Например, если searchd настроен с `snippets_file_prefix = /var/data_` и в качестве имени файла передаётся `text.txt`, сниппеты будут сгенерированы из содержимого файла `/var/data_text.txt`. #### load_files_scattered -Эта опция работает только с распределённой генерацией сниппетов с удалёнными агентами. Исходные файлы для генерации сниппетов могут быть распределены между разными агентами, а основной сервер объединит все корректные результаты. Например, если у одного агента распределённой таблицы есть `file1.txt`, у другого агента — `file2.txt`, и вы используете `CALL SNIPPETS` с обоими этими файлами, searchd объединит результаты агентов, и вы получите результаты из обоих файлов `file1.txt` и `file2.txt`. По умолчанию 0. +Эта опция работает только при распределённой генерации сниппетов с удалёнными агентами. Исходные файлы для генерации сниппетов могут быть распределены между разными агентами, а основной сервер объединит все корректные результаты. Например, если у одного агента распределённой таблицы есть `file1.txt`, у другого — `file2.txt`, и вы используете `CALL SNIPPETS` с обоими этими файлами, searchd объединит результаты агентов, и вы получите результаты как из `file1.txt`, так и из `file2.txt`. Значение по умолчанию — 0. -Если опция `load_files` также включена, запрос вернёт ошибку, если какой-либо из файлов недоступен где-либо. В противном случае (если `load_files` не включена) для всех отсутствующих файлов будут возвращены пустые строки. Searchd не передаёт этот флаг агентам, поэтому агенты не генерируют критическую ошибку, если файл не существует. Если вы хотите быть уверены, что все исходные файлы загружены, установите обе опции `load_files_scattered` и `load_files` в 1. Если отсутствие некоторых исходных файлов на некоторых агентах не критично, установите только `load_files_scattered` в 1. +Если опция `load_files` также включена, запрос вернёт ошибку, если какой-либо из файлов отсутствует везде. В противном случае (если `load_files` не включена) будет возвращена пустая строка для всех отсутствующих файлов. Searchd не передаёт этот флаг агентам, поэтому агенты не генерируют критическую ошибку, если файл не существует. Если вы хотите быть уверены, что все исходные файлы загружены, установите обе опции `load_files_scattered` и `load_files` в 1. Если отсутствие некоторых исходных файлов у некоторых агентов не критично, установите только `load_files_scattered` в 1. ##### SQL: @@ -3824,6 +4076,38 @@ CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_f 2 rows in set (0.02 sec) ``` + + +```JSON +POST /sql?mode=raw -d "CALL SNIPPETS(('data/doc1.txt','data/doc2.txt'), 'forum', 'is text', 1 AS load_files);" +``` + + +```JSON +[ + { + "columns": [ + { + "snippet": { + "type": "string" + } + } + ], + "data": [ + { + "snippet": "this is my document text" + }, + { + "snippet": "this is my another text" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Searching/KNN.md b/manual/russian/Searching/KNN.md index f4858e06e6..8d7f45f45c 100644 --- a/manual/russian/Searching/KNN.md +++ b/manual/russian/Searching/KNN.md @@ -1,26 +1,26 @@ -# Поиск векторов методом k-ближайших соседей +# K-ближайшего соседа векторный поиск -Manticore Search поддерживает возможность добавления эмбеддингов, сгенерированных моделями машинного обучения, к каждому документу, а затем выполнения поиска ближайших соседей по ним. Это позволяет создавать такие функции, как поиск по схожести, рекомендации, семантический поиск и ранжирование релевантности на основе алгоритмов обработки естественного языка (NLP), а также, среди прочего, поиск по изображениям, видео и звуку. +Manticore Search поддерживает возможность добавления эмбеддингов, сгенерированных моделями машинного обучения, к каждому документу, а затем выполнения поиска ближайших соседей по ним. Это позволяет создавать такие функции, как поиск по похожести, рекомендации, семантический поиск и ранжирование релевантности на основе алгоритмов обработки естественного языка, а также поиск изображений, видео и звуков. ## Что такое эмбеддинг? -Эмбеддинг — это метод представления данных — таких как текст, изображения или звук — в виде векторов в пространстве высокой размерности. Эти векторы создаются так, чтобы расстояние между ними отражало схожесть представляемых данных. Этот процесс обычно использует алгоритмы, такие как векторные представления слов (например, Word2Vec, BERT) для текста или нейронные сети для изображений. Высокая размерность векторного пространства, с большим количеством компонентов на вектор, позволяет представлять сложные и тонкие взаимосвязи между объектами. Их схожесть оценивается по расстоянию между этими векторами, часто измеряемому с помощью методов, таких как евклидово расстояние или косинусное сходство. +Эмбеддинг – это метод представления данных, таких как текст, изображения или звук, в виде векторов в высокоразмерном пространстве. Эти векторы создаются таким образом, чтобы расстояние между ними отражало сходство представляемых данных. В этом процессе обычно используются алгоритмы, такие как эмбеддинги слов (например, Word2Vec, BERT) для текста или нейронные сети для изображений. Высокая размерность векторного пространства с множеством компонентов на вектор позволяет представлять сложные и тонкие взаимоотношения между элементами. Их сходство оценивается по расстоянию между этими векторами, часто измеряемым методами, такими как евклидово расстояние или косинусное сходство. -Manticore Search позволяет выполнять поиск k-ближайших соседей (KNN) векторов с использованием библиотеки HNSW. Эта функциональность является частью [Manticore Columnar Library](https://github.com/manticoresoftware/columnar). +Manticore Search обеспечивает поиск по векторам k-ближайших соседей (KNN) с использованием библиотеки HNSW. Эта функциональность является частью [Manticore Columnar Library](https://github.com/manticoresoftware/columnar). -### Настройка таблицы для поиска KNN +### Настройка таблицы для KNN поиска -Для выполнения поиска KNN необходимо сначала настроить таблицу. Векторы с плавающей точкой и поиск KNN поддерживаются только в таблицах реального времени (не в обычных таблицах). Таблица должна содержать как минимум один атрибут [float_vector](../Creating_a_table/Data_types.md#Float-vector), который служит вектором данных. Необходимо указать следующие свойства: +Для выполнения KNN поиска сначала необходимо настроить таблицу. Векторные данные с плавающей точкой и KNN поиск поддерживаются только в таблицах реального времени (не в обычных таблицах). В таблице должен быть хотя бы один атрибут типа [float_vector](../Creating_a_table/Data_types.md#Float-vector), который служит вектором данных. Необходимо указать следующие свойства: * `knn_type`: обязательный параметр; в настоящее время поддерживается только `hnsw`. * `knn_dims`: обязательный параметр, указывающий размерность индексируемых векторов. -* `hnsw_similarity`: обязательный параметр, указывающий функцию расстояния, используемую индексом HNSW. Допустимые значения: +* `hnsw_similarity`: обязательный параметр, определяющий функцию расстояния, используемую индексом HNSW. Допустимые значения: - `L2` - квадрат евклидова расстояния - `IP` - внутреннее произведение - `COSINE` - косинусное сходство - **Примечание:** При использовании косинусного сходства (`COSINE`) векторы автоматически нормализуются при вставке. Это означает, что сохранённые значения векторов могут отличаться от исходных, так как они будут преобразованы в единичные векторы (векторы с математической длиной/модулем 1.0) для эффективного вычисления косинусного сходства. Такая нормализация сохраняет направление вектора при стандартизации его длины. + **Примечание:** При использовании `COSINE` сходства векторы автоматически нормализуются при вставке. Это означает, что хранимые значения векторов могут отличаться от исходных, так как они преобразуются в единичные векторы (векторы с математической длиной/модулем 1.0) для эффективного вычисления косинусного сходства. Такая нормализация сохраняет направление вектора при стандартизации его длины. * `hnsw_m`: необязательный параметр, определяющий максимальное количество исходящих связей в графе. По умолчанию 16. * `hnsw_ef_construction`: необязательный параметр, определяющий компромисс между временем построения и точностью. @@ -38,8 +38,26 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di Query OK, 0 rows affected (0.01 sec) ``` + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' );" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + + -##### Plain mode (использование конфигурационного файла): +##### Режим Plain (с использованием конфигурационного файла): ```ini @@ -59,28 +77,28 @@ table test_vec { #### Автоматические эмбеддинги (рекомендуется) -Самый простой способ работать с векторными данными — использовать **автоматические эмбеддинги**. С этой функцией вы создаёте таблицу с параметрами `MODEL_NAME` и `FROM`, а затем просто вставляете текстовые данные — Manticore автоматически генерирует эмбеддинги для вас. +Самый простой способ работать с векторными данными – использовать **автоматические эмбеддинги**. С этой функцией вы создаёте таблицу с параметрами `MODEL_NAME` и `FROM`, а затем просто вставляете текстовые данные – Manticore автоматически генерирует эмбеддинги для вас. ##### Создание таблицы с автоматическими эмбеддингами -При создании таблицы для автоматических эмбеддингов укажите: +При создании таблицы для автоматических эмбеддингов указывайте: - `MODEL_NAME`: модель эмбеддинга для использования -- `FROM`: какие поля использовать для генерации эмбеддингов (пустое значение означает все текстовые/строковые поля) +- `FROM`: поля, используемые для генерации эмбеддинга (пустое значение означает все текстовые/строковые поля) **Поддерживаемые модели эмбеддингов:** -- **Sentence Transformers**: Любая [подходящая модель на базе BERT из Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — не требует API-ключа. Manticore загружает модель при создании таблицы. -- **OpenAI**: Модели эмбеддингов OpenAI, такие как `openai/text-embedding-ada-002` — требует параметр `API_KEY=''` -- **Voyage**: Модели эмбеддингов Voyage AI — требует параметр `API_KEY=''` -- **Jina**: Модели эмбеддингов Jina AI — требует параметр `API_KEY=''` +- **Sentence Transformers**: Любая [подходящая модель BERT на Hugging Face](https://huggingface.co/sentence-transformers/models) (например, `sentence-transformers/all-MiniLM-L6-v2`) — API-ключ не нужен. Manticore загружает модель при создании таблицы. +- **OpenAI**: Модели эмбеддингов OpenAI, например `openai/text-embedding-ada-002` - требует параметр `API_KEY=''` +- **Voyage**: Модели эмбеддингов Voyage AI - требует параметр `API_KEY=''` +- **Jina**: Модели эмбеддингов Jina AI - требует параметр `API_KEY=''` -Более подробная информация о настройке атрибута `float_vector` доступна [здесь](../Creating_a_table/Data_types.md#Float-vector). +Подробнее о настройке атрибута `float_vector` можно узнать [здесь](../Creating_a_table/Data_types.md#Float-vector). ##### SQL: -Использование sentence-transformers (API-ключ не требуется) +Использование sentence-transformers (API ключ не требуется) ```sql CREATE TABLE products ( title TEXT, @@ -100,7 +118,7 @@ CREATE TABLE products_openai ( ); ``` -Использование всех текстовых полей для эмбеддингов (параметр FROM пуст) +Использование всех текстовых полей для эмбеддингов (FROM пустой) ```sql CREATE TABLE products_all ( title TEXT, @@ -110,45 +128,85 @@ CREATE TABLE products_all ( ); ``` + +##### JSON: + + + +Использование sentence-transformers (API ключ не требуется) +```json +POST /sql?mode=raw -d "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');" +``` + +Использование OpenAI (требуется параметр API_KEY) +```json +POST /sql?mode=raw -d "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 пустой) +```json +POST /sql?mode=raw -d "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='');" +``` + ##### Вставка данных с автоматическими эмбеддингами -При использовании автоматических эмбеддингов **не указывайте поле вектора** в операторе INSERT. Эмбеддинги генерируются автоматически из текстовых полей, указанных в параметре `FROM`. +При использовании автоматических эмбеддингов **не указывайте векторное поле** в инструкции INSERT. Эмбеддинги генерируются автоматически из текстовых полей, указанных в параметре `FROM`. ##### SQL: -Вставка только текстовых данных — эмбеддинги генерируются автоматически +Вставьте только текстовые данные – эмбеддинги генерируются автоматически ```sql INSERT INTO products (title) VALUES ('machine learning artificial intelligence'), ('banana fruit sweet yellow'); ``` -Вставка нескольких полей — все используются для эмбеддинга, если FROM='title,description' +Вставка нескольких полей – оба используются для эмбеддинга если FROM='title,description' ```sql INSERT INTO products_openai (title, description) VALUES ('smartphone', 'latest mobile device with advanced features'), ('laptop', 'portable computer for work and gaming'); ``` -Вставка пустого вектора (документ исключается из поиска по векторам) +Вставка пустого вектора (документ исключён из векторного поиска) ```sql INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ()); ``` + +##### JSON: + + + +Вставьте только текстовые данные – эмбеддинги генерируются автоматически +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title) VALUES ('machine learning artificial intelligence'),('banana fruit sweet yellow');" +``` + +Вставка нескольких полей – оба используются для эмбеддинга если FROM='title,description' +```JSON +POST /sql?mode=raw -d "INSERT INTO products_openai (title, description) VALUES ('smartphone', 'latest mobile device with advanced features'), ('laptop', 'portable computer for work and gaming');" +``` + +Вставка пустого вектора (документ исключён из векторного поиска) +```JSON +POST /sql?mode=raw -d "INSERT INTO products (title, embedding_vector) VALUES ('no embedding item', ());" +``` + -##### Поиск с автоматическими эмбеддингами +##### Поиск с использованием автоматических эмбеддингов -Поиск работает так же — укажите текст запроса, и Manticore сгенерирует эмбеддинги и найдёт похожие документы: +Поиск работает так же – предоставьте текст запроса, и Manticore сгенерирует эмбеддинги и найдёт похожие документы: ##### SQL: @@ -176,7 +234,7 @@ SELECT id, knn_dist() FROM products WHERE knn(embedding_vector, 3, 'machine lear -Использование текстового запроса с автоматическими эмбеддингами +Использование текстового запроса с автоэмбеддингами ```json POST /search { @@ -189,7 +247,7 @@ POST /search } ``` -Использование векторного запроса напрямую +Использование запроса вектора напрямую ```json POST /search { @@ -235,12 +293,12 @@ POST /search -#### Ручная вставка векторов +#### Manual Vector Insertion -В качестве альтернативы вы можете вручную вставлять заранее вычисленные векторные данные, убедившись, что они соответствуют размерности, указанной при создании таблицы. Также можно вставить пустой вектор; это означает, что документ будет исключён из результатов поиска по векторам. +Alternatively, you can manually insert pre-computed vector data, ensuring it matches the dimensions you specified when creating the table. You can also insert an empty vector; this means that the document will be excluded from vector search results. -**Важно:** При использовании `hnsw_similarity='cosine'` векторы автоматически нормализуются при вставке до единичных векторов (векторов с математической длиной/модулем 1.0). Эта нормализация сохраняет направление вектора при стандартизации его длины, что необходимо для эффективных вычислений косинусного сходства. Это означает, что сохранённые значения будут отличаться от ваших исходных значений. +**Important:** When using `hnsw_similarity='cosine'`, vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values. ##### SQL: @@ -301,9 +359,9 @@ POST /insert -### Поиск KNN векторов +### KNN vector search -Теперь вы можете выполнять поиск KNN с помощью оператора `knn` в формате SQL или JSON. Оба интерфейса поддерживают одинаковые основные параметры, обеспечивая единообразный опыт независимо от выбранного формата: +Now, you can perform a KNN search using the `knn` clause in either SQL or JSON format. Both interfaces support the same essential parameters, ensuring a consistent experience regardless of the format you choose: - SQL: `select ... from
where knn ( , , [,] )` - JSON: @@ -323,19 +381,19 @@ POST /insert } ``` -Параметры: -* `field`: Имя атрибута с плавающей точкой, содержащего векторные данные. -* `k`: Количество документов для возврата, ключевой параметр для индексов Hierarchical Navigable Small World (HNSW). Определяет количество документов, которые должен вернуть один индекс HNSW. Однако фактическое количество документов в итоговых результатах может варьироваться. Например, если система работает с таблицами в реальном времени, разбитыми на дисковые чанки, каждый чанк может вернуть `k` документов, что приведёт к общему числу, превышающему заданное `k` (так как суммарное количество будет `num_chunks * k`). С другой стороны, итоговое количество документов может быть меньше `k`, если после запроса `k` документов некоторые из них отфильтровываются по определённым атрибутам. Важно отметить, что параметр `k` не применяется к ramchunks. В контексте ramchunks процесс извлечения работает иначе, и поэтому параметр `k` не влияет на количество возвращаемых документов. -* `query`: (Рекомендуемый параметр) Поисковый запрос, который может быть: - - Текстовой строкой: Автоматически преобразуется в эмбеддинги, если для поля настроены авто-эмбеддинги. Вернёт ошибку, если авто-эмбеддинги не настроены. - - Массивом векторов: Работает так же, как `query_vector`. -* `query_vector`: (Устаревший параметр) Поисковый вектор в виде массива чисел. Поддерживается для обратной совместимости. - **Примечание:** Используйте либо `query`, либо `query_vector`, не оба одновременно. -* `ef`: необязательный размер динамического списка, используемого во время поиска. Более высокий `ef` обеспечивает более точный, но более медленный поиск. -* `rescore`: Включает повторный расчёт KNN (по умолчанию отключён). Установите `1` в SQL или `true` в JSON для включения повторного расчёта. После завершения поиска KNN с использованием квантизированных векторов (с возможным оверсемплингом) расстояния пересчитываются с использованием оригинальных (полной точности) векторов, и результаты пересортировываются для улучшения точности ранжирования. -* `oversampling`: Устанавливает множитель (число с плавающей точкой), на который умножается `k` при выполнении поиска KNN, что приводит к выбору большего количества кандидатов, чем требуется, с использованием квантизированных векторов. По умолчанию оверсемплинг не применяется. Эти кандидаты могут быть повторно оценены, если включён повторный расчёт. Оверсемплинг также работает с неквантизированными векторами. Поскольку он увеличивает `k`, что влияет на работу индекса HNSW, это может вызвать небольшое изменение точности результатов. - -Документы всегда сортируются по расстоянию до поискового вектора. Любые дополнительные критерии сортировки, которые вы укажете, применяются после этого основного условия сортировки. Для получения расстояния существует встроенная функция [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29). +The parameters are: +* `field`: This is the name of the float vector attribute containing vector data. +* `k`: This represents the number of documents to return and is a key parameter for Hierarchical Navigable Small World (HNSW) indexes. It specifies the quantity of documents that a single HNSW index should return. However, the actual number of documents included in the final results may vary. For instance, if the system is dealing with real-time tables divided into disk chunks, each chunk could return `k` documents, leading to a total that exceeds the specified `k` (as the cumulative count would be `num_chunks * k`). On the other hand, the final document count might be less than `k` if, after requesting `k` documents, some are filtered out based on specific attributes. It's important to note that the parameter `k` does not apply to ramchunks. In the context of ramchunks, the retrieval process operates differently, and thus, the `k` parameter's effect on the number of documents returned is not applicable. +* `query`: (Recommended parameter) The search query, which can be either: + - Text string: Automatically converted to embeddings if the field has auto-embeddings configured. Will return an error if the field doesn't have auto-embeddings. + - Vector array: Works the same as `query_vector`. +* `query_vector`: (Legacy parameter) The search vector as an array of numbers. Still supported for backward compatibility. + **Note:** Use either `query` or `query_vector`, not both in the same request. +* `ef`: optional size of the dynamic list used during the search. A higher `ef` leads to more accurate but slower search. +* `rescore`: Enables KNN rescoring (disabled by default). Set to `1` in SQL or `true` in JSON to enable rescoring. After the KNN search is completed using quantized vectors (with possible oversampling), distances are recalculated with the original (full-precision) vectors and results are re-sorted to improve ranking accuracy. +* `oversampling`: Sets a factor (float value) by which `k` is multiplied when executing the KNN search, causing more candidates to be retrieved than needed using quantized vectors. No oversampling is applied by default. These candidates can be re-evaluated later if rescoring is enabled. Oversampling also works with non-quantized vectors. Since it increases `k`, which affects how the HNSW index works, it may cause a small change in result accuracy. + +Documents are always sorted by their distance to the search vector. Any additional sorting criteria you specify will be applied after this primary sort condition. For retrieving the distance, there is a built-in function called [knn_dist()](../Functions/Other_functions.md#KNN_DIST%28%29). ##### SQL: @@ -419,14 +477,14 @@ POST /search -### Квантование векторов +### Vector quantization -Индексы HNSW должны быть полностью загружены в память для выполнения поиска KNN, что может привести к значительному потреблению памяти. Для уменьшения использования памяти можно применить скалярное квантование — метод сжатия высокоразмерных векторов путём представления каждого компонента (измерения) ограниченным числом дискретных значений. Manticore поддерживает 8-битное и 1-битное квантование, что означает, что каждый компонент вектора сжимается с 32-битного float до 8 бит или даже 1 бита, уменьшая использование памяти в 4 или 32 раза соответственно. Эти сжатые представления также позволяют быстрее вычислять расстояния, так как больше компонентов вектора можно обработать за одну SIMD-инструкцию. Хотя скалярное квантование вводит некоторую погрешность, это часто оправданный компромисс между точностью поиска и эффективностью ресурсов. Для ещё лучшей точности квантование можно сочетать с повторным расчётом и оверсемплингом: выбирается больше кандидатов, чем запрошено, и расстояния для этих кандидатов пересчитываются с использованием оригинальных 32-битных float-векторов. +HNSW indexes need to be fully loaded into memory to perform KNN search, which can lead to significant memory consumption. To reduce memory usage, scalar quantization can be applied - a technique that compresses high-dimensional vectors by representing each component (dimension) with a limited number of discrete values. Manticore supports 8-bit and 1-bit quantization, meaning each vector component is compressed from a 32-bit float to 8 bits or even 1 bit, reducing memory usage by 4x or 32x, respectively. These compressed representations also allow for faster distance calculations, as more vector components can be processed in a single SIMD instruction. Although scalar quantization introduces some approximation error, it is often a worthwhile trade-off between search accuracy and resource efficiency. For even better accuracy, quantization can be combined with rescoring and oversampling: more candidates are retrieved than requested, and distances for these candidates are recalculated using the original 32-bit float vectors. -Поддерживаемые типы квантования: -* `8bit`: Каждый компонент вектора квантован до 8 бит. -* `1bit`: Каждый компонент вектора квантован до 1 бита. Используется асимметричное квантование: векторы запроса квантованы до 4 бит, а хранимые векторы — до 1 бита. Такой подход обеспечивает большую точность, чем более простые методы, хотя и с некоторыми потерями в производительности. -* `1bitsimple`: Каждый компонент вектора квантован до 1 бита. Этот метод быстрее, чем `1bit`, но обычно менее точен. +Supported quantization types include: +* `8bit`: Each vector component is quantized to 8 bits. +* `1bit`: Each vector component is quantized to 1 bit. Asymmetric quantization is used, with query vectors quantized to 4 bits and stored vectors to 1 bit. This approach offers greater precision than simpler methods, though with some performance trade-off. +* `1bitsimple`: Each vector component is quantized to 1 bit. This method is faster than `1bit`, but typically less accurate. ##### SQL: @@ -441,15 +499,36 @@ create table test ( title text, image_vector float_vector knn_type='hnsw' knn_di ```sql Query OK, 0 rows affected (0.01 sec) ``` + + +##### JSON: + + +```json +POST /sql?mode=raw -d "create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' quantization='1bit');" +``` + + + +```json +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + -### Поиск похожих документов по id +### Найти похожие документы по id -> ПРИМЕЧАНИЕ: Поиск похожих документов по id требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен. +> ПРИМЕЧАНИЕ: Поиск похожих документов по id требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если это не работает, убедитесь, что Buddy установлен. -Нахождение документов, похожих на конкретный, на основе его уникального идентификатора — распространённая задача. Например, когда пользователь просматривает определённый элемент, Manticore Search может эффективно определить и отобразить список элементов, наиболее похожих на него в векторном пространстве. Вот как это можно сделать: +Поиск документов, похожих на конкретный на основе его уникального ID — распространённая задача. Например, когда пользователь просматривает определённый элемент, Manticore Search может эффективно определить и отобразить список элементов, наиболее похожих на него в векторном пространстве. Вот как это можно сделать: - SQL: `select ... from
where knn ( , , )` - JSON: @@ -467,9 +546,9 @@ Query OK, 0 rows affected (0.01 sec) ``` Параметры: -* `field`: Это имя атрибута с плавающей точкой, содержащего векторные данные. -* `k`: Это количество документов для возврата и ключевой параметр для индексов Hierarchical Navigable Small World (HNSW). Он указывает количество документов, которые должен вернуть один индекс HNSW. Однако фактическое количество документов в итоговых результатах может варьироваться. Например, если система работает с таблицами в реальном времени, разделёнными на дисковые чанки, каждый чанк может вернуть `k` документов, что приведёт к общему числу, превышающему указанное `k` (так как суммарное количество будет `num_chunks * k`). С другой стороны, итоговое количество документов может быть меньше `k`, если после запроса `k` документов некоторые из них отфильтровываются по определённым атрибутам. Важно отметить, что параметр `k` не применяется к ramchunks. В контексте ramchunks процесс извлечения работает иначе, и поэтому параметр `k` не влияет на количество возвращаемых документов. -* `document id`: Идентификатор документа для поиска по сходству KNN. +* `field`: Имя атрибута с плавающей точкой, содержащего векторные данные. +* `k`: Количество документов для возврата, ключевой параметр для индексов Hierarchical Navigable Small World (HNSW). Он указывает, сколько документов должен вернуть один индекс HNSW. Однако фактическое количество документов в итоговых результатах может варьироваться. Например, если система работает с таблицами реального времени, разделёнными на дисковые чанки, каждый чанк может вернуть `k` документов, что в сумме превысит заданное `k` (так как суммарное количество будет равно `num_chunks * k`). С другой стороны, итоговое количество документов может быть меньше `k`, если после запроса `k` документов некоторые из них отфильтровываются по атрибутам. Важно отметить, что параметр `k` не применяется к ramchunks. В случае ramchunks процесс выборки устроен иначе, и параметр `k` не влияет на количество возвращаемых документов. +* `document id`: ID документа для поиска по сходству KNN. @@ -540,9 +619,9 @@ POST /search -### Фильтрация результатов KNN векторного поиска +### Фильтрация результатов векторного поиска KNN -Manticore также поддерживает дополнительную фильтрацию документов, возвращаемых поиском KNN, либо по полнотекстовому совпадению, фильтрам атрибутов, либо по обоим критериям. +Manticore также поддерживает дополнительную фильтрацию документов, возвращаемых поиском KNN, как по полнотекстовому совпадению, так и по атрибутам, или по обоим критериям. ##### SQL: diff --git a/manual/russian/Searching/Multi-queries.md b/manual/russian/Searching/Multi-queries.md index c2209edeb2..5ec3b84d11 100644 --- a/manual/russian/Searching/Multi-queries.md +++ b/manual/russian/Searching/Multi-queries.md @@ -1,19 +1,19 @@ # Мультизапросы -Мультизапросы, или пакеты запросов, позволяют отправлять несколько поисковых запросов в Manticore в одном сетевом запросе. +Мультизапросы, или пакетные запросы, позволяют отправлять несколько поисковых запросов в Manticore одним сетевым запросом. -👍 Почему стоит использовать мультизапросы? +👍 Зачем использовать мультизапросы? -Основная причина — производительность. Отправляя запросы в Manticore пакетами, а не по одному, вы экономите время за счёт уменьшения количества сетевых обращений. Кроме того, отправка запросов пакетами позволяет Manticore выполнять определённые внутренние оптимизации. Если оптимизации пакета применить нельзя, запросы будут обработаны по отдельности. +Основная причина — производительность. Отправляя запросы в Manticore пакетом, а не по одному, вы экономите время за счет уменьшения количества сетевых кругов. Кроме того, отправка запросов пакетно позволяет Manticore выполнять определённые внутренние оптимизации. Если оптимизации пакета применить нельзя, запросы будут обработаны по отдельности. ⛔ Когда не стоит использовать мультизапросы? -Мультизапросы требуют, чтобы все поисковые запросы в пакете были независимы, что бывает не всегда. Иногда запрос B зависит от результатов запроса A, то есть запрос B можно сформировать только после выполнения запроса A. Например, вы можете захотеть показать результаты из вторичного индекса только если в основной таблице не было найдено результатов, или указать смещение во втором наборе результатов на основе количества совпадений в первом наборе. В таких случаях нужно использовать отдельные запросы (или отдельные пакеты). +Для мультизапросов все поисковые запросы в пакете должны быть независимы, что бывает не всегда. Иногда запрос B зависит от результатов запроса A, то есть запрос B может быть сформирован только после выполнения запроса A. Например, вы можете хотеть отобразить результаты из вторичного индекса только если в основной таблице не было найдено результатов, или указать смещение во втором наборе результатов на основе количества совпадений в первом наборе данных. В таких случаях потребуется использовать отдельные запросы (или отдельные пакеты). -Вы можете выполнять несколько поисковых запросов в SQL, разделяя их точкой с запятой. Когда Manticore получает такой запрос от клиента, применяются все оптимизации между запросами. +Вы можете выполнить несколько поисковых запросов с помощью SQL, разделяя их точкой с запятой. Когда Manticore получает такой запрос от клиента, применяются все межинструкционные оптимизации. -Мультизапросы не поддерживают запросы с `FACET`. Количество мультизапросов в одном пакете не должно превышать [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries). +Мультизапросы не поддерживают запросы с `FACET`. Число мультизапросов в одном пакете не должно превышать значение [max_batch_queries](../Server_settings/Searchd.md#max_batch_queries). @@ -26,15 +26,25 @@ SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; S ``` + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price DESC; SELECT id, price FROM products WHERE MATCH('remove hair') ORDER BY price ASC" +``` + + ## Оптимизации мультизапросов -Существует две основные оптимизации, о которых стоит знать: оптимизация общих запросов и оптимизация общих поддеревьев. +Существуют две основные оптимизации, о которых стоит знать: оптимизация общих запросов и оптимизация общих поддеревьев. -**Оптимизация общих запросов** означает, что `searchd` определит все запросы в пакете, которые отличаются только настройками сортировки и группировки, и *выполнит поиск только один раз*. Например, если пакет состоит из 3 запросов, все они по запросу "ipod nano", но первый запрос запрашивает топ-10 результатов, отсортированных по цене, второй группирует по ID поставщика и запрашивает топ-5 поставщиков, отсортированных по рейтингу, а третий запрашивает максимальную цену, полнотекстовый поиск по "ipod nano" будет выполнен только один раз, а его результаты будут использованы для построения трёх разных наборов результатов. +**Оптимизация общих запросов** означает, что `searchd` выявит в пакете все запросы, отличающиеся только настройками сортировки и группировки, и *выполнит поиск только один раз*. Например, если пакет состоит из 3 запросов, все они по запросу «ipod nano», но 1-й запрос выводит топ-10 результатов, отсортированных по цене, 2-й запрет группирует по ID поставщика и выводит топ-5 поставщиков, отсортированных по рейтингу, а 3-й запрос запрашивает максимальную цену, поиск по полнотекстовому запросу «ipod nano» будет выполнен один раз, а результаты переиспользованы для формирования трёх разных наборов данных. -[Фасетный поиск](../Searching/Faceted_search.md) — особенно важный случай, который выигрывает от этой оптимизации. Действительно, фасетный поиск можно реализовать, выполняя несколько запросов: один для получения самих результатов поиска и несколько других с тем же полнотекстовым запросом, но с разными настройками группировки, чтобы получить все необходимые группы результатов (топ-3 авторов, топ-5 поставщиков и т.д.). Пока полнотекстовый запрос и настройки фильтрации остаются одинаковыми, сработает оптимизация общих запросов, значительно улучшая производительность. +[Фасетный поиск](../Searching/Faceted_search.md) — это особенно важный сценарий, для которого выгодна такая оптимизация. В самом деле, фасетный поиск реализуется запуском нескольких запросов — один для собственно поисковой выдачи, а несколько других с тем же полнотекстовым запросом, но разными настройками группировки для получения всех необходимых групп результатов (топ-3 авторов, топ-5 поставщиков и т.д.). Пока полнотекстовый запрос и настройки фильтрации остаются одинаковыми, оптимизация общих запросов сработает и значительно улучшит производительность. -**Оптимизация общих поддеревьев** ещё интереснее. Она позволяет `searchd` использовать сходства между пакетными полнотекстовыми запросами. Он выявляет общие части полнотекстовых запросов (поддеревья) во всех запросах и кэширует их между запросами. Например, рассмотрим следующий пакет запросов: +**Оптимизация общих поддеревьев** ещё интереснее. Она позволяет `searchd` использовать сходства между пакетными полнотекстовыми запросами. Она выявляет общие части полнотекстовых запросов (поддеревья) во всех запросах и кэширует их для повторного использования. Например, рассмотрим следующий пакет запросов: ```bash donald trump president @@ -42,16 +52,16 @@ donald trump barack obama john mccain donald trump speech ``` -Есть общая двухсловная часть `donald trump`, которую можно вычислить один раз, затем закэшировать и использовать во всех запросах. Именно это и делает оптимизация общих поддеревьев. Размер кэша на запрос строго контролируется директивами [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) и [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) (чтобы кэширование *всех* шестнадцати миллиардов документов, соответствующих "i am", не исчерпало оперативную память и не убило сервер). +В нём есть общая двухсловная часть `donald trump`, вычисляющаяся один раз, а затем кэшируемая и используемая всеми запросами. Именно это и делает оптимизация общих поддеревьев. Размер кэша на запрос строго контролируется директивами [subtree_docs_cache](../Server_settings/Searchd.md#subtree_docs_cache) и [subtree_hits_cache](../Server_settings/Searchd.md#subtree_hits_cache) (чтобы кэширование *всех* шестнадцати миллионных документов, соответствующих "i am", не исчерпывало оперативную память и не приводило к краху сервера). -Как узнать, были ли запросы в пакете действительно оптимизированы? Если да, в соответствующем логе запросов появится поле "multiplier", указывающее, сколько запросов было обработано вместе: +Как понять, что запросы в пакете действительно были оптимизированы? Если да, в журнале запросов появится поле "multiplier", указывающее, сколько запросов обработано вместе: -Обратите внимание на поле "x3". Это означает, что запрос был оптимизирован и обработан в под-пакете из 3 запросов. +Обратите внимание на поле "x3". Оно означает, что этот запрос был оптимизирован и обработан в подпакете из 3 запросов. -##### log: +##### журнал: ```bash @@ -62,11 +72,11 @@ donald trump speech -Для сравнения, вот как выглядел бы обычный лог, если бы запросы не были объединены в пакет: +Для сравнения, вот как выглядел бы обычный журнал, если бы запросы не были пакетными: -##### log: +##### журнал: ```bash @@ -76,7 +86,7 @@ donald trump speech ``` -Обратите внимание, что время на запрос в случае мультизапроса улучшилось в 1.5–2.3 раза, в зависимости от конкретного режима сортировки. +Обратите внимание, что время обработки на запрос в случае мультизапроса улучшилось в 1.5-2.3 раза, в зависимости от конкретного режима сортировки. diff --git a/manual/russian/Searching/Options.md b/manual/russian/Searching/Options.md index 67b558262e..450b5b5a07 100644 --- a/manual/russian/Searching/Options.md +++ b/manual/russian/Searching/Options.md @@ -288,17 +288,17 @@ Manticore может увеличить `max_matches` для повышения Вы также можете включить режим гарантированной точности groupby/aggregate с помощью опции [accurate_aggregation](../Searching/Options.md#accurate_aggregation). ### max_query_time -Устанавливает максимальное время выполнения поискового запроса в миллисекундах. Должно быть неотрицательным целым числом. Значение по умолчанию — 0, что означает «не ограничивать». Локальные поисковые запросы будут остановлены после истечения указанного времени. Обратите внимание, что если вы выполняете поиск, который обращается к нескольким локальным таблицам, это ограничение применяется к каждой таблице отдельно. Имейте в виду, что это может немного увеличить время отклика запроса из-за накладных расходов, связанных с постоянным отслеживанием времени остановки запроса. +Устанавливает максимальное время выполнения поискового запроса в миллисекундах. Должно быть неотрицательным целым числом. Значение по умолчанию — 0, что означает «не ограничивать». Локальные поисковые запросы будут остановлены после истечения указанного времени. Обратите внимание, что если вы выполняете поиск, который опрашивает несколько локальных таблиц, это ограничение применяется к каждой таблице отдельно. Имейте в виду, что это может незначительно увеличить время ответа запроса из-за накладных расходов, связанных с постоянным отслеживанием времени остановки запроса. ### max_predicted_time Целое число. Максимальное предсказанное время поиска; см. [predicted_time_costs](../Server_settings/Searchd.md#predicted_time_costs). ### morphology -`none` позволяет заменять все термины запроса их точными формами, если таблица была построена с включённым [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words). Это полезно для предотвращения стемминга или лемматизации терминов запроса. +`none` позволяет заменять все термины запроса их точными формами, если таблица была создана с включённой опцией [index_exact_words](../Creating_a_table/NLP_and_tokenization/Morphology.md#index_exact_words). Это полезно для предотвращения стемминга или лемматизации терминов запроса. ### not_terms_only_allowed -`0` или `1` разрешает использование отдельного [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) в запросе. Значение по умолчанию — 0. См. также соответствующую [глобальную настройку](../Server_settings/Searchd.md#not_terms_only_allowed). +`0` или `1` разрешает использование отдельного [отрицания](../Searching/Full_text_matching/Operators.md#Negation-operator) в запросе. Значение по умолчанию – 0. Также смотрите соответствующую [глобальную настройку](../Server_settings/Searchd.md#not_terms_only_allowed). ```sql @@ -311,6 +311,58 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all | 1658178727135150081 | smth else | +---------------------+-----------+ ``` + + +```JSON +POST /sql?mode=raw -d "select * from tbl where match('-d');" +{ + "error": "table t: query error: query is non-computable (single NOT operator)" +} + +POST /sql?mode=raw -d "select * from t where match('-d') option not_terms_only_allowed=1;" +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "c", + "f2": 3 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] +``` + ### ranker @@ -326,51 +378,51 @@ MySQL [(none)]> select * from t where match('-donald') option not_terms_only_all * `expr` * `export` -Для получения подробной информации о каждом ранжировщике смотрите [Ранжирование результатов поиска](../Searching/Sorting_and_ranking.md#Available-built-in-rankers). +Для получения подробной информации о каждом ранжировщике смотрите раздел [Ранжирование результатов поиска](../Searching/Sorting_and_ranking.md#Available-built-in-rankers). ### rand_seed -Позволяет указать конкретное целочисленное значение зерна для запроса `ORDER BY RAND()`, например: `... OPTION rand_seed=1234`. По умолчанию для каждого запроса автоматически генерируется новое и уникальное значение зерна. +Позволяет указать конкретное целочисленное значение начального зерна для запроса `ORDER BY RAND()`, например: `... OPTION rand_seed=1234`. По умолчанию для каждого запроса автоматически генерируется новое и отличное значение зерна. ### retry_count -Целое число. Количество повторных попыток в распределённом режиме. +Целое число. Количество попыток повторного выполнения в распределённой системе. ### retry_delay -Целое число. Задержка между повторными попытками в распределённом режиме, в миллисекундах. +Целое число. Задержка между повторными попытками в распределённой системе, в миллисекундах. ### scroll -Строка. Токен прокрутки для постраничного вывода результатов с использованием [подхода Scroll pagination](../Searching/Pagination.md#Scroll-Search-Option). +Строка. Токен прокрутки для постраничной навигации с использованием подхода [Scroll pagination](../Searching/Pagination.md#Scroll-Search-Option). ### sort_method -* `pq` — очередь с приоритетом, установлена по умолчанию +* `pq` — очередь с приоритетом, используется по умолчанию * `kbuffer` — обеспечивает более быструю сортировку для уже предварительно отсортированных данных, например, данных таблицы, отсортированных по id -Набор результатов одинаков в обоих случаях; выбор одного из вариантов может просто улучшить (или ухудшить) производительность. +Результат одинаков в обоих случаях; выбор одного из вариантов может только улучшить (или ухудшить) производительность. ### threads -Ограничивает максимальное количество потоков, используемых для обработки текущего запроса. По умолчанию — без ограничений (запрос может использовать все [потоки](../Server_settings/Searchd.md#threads), определённые глобально). -Для пакета запросов опция должна быть добавлена к самому первому запросу в пакете, после чего применяется при создании рабочей очереди и действует для всего пакета. Эта опция имеет то же значение, что и опция [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query), но применяется только к текущему запросу или пакету запросов. +Ограничивает максимальное количество потоков, используемых для обработки текущего запроса. По умолчанию нет ограничений (запрос может занять все [потоки](../Server_settings/Searchd.md#threads), определённые глобально). +Для пакета запросов опция должна быть прикреплена к первому запросу в пакете и применяется при создании рабочей очереди, действуя на весь пакет. Эта опция имеет то же значение, что и опция [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query), но применяется только к текущему запросу или пакету запросов. ### token_filter -Заключённая в кавычки строка с разделением двоеточиями в формате `название библиотеки:название плагина:необязательная строка настроек`. Для каждого поиска при вызове полнотекстового поиска каждой задействованной таблицей создаётся фильтр токенов во время выполнения запроса, что позволяет реализовать пользовательский токенизатор, генерирующий токены согласно пользовательским правилам. +Заключённая в кавычки строка с разделением двоеточием в формате `название библиотеки:название плагина:необязательная строка с настройками`. Фильтр токенов во время запроса создаётся для каждого поиска при вызове полнотекстового поиска каждой задействованной таблицей, что позволяет реализовать собственный токенизатор, генерирующий токены по индивидуальным правилам. ```sql SELECT * FROM index WHERE MATCH ('yes@no') OPTION token_filter='mylib.so:blend:@' ``` ### expansion_limit -Ограничивает максимальное количество расширенных ключевых слов для одного подстановочного знака, значение по умолчанию 0 означает отсутствие ограничения. Для дополнительной информации смотрите [expansion_limit](../Server_settings/Searchd.md#expansion_limit). +Ограничивает максимальное количество расширенных ключевых слов для одного подстановочного знака, значение по умолчанию — 0, что означает отсутствие ограничения. Дополнительные сведения см. в разделе [expansion_limit](../Server_settings/Searchd.md#expansion_limit). ## Подсказки оптимизатора запросов -В редких случаях встроенный анализатор запросов Manticore может неправильно понять запрос и определить, следует ли использовать индекс docid, вторичные индексы или колонковое сканирование. Чтобы переопределить решения оптимизатора запросов, вы можете использовать следующие подсказки в вашем запросе: +В редких случаях встроенный анализатор запросов Manticore может некорректно понять запрос и определить, следует ли использовать индекс docid, вторичные индексы или колонночное сканирование. Чтобы переопределить решения оптимизатора запросов, вы можете использовать следующие подсказки в вашем запросе: -* `/*+ DocidIndex(id) */` — принудительно использовать индекс docid, `/*+ NO_DocidIndex(id) */` — указать оптимизатору игнорировать его -* `/*+ SecondaryIndex([, ]) */` — принудительно использовать вторичный индекс (если доступен), `/*+ NO_SecondaryIndex(id) */` — указать оптимизатору игнорировать его -* `/*+ ColumnarScan([, ]) */` — принудительно использовать колонковое сканирование (если атрибут колонковый), `/*+ NO_ColumnarScan(id) */` — указать оптимизатору игнорировать его +* `/*+ DocidIndex(id) */` чтобы принудительно использовать индекс docid, `/*+ NO_DocidIndex(id) */` чтобы сообщить оптимизатору игнорировать его +* `/*+ SecondaryIndex([, ]) */` чтобы принудительно использовать вторичный индекс (если доступен), `/*+ NO_SecondaryIndex(id) */` чтобы сообщить оптимизатору игнорировать его +* `/*+ ColumnarScan([, ]) */` чтобы принудительно использовать колонночное сканирование (если атрибут колонночный), `/*+ NO_ColumnarScan(id) */` чтобы сообщить оптимизатору игнорировать его -Обратите внимание, что при выполнении полнотекстового запроса с фильтрами оптимизатор запросов выбирает между пересечением результатов полнотекстового дерева с результатами фильтра или использованием стандартного подхода match-then-filter. Указание *любой* подсказки заставит демон использовать путь кода, который выполняет пересечение результатов полнотекстового дерева с результатами фильтра. +Обратите внимание, что при выполнении полнотекстового запроса с фильтрами оптимизатор запроса выбирает между пересечением результатов полнотекстового дерева с результатами фильтра или использованием стандартного подхода match-then-filter. Указание *любой* подсказки заставит демон использовать кодовый путь, который выполняет пересечение результатов полнотекстового дерева с результатами фильтра. -Для получения дополнительной информации о работе оптимизатора запросов смотрите страницу [Оптимизатор на основе стоимости](../Searching/Cost_based_optimizer.md). +Для получения дополнительной информации о работе оптимизатора запросов обратитесь к странице [Оптимизатор на основе затрат](../Searching/Cost_based_optimizer.md). @@ -378,10 +430,16 @@ SELECT * FROM index WHERE MATCH ('yes@no') OPTION token_filter='mylib.so:blend:@ SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */ ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */" +``` + -При использовании клиента MySQL/MariaDB убедитесь, что включён флаг `--comments` для активации подсказок в ваших запросах. +При использовании клиента MySQL/MariaDB убедитесь, что включили флаг `--comments` для активации подсказок в ваших запросах. ```bash diff --git a/manual/russian/Searching/Percolate_query.md b/manual/russian/Searching/Percolate_query.md index d7ab9e322e..ac1a3f034c 100644 --- a/manual/russian/Searching/Percolate_query.md +++ b/manual/russian/Searching/Percolate_query.md @@ -890,7 +890,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -##### Я хочу узнать полные правила PQ, соответствующие моему документу +##### Я хочу узнать все правила PQ, соответствующие моему документу SQL: @@ -1263,12 +1263,12 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -##### Как насчёт нескольких документов? +##### А как насчет нескольких документов? Обратите внимание, что с помощью `CALL PQ` вы можете предоставить несколько документов разными способами: -* как массив простых документов в круглых скобках `('doc1', 'doc2')`. Для этого требуется `0 as docs_json` -* как массив JSON в круглых скобках `('{doc1}', '{doc2}')` +* в виде массива простых документов в круглых скобках `('doc1', 'doc2')`. Для этого требуется `0 as docs_json` +* в виде массива JSON в круглых скобках `('{doc1}', '{doc2}')` * или как стандартный JSON-массив `'[{doc1}, {doc2}]'` @@ -2281,9 +2281,9 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc #### Статические идентификаторы -По умолчанию идентификаторы совпадающих документов соответствуют их относительным номерам в списке, который вы предоставляете. Однако в некоторых случаях у каждого документа уже есть свой собственный идентификатор. Для этого случая существует опция `'id field name' as docs_id` для `CALL PQ`. +По умолчанию идентификаторы соответствующих документов соответствуют их относительным номерам в списке, который вы предоставляете. Однако в некоторых случаях каждый документ уже имеет свой собственный идентификатор. Для этого случая существует опция `'id field name' as docs_id` для `CALL PQ`. -Обратите внимание, что если идентификатор не может быть найден по указанному имени поля, правило PQ не будет отображено в результатах. +Обратите внимание, что если идентификатор не может быть найден по предоставленному имени поля, правило PQ не будет показано в результатах. Эта опция доступна только для `CALL PQ` через SQL. @@ -2305,12 +2305,76 @@ CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue" | 1657852401006149666 | 123 | @title shoes | | color IN ('blue, 'green') | +---------------------+-----------+--------------+------+---------------------------+ ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', '[{"id": 123, "title": "nice pair of shoes", "color": "blue"}, {"id": 456, "title": "beautiful bag"}]', 1 as query, 'id' as docs_id, 1 as docs);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "documents": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149664, + "documents": 456, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149666, + "documents": 123, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -##### У меня могут быть некорректные JSON, пожалуйста, пропускайте их +##### Возможно, у меня есть некорректные JSON, пожалуйста, пропустите их -При использовании CALL PQ с отдельными JSON можно использовать опцию 1 в качестве skip_bad_json, чтобы пропускать любые недопустимые JSON в вводе. В приведённом ниже примере второй запрос не выполняется из-за недопустимого JSON, но третий запрос избегает ошибки, используя 1 в качестве skip_bad_json. Имейте в виду, что эта опция недоступна при отправке JSON-запросов по HTTP, так как в этом случае весь JSON-запрос должен быть валидным. +При использовании CALL PQ с отдельными JSON можно использовать опцию 1 в качестве skip_bad_json, чтобы пропускать любые некорректные JSON в вводе. В приведённом ниже примере второй запрос не выполняется из-за некорректного JSON, но третий запрос избегает ошибки, используя 1 в качестве skip_bad_json. Имейте в виду, что эта опция недоступна при отправке JSON-запросов через HTTP, так как в этом случае весь JSON-запрос должен быть корректным. SQL: @@ -2342,15 +2406,77 @@ ERROR 1064 (42000): Bad JSON objects in strings: 2 +---------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'));" + +POST /sql?mode=raw -d "CALL PQ('products', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag}'), 1 as skip_bad_json);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + }, + { + "id": 1657852401006149637 + } + ], + "total": 2, + "error": "", + "warning": "" + } +] + +{ + "error": "Bad JSON objects in strings: 1" +} + +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + } + ], + "data": [ + { + "id": 1657852401006149635 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ##### Я хочу повысить производительность перколяционного запроса -Перколяционные запросы разработаны с учётом высокой пропускной способности и больших объёмов данных. Чтобы оптимизировать производительность для снижения задержек и увеличения пропускной способности, рассмотрите следующее. +Перколяционные запросы разработаны с учётом высокой пропускной способности и больших объёмов данных. Чтобы оптимизировать производительность для снижения задержек и увеличения пропускной способности, рассмотрите следующие варианты. -Существует два режима распределения для перколяционной таблицы и способа работы перколяционного запроса с ней: +Существует два режима распределения для перколяционной таблицы и способа работы с ней перколяционного запроса: -* **Sparse (по умолчанию).** Идеально для: большого количества документов, зеркальных PQ таблиц. Когда ваш набор документов большой, но набор запросов, хранящихся в PQ таблице, мал, режим sparse будет полезен. В этом режиме пакет документов, который вы передаёте, будет разделён между количеством агентов, так что каждый узел обрабатывает только часть документов из вашего запроса. Manticore разбивает ваш набор документов и распределяет части между зеркалами. После того как агенты закончат обработку запросов, Manticore собирает и объединяет результаты, возвращая итоговый набор запросов, как если бы он пришёл из одной таблицы. Используйте [репликацию](../References.md#Replication) для поддержки процесса. -* **Sharded.** Идеально для: большого количества правил PQ, правил, разделённых между PQ таблицами. В этом режиме весь набор документов транслируется всем таблицам распределённой PQ таблицы без первоначального разделения документов. Это полезно, когда вы отправляете относительно небольшой набор документов, но количество хранимых запросов велико. В этом случае более целесообразно хранить только часть правил PQ на каждом узле, а затем объединять результаты, возвращаемые узлами, которые обрабатывают один и тот же набор документов против разных наборов правил PQ. Этот режим должен быть установлен явно, так как он подразумевает увеличение сетевого трафика и ожидает таблицы с разными PQ, что [репликация](../References.md#Replication) не может сделать из коробки. +* **Разреженный (по умолчанию).** Идеально для: большого количества документов, зеркальных PQ таблиц. Когда набор ваших документов большой, но набор запросов, хранящихся в PQ таблице, мал, полезен разреженный режим. В этом режиме пакет документов, который вы передаёте, делится между агентами, так что каждый узел обрабатывает только часть документов из вашего запроса. Manticore разбивает ваш набор документов и распределяет части между зеркалами. После того, как агенты закончат обработку запросов, Manticore собирает и объединяет результаты, возвращая итоговый набор запросов, как если бы он исходил из одной таблицы. Используйте [репликацию](../References.md#Replication) для поддержки процесса. +* **Шардированный.** Идеально для: большого количества правил PQ, разделённых между PQ таблицами. В этом режиме весь набор документов транслируется всем таблицам распределённой PQ таблицы без первоначального разделения документов. Это полезно при передаче относительно небольшого набора документов, но когда количество хранимых запросов велико. В этом случае правильнее хранить только часть правил PQ на каждом узле, а затем объединять результаты, возвращаемые узлами, которые обрабатывают одинаковый набор документов, но применяют разные наборы правил PQ. Этот режим должен быть установлен явно, так как он увеличивает сетевой трафик и предполагает таблицы с разными PQ, что [репликация](../References.md#Replication) не обеспечивает "из коробки". Предположим, у вас есть таблица `pq_d2`, определённая как: @@ -2364,7 +2490,7 @@ table pq_d2 ``` -Каждая из 'pq' и 'ptitle' содержит: +Каждая из таблиц 'pq' и 'ptitle' содержит: @@ -3212,7 +3338,7 @@ res, _, _ := apiClient.SearchAPI.Percolate(context.Background(), "test_pq").Perc -В предыдущем примере мы использовали режим по умолчанию — **sparse**. Чтобы продемонстрировать режим **sharded**, давайте создадим распределённую PQ таблицу, состоящую из 2 локальных PQ таблиц, и добавим 2 документа в "products1" и 1 документ в "products2": +В предыдущем примере мы использовали режим по умолчанию — **разреженный**. Чтобы показать работу **шардированного** режима, создадим распределённую PQ таблицу, состоящую из 2 локальных PQ таблиц, и добавим 2 документа в "products1" и 1 документ в "products2": ```sql create table products1(title text, color string) type='pq'; create table products2(title text, color string) type='pq'; @@ -3224,7 +3350,7 @@ INSERT INTO products2(query,filters) values('@title shoes', 'color in (\'blue\', ``` -Теперь, если вы добавите `'sharded' as mode` к `CALL PQ`, документы будут отправлены во все таблицы агента (в данном случае только локальные таблицы, но они могут быть удалёнными для использования внешнего оборудования). Этот режим недоступен через JSON-интерфейс. +Теперь, если добавить `'sharded' as mode` к `CALL PQ`, то документы будут отправлены во все таблицы агента (в данном случае только локальные таблицы, но они могут быть удалёнными для использования внешнего оборудования). Этот режим недоступен через JSON-интерфейс. SQL: @@ -3244,13 +3370,68 @@ CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue +---------------------+--------------+------+---------------------------+ ``` + +JSON: + + +```JSON +POST /sql?mode=raw -d "CALL PQ('products_distributed', ('{"title": "nice pair of shoes", "color": "blue"}', '{"title": "beautiful bag"}'), 'sharded' as mode, 1 as query);" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "query": { + "type": "string" + } + }, + { + "tags": { + "type": "string" + } + }, + { + "filters": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1657852401006149639, + "query": "@title bag", + "tags": "", + "filters": "" + }, + { + "id": 1657852401006149643, + "query": "@title shoes", + "tags": "", + "filters": "color IN ('blue, 'green')" + } + ], + "total": 2, + "error": "", + "warning": "" + } +] +``` + -Обратите внимание, что синтаксис зеркал агентов в конфигурации (когда несколько хостов указаны в одной строке `agent`, разделённые `|`) не имеет никакого отношения к режиму запроса `CALL PQ`. Каждый `agent` всегда представляет **один** узел, независимо от количества HA-зеркал, указанных для этого агента. +Обратите внимание, что синтаксис зеркал агентов в конфигурации (когда несколько хостов указаны в одной строке `agent`, разделённой символом `|`) не связан с режимом запроса `CALL PQ`. Каждый `agent` всегда представляет **один** узел, независимо от количества зеркал HA, указанных для этого агента. ##### Как я могу узнать больше о производительности? -В некоторых случаях вы можете захотеть получить более подробную информацию о производительности запроса percolate. Для этой цели существует опция `1 as verbose`, которая доступна только через SQL и позволяет сохранять больше метрик производительности. Вы можете просмотреть их с помощью запроса `SHOW META`, который можно выполнить после `CALL PQ`. Подробнее см. в разделе [SHOW META](../Node_info_and_management/SHOW_META.md). +В некоторых случаях вы можете захотеть получить более подробную информацию о производительности перколяционного запроса. Для этой цели существует опция `1 as verbose`, которая доступна только через SQL и позволяет сохранить больше метрик производительности. Вы можете просмотреть их с помощью запроса `SHOW META`, который можно выполнить после `CALL PQ`. Подробнее смотрите в [SHOW META](../Node_info_and_management/SHOW_META.md). 1 as verbose: diff --git a/manual/russian/Searching/Search_results.md b/manual/russian/Searching/Search_results.md index bc43ff309e..f31fd2f13b 100644 --- a/manual/russian/Searching/Search_results.md +++ b/manual/russian/Searching/Search_results.md @@ -21,10 +21,62 @@ SELECT * FROM tbl; +------+------+--------+ 3 rows in set (0.00 sec) ``` + + +```JSON +POST /sql -d "SELECT * FROM tbl;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "age": { + "type": "long" + } + }, + { + "name": { + "type": "string" + } + } + ], + "data": [ + { + "id": 1, + "age": "joe", + "name": 25 + }, + { + "id": 2, + "age": "mary", + "name": 255 + }, + { + "id": 3, + "age": "albert", + "name": 33 + } + ], + "total": 3, + "error": "", + "warning": "" + } +] + +``` + -Кроме того, вы можете использовать вызов [SHOW META](../Node_info_and_management/SHOW_META.md), чтобы увидеть дополнительную мета-информацию о последнем запросе. +Кроме того, вы можете использовать вызов [SHOW META](../Node_info_and_management/SHOW_META.md), чтобы увидеть дополнительную метаинформацию о последнем запросе. ```sql @@ -52,10 +104,86 @@ SELECT id,story_author,comment_author FROM hn_small WHERE story_author='joe' LIM +----------------+-------+ 4 rows in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT id,f1,f2 FROM t WHERE f2=2 LIMIT 1; SHOW META;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Variable_name": { + "type": "string" + } + }, + { + "Value": { + "type": "string" + } + } + ], + "data": [ + { + "Variable_name": "total", + "Value": "1" + }, + { + "Variable_name": "total_found", + "Value": "1" + }, + { + "Variable_name": "total_relation", + "Value": "gte" + }, + { + "Variable_name": "time", + "Value": "0.000" + } + ], + "total": 4, + "error": "", + "warning": "" + } +] +``` + -В некоторых случаях, например при выполнении [фасетного поиска](../Searching/Faceted_search.md), вы можете получить несколько наборов результатов в ответ на ваш SQL-запрос. +В некоторых случаях, например, при выполнении [фасетного поиска](../Searching/Faceted_search.md), вы можете получить несколько наборов результатов в ответ на ваш SQL-запрос. ```sql @@ -78,10 +206,79 @@ SELECT * FROM tbl WHERE MATCH('joe') FACET age; +------+----------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * FROM tbl WHERE MATCH('b') FACET f2;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f1": { + "type": "string" + } + }, + { + "f2": { + "type": "long" + } + } + ], + "data": [ + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + }, + { + "id": 724024784404348900, + "f1": "b", + "f2": 2 + } + ], + "total": 2, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "f2": { + "type": "long" + } + }, + { + "count(*)": { + "type": "long long" + } + } + ], + "data": [ + { + "f2": 2, + "count(*)": 2 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + -В случае предупреждения набор результатов будет содержать флаг предупреждения, и вы можете увидеть предупреждение с помощью [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md). +В случае предупреждения набор результатов будет включать флаг предупреждения, и вы можете просмотреть предупреждение с помощью [SHOW WARNINGS](../Node_info_and_management/SHOW_WARNINGS.md). ```sql SELECT * from tbl where match('"joe"/3'); show warnings; @@ -103,6 +300,70 @@ SELECT * from tbl where match('"joe"/3'); show warnings; +---------+------+--------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) ``` + + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('\"a\"/3'); show warnings;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "f2": { + "type": "long" + } + }, + { + "f1": { + "type": "string" + } + } + ], + "data": [], + "total": 0, + "error": "", + "warning": "" + }, + { + "columns": [ + { + "Level": { + "type": "string" + } + }, + { + "Code": { + "type": "decimal" + } + }, + { + "Message": { + "type": "string" + } + } + ], + "data": [ + { + "Level": "warning", + "Code": "1000", + "Message": "table t: quorum threshold too high (words=1, thresh=3); replacing quorum operator with AND operator" + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + @@ -118,6 +379,18 @@ SELECT * from tbl where match('@surname joe'); ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema ``` + +```JSON +POST /sql?mode=raw -d "SELECT * from t where match('@surname joe');" +``` + + +```JSON +{ + "error": "table t: query error: no field 'surname' found in schema" +} +``` + @@ -150,12 +423,12 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema ``` * `took`: время в миллисекундах, затраченное на выполнение поиска -* `timed_out`: истекло ли время выполнения запроса +* `timed_out`: указание, превысило ли время выполнения запроса лимит * `hits`: результаты поиска, с следующими свойствами: - `total`: общее количество совпадающих документов - `hits`: массив, содержащий совпадения -Результат запроса также может включать информацию о профилировании запроса. См. [Профиль запроса](../Node_info_and_management/Profiling/Query_profile.md). +Результат запроса также может включать информацию о профиле запроса. См. [Query profile](../Node_info_and_management/Profiling/Query_profile.md). Каждое совпадение в массиве `hits` имеет следующие свойства: @@ -175,9 +448,9 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema } ``` -Вы можете указать атрибуты, которые хотите включить в результат запроса, в виде строки (`"_source": "attr*"`) или массива строк (`"_source": [ "attr1", "attri*" ]"`). Каждая запись может быть именем атрибута или шаблоном с подстановочными знаками (`*`, `%` и `?` поддерживаются). +Вы можете указать атрибуты, которые хотите включить в результат запроса, как строку (`"_source": "attr*"`), так и массив строк (`"_source": [ "attr1", "attri*" ]"`). Каждый элемент может быть именем атрибута или шаблоном с подстановочными знаками (`*`, `%` и `?` поддерживаются). -Вы также можете явно указать, какие атрибуты хотите включить, а какие исключить из набора результатов, используя свойства `includes` и `excludes`: +Вы также можете явно указать, какие атрибуты включать, а какие исключать из набора результатов, используя свойства `includes` и `excludes`: ```json "_source": @@ -187,7 +460,7 @@ ERROR 1064 (42000): index idx: query error: no field 'surname' found in schema } ``` -Пустой список includes интерпретируется как «включить все атрибуты», в то время как пустой список excludes не совпадает ни с чем. Если атрибут совпадает и с includes, и с excludes, то приоритет имеет excludes. +Пустой список includes интерпретируется как «включить все атрибуты», в то время как пустой список excludes ни с чем не совпадает. Если атрибут совпадает и с includes, и с excludes, то выигрывает исключение (excludes). diff --git a/manual/russian/Searching/Sorting_and_ranking.md b/manual/russian/Searching/Sorting_and_ranking.md index 37f541c9a7..9eabc5d4ba 100644 --- a/manual/russian/Searching/Sorting_and_ranking.md +++ b/manual/russian/Searching/Sorting_and_ranking.md @@ -1,14 +1,14 @@ # Сортировка и ранжирование -Результаты запроса могут быть отсортированы по весу полнотекстового ранжирования, одному или нескольким атрибутам или выражениям. +Результаты запроса можно сортировать по весу ранжирования полнотекстового поиска, одному или нескольким атрибутам или выражениям. -**Полнотекстовые** запросы возвращают совпадения, отсортированные по умолчанию. Если ничего не указано, они сортируются по релевантности, что эквивалентно `ORDER BY weight() DESC` в формате SQL. +**Полнотекстовые** запросы по умолчанию возвращают совпадения, отсортированные по релевантности. Если ничего не указано, они сортируются по релевантности, что эквивалентно `ORDER BY weight() DESC` в SQL-формате. -**Не полнотекстовые** запросы по умолчанию не выполняют никакой сортировки. +**Не полнотекстовые** запросы по умолчанию не выполняют сортировку. ## Расширенная сортировка -Расширенный режим автоматически включается, когда вы явно задаёте правила сортировки, добавляя к запросу `ORDER BY` в формате SQL или используя опцию `sort` через HTTP JSON. +Расширенный режим автоматически включается, когда вы явно задаёте правила сортировки, добавляя в запрос клаузы `ORDER BY` в SQL-формате или используя опцию `sort` через HTTP JSON. ### Сортировка через SQL @@ -22,7 +22,7 @@ SELECT ... ORDER BY -В клаузе сортировки можно использовать любую комбинацию до 5 столбцов, за каждым из которых следует `asc` или `desc`. Функции и выражения не допускаются в качестве аргументов для клаузулы сортировки, за исключением функций `weight()` и `random()` (последняя может использоваться только через SQL в виде `ORDER BY random()`). Однако вы можете использовать любое выражение в списке SELECT и сортировать по его псевдониму. +В клаузе сортировки можно использовать любую комбинацию до 5 колонок, каждая из которых сопровождается `asc` или `desc`. Функции и выражения не допускаются как аргументы для клауззы сортировки, за исключением функций `weight()` и `random()` (последнюю можно использовать только через SQL в виде `ORDER BY random()`). Однако вы можете использовать любое выражение в списке SELECT и сортировать по его псевдониму. ```sql @@ -38,12 +38,64 @@ select *, a + b alias from test order by alias desc; +------+------+------+----------+-------+ ``` + +```JSON +POST /sql?mode=raw -d "select *, a + b alias from test order by alias desc;" +``` + + +```JSON +[ + { + "columns": [ + { + "id": { + "type": "long long" + } + }, + { + "a": { + "type": "long" + } + }, + { + "b": { + "type": "long" + } + }, + { + "f": { + "type": "string" + } + }, + { + "alias": { + "type": "long" + } + } + ], + "data": [ + { + "id": 1, + "a": 2, + "b": 3, + "f": document, + "alias": 5 + } + ], + "total": 1, + "error": "", + "warning": "" + } +] +``` + ## Сортировка через JSON -`"sort"` задаёт массив, где каждый элемент может быть именем атрибута или `_score`, если вы хотите сортировать по весам совпадений, или `_random`, если хотите случайный порядок совпадений. В этом случае порядок сортировки по умолчанию — по возрастанию для атрибутов и по убыванию для `_score`. +Опция `"sort"` задаёт массив, в котором каждый элемент может быть именем атрибута или `_score`, если вы хотите сортировать по весам совпадений, или `_random`, если хотите случайный порядок совпадений. В этом случае порядок сортировки по умолчанию — по возрастанию для атрибутов и по убыванию для `_score`. @@ -217,7 +269,7 @@ searchRequest.SetSort(sort) -Вы также можете явно указать порядок сортировки: +Также можно явно указать порядок сортировки: * `asc`: сортировка по возрастанию * `desc`: сортировка по убыванию @@ -414,7 +466,7 @@ searchRequest.SetSort(sort) -Вы также можете использовать другой синтаксис и указать порядок сортировки через свойство `order`: +Можно также использовать другой синтаксис и указать порядок сортировки через свойство `order`: @@ -602,7 +654,7 @@ searchRequest.SetSort(sort) -Сортировка по MVA-атрибутам также поддерживается в JSON-запросах. Режим сортировки можно задать через свойство `mode`. Поддерживаются следующие режимы: +В JSON-запросах также поддерживается сортировка по атрибутам MVA. Режим сортировки можно задать через свойство `mode`. Поддерживаются следующие режимы: * `min`: сортировка по минимальному значению * `max`: сортировка по максимальному значению @@ -992,27 +1044,27 @@ searchRequest.SetSort(sort) ## Обзор ранжирования -Ранжирование (также известное как взвешивание) результатов поиска можно определить как процесс вычисления так называемой релевантности (веса) для каждого найденного документа относительно данного запроса, который его сопоставил. Таким образом, релевантность — это, в конечном счёте, просто число, прикреплённое к каждому документу, которое оценивает, насколько документ релевантен запросу. Результаты поиска затем могут быть отсортированы на основе этого числа и/или некоторых дополнительных параметров, чтобы наиболее востребованные результаты появлялись выше на странице результатов. +Ранжирование (также известное как взвешивание) результатов поиска можно определить как процесс вычисления так называемой релевантности (веса) для каждого совпавшего документа относительно данного запроса, который его совпал. Таким образом, релевантность в конечном итоге — это просто число, прикреплённое к каждому документу, которое оценивает, насколько релевантен документ запросу. Затем результаты поиска могут быть отсортированы на основе этого числа и/или некоторых дополнительных параметров, чтобы наиболее востребованные результаты появлялись выше на странице результатов. -Не существует единого универсального способа ранжирования любого документа в любой ситуации. Более того, такого способа никогда не может быть, потому что релевантность *субъективна*. То есть то, что кажется релевантным вам, может не казаться релевантным мне. Следовательно, в общих случаях это не просто трудно вычислить; это теоретически невозможно. +Не существует универсального стандарта для ранжирования любого документа в любой ситуации. Более того, такой способ никогда не сможет существовать, потому что релевантность — *субъективна*. То есть то, что кажется релевантным вам, может не казаться релевантным мне. Следовательно, в общем случае, это не просто трудно вычислить; это теоретически невозможно. -Поэтому ранжирование в Manticore настраивается. В нём есть понятие так называемого **ранкера**. Ранкер формально можно определить как функцию, которая принимает на вход документ и запрос и выдаёт значение релевантности на выходе. Простыми словами, ранкер контролирует, как именно (с помощью какого конкретного алгоритма) Manticore будет присваивать веса документам. +Поэтому ранжирование в Manticore конфигурируемо. В нём есть понятие так называемого **ранкера**. Ранкер можно формально определить как функцию, которая принимает документ и запрос на вход и выдает значение релевантности на выходе. По-простому, ранкер контролирует, как именно (с использованием какого конкретного алгоритма) Manticore будет присваивать весовые значения документам. ## Доступные встроенные ранкеры -Manticore поставляется с несколькими встроенными ранкерами, подходящими для разных целей. Многие из них используют два фактора: близость фраз (также известную как LCS) и BM25. Близость фраз работает с позициями ключевых слов, в то время как BM25 — с частотами ключевых слов. По сути, чем лучше степень совпадения фразы между телом документа и запросом, тем выше близость фраз (она достигает максимума, когда документ содержит весь запрос как дословную цитату). А BM25 выше, когда документ содержит более редкие слова. Подробное обсуждение мы оставим на потом. +Manticore поставляется с несколькими встроенными ранкерами, подходящими для разных целей. Многие из них используют два фактора: близость фраз (также известная как LCS) и BM25. Близость фраз работает с позициями ключевых слов, в то время как BM25 работает с частотами ключевых слов. По сути, чем лучше степень совпадения фраз между телом документа и запросом, тем выше близость фраз (она достигает максимума, когда документ содержит весь запрос дословно). А BM25 выше, когда в документе больше редких слов. Детальное обсуждение мы отложим на потом. В настоящее время реализованы следующие ранкеры: -* `proximity_bm25` — режим ранжирования по умолчанию, который использует и комбинирует как близость фраз, так и ранжирование BM25. -* `bm25` — статистический режим ранжирования, который использует только BM25 (аналогично большинству других полнотекстовых движков). Этот режим быстрее, но может давать худшее качество для запросов, содержащих более одного ключевого слова. -* `none` — режим без ранжирования. Этот режим, очевидно, самый быстрый. Всем совпадениям присваивается вес 1. Иногда это называют булевым поиском, который просто находит документы, но не ранжирует их. -* `wordcount` — ранжирование по количеству вхождений ключевых слов. Этот ранкер вычисляет количество вхождений ключевых слов по каждому полю, затем умножает их на веса полей и суммирует полученные значения. -* `proximity` возвращает сырое значение близости фраз в качестве результата. Этот режим внутренне используется для эмуляции запросов `SPH_MATCH_ALL`. -* `matchany` возвращает ранг, как он вычислялся ранее в режиме `SPH_MATCH_ANY`, и внутренне используется для эмуляции запросов `SPH_MATCH_ANY`. -* `fieldmask` возвращает 32-битную маску, где N-й бит соответствует N-му полнотекстовому полю, нумерация с 0. Бит будет установлен только если в соответствующем поле есть вхождения ключевых слов, удовлетворяющих запросу. -* `sph04` в целом основан на ранкере по умолчанию 'proximity_bm25', но дополнительно повышает рейтинг совпадений, когда они встречаются в самом начале или в самом конце текстового поля. Таким образом, если поле равно точному запросу, `sph04` должен ранжировать его выше, чем поле, которое содержит точный запрос, но не равно ему. (Например, если запрос "Hyde Park", документ с заголовком "Hyde Park" должен иметь более высокий ранг, чем документ с заголовком "Hyde Park, London" или "The Hyde Park Cafe".) -* `expr` позволяет задавать формулу ранжирования во время выполнения. Он предоставляет несколько внутренних текстовых факторов и позволяет определить, как из этих факторов вычислять итоговый вес. Подробнее о синтаксисе и справочник доступных факторов можно найти в [подразделе ниже](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors). +* `proximity_bm25` — режим ранжирования по умолчанию, который использует и комбинирует как близость фраз, так и BM25. +* `bm25` — статистический режим ранжирования, который использует только BM25 (похоже на большинство других полнотекстовых движков). Этот режим быстрее, но может ухудшить качество запросов, содержащих более одного ключевого слова. +* `none` — режим без ранжирования. Этот режим, разумеется, самый быстрый. Вес 1 присваивается всем совпадениям. Иногда это называют булевым поиском, который просто находит документы, но не ранжирует их. +* `wordcount` — ранжирование по количеству вхождений ключевых слов. Этот ранкер вычисляет количество вхождений ключевых слов в каждом поле, затем умножает их на веса полей и суммирует полученные значения. +* `proximity` возвращает чистое значение близости фраз. Этот режим внутренне используется для эмуляции запросов с `SPH_MATCH_ALL`. +* `matchany` возвращает ранг, как он вычислялся в режиме `SPH_MATCH_ANY` ранее, и также внутренне используется для эмуляции запросов с `SPH_MATCH_ANY`. +* `fieldmask` возвращает 32-битную маску, где N-й бит соответствует N-му полнотекстовому полю, нумерация с 0. Бит устанавливается, только если соответствующее поле содержит вхождения ключевых слов, удовлетворяющих запросу. +* `sph04` в целом основан на ранкере по умолчанию 'proximity_bm25', но дополнительно усиливает совпадения, если они встречаются либо в самом начале, либо в самом конце текстового поля. Таким образом, если поле равно точному запросу, `sph04` должен ранжировать его выше, чем поле, содержащее точный запрос, но не равное ему. (Например, когда запрос "Hyde Park", документ с заголовком "Hyde Park" будет иметь более высокий ранг, чем "Hyde Park, London" или "The Hyde Park Cafe".) +* `expr` позволяет указать формулу ранжирования во время выполнения. Он раскрывает несколько внутренних текстовых факторов и позволяет определить, как вычислять итоговый вес из этих факторов. Больше подробностей о его синтаксисе и список доступных факторов можно найти в [подразделе ниже](../Searching/Sorting_and_ranking.md#Quick-summary-of-the-ranking-factors). Имя ранкера не чувствительно к регистру. Пример: @@ -1022,19 +1074,19 @@ SELECT ... OPTION ranker=sph04; ## Краткое резюме факторов ранжирования -| Name | Level | Type | Summary | -| ----------------------- | --------- | ----- | ------------------------------------------------------------------------------------------------------------------ | -| max_lcs | query | int | максимальное возможное значение LCS для текущего запроса | -| bm25 | document | int | быстрая оценка BM25(1.2, 0) | -| bm25a(k1, b) | document | int | точное значение BM25() с настраиваемыми константами K1, B и поддержкой синтаксиса | -| bm25f(k1, b, {field=weight, ...}) | document | int | точное значение BM25F() с дополнительной настройкой весов полей | -| field_mask | document | int | битовая маска совпавших полей | -| query_word_count | document | int | количество уникальных включённых ключевых слов в запросе | -| doc_word_count | document | int | количество уникальных ключевых слов, совпавших в документе | -| lcs | field | int | Наибольшая общая подпоследовательность между запросом и документом, в словах | -| user_weight | field | int | пользовательский вес поля | -| hit_count | field | int | общее количество вхождений ключевых слов | -| word_count | field | int | количество уникальных совпавших ключевых слов | +| Название | Уровень | Тип | Краткое описание | +| ------------------------ | --------- | ----- | ------------------------------------------------------------------------------------------------------------------ | +| max_lcs | запрос | int | максимальное возможное значение LCS для текущего запроса | +| bm25 | документ | int | быстрая оценка BM25(1.2, 0) | +| bm25a(k1, b) | документ | int | точное значение BM25() с настраиваемыми константами K1, B и поддержкой синтаксиса | +| bm25f(k1, b, {field=weight, ...}) | документ | int | точное значение BM25F() с дополнительной настройкой весов полей | +| field_mask | документ | int | битовая маска совпавших полей | +| query_word_count | документ | int | количество уникальных включённых ключевых слов в запросе | +| doc_word_count | документ | int | количество уникальных ключевых слов, совпавших в документе | +| lcs | поле | int | Длиннейшая общая подпоследовательность между запросом и документом, в словах | +| user_weight | поле | int | вес пользовательского поля | +| hit_count | поле | int | общее количество вхождений ключевых слов | +| word_count | поле | int | количество уникальных совпавших ключевых слов | | tf_idf | field | float | сумма(tf*idf) по совпавшим ключевым словам == сумма(idf) по вхождениям | | min_hit_pos | field | int | позиция первого совпавшего вхождения, в словах, с 1 | | min_best_span_pos | field | int | позиция первого максимального LCS спана, в словах, с 1 | @@ -1066,49 +1118,49 @@ SELECT ... OPTION ranker=sph04; * `user_weight` (целое), вес, указанный пользователем для поля (см. [OPTION field_weights](../Searching/Options.md#field_weights) в SQL). По умолчанию вес равен 1, если явно не указан. * `hit_count` (целое), количество вхождений ключевых слов, совпавших в поле. Обратите внимание, что одно ключевое слово может встречаться несколько раз. Например, если 'hello' встречается 3 раза в поле, а 'world' 5 раз, `hit_count` будет 8. * `word_count` (целое), количество уникальных ключевых слов, совпавших в поле. Например, если 'hello' и 'world' встречаются в поле, `word_count` будет 2, независимо от количества вхождений каждого слова. -* `tf_idf` (float), сумма TF/IDF по всем ключевым словам, совпавшим в поле. IDF — это обратная частота документа, число с плавающей точкой от 0 до 1, описывающее, насколько часто встречается ключевое слово (по сути, 0 для ключевого слова, встречающегося в каждом проиндексированном документе, и 1 для уникального ключевого слова, встречающегося только в одном документе). TF — это частота термина, количество совпадений ключевого слова в поле. В качестве примечания, `tf_idf` фактически вычисляется суммированием IDF по всем совпавшим вхождениям. Это по конструкции эквивалентно суммированию TF*IDF по всем совпавшим ключевым словам. -* `min_hit_pos` (integer), позиция первого совпавшего ключевого слова, считаемая в словах +* `tf_idf` (float), сумма TF/IDF по всем ключевым словам, найденным в поле. IDF — обратная частота документов, число с плавающей точкой от 0 до 1, описывающее, насколько часто встречается ключевое слово (примерно 0 для ключевого слова, встречающегося в каждом проиндексированном документе, и 1 для уникального ключевого слова, встречающегося только в одном документе). TF — частота термина, количество совпадений ключевого слова в поле. Кстати, `tf_idf` фактически вычисляется как сумма IDF по всем найденным совпадениям. Это по сути эквивалентно суммированию TF*IDF по всем совпавшим ключевым словам. +* `min_hit_pos` (integer), позиция первого найденного совпадения ключевого слова, считается в словах - Следовательно, это относительно низкоуровневый, «сырой» фактор, который, вероятно, вы захотите *скорректировать* перед использованием для ранжирования. Конкретные корректировки сильно зависят от ваших данных и итоговой формулы, но вот несколько идей для начала: (a) любые бусты на основе min_gaps можно просто игнорировать, если word_count<2; + Следовательно, это относительно низкоуровневый, «сырой» фактор, который вы, вероятно, захотите *отрегулировать* перед использованием его для ранжирования. Конкретные настройки сильно зависят от ваших данных и итоговой формулы, но вот несколько идей для начала: (a) любые бусты, основанные на min_gaps, могут просто игнорироваться, если word_count < 2; - (b) нетривиальные значения min_gaps (то есть когда word_count>=2) можно ограничить определённой «худшей» константой, в то время как тривиальные значения (то есть когда min_gaps=0 и word_count<2) можно заменить этой константой; + (b) нетривиальные значения min_gaps (то есть когда word_count >= 2) могут быть ограничены определенной «наихудшей» константой, а тривиальные значения (то есть когда min_gaps = 0 и word_count < 2) могут быть заменены этой константой; - (c) можно применить функцию преобразования, например 1/(1+min_gaps) (чтобы лучшие, меньшие значения min_gaps максимизировали её, а худшие, большие значения min_gaps постепенно уменьшали); и так далее. -* `lccs` (integer). Длина самой длинной общей непрерывной подпоследовательности. Длина самой длинной общей подфразы между запросом и документом, вычисленная в ключевых словах. + (c) может применяться функция преобразования, например 1/(1+min_gaps) (чтобы лучшие, меньшие значения min_gaps максимизировали её, а худшие, большие значения min_gaps уменьшали плавно); и так далее. +* `lccs` (integer). Longest Common Contiguous Subsequence — наиболее длинная общая непрерывная подпоследовательность. Длина самой длинной подфразы, общей для запроса и документа, вычисленная в ключевых словах. - Фактор LCCS несколько похож на LCS, но более строгий. В то время как LCS может быть больше 1, даже если ни два слова запроса не совпадают рядом друг с другом, LCCS будет больше 1 только если в документе есть *точные*, непрерывные подфразы запроса. Например, запрос (one two three four five) и документ (one hundred three hundred five hundred) дадут lcs=3, но lccs=1, потому что, хотя взаимное расположение 3 ключевых слов (one, three, five) совпадает между запросом и документом, ни две совпадающие позиции фактически не соседствуют. + Фактор LCCS похож на LCS, но более строгий. В то время как LCS может быть больше 1, даже если ни два слова запроса не стоят рядом друг с другом, LCCS будет больше 1 только если в документе есть *точные*, непрерывные подфразы запроса. Например, запрос (one two three four five) и документ (one hundred three hundred five hundred) дадут lcs=3, но lccs=1, поскольку, хотя взаимное расположение 3 ключевых слов (one, three, five) совпадает между запросом и документом, ни две совпадающие позиции на самом деле не являются смежными. - Обратите внимание, что LCCS всё ещё не различает частые и редкие ключевые слова; для этого смотрите WLCCS. -* `wlccs` (float). Взвешенная длина самой длинной общей непрерывной подпоследовательности. Сумма IDF ключевых слов самой длинной общей подфразы между запросом и документом. + Обратите внимание, что LCCS по-прежнему не различает частотные и редкие ключевые слова; для этого см. WLCCS. +* `wlccs` (float). Weighted Longest Common Contiguous Subsequence — взвешенная наиболее длинная общая непрерывная подпоследовательность. Сумма IDF ключевых слов самой длинной подфразы, общей для запроса и документа. - WLCCS вычисляется аналогично LCCS, но каждое «подходящее» вхождение ключевого слова увеличивает его на IDF ключевого слова, а не просто на 1 (как в LCS и LCCS). Это позволяет ранжировать последовательности более редких и важных ключевых слов выше, чем последовательности частых ключевых слов, даже если последние длиннее. Например, запрос `(Zanzibar bed and breakfast)` даст lccs=1 для документа `(hotels of Zanzibar)`, но lccs=3 для `(London bed and breakfast)`, хотя «Zanzibar» на самом деле несколько реже, чем вся фраза «bed and breakfast». Фактор WLCCS решает эту проблему, используя частоты ключевых слов. -* `atc` (float). Aggregate Term Closeness. Мера близости, основанная на расположении, которая увеличивается, когда в документе содержится больше групп более близко расположенных и более важных (редких) ключевых слов запроса. + WLCCS вычисляется аналогично LCCS, но каждое «подходящее» вхождение ключевого слова увеличивает её на IDF ключевого слова, а не просто на 1 (как в LCS и LCCS). Это позволяет ранжировать выше последовательности более редких и важных ключевых слов, чем последовательности часто встречающихся ключевых слов, даже если последние длиннее. Например, запрос `(Zanzibar bed and breakfast)` даст lccs=1 для документа `(hotels of Zanzibar)`, но lccs=3 для `(London bed and breakfast)`, хотя «Zanzibar» на самом деле несколько реже, чем вся фраза «bed and breakfast». Фактор WLCCS решает эту проблему, используя частоты ключевых слов. +* `atc` (float). Aggregate Term Closeness — агрегированная близость терминов. Мера близости, которая увеличивается, если в документе содержится больше групп более близко расположенных и более важных (редких) ключевых слов из запроса. - **ВНИМАНИЕ:** следует использовать ATC с OPTION idf='plain,tfidf_unnormalized' (см. [ниже](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)); иначе вы можете получить неожиданные результаты. + **ПРЕДУПРЕЖДЕНИЕ:** следует использовать ATC с OPTION idf='plain,tfidf_unnormalized' (см. [ниже](../Searching/Sorting_and_ranking.md#Configuration-of-IDF-formula)); иначе могут возникнуть неожиданные результаты. - ATC работает следующим образом. Для каждого вхождения ключевого слова в документе вычисляется так называемая *близость термина*. Для этого рассматриваются все другие ближайшие вхождения всех ключевых слов запроса (включая само ключевое слово) слева и справа от рассматриваемого вхождения, вычисляется коэффициент затухания расстояния как k = pow(distance, -1.75) для этих вхождений, и суммируются затухающие IDF. В результате для каждого вхождения каждого ключевого слова получается значение «близости», описывающее «соседей» этого вхождения. Затем эти значения близости для каждого вхождения умножаются на соответствующий IDF ключевого слова, суммируются, и в конце вычисляется логарифм этой суммы. + ATC работает таким образом. Для каждого *вхождения* ключевого слова в документе мы вычисляем так называемую *близость термина*. Для этого рассматриваем все другие ближайшие вхождения всех ключевых слов запроса (включая само ключевое слово) слева и справа от данного вхождения, вычисляем коэффициент затухания расстояния как k = pow(distance, -1.75) для этих вхождений и суммируем затухающие IDF. В результате для каждого вхождения каждого ключевого слова получаем значение «близости», описывающее «соседей» этого вхождения. Затем множим эти значения близости для каждого вхождения на соответствующий IDF ключевого слова, суммируем всё это и в конце вычисляем логарифм от суммы. -Другими словами, мы обрабатываем лучшие (ближайшие) пары совпавших ключевых слов в документе и вычисляем попарные «близости» как произведение их IDF, масштабированное коэффициентом расстояния: +Проще говоря, мы обрабатываем лучшие (ближайшие) пары совпавших ключевых слов в документе и вычисляем попарные «близости» как произведение их IDF, умноженное на коэффициент расстояния: ``` pair_tc = idf(pair_word1) * idf(pair_word2) * pow(pair_distance, -1.75) ``` -Затем мы суммируем такие близости и вычисляем итоговое, логарифмически затухающее значение ATC: +Затем суммируем такие близости и вычисляем итоговое логарифмическое затухание ATC: ``` atc = log(1+sum(pair_tc)) ``` -Обратите внимание, что именно этот финальный затухающий логарифм является причиной, по которой следует использовать OPTION idf=plain, потому что без него выражение внутри log() может быть отрицательным. +Обратите внимание, что именно из-за этого конечного логарифмического затухания вы должны использовать OPTION idf=plain, потому что без него выражение внутри log() могло бы быть отрицательным. -Более близкие вхождения ключевых слов вносят *гораздо* больший вклад в ATC, чем более частые ключевые слова. Действительно, когда ключевые слова находятся рядом, distance=1 и k=1; если между ними одно слово, distance=2 и k=0.297, при двух словах между ними distance=3 и k=0.146 и так далее. При этом IDF затухает несколько медленнее. Например, в коллекции из 1 миллиона документов значения IDF для ключевых слов, совпадающих в 10, 100 и 1000 документах, будут соответственно 0.833, 0.667 и 0.500. Таким образом, пара ключевых слов с двумя довольно редкими ключевыми словами, встречающимися всего в 10 документах каждое, но с двумя словами между ними, даст pair_tc = 0.101 и едва превзойдёт пару с ключевыми словами из 100 и 1000 документов с одним словом между ними и pair_tc = 0.099. Более того, пара из двух *уникальных*, встречающихся в 1 документе ключевых слов с тремя словами между ними получит pair_tc = 0.088 и проиграет паре из двух ключевых слов из 1000 документов, расположенных рядом, с pair_tc = 0.25. Таким образом, в целом, хотя ATC и сочетает частоту ключевых слов и близость, он всё же несколько отдаёт предпочтение близости. +Более близкое расположение ключевых слов вносит *гораздо* больший вклад в ATC, чем более частотные ключевые слова. Действительно, когда ключевые слова расположены рядом, distance=1 и k=1; если между ними одно слово, distance=2 и k=0.297, при двух словах между distance=3 и k=0.146 и т.д. При этом IDF затухает несколько медленнее. Например, в коллекции из миллиона документов IDF ключевых слов, совпадающих в 10, 100 и 1000 документов соответственно, равны примерно 0.833, 0.667 и 0.500. Таким образом, пара ключевых слов с двумя достаточно редкими словами, каждое из которых встречается только в 10 документах и между которыми два слова, даст pair_tc = 0.101 и едва превзойдет пару из ключевых слов, которые встречаются в 100 и 1000 документах, с одним словом между ними и pair_tc = 0.099. Более того, пара из двух *уникальных* ключевых слов (по одному документу на каждое) с тремя словами между ними получит pair_tc = 0.088 и уступит паре из двух ключевых слов, встречающихся в 1000 документах, расположенных вплотную и дающих pair_tc = 0.25. Таким образом, хотя ATC и сочетает оба фактора — частоту ключевых слов и их близость, он по-прежнему несколько отдает предпочтение близости. ### Функции агрегации факторов ранжирования -**Функция агрегации по полю** — это функция с одним аргументом, которая принимает выражение с факторами на уровне поля, перебирает все совпавшие поля и вычисляет итоговые результаты. В настоящее время реализованы следующие функции агрегации по полю: +**Функция агрегации поля** — это функция с одним аргументом, которая принимает выражение с факторами уровня поля, перебирает все совпавшие поля и вычисляет итоговый результат. В настоящее время реализованы следующие функции агрегации поля: -* `sum`, которая суммирует аргумент по всем совпавшим полям. Например, `sum(1)` должна возвращать количество совпавших полей. +* `sum`, которая суммирует аргументное выражение по всем совпавшим полям. Например, `sum(1)` должна возвращать количество совпавших полей. * `top`, который возвращает наибольшее значение аргумента по всем совпадающим полям. * `max_window_hits`, управляет скользящим окном позиций попаданий для отслеживания максимального количества попаданий в пределах заданного размера окна. Он удаляет устаревшие попадания, выходящие за пределы окна, и добавляет последнее попадание, обновляя максимальное количество попаданий, найденных в этом окне. diff --git a/manual/russian/Securing_and_compacting_a_table/Compacting_a_table.md b/manual/russian/Securing_and_compacting_a_table/Compacting_a_table.md index 66fb933b29..604f9258ee 100644 --- a/manual/russian/Securing_and_compacting_a_table/Compacting_a_table.md +++ b/manual/russian/Securing_and_compacting_a_table/Compacting_a_table.md @@ -1,8 +1,8 @@ -# Компактирование таблицы +# Компактизация таблицы -Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или загрязняться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые были ранее удалены с помощью операторов DELETE. +Со временем RT-таблицы могут фрагментироваться на множество кусков на диске и/или сопровождаться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары кусков на диске, удаляя документы, которые были ранее удалены с помощью операторов DELETE. -Начиная с Manticore 4, этот процесс происходит [автоматически по умолчанию](../Server_settings/Searchd.md#auto_optimize). Однако вы также можете использовать следующие команды для ручного запуска компактирования таблицы. +Начиная с Manticore 4, этот процесс происходит [автоматически по умолчанию](../Server_settings/Searchd.md#auto_optimize). Однако вы также можете использовать следующие команды для ручного запуска компактизации таблицы. ## OPTIMIZE TABLE @@ -11,7 +11,7 @@ OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]] ``` -Оператор `OPTIMIZE` добавляет RT-таблицу в очередь оптимизации, которая будет обработана в фоновом потоке. +Оператор `OPTIMIZE` добавляет RT-таблицу в очередь оптимизации, которая будет обрабатываться в фоновом потоке. ##### SQL: @@ -21,21 +21,31 @@ OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]] ```sql OPTIMIZE TABLE rt; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt;" +``` + -### Количество оптимизируемых дисковых чанков +### Количество оптимизируемых кусков на диске -По умолчанию OPTIMIZE объединяет дисковые чанки RT-таблицы до количества, меньшего или равного числу логических ядер процессора, умноженному на 2. +По умолчанию OPTIMIZE сливает дисковые куски RT-таблицы до количества, не превышающего число логических ядер процессора, умноженное на 2. -Однако, если в таблице есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается как количество физических ядер процессора, делённое на 2, для улучшения производительности KNN-поиска. +Однако, если в таблице есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается как число физических ядер процессора, делённое на 2, для улучшения производительности KNN-поиска. -Вы также можете вручную контролировать количество оптимизируемых дисковых чанков с помощью опции `cutoff`. +Вы также можете вручную контролировать количество оптимизируемых кусков на диске с помощью опции `cutoff`. Дополнительные опции включают: -* Настройку сервера [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) для переопределения порога по умолчанию -* Настройку на уровне таблицы [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff) +* Параметр сервера [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) для переопределения порога по умолчанию +* Параметр для конкретной таблицы [optimize_cutoff](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#optimize_cutoff) ##### SQL: @@ -45,13 +55,23 @@ OPTIMIZE TABLE rt; ```sql OPTIMIZE TABLE rt OPTION cutoff=4; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION cutoff=4;" +``` + -### Запуск в фореграунде +### Запуск в фореграунд режиме -При использовании `OPTION sync=1` (по умолчанию 0) команда будет ждать завершения процесса оптимизации перед возвратом результата. Если соединение прервётся, оптимизация продолжит выполняться на сервере. +При использовании `OPTION sync=1` (по умолчанию 0) команда дождётся завершения процесса оптимизации перед возвратом результата. Если соединение будет прервано, оптимизация продолжит выполняться на сервере. ##### SQL: @@ -61,19 +81,29 @@ OPTIMIZE TABLE rt OPTION cutoff=4; ```sql OPTIMIZE TABLE rt OPTION sync=1; ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE rt OPTION sync=1;" +``` + ### Ограничение влияния на ввод-вывод -Оптимизация может быть длительным и интенсивным по вводу-выводу процессом. Чтобы минимизировать влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор `OPTIMIZE` просто добавляет задачу в его очередь. Фоновый поток оптимизации может быть ограничен по вводу-выводу, и вы можете контролировать максимальное количество операций ввода-вывода в секунду и максимальный размер ввода-вывода с помощью директив [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) и [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) соответственно. +Оптимизация может быть продолжительным и ресурсоёмким процессом по вводу-выводу. Чтобы уменьшить влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор `OPTIMIZE` всего лишь добавляет задачу в его очередь. Фоновый поток оптимизации может ограничивать скорость ввода-вывода, и вы можете контролировать максимальное число операций ввода-вывода в секунду и максимальный размер ввода-вывода с помощью директив [rt_merge_iops](../Server_settings/Searchd.md#rt_merge_iops) и [rt_merge_maxiosize](../Server_settings/Searchd.md#rt_merge_maxiosize) соответственно. -Во время оптимизации RT-таблица остаётся онлайн и доступна для поиска и обновлений почти всё время. Она блокируется на очень короткий период, когда успешно объединяется пара дисковых чанков, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы. +Во время оптимизации оптимизируемая RT-таблица остаётся онлайн и доступна для поиска и обновлений почти всё время. Она блокируется на очень короткий период, когда успешно сливается пара кусков на диске, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы. ### Оптимизация кластерных таблиц Пока [auto_optimize](../Server_settings/Searchd.md#auto_optimize) не отключён, таблицы оптимизируются автоматически. -Если вы сталкиваетесь с неожиданными SST или хотите, чтобы таблицы на всех узлах кластера были бинарно идентичны, необходимо: +Если у вас возникают неожиданные SST или вы хотите, чтобы таблицы на всех узлах кластера были бинарно идентичны, вам необходимо: 1. Отключить [auto_optimize](../Server_settings/Searchd.md#auto_optimize). 2. Вручную оптимизировать таблицы: @@ -82,6 +112,10 @@ OPTIMIZE TABLE rt OPTION sync=1; ```sql ALTER CLUSTER mycluster DROP myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster DROP myindex;" +``` Оптимизируйте таблицу: @@ -89,6 +123,10 @@ ALTER CLUSTER mycluster DROP myindex; ```sql OPTIMIZE TABLE myindex; ``` + +```JSON +POST /sql?mode=raw -d "OPTIMIZE TABLE myindex;" +``` Добавьте таблицу обратно в кластер: @@ -96,17 +134,21 @@ OPTIMIZE TABLE myindex; ```sql ALTER CLUSTER mycluster ADD myindex; ``` + +```JSON +POST /sql?mode=raw -d "ALTER CLUSTER mycluster ADD myindex;" +``` -Когда таблица будет добавлена обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера. -Любые локальные изменения, сделанные в таблице на других узлах, будут потеряны. +После того как таблица будет добавлена обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера. +Любые локальные изменения, произведённые в таблице на других узлах, будут потеряны. Изменения данных таблицы (вставки, замены, удаления, обновления) должны либо: -1. Быть отложены, либо -2. Направляться на узел, где выполняется процесс оптимизации. +1. Быть отложены, или +2. Быть направлены на узел, где выполняется процесс оптимизации. -Обратите внимание, что пока таблица отсутствует в кластере, команды insert/replace/delete/update должны обращаться к ней без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся с ошибкой. -После того как таблица будет добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова использовать префикс имени кластера, иначе они будут завершаться с ошибкой. +Обратите внимание, что пока таблица отсутствует в кластере, команды insert/replace/delete/update должны обращаться к ней без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся неудачей. +Когда таблица добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова включить префикс имени кластера, иначе они не будут работать. Операции поиска доступны как обычно на любом из узлов в процессе. diff --git a/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md b/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md index be2ace8b23..4b57222463 100644 --- a/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md +++ b/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_a_new_disk_chunk.md @@ -1,4 +1,4 @@ -# Сброс RAM-чанка в новый диск-чанк +# Сброс чанк RAM в новый чанк на диске ## FLUSH RAMCHUNK @@ -8,9 +8,9 @@ FLUSH RAMCHUNK rt_table ``` -Команда `FLUSH RAMCHUNK` создает новый диск-чанк в RT-таблице. +Команда `FLUSH RAMCHUNK` создаёт новый чанк на диске в RT-таблице. -Обычно RT-таблица автоматически сбрасывает и конвертирует содержимое RAM-чанка в новый диск-чанк, когда выполняется одно из [специальных условий](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions). Однако в некоторых случаях вы можете захотеть инициировать сброс вручную — и оператор `FLUSH RAMCHUNK` позволяет это сделать. +Обычно RT-таблица автоматически сбрасывает и преобразует содержимое чанка RAM в новый чанк на диске, когда выполняется одно из [специальных условий](../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#RAM-chunk-flushing-conditions). Однако в некоторых случаях вы можете захотеть вызвать сброс вручную — и инструкция `FLUSH RAMCHUNK` позволяет это сделать. ##### SQL: @@ -24,6 +24,26 @@ FLUSH RAMCHUNK rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH RAMCHUNK rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +``` + diff --git a/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md b/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md index 84b064641e..9d0682a460 100644 --- a/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md +++ b/manual/russian/Securing_and_compacting_a_table/Flushing_RAM_chunk_to_disk.md @@ -1,4 +1,4 @@ -# Сброс чанка RAM на диск +# Сброс чанка ОЗУ в файл ## FLUSH TABLE @@ -8,11 +8,11 @@ FLUSH TABLE rt_table ``` -`FLUSH TABLE` принудительно сбрасывает содержимое RAM чанка RT таблицы на диск. +`FLUSH TABLE` принудительно сбрасывает содержимое чанка ОЗУ RT-таблицы на диск. -Чанк RAM реального времени таблицы [RT table](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) автоматически сбрасывается на диск при корректном завершении работы или периодически каждые [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) секунд. +Чанк ОЗУ таблицы реального времени [RAM chunk](../Creating_a_table/Local_tables/Real-time_table.md#Real-time-table-files-structure) автоматически сбрасывается на диск при корректном завершении работы или периодически каждые [rt_flush_period](../Server_settings/Searchd.md#rt_flush_period) секунд. -Выполнение команды `FLUSH TABLE` не только принудительно записывает содержимое RAM чанка на диск, но и запускает очистку бинарных лог-файлов. +Выполнение команды `FLUSH TABLE` не только принудительно записывает содержимое чанка ОЗУ на диск, но и запускает очистку бинарных логов. ##### SQL: @@ -26,6 +26,25 @@ FLUSH TABLE rt; ```sql Query OK, 0 rows affected (0.05 sec) ``` + + +##### JSON: + + + +```JSON +POST /sql?mode=raw -d "FLUSH TABLE rt;" +``` + +```JSON +[ + { + "total": 0, + "error": "", + "warning": "" + } +] +```