Управление запросами¶

Просмотр списка активных запросов¶

Для просмотра списка активных запросов, выполняемых на всех экземплярах TCS-кластера, отправьте следующий POST-запрос на HTTP-адрес /sql:

POST http://localhost:7777/sql HTTP/1.1
x-tcs-route: broadcast
Content-Type: application/json

SELECT * FROM active_requests();

Пример ответа:

{
    "$HOST1:$PORT1": [
        {
            "config_details": {
                "computation_max_duration_ms": "4500",
                "computation_run_optimizations": "false",
                "execution_sample_rate": "0",
                "max_lsn": "0",
                "only_buffer": "false",
                "only_tarantool_exec": "false",
                "reverse_order": "true",
                "timeout_ms": "50000",
                "with_readview_buffer": "true"
            },
            "duration": 0,
            "path": "/sql",
            "request_details": {
                "query": "select * from active_requests();"
            },
            "request_id": "2-395197a0-0228-4ee6-a912-c79b14223725"
        }
    ],
    "$HOST2:$PORT2": [
        {
            "config_details": {
                "computation_max_duration_ms": "4500",
                "computation_run_optimizations": "false",
                "execution_sample_rate": "0",
                "max_lsn": "0",
                "only_buffer": "false",
                "only_tarantool_exec": "false",
                "reverse_order": "true",
                "timeout_ms": "50000",
                "with_readview_buffer": "true"
            },
            "duration": 0,
            "path": "/sql",
            "request_details": {
                "query": "select * from active_requests();"
            },
            "request_id": "1-238d0f47-9e30-4e8c-a04d-cb73bba93b7a"
        }
    ]
}

Отмена запроса¶

1. Найдите request_id запроса в списке активных запросов.

2. Отправьте следующий POST-запрос на HTTP-адрес /cancel с указанием request_id нужного запроса:

   curl -X POST 'http://$HOST:$PORT/cancel/$REQUEST_ID' \
   --header 'content-type: application/json' \
   --header 'x-tcs-route: broadcast' \
   --data ''
   

где:

• $HOST:$PORT - имя хоста и номер порта для приема запросов у экземпляра Scheduler (параметр http_listen в конфигурации).

• $REQUEST_ID - ID запроса, который нужно удалить.

• x-tcs-route: broadcast - этот параметр заголовка необходим, чтобы отправить запрос на все экземпляры Storage в кластере.

Пример ответа (от кластера c 3 экземплярами Storage):

{
    "$HOST1:$PORT1": "request context not exists",
    "$HOST2:$PORT2": "successfully cancel request with id=1-ddc44da9-f994-40d4-8d53-930575740751",
    "$HOST3:$PORT3": "request context not exists"
}

Возможные варианты ответов:

• request context not exists - нет запроса с таким request_id. Возможно, он уже завершился.

• successfully cancel request with id=%s - запрос отправлен на завершение.

• request context is not cancellable - запрос нельзя отменить.

• early cancel - wait - попробуйте отменить запрос еще раз. Отмена пришла слишком рано, еще на стадии маршрутизации запроса.

Пример HTTP-ответа от экземпляра Storage:

HTTP/1.1 409 Conflict
content-length: 21
date: Fri, 26 Jul 2024 09:00:24 GMT

Request was cancelled

Чтение из одного источника¶

По умолчанию чтение в TCS осуществляется сразу из двух источников:

• из буфера записи;

• из основного хранилища.

При необходимости можно настроить чтение только из одного источника. Для этого в заголовке HTTP-запроса нужно передать один из следующих параметров:

• x-tcs-only_buffer:true - чтение только из буфера записи. Такой запрос выполняется только на тех, которые приходили недавно и еще находятся в буфере записи. Тот же эффект можно получить, отправив запрос без этого параметра на HTTP-адрес /select_for_update.

• x-tcs-only_tarantool_exec:true - чтение только из основного хранилища.

Управление ускоренным обновлением буфера записи¶

