Удалённая таблица в Manticore Search представлена префиксом agent в определении распределённой таблицы. Распределённая таблица может включать комбинацию локальных и удалённых таблиц. Если локальные таблицы не указаны, распределённая таблица будет полностью удалённой и служить только в качестве прокси. Например, у вас может быть экземпляр Manticore, который слушает на нескольких портах и обслуживает разные протоколы, а затем перенаправляет запросы на серверы бэкенда, которые принимают соединения только через внутренний бинарный протокол Manticore, используя постоянные соединения для уменьшения накладных расходов на установление соединений. Хотя полностью удалённая распределённая таблица сама по себе не обслуживает локальные таблицы, она всё равно потребляет ресурсы машины, так как ей всё равно нужно выполнять окончательные вычисления, такие как слияние результатов и вычисление итоговых агрегированных значений.

agent = address1 [ | address2 [...] ][:table-list]
agent = address1[:table-list [ | address2[:table-list [...] ] ] ]

Директива agent объявляет удалённых агентов, которые ищутся каждый раз при поиске во включённой распределённой таблице. Эти агенты по сути являются указателями на сетевые таблицы. Указанное значение включает адрес и может также включать несколько альтернатив (зеркал агентов) либо только для адреса, либо для адреса и списка таблиц.

Спецификация адреса должна быть одной из следующих:

address = hostname[:port] # eg. server2:9312
address = /absolute/unix/socket/path # eg. /var/run/manticore2.sock

hostname — это имя удалённого хоста, port — номер удалённого TCP-порта, table-list — список имён таблиц, разделённых запятыми, а квадратные скобки [] обозначают необязательное условие.

Если имя таблицы опущено, предполагается, что это та же таблица, где определена эта строка. Другими словами, при определении агентов для распределённой таблицы 'mycoolindex' вы можете просто указать адрес, и будет предполагаться, что вы запрашиваете таблицу mycoolindex на конечных точках агента.

Если номер порта опущен, предполагается значение 9312. Если он указан, но недействителен (например, 70000), агент будет пропущен.

Вы можете указать каждому агенту одну или несколько удалённых таблиц, расположенных на одном или нескольких сетевых серверах без ограничений. Это позволяет несколько различных режимов использования:

• Шардирование по нескольким серверам агентов и создание произвольной топологии кластера
• Шардирование по нескольким серверам агентов, зеркалированным для высокой доступности и балансировки нагрузки
• Шардирование внутри localhost для использования нескольких ядер (однако проще просто использовать несколько локальных таблиц)

Все агенты ищутся параллельно. Список индексов передаётся удалённому агенту дословно. Точный способ поиска по этому списку внутри агента (т.е. последовательно или параллельно) зависит исключительно от конфигурации агента (см. настройку threads). Мастер не имеет удалённого контроля над этим.

Важно отметить, что опция LIMIT игнорируется в запросах к агентам. Это связано с тем, что каждый агент может содержать разные таблицы, поэтому ответственность за применение ограничения к итоговому набору результатов лежит на клиенте. Именно поэтому запрос к физической таблице отличается от запроса к распределённой таблице при просмотре логов запросов. Запрос не может быть простой копией исходного запроса, так как это не даст правильных результатов.

Например, если клиент выполняет запрос SELECT ... LIMIT 10, 10, и есть два агента, при этом у второго агента всего 10 документов, то трансляция исходного запроса LIMIT 10, 10 приведёт к получению 0 документов от второго агента. Однако LIMIT 10,10 должен вернуть документы с 10 по 20 из итогового набора. Чтобы решить эту проблему, запрос должен быть отправлен агентам с более широким лимитом, например, с использованием значения max_matches по умолчанию 1000.

Например, если есть распределённая таблица dist, которая ссылается на удалённую таблицу user, запрос клиента SELECT * FROM dist LIMIT 10,10 будет преобразован в SELECT * FROM user LIMIT 0,1000 и отправлен удалённой таблице user. После получения результата распределённая таблица применит LIMIT 10,10 и вернёт запрошенные 10 документов.

