SELECT  ... FROM ...  [LIMIT [offset,] row_count]
SELECT  ... FROM ...  [LIMIT row_count][ OFFSET offset]

{
  "table": "<table_name>",
  "query": ...
  ...
  "limit": 20,
  "offset": 0
}
{
  "table": "<table_name>",
  "query": ...
  ...
  "size": 20,
  "from": 0
}

SELECT  ... FROM ...   OPTION max_matches=<value>

{
  "table": "<table_name>",
  "query": ...
  ...
  "max_matches":<value>
  }
}

Опция прокрутки (scroll search) предоставляет эффективный и надежный способ пагинации по большим наборам результатов. В отличие от традиционной пагинации на основе смещения, прокрутка обеспечивает лучшую производительность для глубокой пагинации и предлагает более простой способ её реализации. Хотя она использует то же окно max_matches, что и пагинация на основе смещения, прокрутка может возвращать больше документов, чем значение max_matches, извлекая результаты за несколько запросов с использованием токена прокрутки. При использовании пагинации через прокрутку нет необходимости использовать offset и limit вместе — это избыточно и обычно считается излишним усложнением. Вместо этого просто укажите limit вместе с токеном scroll для получения каждой последующей страницы.

SELECT ... ORDER BY [... ,] id {ASC|DESC};

SELECT weight(), id FROM test WHERE match('hello') ORDER BY weight() desc, id asc limit 2;

+----------+------+
| weight() | id   |
+----------+------+
|     1281 |    1 |
|     1281 |    2 |
+----------+------+
2 rows in set (0.00 sec)

SHOW SCROLL;

| scroll_token                       |
|------------------------------------|
| <base64 encoded scroll token>      |

SHOW SCROLL;

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| scroll_token                                                                                                                                                                                                             |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| eyJvcmRlcl9ieV9zdHIiOiJ3ZWlnaHQoKSBkZXNjLCBpZCBhc2MiLCJvcmRlcl9ieSI6W3siYXR0ciI6IndlaWdodCgpIiwiZGVzYyI6dHJ1ZSwidmFsdWUiOjEyODEsInR5cGUiOiJpbnQifSx7ImF0dHIiOiJpZCIsImRlc2MiOmZhbHNlLCJ2YWx1ZSI6MiwidHlwZSI6ImludCJ9XX0= |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

SELECT ... [ORDER BY [... ,] id {ASC|DESC}] OPTION scroll='<base64 encoded scroll token>'[, ...];

SELECT weight(), id FROM test WHERE match('hello') limit 2
OPTION scroll='eyJvcmRlcl9ieV9zdHIiOiJ3ZWlnaHQoKSBkZXNjLCBpZCBhc2MiLCJvcmRlcl9ieSI6W3siYXR0ciI6IndlaWdodCgpIiwiZGVzYyI6dHJ1ZSwidmFsdWUiOjEyODEsInR5cGUiOiJpbnQifSx7ImF0dHIiOiJpZCIsImRlc2MiOmZhbHNlLCJ2YWx1ZSI6MiwidHlwZSI6ImludCJ9XX0=';

+----------+------+
| weight() | id   |
+----------+------+
|     1281 |    3 |
|     1281 |    4 |
+----------+------+
2 rows in set (0.00 sec)

POST /search
{
  "table": "<table_names>",
  "options": {
      "scroll": true
  },
  ...
  "sort": [
    ...
    { "id":{ "order":"{asc|desc}"} }
  ]
}

{
    "timed_out": false,
    "hits": {
        ...
    },
    "scroll": "<base64 encoded scroll token>"
}

POST /search
{
  "table": "test",
  "options":
  {
    "scroll": true
  },
  "query":
  {
    "query_string":"hello"
  },
  "sort":
  [
    { "_score":{ "order":"desc"} },
    { "id":{ "order":"asc"} }
  ],
  "track_scores": true,
  "limit":2
}