После выполнения запроса на вставку по умолчанию происходит ускоренное обновление представления для чтения, и вставленные данные становятся доступны для чтения. При необходимости можно отключить ускоренное обновление, указав в заголовке запроса "x-tcs-with_readview_buffer": "false". В результате запрос на вставку может отработать быстрее, однако вставленные данные будут доступны для чтения только после следующего обновления представления для чтения.

Тот же параметр заголовка можно использовать в запросах на чтение. В этом случае эффект будет следующий: если в заголовке запроса указать "x-tcs-with_readview_buffer": "false", то при чтении из буфера записи не будут учитываться данные последних сделанных вставок.

Предварительная оценка времени выполнения запроса¶

Для запросов, отправляемых на HTTP-адреса /sql и /select_for_update, в заголовке можно указать параметр x-tcs-execution_sample_rate: N (например, x-tcs-execution_sample_rate: 1000). Для такого запроса используется каждый N-ый (например, 1000-ный) блок данных из основного хранилища. Таким образом, запрос обрабатывается на одной N-ой части всех данных. Это позволяет производить предварительную оценку длительности выполнения запроса без запуска его на всем объеме данных.

Просмотр фактического времени выполнения запроса¶

Для запросов, отправляемых на HTTP-адреса /sql и /computation, TCS отображает время, потраченное на разные этапы обработки запроса. Время отображается в заголовках ответа.

Пример запроса на HTTP-адрес /sql:

POST http://localhost:7777/sql HTTP/1.1
Content-Type: application/sql

select count(*) from attributes

Пример ответа:

HTTP/1.1 200 OK
content-type: application/json
x-elapsed-total: 69 ms
x-timings-details: logical_plan: 16.338351ms; phys_plan: 48.429085ms; exec: 218.203µs; collect: 1.012888ms mcs
content-length: 17
date: Fri, 21 Jun 2024 08:43:37 GMT

[
  {
    "COUNT(*)": 33
  }
]

где:

• x-elapsed-total отображает общее время внутри TCS от момента получения HTTP-запроса до формирования ответа клиенту.

• x-timings-details отображает время, потраченное на:

  • построение логического плана (logical_plan);

  • построение физического плана (phys_plan);

  • исполнение запроса (exec);

  • сбор результатов (collect).

Пример запроса на HTTP-адрес /computation:

POST http://localhost:7777/computation/run HTTP/1.1
Content-Type: application/json

[
    {
        "name": "prep",
        "args": [10]
    },
        {
        "name": "prep2",
        "args": [10]
    }
]

Пример ответа (детализация отображается в секции timings):

HTTP/1.1 200 OK
content-type: application/json
x-elapsed-total: 65 ms
content-length: 330
date: Fri, 21 Jun 2024 09:02:33 GMT

{
  "success": {
    "prep": [
      {
        "MAX(attributes.Attribute1)": 10
      }
    ],
    "prep2": [
      {
        "MAX(attributes.Attribute1)": 10
      }
    ]
  },
  "fail": {},
  "timings": {
    "prep": "log_plan_params: 207µs; phys_plan: 4.140193ms; exec: 385.881µs; collect: 35.266033ms",
    "prep2": "log_plan_params: 143.787µs; phys_plan: 2.087069ms; exec: 116.243µs; collect: 21.073716ms"
  },
  "plans": {}
}

Кроме этого, для запросов на HTTP-адрес /computation в параметре заголовка x-ext-tcs-computations-explain можно указать имена аналитических расчетов, для которых нужно отобразить детализацию EXPLAIN ANALYZE. Можно перечислить имена конкретных расчетов через запятую, либо указать * для вывода детализации по всем расчетам.

Пример запроса:

POST http://localhost:7777/computation/run HTTP/1.1
Content-Type: application/json
x-ext-tcs-computations-explain: prep

[
    {
        "name": "prep",
        "args": [10]
    },
        {
        "name": "prep2",
        "args": [10]
    }
]

Пример ответа (детализация отображается в секции plans):

HTTP/1.1 200 OK
content-type: application/json
x-elapsed-total: 79 ms
content-length: 3443
date: Fri, 21 Jun 2024 09:03:49 GMT