SELECT * FROM dist LIMIT 10,10;

запрос будет преобразован в:

SELECT * FROM user LIMIT 0,1000

Кроме того, значение может указывать опции для каждого отдельного агента, такие как:

• ha_strategy - random, roundrobin, nodeads, noerrors (переопределяет глобальную настройку ha_strategy для конкретного агента)
• conn - pconn, persistent (эквивалентно установке agent_persistent на уровне таблицы)
• blackhole 0,1 (идентично настройке agent_blackhole для агента)
• retry_count целочисленное значение (соответствует agent_retry_count, но указанное значение не будет умножаться на количество зеркал)

agent = address1:table-list[[ha_strategy=value, conn=value, blackhole=value]]

Пример:

# config on box1
# sharding a table over 3 servers
agent = box2:9312:shard1
agent = box3:9312:shard2
# config on box2
# sharding a table over 3 servers
agent = box1:9312:shard2
agent = box3:9312:shard3
# config on box3
# sharding a table over 3 servers
agent = box1:9312:shard1
agent = box2:9312:shard3
# per agent options
agent = box1:9312:shard1[ha_strategy=nodeads]
agent = box2:9312:shard2[conn=pconn]
agent = box2:9312:shard2[conn=pconn,ha_strategy=nodeads]
agent = test:9312:any[blackhole=1]
agent = test:9312|box2:9312|box3:9312:any2[retry_count=2]
agent = test:9312|box2:9312:any2[retry_count=2,conn=pconn,ha_strategy=noerrors]

Для оптимальной производительности рекомендуется размещать удалённые таблицы, находящиеся на одном сервере, в одной записи. Например, вместо:

agent = remote:9312:idx1
agent = remote:9312:idx2

следует предпочесть:

agent = remote:9312:idx1,idx2

agent_persistent = remotebox:9312:index2

Опция agent_persistent позволяет устанавливать постоянное соединение с агентом, то есть соединение не будет разрываться после выполнения запроса. Синтаксис этой директивы такой же, как у директивы agent. Однако вместо открытия нового соединения с агентом для каждого запроса и последующего его закрытия, мастер будет поддерживать открытое соединение и повторно использовать его для последующих запросов. Максимальное количество постоянных соединений на хост агента определяется опцией persistent_connections_limit в разделе searchd.

Важно отметить, что persistent_connections_limit должен быть установлен в значение больше 0 для использования постоянных соединений с агентом. Если он не определён, по умолчанию равен 0, и директива agent_persistent будет работать так же, как директива agent.

Использование постоянных соединений мастер-агент снижает нагрузку на TCP-порты и экономит время на установку соединений, делая процесс более эффективным.

agent_blackhole = testbox:9312:testindex1,testindex2

Директива agent_blackhole позволяет пересылать запросы удалённым агентам без ожидания или обработки их ответов. Это полезно для отладки или тестирования производственных кластеров, так как можно настроить отдельный экземпляр для отладки/тестирования и пересылать запросы к нему с производственного мастер-экземпляра (агрегатора), не мешая работе в продакшене. Мастер searchd будет пытаться подключиться к blackhole-агенту и отправлять запросы как обычно, но не будет ждать или обрабатывать ответы, а все сетевые ошибки на blackhole-агентах будут игнорироваться. Формат значения идентичен формату обычной директивы agent.

agent_connect_timeout = 300

Директива agent_connect_timeout задаёт таймаут подключения к удалённым агентам. По умолчанию значение считается в миллисекундах, но может иметь другой суффикс). Значение по умолчанию — 1000 (1 секунда).

При подключении к удалённым агентам searchd будет ждать не более этого времени для успешного установления соединения. Если таймаут достигнут, но соединение не установлено, и включены retries, будет предпринята повторная попытка.

agent_query_timeout = 10000 # our query can be long, allow up to 10 sec