{
  "took": 0,
  "timed_out": false,
  "hits":
  {
    "total": 10,
    "total_relation": "eq",
    "hits":
    [
      {
        "_id": 1,
        "_score": 1281,
        "_source":
        {
          "title": "hello world1"
        }
      },
      {
        "_id": 2,
        "_score": 1281,
        "_source":
        {
          "title": "hello world2"
        }
      }
    ]
  },
  "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjoyLCJ0eXBlIjoiaW50In1dfQ=="
}

POST /search
{
  "table": "<table_names>",
  "options": {
    "scroll": "<base64 encoded scroll token>"
  },
  ...
}

POST /search
{
  "table": "test",
  "options":
  {
    "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjoyLCJ0eXBlIjoiaW50In1dfQ=="
  },
  "query":
  {
    "query_string":"hello"
  },
  "track_scores": true,
  "limit":2
}

{
  "took": 0,
  "timed_out": false,
  "hits":
  {
    "total": 8,
    "total_relation": "eq",
    "hits":
   [
      {
        "_id": 3,
        "_score": 1281,
        "_source":
        {
          "title": "hello world3"
        }
      },
      {
        "_id": 4,
        "_score": 1281,
        "_source":
        {
          "title": "hello world4"
        }
      }
    ]
  },
  "scroll": "eyJvcmRlcl9ieV9zdHIiOiJAd2VpZ2h0IGRlc2MsIGlkIGFzYyIsIm9yZGVyX2J5IjpbeyJhdHRyIjoid2VpZ2h0KCkiLCJkZXNjIjp0cnVlLCJ2YWx1ZSI6MTI4MSwidHlwZSI6ImludCJ9LHsiYXR0ciI6ImlkIiwiZGVzYyI6ZmFsc2UsInZhbHVlIjo0LCJ0eXBlIjoiaW50In1dfQ=="
}

Manticore разработан для эффективного масштабирования за счёт возможностей распределённого поиска. Распределённый поиск полезен для улучшения задержки выполнения запросов (т.е. времени поиска) и пропускной способности (т.е. максимального количества запросов в секунду) в многосерверных, многоядерных или многоядерных средах. Это критично для приложений, которым нужно искать в огромных объёмах данных (т.е. миллиарды записей и терабайты текста).

Основная идея заключается в горизонтальном разделении данных для поиска между узлами поиска и их параллельной обработке.

Разбиение выполняется вручную. Для настройки необходимо:

• Развернуть несколько экземпляров Manticore на разных серверах
• Распределить разные части вашего набора данных по разным экземплярам
• Настроить специальную распределённую таблицу на некоторых из searchd экземпляров
• Направить ваши запросы к распределённой таблице

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

Когда Manticore получает запрос к распределённой таблице, он выполняет следующие шаги:

1. Подключается к настроенным удалённым агентам
2. Отправляет им запрос
3. Одновременно выполняет поиск по настроенным локальным таблицам (в то время как удалённые агенты ищут)
4. Получает результаты поиска от удалённых агентов
5. Объединяет все результаты, удаляя дубликаты
6. Отправляет объединённые результаты клиенту

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

Узнайте больше о удалённых узлах.

Мультизапросы, или пакетные запросы, позволяют отправлять несколько поисковых запросов в Manticore в рамках одного сетевого запроса.

👍 Зачем использовать мультизапросы?

Основная причина — производительность. Отправляя запросы в Manticore пакетом, а не по одному, вы экономите время за счет сокращения сетевых обходов. Кроме того, отправка запросов пакетом позволяет Manticore выполнять определенные внутренние оптимизации. Если оптимизации пакета неприменимы, запросы будут обрабатываться по отдельности.

⛔ Когда не следует использовать мультизапросы?

Мультизапросы требуют, чтобы все поисковые запросы в пакете были независимыми, что не всегда так. Иногда запрос B зависит от результатов запроса A, то есть запрос B можно настроить только после выполнения запроса A. Например, вы можете захотеть отобразить результаты из вторичного индекса только в том случае, если в основной таблице не найдено результатов, или вы можете указать смещение во втором наборе результатов на основе количества совпадений в первом наборе результатов. В этих случаях вам потребуется использовать отдельные запросы (или отдельные пакеты).