{
  "success": {
    "prep": [
      {
        "MAX(attributes.Attribute1)": 10
      }
    ],
    "prep2": [
      {
        "MAX(attributes.Attribute1)": 10
      }
    ]
  },
  "fail": {},
  "timings": {
    "prep": "log_plan_params: 161.717µs; phys_plan: 2.926266ms; exec: 462.374µs; collect: 45.819644ms",
    "prep2": "log_plan_params: 139.376µs; phys_plan: 2.091118ms; exec: 111.892µs; collect: 25.265247ms"
  },
  "plans": {
    "prep": "AggregateExec: mode=Single, gby=[], aggr=[MAX(attributes.Attribute1)],
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054078446 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.100186450 UTC,
                            elapsed_compute{partition=0}=36.736µs,
                            output_rows{partition=0}=1]\n
             CoalesceBatchesExec: target_batch_size=8192,
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054351475 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.100167028 UTC,
                            elapsed_compute{partition=0}=35.483µs,
                            output_rows{partition=0}=3]\n
             FilterExec: Attribute1@0 = 10,
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054135174 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.100107739 UTC,
                            elapsed_compute{partition=0}=150.762µs,
                            output_rows{partition=0}=3]\n
             GlobalLimitExec: skip=0, fetch=5000,
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054147863 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.100107324 UTC,
                            elapsed_compute{partition=0}=187ns,
                            output_rows{partition=0}=33]\n
             CoalescePartitionsExec, metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054159107 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.100106887 UTC,
                            elapsed_compute{partition=0}=178.829µs,
                            output_rows{partition=0}=33]\n
             LocalLimitExec: fetch=5000, metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054405894 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.054833748 UTC,
                            elapsed_compute{partition=0}=NOT RECORDED,
                            output_rows{partition=0}=0,
                            start_timestamp{partition=1}=2024-06-21 09:03:49.054499246 UTC,
                            end_timestamp{partition=1}=2024-06-21 09:03:49.099716257 UTC,
                            elapsed_compute{partition=1}=219ns, output_rows{partition=1}=33]\n
             UnionExec, metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054413558 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.054829576 UTC,
                            elapsed_compute{partition=0}=288.039µs,
                            output_rows{partition=0}=0,
                            start_timestamp{partition=1}=2024-06-21 09:03:49.054503867 UTC,
                            end_timestamp{partition=1}=2024-06-21 09:03:49.099709792 UTC,
                            elapsed_compute{partition=1}=651.434µs,
                            output_rows{partition=1}=33]\n
             TarantoolExec: fields=[Attribute1], fields_count=1,
                            reverse_order=false arrow_select=true,
                            index_seek=None inexact_filters=None,
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054424431 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.054856549 UTC,
                            elapsed_compute{partition=0}=106.754µs,
                            output_rows{partition=0}=0,
                            record_batch_counter{partition=0}=1,
                            input_batches{partition=0}=0,
                            errors{partition=0}=0,
                            max_index_size{partition=0}=0,
                            max_empty_chunks{partition=0}=0]\n
             BufExec: fields=[Attribute1], fields_count=1,
                            reverse_order=false index_seek=None
                            readview_buffer=Enabled max_lsn=0,
                            metrics=[start_timestamp{partition=0}=2024-06-21 09:03:49.054508948 UTC,
                            end_timestamp{partition=0}=2024-06-21 09:03:49.099724879 UTC,
                            elapsed_compute{partition=0}=94.642µs,
                            output_rows{partition=0}=33,
                            record_batch_counter{partition=0}=1,
                            input_batches{partition=0}=0,
                            errors{partition=0}=0,
                            max_index_size{partition=0}=0,
                            max_empty_chunks{partition=0}=0]\n"
  }
}

Ограничение времени выполнения запроса¶

Для запросов, отправляемых на HTTP-адрес /computation/run, можно указать максимальное время выполнения запроса (в миллисекундах). Для этого используются следующие параметры заголовка:

• x-tcs-timeout_ms - ограничение на суммарное время выполнения всех счетчиков в рамках запроса (по умолчанию, 5 мсек). При достижении этого ограничения прерывается обработка всего запроса и возвращается статус-код 408 Request timeout.