Директива agent_query_timeout задаёт время ожидания выполнения запроса удалённым агентом. Значение по умолчанию — 3000 миллисекунд (3 секунды), но может иметь суффикс для указания другой единицы времени.

После установления соединения searchd будет ждать не более agent_query_timeout для завершения удалённых запросов. Обратите внимание, что этот таймаут отличается от agent_connection_timeout, и общая возможная задержка, вызванная удалённым агентом, будет суммой обоих значений. Если таймаут agent_query_timeout достигнут, запрос не будет повторяться, вместо этого будет выдано предупреждение.

Обратите внимание, что поведение также зависит от reset_network_timeout_on_packet

Директива agent_retry_count — целое число, указывающее, сколько раз Manticore попытается подключиться и выполнить запрос к удалённым агентам в распределённой таблице, прежде чем сообщить о фатальной ошибке запроса. Работает аналогично agent_retry_count, определённому в разделе "searchd" конфигурационного файла, но применяется конкретно к таблице.

mirror_retry_count выполняет ту же функцию, что и agent_retry_count. Если заданы оба значения, приоритет будет у mirror_retry_count, и будет выдано предупреждение.

Следующие параметры управляют общим поведением удалённых агентов и задаются в разделе searchd конфигурационного файла. Они устанавливают значения по умолчанию для всего экземпляра Manticore.

• agent_connect_timeout — значение по умолчанию для параметра agent_connect_timeout.
• agent_query_timeout — значение по умолчанию для параметра agent_query_timeout. Его также можно переопределить для каждого запроса, используя то же имя параметра в распределённой (сетевой) таблице.
• agent_retry_count — целое число, указывающее количество попыток подключения и запроса к удалённым агентам в распределённой таблице до сообщения о фатальной ошибке. Значение по умолчанию — 0 (т.е. без повторных попыток). Это значение также можно задать для каждого запроса с помощью опции 'OPTION retry_count=XXX'. Если задана опция для конкретного запроса, она имеет приоритет над значением из конфигурации.

Обратите внимание, что если вы используете agent mirrors в определении вашей распределённой таблицы, сервер будет выбирать другой mirror перед каждой попыткой подключения согласно указанной ha_strategy. В этом случае значение agent_retry_count будет суммироваться для всех mirrors в наборе.

Например, если у вас 10 mirrors и задано agent_retry_count=5, сервер попытается выполнить до 50 повторных попыток (в среднем 5 попыток на каждые 10 mirrors). В случае опции ha_strategy = roundrobin будет ровно 5 попыток на каждый mirror.

При этом значение, заданное в опции retry_count в определении agent, служит абсолютным лимитом. Другими словами, опция [retry_count=2] в определении агента означает максимум 2 попытки, независимо от того, 1 или 10 mirrors в строке.

Директива agent_retry_delay — целочисленное значение, определяющее время в миллисекундах, которое Manticore Search будет ждать перед повторной попыткой запроса к удалённому агенту в случае сбоя. Это значение можно задать глобально в конфигурации searchd или для каждого запроса с помощью опции OPTION retry_delay=XXX. Если заданы обе опции, приоритет имеет опция для конкретного запроса. Значение по умолчанию — 500 миллисекунд (0.5 секунды). Эта опция актуальна только если agent_retry_count или опция OPTION retry_count для запроса не равны нулю.

Опция client_timeout задаёт максимальное время ожидания между запросами при использовании постоянных соединений. Значение указывается в секундах или с суффиксом времени. Значение по умолчанию — 5 минут.

Пример:

client_timeout = 1h

Опция hostname_lookup определяет стратегию обновления имён хостов. По умолчанию IP-адреса имён агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к DNS. Однако в некоторых случаях IP может динамически меняться (например, облачный хостинг), и может быть желательно не кэшировать IP. Установка этой опции в request отключает кэширование и выполняет запросы к DNS для каждого запроса. IP-адреса также можно обновить вручную с помощью команды FLUSH HOSTNAMES.