При использовании библиотек-коннекторов, таких как mysqli в PHP, вы можете добавить несколько запросов, а затем выполнить их все как единый пакет. Это будет работать как один пакет мультизапросов.

Примечание: Если вы используете консольный клиент MySQL, по умолчанию он интерпретирует точку с запятой (;) как разделитель и отправляет каждый запрос на сервер по отдельности; это не пакет мультизапросов. Чтобы переопределить это поведение, переопределите разделитель на стороне клиента на другой символ с помощью внутренней команды delimiter. После внесения этого изменения клиент будет отправлять всю строку с точками с запятой без изменений, что позволит работать "магии мультизапросов".

Такое побочное поведение консольного клиента часто может сбивать с толку, потому что вы можете заметить, что одна и та же последовательность команд ведет себя по-разному в консоли клиента MySQL по сравнению с другим протоколом, таким как SQL-over-HTTP. Это именно потому, что сам консольный клиент MySQL разделяет запросы с помощью точек с запятой, но другие протоколы могут отправлять всю последовательность как единый пакет.

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

Из консольного клиента MySQL/MariaDB:

DELIMITER _
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", но 1-й запрос запрашивает топ-10 результатов, отсортированных по цене, 2-й запрос группирует по ID поставщика и запрашивает топ-5 поставщиков, отсортированных по рейтингу, а 3-й запрос запрашивает максимальную цену, полнотекстовый поиск по "ipod nano" будет выполнен только один раз, и его результаты будут повторно использованы для построения 3 различных наборов результатов.

Фасетный поиск — это особенно важный случай, который выигрывает от этой оптимизации. Действительно, фасетный поиск может быть реализован путем выполнения нескольких запросов: один для получения самих результатов поиска, и несколько других с тем же полнотекстовым запросом, но с разными настройками группировки для получения всех требуемых групп результатов (топ-3 автора, топ-5 поставщиков и т.д.). Пока полнотекстовый запрос и настройки фильтрации остаются неизменными, сработает оптимизация общих запросов и значительно повысит производительность.

Оптимизация общих поддеревьев еще интереснее. Она позволяет searchd использовать сходства между пакетными полнотекстовыми запросами. Она определяет общие части полнотекстовых запросов (поддеревья) во всех запросах и кэширует их между запросами. Например, рассмотрим следующий пакет запросов:

donald trump president
donald trump barack obama john mccain
donald trump speech

Есть общая часть из двух слов donald trump, которую можно вычислить только один раз, затем закэшировать и использовать во всех запросах. И оптимизация общих поддеревьев делает именно это. Размер кэша на запрос строго контролируется директивами subtree_docs_cache и subtree_hits_cache (чтобы кэширование всех шестнадцати газиллионов документов, соответствующих "i am", не исчерпало оперативную память и мгновенно не убило ваш сервер).