• x-tcs-computation_max_duration_ms - ограничение на индивидуальное время выполнение каждого счетчика в рамках запроса (по умолчанию, 4,5 мсек). При достижении этого ограничения прерывается вычисление конкретного счетчика, но обработка запроса продолжается. Информация о счетчиках, которые были прерваны по времени x-tcs-computation_max_duration_ms, записывается в ответе в секции fail.

Пример ответа:

{
   "success":{

   },
   "fail":{
      "very_long_plan1":"timed out",
      "very_long_plan2":"timed out"
   },
   "timings":{

   },
   "plans":{

   }
}

Передача заголовков столбцов в выводе аналитических расчетов¶

При отправке запроса на HTTP-адрес /computation/run можно включить передачу заголовков столбцов в успешном выводе. Для этого необходимо указать параметр x-tcs-include-table-headers: true в заголовке запроса.

Пример результата успешной обработки со включенным параметром x-tcs-include-table-headers:

{
  "success": {
    "success_key1": [["column_a", "column_b"], [{"column_a": 1, "column_b": 2"}, {"column_a": 3, "column_b": 4}]],
      ...
    "success_keyN": [["column_c", "column_d"], [{"column_c": 5, "column_d": 6"}]]
  },
  "fail": {
    "fail_key1": "err1",
      ...
    "fail_keyM": "errM"
  },
  "timings": {
    "key1": "timing1",
      ...
    "keyN": "timingN"
  },
  "plans": {
    "key1": "plan1",
      ...
    "keyN": "planN"
  },
}

Включение Ignite-совместимости для аналитических расчетов¶

Если результат запроса на HTTP-адрес /computation/run передается на платформу Apache Ignite, то в заголовок запроса необходимо добавить параметр x-tcs-ignite_compatible: true.

При установленном параметре x-tcs-ignite_compatible: true секция success в выводе будет иметь формат, совместимый с Apache Ignite.

Пример:

{
  "success": {
    "success_key1": { “schema”: ["column_a", "column_b"], “values”: [[1, 2], [3, 4]] },
      ...
    "success_keyN": { “schema”: ["column_c", "column_d"], “values”: [[5, 6]] },
  },
  "fail": {
    "fail_key1": "err1",
      ...
    "fail_keyM": "errM"
  },
  "timings": {
    "key1": "timing1",
      ...
    "keyN": "timingN"
  },
  "plans": {
    "key1": "plan1",
      ...
    "keyN": "planN"
  },
}

Отключение оптимизаций для аналитических расчетов¶

По умолчанию аналитические расчеты выполняются со всеми возможными оптимизациями. При необходимости любые из этих оптимизаций можно отключить для конкретного запроса. Для этого нужно указать названия отключаемых оптимизаций в параметре заголовка x-tcs-disabled_optimizations.

Пример запроса:

POST http://localhost:7777/computation
Content-Type: application/json
x-tcs-disabled_optimizations: common_sub_expression_eliminate, simplify_expressions

[тело_запроса]

Список названий всех возможных оптимизаций:

• common_sub_expression_eliminate

• decorrelate_predicate_subquery

• eliminate_cross_join

• eliminate_duplicated_expr

• eliminate_filter

• eliminate_group_by_constant

• eliminate_join

• eliminate_limit

• eliminate_nested_union

• eliminate_one_union

• eliminate_outer_join

• extract_equijoin_predicate

• filter_null_join_keys

• optimize_projections

• propagate_empty_relation

• push_down_filter

• push_down_limit

• replace_distinct_aggregate

• rewrite_disjunctive_predicate

• scalar_subquery_to_join

• simplify_expressions

• single_distinct_aggregation_to_group_by

• unwrap_cast_in_comparison

Параллельное выполнение аналитических расчетов¶

По умолчанию аналитические расчеты выполняются последовательно, в одном потоке. При необходимости их можно выполнять параллельно, в несколько потоков. Для этого нужно указать параметр run_concurrent=true.

Пример запроса:

POST http://localhost:7777/computation/run?run_concurrent=true HTTP/1.1

[тело_запроса]

Принудительная маршрутизация запросов на чтение¶

При необходимости экземпляры Scheduler могут принудительно отправлять запросы на чтение лишь на те экземпляры Storage, которые настроены на работу только в режиме чтения (read-only) – либо наборот, экземпляры Scheduler могут принудительно исключать такие экземпляры Storage из маршрутизации.

Для этого в заголовке запроса нужно указать параметр x-tcs-route и тот тип экземпляров, на которые нужно маршрутизировать запрос:

• "ro" для отправки на экземпляры, настроенные только на чтение;

• "rw" для исключения read-only экземпляров из маршрутизации (в этом случае запрос будет отправлен только на экземпляры, настроенные на чтение-запись);

• "ANY" для отправки на все типы экземпляров (это аналогично тому, когда заголовок x-tcs-route не указан).

Пример запроса для принудительной отправки на read-only экземпляры Storage:

POST http://localhost:7777/sql HTTP/1.1
Content-Type: application/json
x-tcs-route: "ro"

SELECT * FROM users WHERE id=1

Балансировка нагрузки для таких запросов осуществляется только среди указанного типа экземпляров Storage.

Отправка запросов в отдельную среду выполнения¶

Для ресурсоемких запросов (например, запросов с полным сканированием или запросов-слияний) предусмотрена возможность отправки в отдельную среду выполнения (runtime), где они будут обрабатываться ограниченными ресурсами сервера, не мешая обработке остальных запросов.

Для отправки запроса в одну из дополнительных сред выполнения нужно задать следующий параметр заголовка:

x-ext-tcs-request-runtime: ${имя_среды_выполнения}

например:

x-ext-tcs-request-runtime: analytics

Параллельное чтение колонок¶

Во время запросов на чтение TCS разбивает вычитанные из хранилища данные на части (партиции), проводит тяжелые операции (такие как GROUP BY, JOIN), склеивает данные и проводит финальную обработку. Каждая партиция может обрабатываться параллельно, это позволяет ускорить запрос.

Также параллельное чтение может ускорить любой запрос за счет лучшей утилизации CPU.

Для управления настройками параллельного чтения можно использовать следующие заголовки:

• x-tcs-partition_count – количество потоков обработки запроса (партиций) при чтении. Если заголовок x-tcs-partition_count не задан явным образом в запросе, то берется значение из параметра partition_count в конфигурации TCS (по умолчанию 1).

• x-tcs-partitioning_strategy – стратегия, по которой читаемые данные распределяются по партициям. В текущей версии TCS поддерживается только стратегия round_robin, при которой данные между партициями разделяются с помощью алогоритма round-robin, то есть циклически по порядку. Например, для 4 партиций и последовательности данных 1, 2, 3, 4, 5, 6, 7, 8 разделение данных по партициям будет выглядеть так:

  • партиция 1: 1, 5

  • партиция 2: 2, 6

  • партиция 3: 3, 7

  • партиция 4: 4, 8

Эти заголовки поддерживаются для запросов по следующим HTTP-адресам:

• /sql

• /streaming/sql

• /computation/run

• /exec/*

Отправка нескольких SQL-инструкций (multi-statement)¶

На HTTP-адрес /sql можно отсылать сразу несколько SQL-инструкций SELECT и/или INSERT INTO SELECT, разделенных точкой с запятой (;).

TCS обрабатывает инструкции в указанном порядке и возвращает список статусов.

Если обработка какой-либо инструкции заканчивается ошибкой, то TCS прекращает обработку инструкций и возвращает список статусов.

Пример запроса:

POST http://localhost:7777/sql HTTP/1.1
Content-Type: application/json

SELECT name FROM users; INSERT INTO names SELECT name FROM users; SELECT * FROM names ORDER BY name

Если, например, вторая инструкция (INSERT INTO names SELECT name FROM users) завершится ошибкой, то третья инструкция тоже не выполнится.

Атомарные вставки¶

По умолчанию запросы на вставку в TCS обрабатываются неатомарно. В этом случае, если вставка какого-либо объекта из запроса заканчивается неудачей, то вставка прерывается, но результат вставки не откатывается – те объекты, которые были обработаны до неудачи, остаются вставленными (TCS обрабатывает объекты в том порядке, в каком они указаны в запросе).

При необходимости для запроса можно указать режим атомарной вставки. В этом случае, если вставка какого-либо объекта из запроса заканчивается неудачей, то откатывается результат обработки всего запроса.

Режим атомарной вставки задается с помощью параметра заголовка x-tcs-atomic: true.

Пример запроса на атомарную вставку:

POST http://localhost:7777/insert HTTP/1.1
Content-Type: application/json
x-tcs-atomic: true

{
  "table_name": "db.public.users",
  "rows": [
    {
      "id": "1",
      "username": "alice",
      "created_at": 1710324848000
    },
    {
      "id": "2",
      "username": "bob",
      "created_at": 1710324849000
    },
    {
      "id": "3",
      "username": "ronald",
      "created_at": 1710324850000
    }
  ]
}

Если, например, вставка объекта с "id": "2" завершится ошибкой, то вообще никакой из объектов в запросе вставлен не будет.

В той же ситуации, если для запроса не указан параметр x-tcs-atomic: true (неатомарная вставка), то выполнится вставка только для объекта с "id": "1".

Выбор режима вставки в буфер записи¶

При вставке в колоночный буфер (engine: memcs) на HTTP-адресе /insert доступны два режима вставки:

• вставка строк как массивов формата Apache Arrow (по умолчанию);

• вставка строк как кортежей формата Tarantool.

Для переключения на вставку кортежами нужно указать параметр x-tcs-memcs_insert_arrow=false в заголовке запроса.

При вставке в колоночный буфер (engine: memcs) на HTTP-адрес /v2/insert доступен только режим вставки строк как кортежей формата Tarantool.

Выбор типа хранилища таблицы для вставки данных¶

При вставке данных в таблицы при помощи запросов на HTTP-адреса /sql и /v2/insert, данные попадают или в буфер записи, или в колоночное хранилище в зависимости от глобальных настроек системы.

Для того, чтобы указать, куда именно должны быть вставлены данные при конкретном запросе, необходимо в заголовке запроса указать параметр x-tcs-insert_into_columns:

• true - вставка данных в колоночное хранилище;

• false - вставка данных в буфер записи.

Включение схемы данных в ответ¶

По умолчанию, в ответ на запросы, сделанные на HTTP-адреса /sql и /streaming/sql, TCS возвращает JSON-ответ, содержащий массив данных без указания схемы. Например:

[
  {"t1":9,"t2":10},
  {"t1":7,"t2":8},
  {"t1":5,"t2":6},
  {"t1":3,"t2":4},
  {"t1":1,"t2":2}
]

При необходимости можно включить в ответ схему данных. Для этого заголовке запроса нужно указать один из следующих параметров:

• x-tcs-include_table_headers: true, чтобы в начале ответа возвращалась схема данных в формате каталог.схема.таблица.колонка. Например:

  [
    ["attributes.t1", "attributes.t2"],
    [
      {"t1":9,"t2":10},
      {"t1":7,"t2":8},
      {"t1":5,"t2":6},
      {"t1":3,"t2":4},
      {"t1":1,"t2":2}
    ]
  ]
  

• x-tcs-ignite_compatible: true, чтобы ответ приходил в формате Apache Ignite. Например:

  {
    "schema": ["t1", "t2"],
    "values": [ [1, 2], [3, 4]]
  }
  

Чтение данных в прямом/обратном порядке¶

По умолчанию, запись и чтение данных из таблиц в TCS производятся в разном порядке:

• чтение – в обратном порядке (первыми читаются и возвращаются старые данные),

• запись – в прямом порядке (запись начинается со свежих данных).

Порядок записи для всех таблиц указывается в конфигурации.

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

Для задания нужного порядка чтения следует указать в заголовке запроса параметр x-tcs-reverse_order:

• true (по умолчанию) для обратного порядка чтения (от старых данных к свежим);

• false для прямого порядка чтения (от свежих данных к старым).

Указанный порядок чтения задает направление обхода колоночных блоков в индексе и порядок чтения записей в самом блоке.