Опция listen_tfo позволяет использовать флаг TCP_FASTOPEN для всех слушателей. По умолчанию он управляется системой, но его можно явно отключить, установив значение '0'.

Для получения дополнительной информации о расширении TCP Fast Open, пожалуйста, обратитесь к Wikipedia. Кратко, это позволяет исключить один круговой обмен TCP при установлении соединения.

На практике использование TFO может оптимизировать сетевую эффективность клиента-агента, аналогично использованию agent_persistent, но без удержания активных соединений и без ограничений на максимальное количество соединений.

Большинство современных операционных систем поддерживают TFO. Linux (как одна из самых прогрессивных) поддерживает его с 2011 года, начиная с ядер версии 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие системы, такие как FreeBSD и MacOS, также поддерживают эту функцию.

Для систем Linux сервер проверяет переменную /proc/sys/net/ipv4/tcp_fastopen и ведет себя соответственно. Бит 0 управляет клиентской стороной, а бит 1 — слушателями. По умолчанию в системе этот параметр установлен в 1, то есть клиенты включены, а слушатели отключены.

persistent_connections_limit = 29 # assume that each host of agents has max_connections = 30 (or 29).

Опция persistent_connections_limit определяет максимальное количество одновременных постоянных соединений с удалёнными постоянными агентами. Это настройка на уровне экземпляра и должна быть определена в разделе конфигурации searchd. Каждый раз при установлении соединения с агентом, определённым в agent_persistent, мы пытаемся повторно использовать существующее соединение (если оно есть) или создать новое и сохранить его для будущего использования. Однако в некоторых случаях может потребоваться ограничить количество постоянных соединений. Эта директива задаёт лимит и влияет на количество соединений с хостом каждого агента во всех распределённых таблицах.

Рекомендуется устанавливать это значение равным или меньшим, чем опция max_connections в конфигурации агента.

Особым случаем распределённой таблицы является одна локальная и несколько удалённых, которая используется исключительно для создания распределённых сниппетов, когда сниппеты берутся из файлов. В этом случае локальная таблица может выступать в роли "шаблонной" таблицы, предоставляя настройки для токенизации при построении сниппетов.

snippets_file_prefix = /mnt/common/server1/

snippets_file_prefix — это необязательный префикс, который можно добавить к локальным именам файлов при генерации сниппетов. Значение по умолчанию — текущая рабочая папка.

Чтобы узнать больше о создании распределённых сниппетов, смотрите CALL SNIPPETS.

Вы можете создать распределённую таблицу из нескольких перколяторных таблиц. Синтаксис построения такого типа таблиц такой же, как и для других распределённых таблиц, и может включать несколько local таблиц, а также agents.

Для DPQ операции перечисления сохранённых запросов и поиска по ним (с использованием CALL PQ) прозрачны и работают так, как если бы все таблицы были одной локальной таблицей. Однако операции изменения данных, такие как insert, replace, truncate, недоступны.

Если в список агентов включена не перколяторная таблица, поведение будет неопределённым. Если неправильный агент имеет ту же схему, что и внешняя схема PQ таблицы (id, query, tags, filters), это не вызовет ошибку при перечислении сохранённых правил PQ и может загрязнить список фактических правил PQ, хранящихся в PQ таблицах, своими собственными не-PQ строками. В результате будьте осторожны и осознавайте возможную путаницу. Вызов CALL PQ к такому неправильному агенту вызовет ошибку.

Для получения дополнительной информации о выполнении запросов к распределённой перколяторной таблице смотрите выполнение запросов к распределённой перколяторной таблице.

Manticore Search имеет один уровень иерархии для таблиц.

В отличие от других СУБД, в Manticore нет концепции группировки таблиц в базы данных. Однако, для совместимости с диалектами SQL, Manticore принимает операторы SHOW DATABASES для совместимости с диалектом SQL, но оператор не возвращает никаких результатов.

SHOW TABLES [ LIKE pattern ]