[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/rel 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the

[Sun Jul 12 15:18:17.062 2009] 0.059 sec [ext/0/rel 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.156 2009] 0.091 sec [ext/0/ext 747541 (0,20)] [lj] the
[Sun Jul 12 15:18:17.250 2009] 0.092 sec [ext/0/ext 747541 (0,20)] [lj] the

Обратите внимание, как время на запрос в случае мультизапроса улучшилось в 1,5–2,3 раза в зависимости от конкретного режима сортировки.

Мультизапросы в основном поддерживаются для пакетной обработки запросов и получения метаинформации после таких пакетов. Из-за этого ограничения в пакетах разрешено только небольшое подмножество операторов. В одном пакете можно комбинировать только операторы SELECT, SHOW и SET.

Вы можете использовать SELECT как обычно; однако обратите внимание, что все запросы будут выполняться вместе за один проход. Если запросы не связаны, нет пользы от мультизапросов. Демон обнаружит это и запустит запросы по одному.

Вы можете использовать SHOW для обработки предупреждений, статуса, статуса агента, метаданных, профиля и плана. Все остальные операторы SHOW в пакетах будут тихо игнорироваться без вывода. Например, вы не можете выполнить SHOW TABLES, SHOW THREADS или SHOW VARIABLES, или любой другой оператор, не упомянутый выше, при пакетной обработке.

Вы можете использовать SET только для SET PROFILING. Все остальные команды SET ... будут тихо игнорироваться.

Порядок выполнения также отличается. Демон обрабатывает пакеты в два прохода.

Сначала он собирает все операторы SELECT и выполняет все встреченные операторы SET PROFILING одновременно. Как побочный эффект, только последний оператор SET PROFILING является эффективным. Если вы выполните мультизапрос, например: SET PROFILING=1; SELECT...; SHOW META; SHOW PROFILE; SET PROFILING=0, вы не увидите никакого профиля, потому что на первом проходе демон выполняет SET PROFILING=1, а затем сразу SET PROFILING=0.

Во-вторых, демон пытается выполнить один пакетный запрос со всеми собранными операторами SELECT. Если операторы не связаны, он выполнит их один за другим.

Наконец, он проходит по исходной последовательности пакета и возвращает данные подрезультата и метаданные из набора результатов для каждого SELECT и SHOW. Поскольку все операторы SET PROFILING были выполнены на первом проходе, они пропускаются на этом втором проходе. each SELECT and SHOW. Since all SET PROFILING statements were executed in the first pass, they are skipped on this second pass.

Manticore поддерживает подзапросы SELECT в SQL следующем формате:

SELECT * FROM (SELECT ... ORDER BY cond1 LIMIT X) ORDER BY cond2 LIMIT Y

Внешний SELECT допускает только конструкции ORDER BY и LIMIT. В настоящее время подзапросы используются в двух случаях:

1. Когда у вас есть запрос с двумя функциями ранжирования UDF, одна очень быстрая, другая медленная, и выполняется полнотекстовый поиск с большим набором результатов совпадений. Без подвыборки запрос выглядел бы так:

    SELECT id,slow_rank() as slow,fast_rank() as fast FROM index
        WHERE MATCH(‘some common query terms’) ORDER BY fast DESC, slow DESC LIMIT 20
        OPTION max_matches=1000;

   С подвыборками запрос можно переписать следующим образом:

    SELECT * FROM
        (SELECT id,slow_rank() as slow,fast_rank() as fast FROM index WHERE
            MATCH(‘some common query terms’)
            ORDER BY fast DESC LIMIT 100 OPTION max_matches=1000)
    ORDER BY slow DESC LIMIT 20;

   В исходном запросе UDF slow_rank() вычисляется для всего набора результатов совпадений. С помощью подзапросов SELECT для всего набора совпадений вычисляется только fast_rank(), а slow_rank() вычисляется для ограниченного набора.

2. Второй случай полезен для больших наборов результатов, поступающих из распределённой таблицы.

   Для этого запроса:

    SELECT * FROM my_dist_index WHERE some_conditions LIMIT 50000;

   Если у вас 20 узлов, каждый узел может отправить мастеру максимум 50K записей, что в сумме дает 20 x 50K = 1M записей. Однако, поскольку мастер возвращает только 50K (из 1M), может быть достаточно, чтобы узлы отправляли только топ 10K записей. С подзапросом вы можете переписать запрос так:

    SELECT * FROM
         (SELECT * FROM my_dist_index WHERE some_conditions LIMIT 10000)
     ORDER by some_attr LIMIT 50000;

   В этом случае узлы получают только внутренний запрос и выполняют его. Это означает, что мастер получит только 20x10K=200K записей. Мастер возьмет все полученные записи, переупорядочит их по ВНЕШНЕМУ условию и вернет лучшие 50K записей. Подвыборка помогает сократить трафик между мастером и узлами, а также уменьшить время обработки мастера (так как он обрабатывает только 200K вместо 1M записей).