SHOW TABLES;

$client->nodes()->table();

utilsApi.sql('SHOW TABLES')

await utilsApi.sql('SHOW TABLES')

res = await utilsApi.sql('SHOW TABLES');

utilsApi.sql("SHOW TABLES", true)

utilsApi.Sql("SHOW TABLES", true)

utils_api.sql("SHOW TABLES", Some(true)).await

+----------+-------------+
| Index    | Type        |
+----------+-------------+
| dist     | distributed |
| plain    | local       |
| pq       | percolate   |
| rt       | rt          |
| template | template    |
+----------+-------------+
5 rows in set (0.00 sec)

Array
(
    [dist1] => distributed
    [rt] => rt
    [products] => rt
)

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'dist1', u'Type': u'distributed'},
           {u'Index': u'rt', u'Type': u'rt'},
           {u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'dist1', u'Type': u'distributed'},
           {u'Index': u'rt', u'Type': u'rt'},
           {u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{"columns":[{"Index":{"type":"string"}},{"Type":{"type":"string"}}],"data":[{"Index":"products","Type":"rt"}],"total":0,"error":"","warning":""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error=, warning=}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

SHOW TABLES LIKE 'pro%';

$client->nodes()->table(['body'=>['pattern'=>'pro%']]);

utilsApi.sql('SHOW TABLES LIKE \'pro%\'');

await utilsApi.sql('SHOW TABLES LIKE \'pro%\'');

utilsApi.sql('SHOW TABLES LIKE \'pro%\'')

utilsApi.sql("SHOW TABLES LIKE 'pro%'", true)

utilsApi.Sql("SHOW TABLES LIKE 'pro%'", true)

utils_api.sql("SHOW TABLES LIKE 'pro%'", Some(true)).await

+----------+-------------+
| Index    | Type        |
+----------+-------------+
| products | distributed |
+----------+-------------+
1 row in set (0.00 sec)

Array
(
    [products] => distributed
)

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{"columns":[{"Index":{"type":"string"}},{"Type":{"type":"string"}}],"data":[{"Index":"products","Type":"rt"}],"total":0,"error":"","warning":""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error=, warning=}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{DESC | DESCRIBE} table_name [ LIKE pattern ]

Оператор DESCRIBE выводит столбцы таблицы и их соответствующие типы. Столбцы включают ID документа, полнотекстовые поля и атрибуты. Порядок соответствует порядку, в котором поля и атрибуты ожидаются в операторах INSERT и REPLACE. Типы столбцов включают field, integer, timestamp, ordinal, bool, float, bigint, string и mva. Столбец ID будет иметь тип bigint. Пример:

mysql> DESC rt;
+---------+---------+
| Field   | Type    |
+---------+---------+
| id      | bigint  |
| title   | field   |
| content | field   |
| gid     | integer |
+---------+---------+
4 rows in set (0.00 sec)

Поддерживается необязательный оператор LIKE. Обратитесь к SHOW META для деталей синтаксиса.

select * from tbl.@table where type='text';

+------+-------+------+----------------+
| id   | field | type | properties     |
+------+-------+------+----------------+
|    2 | title | text | indexed stored |
+------+-------+------+----------------+
1 row in set (0.00 sec)

select field from tbl.@table;
select field, properties from tbl.@table where type in ('text', 'uint');
select * from tbl.@table where properties any ('stored');

SHOW CREATE TABLE table_name

SHOW CREATE TABLE tbl\G

       Table: tbl
Create Table: CREATE TABLE tbl (
f text indexed stored
) charset_table='non_cont,cont' morphology='icu_chinese'
1 row in set (0.00 sec)

Если вы используете оператор DESC для таблицы percolate, он отобразит схему внешней таблицы, которая является схемой сохранённых запросов. Эта схема статична и одинакова для всех локальных таблиц percolate:

mysql> DESC pq;
+---------+--------+
| Field   | Type   |
+---------+--------+
| id      | bigint |
| query   | string |
| tags    | string |
| filters | string |
+---------+--------+
4 rows in set (0.00 sec)

Если вы хотите просмотреть ожидаемую схему документа, используйте следующую команду: DESC <pq table name> table:

mysql> DESC pq TABLE;
+-------+--------+
| Field | Type   |
+-------+--------+
| id    | bigint |
| title | text   |
| gid   | uint   |
+-------+--------+
3 rows in set (0.00 sec)

Также поддерживается desc pq table like ... и работает следующим образом:

mysql> desc pq table like '%title%';
+-------+------+----------------+
| Field | Type | Properties     |
+-------+------+----------------+
| title | text | indexed stored |
+-------+------+----------------+
1 row in set (0.00 sec)

DROP TABLE products;

POST /cli -d "DROP TABLE products"

$params = [ 'table' => 'products' ];
$response = $client->indices()->drop($params);

utilsApi.sql('DROP TABLE products')

await utilsApi.sql('DROP TABLE products')

res = await utilsApi.sql('DROP TABLE products');

sqlresult = utilsApi.sql("DROP TABLE products", true);

sqlresult = utilsApi.Sql("DROP TABLE products", true);

let sqlresult = utils_api.sql("DROP TABLE products", Some(true)).await;

Query OK, 0 rows affected (0.02 sec)

{
"total":0,
"error":"",
"warning":""
}

Array
(
    [total] => 0
    [error] =>
    [warning] =>
)

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

Вот синтаксис оператора DROP TABLE в SQL:

DROP TABLE [IF EXISTS] table_name

DROP TABLE IF EXISTS products;

POST /cli -d "DROP TABLE IF EXISTS products"

$params =
[
  'table' => 'products',
  'body' => ['silent' => true]
];
$client->indices()->drop($params);

utilsApi.sql('DROP TABLE IF EXISTS products')

await utilsApi.sql('DROP TABLE IF EXISTS products')

res = await utilsApi.sql('DROP TABLE IF EXISTS products');

sqlresult = utilsApi.sql("DROP TABLE IF EXISTS products", true);

sqlresult = utilsApi.Sql("DROP TABLE IF EXISTS products", true);

let sqlresult = utils_api.sql("DROP TABLE IF EXISTS products", Some(true)).await;

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

TRUNCATE TABLE table_name [WITH RECONFIGURE]

TRUNCATE TABLE distributed_table

TRUNCATE TABLE products;

POST /cli -d "TRUNCATE TABLE products"

$params = [ 'table' => 'products' ];
$response = $client->indices()->truncate($params);

utilsApi.sql('TRUNCATE TABLE products')

await utilsApi.sql('TRUNCATE TABLE products')

res = await utilsApi.sql('TRUNCATE TABLE products');

utilsApi.sql("TRUNCATE TABLE products", true);

utilsApi.Sql("TRUNCATE TABLE products", true);

utils_api.sql("TRUNCATE TABLE products", Some(true)).await;

Query OK, 0 rows affected (0.02 sec)

{
"total":0,
"error":"",
"warning":""
}

Array(
    [total] => 0
    [error] =>
    [warning] =>
)

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

Одно из возможных применений этой команды — перед присоединением таблицы.

TRUNCATE TABLE products with reconfigure;

POST /cli -d "TRUNCATE TABLE products with reconfigure"

$params = [ 'table' => 'products', 'with' => 'reconfigure' ];
$response = $client->indices()->truncate($params);

utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE')

await utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE')

res = await utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE');

utilsApi.sql("TRUNCATE TABLE products WITH RECONFIGURE", true);

utilsApi.Sql("TRUNCATE TABLE products WITH RECONFIGURE" ,true);

utils_api.sql("TRUNCATE TABLE products WITH RECONFIGURE", Some(true)).await;

Query OK, 0 rows affected (0.02 sec)

{
"total":0,
"error":"",
"warning":""
}

Array(
    [total] => 0
    [error] =>
    [warning] =>
)

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}