WHERE — это SQL-клауза, которая работает как для полнотекстового поиска, так и для дополнительной фильтрации. Доступны следующие операторы:

• Операторы сравнения <, >, <=, >=, =, <>, BETWEEN, IN, IS NULL
• Булевы операторы AND, OR, NOT

Поддерживается MATCH('query'), который соответствует полнотекстовому запросу.

Поддерживается синтаксис условия {col_name | expr_alias} [NOT] IN @uservar. Обратитесь к синтаксису SET для описания глобальных пользовательских переменных.

Если вы предпочитаете интерфейс HTTP JSON, вы также можете применять фильтрацию. Это может показаться сложнее, чем SQL, но рекомендуется в случаях, когда нужно программно подготовить запрос, например, когда пользователь заполняет форму в вашем приложении.

POST /search
{
  "table": "test1",
  "query": {
    "bool": {
      "must": [
        { "match" : { "_all" : "product" } },
        { "range": { "price": { "gte": 500, "lte": 1000 } } }
      ],
      "must_not": {
        "range": { "revision": { "lt": 15 } }
      }
    }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "bool": {
      "must": [
        { "match": {"_all":"keyword"} },
        { "range": { "revision": { "gte": 14 } } }
      ]
    }
  }
}

"must": [
  {"equals" : { "product_codes": 5 }},
  {"equals" : { "product_codes": 6 }}
]

  {"in" : { "all(product_codes)": [5,6] }}

"should": [
  {"equals" : { "product_codes": 7 }},
  {"equals" : { "product_codes": 8 }}
]

  {"in" : { "any(product_codes)": [7,8] }}

POST /search
{
  "table":"t",
  "query": {
    "bool": {
      "should": [
        {
          "equals": {
            "b": 1
          }
        },
        {
          "equals": {
            "b": 3
          }
        }
      ],
      "must": [
        {
          "equals": {
            "a": 1
          }
        }
      ],
      "must_not": {
        "equals": {
          "b": 2
        }
      }
    }
  }
}

a = 2 and (a = 10 or b = 0)

POST /search
{
  "table":"t",
  "query": {
    "bool": {
      "must": [
        {
          "equals": {
            "a": 2
          }
        },
        {
          "bool": {
            "should": [
              {
                "equals": {
                  "a": 10
                }
              },
              {
                "equals": {
                  "b": 0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

(a = 1 and b = 1) or (a = 10 and b = 2) or (b = 0)

POST /search
{
  "table":"t",
  "query": {
    "bool": {
      "should": [
        {
          "bool": {
            "must": [
              {
                "equals": {
                  "a": 1
                }
              },
              {
                "equals": {
                  "b": 1
                }
              }
            ]
          }
        },
        {
          "bool": {
            "must": [
              {
                "equals": {
                  "a": 10
                }
              },
              {
                "equals": {
                  "b": 2
                }
              }
            ]
          }
        },
        {
          "bool": {
            "must": [
              {
                "equals": {
                  "b": 0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

POST /search
{
  "table": "test1",
  "query": {
    "bool": {
      "must": [
        { "query_string" : "product" },
        { "query_string" : "good" }
      ]
    }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "equals": { "price": 500 }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "equals": { "any(price)": 100 }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "in": {
      "price": [1,10,100]
    }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "in": {
      "all(price)": [1,10]
    }
  }
}

POST /search
{
  "table":"test1",
  "query": {
    "range": {
      "price": {
        "gte": 500,
        "lte": 1000
      }
    }
  }
}

POST /search
{
  "table":"test",
  "query": {
    "geo_distance": {
      "location_anchor": {"lat":49, "lon":15},
      "location_source": {"attr_lat, attr_lon"},
      "distance_type": "adaptive",
      "distance":"100 km"
    }
  }
}

POST /search
{
  "table": "geodemo",
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "*": "station"
          }
        },
        {
          "equals": {
            "state_code": "ENG"
          }
        },
        {
          "geo_distance": {
            "distance_type": "adaptive",
            "location_anchor": {
              "lat": 52.396,
              "lon": -1.774
            },
            "location_source": "latitude_deg,longitude_deg",
            "distance": "10000 m"
          }
        }
      ]
    }
  }
}

Объединения таблиц в Manticore Search позволяют комбинировать документы из двух таблиц, сопоставляя связанные столбцы. Эта функциональность обеспечивает более сложные запросы и улучшенный поиск данных по нескольким таблицам.

SELECT
    select_expr [, select_expr] ...
    FROM tbl_name
    {INNER | LEFT} JOIN tbl2_name
    ON join_condition
    [...other select options]
join_condition: {
    left_table.attr = right_table.attr
    | left_table.json_attr.string_id = string(right_table.json_attr.string_id)
    | left_table.json_attr.int_id = int(right_table.json_attr.int_id)
    | [..фильтры по атрибутам правой таблицы]
}

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

При объединении по значению из JSON-атрибута необходимо явно указать тип значения с помощью функции int() или string().

SELECT ... ON left_table.json_attr.string_id = string(right_table.json_attr.string_id)

SELECT ... ON left_table.json_attr.int_id = int(right_table.json_attr.int_id)

POST /search
{
  "table": "table_name",
  "query": {
    <optional full-text query against the left table>
  },
  "join": [
    {
      "type": "inner" | "left",
      "table": "joined_table_name",
      "query": {
        <optional full-text query against the right table>
      },
      "on": [
        {
          "left": {
            "table": "left_table_name",
            "field": "field_name",
            "type": "<common field's type when joining using json attributes>"
          },
          "operator": "eq",
          "right": {
            "table": "right_table_name",
            "field": "field_name"
          }
        }
      ]
    }
  ],
  "options": {
    ...
  }
}
on.type: {
    int
    | string
}

Обратите внимание, что в разделе операнда left есть поле type, которое следует использовать при объединении двух таблиц с использованием json-атрибутов. Допустимые значения — string и int.

Manticore Search поддерживает два типа объединений:

SELECT product, customers.email, customers.name, customers.address
FROM orders
INNER JOIN customers
ON customers.id = orders.customer_id
WHERE MATCH('maple', customers)
ORDER BY customers.email ASC;

POST /search
{
  "table": "orders",
  "join": [
    {
      "type": "inner",
      "table": "customers",
      "query": {
        "query_string": "maple"
      },
      "on": [
        {
          "left": {
            "table": "orders",
            "field": "customer_id"
          },
          "operator": "eq",
          "right": {
            "table": "customers",
            "field": "id"
          }
        }
      ]
    }
  ],
  "_source": ["product", "customers.email", "customers.name", "customers.address"],
  "sort": [{"customers.email": "asc"}]
}

+---------+-------------------+----------------+-------------------+
| product | customers.email   | customers.name | customers.address |
+---------+-------------------+----------------+-------------------+
| Laptop  | alice@example.com | Alice Johnson  | 123 Maple St      |
| Tablet  | alice@example.com | Alice Johnson  | 123 Maple St      |
+---------+-------------------+----------------+-------------------+
2 rows in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 2,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 1,
        "_source": {
          "product": "Laptop",
          "customers.email": "alice@example.com",
          "customers.name": "Alice Johnson",
          "customers.address": "123 Maple St"
        }
      },
      {
        "_id": 3,
        "_score": 1,
        "_source": {
          "product": "Tablet",
          "customers.email": "alice@example.com",
          "customers.name": "Alice Johnson",
          "customers.address": "123 Maple St"
        }
      }
    ]
  }
}

SELECT
name, orders.quantity
FROM customers
LEFT JOIN orders
ON orders.customer_id = customers.id
ORDER BY email ASC;

POST /search
{
    "table": "customers",
    "_source": ["name", "orders.quantity"],
    "join": [
    {
      "type": "left",
      "table": "orders",
      "on": [
        {
          "left": {
            "table": "orders",
            "field": "customer_id"
          },
          "operator": "eq",
          "right": {
            "table": "customers",
            "field": "id"
          }
        }
      ]
    }
  ],
  "sort": [{"email": "asc"}]
}

+---------------+-----------------+-------------------+
| name          | orders.quantity | @int_attr_email   |
+---------------+-----------------+-------------------+
| Alice Johnson |               1 | alice@example.com |
| Alice Johnson |               1 | alice@example.com |
| Bob Smith     |               2 | bob@example.com   |
| Carol White   |               1 | carol@example.com |
| John Smith    |            NULL | john@example.com  |
+---------------+-----------------+-------------------+
5 rows in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 5,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 1,
        "_source": {
          "name": "Alice Johnson",
          "address": "123 Maple St",
          "email": "alice@example.com",
          "orders.id": 3,
          "orders.customer_id": 1,
          "orders.quantity": 1,
          "orders.order_date": "2023-01-03",
          "orders.tags": [
            101,
            104
          ],
          "orders.details": {
            "price": 450,
            "warranty": "1 year"
          },
          "orders.product": "Tablet"
        }
      },
      {
        "_id": 1,
        "_score": 1,
        "_source": {
          "name": "Alice Johnson",
          "address": "123 Maple St",
          "email": "alice@example.com",
          "orders.id": 1,
          "orders.customer_id": 1,
          "orders.quantity": 1,
          "orders.order_date": "2023-01-01",
          "orders.tags": [
            101,
            102
          ],
          "orders.details": {
            "price": 1200,
            "warranty": "2 years"
          },
          "orders.product": "Laptop"
        }
      },
      {
        "_id": 2,
        "_score": 1,
        "_source": {
          "name": "Bob Smith",
          "address": "456 Oak St",
          "email": "bob@example.com",
          "orders.id": 2,
          "orders.customer_id": 2,
          "orders.quantity": 2,
          "orders.order_date": "2023-01-02",
          "orders.tags": [
            103
          ],
          "orders.details": {
            "price": 800,
            "warranty": "1 year"
          },
          "orders.product": "Phone"
        }
      },
      {
        "_id": 3,
        "_score": 1,
        "_source": {
          "name": "Carol White",
          "address": "789 Pine St",
          "email": "carol@example.com",
          "orders.id": 4,
          "orders.customer_id": 3,
          "orders.quantity": 1,
          "orders.order_date": "2023-01-04",
          "orders.tags": [
            105
          ],
          "orders.details": {
            "price": 300,
            "warranty": "1 year"
          },
          "orders.product": "Monitor"
        }
      },
      {
        "_id": 4,
        "_score": 1,
        "_source": {
          "name": "John Smith",
          "address": "15 Barclays St",
          "email": "john@example.com",
          "orders.id": 0,
          "orders.customer_id": 0,
          "orders.quantity": 0,
          "orders.order_date": "",
          "orders.tags": [],
          "orders.details": null,
          "orders.product": ""
        }
      }
    ]
  }
}

Одна из мощных возможностей объединений таблиц в Manticore Search — это возможность выполнять полнотекстовый поиск одновременно по левой и правой таблицам. Это позволяет создавать сложные запросы, фильтрующие данные на основе текстового содержимого в нескольких таблицах.

SELECT t1.f, t2.f 
FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
WHERE MATCH('hello', t1) AND MATCH('goodbye', t2);

POST /search
{
  "table": "t1",
  "query": {
    "query_string": "hello"
  },
  "join": [
    {
      "type": "left",
      "table": "t2",
      "query": {
        "query_string": "goodbye"
      },
      "on": [
        {
          "left": {
            "table": "t1",
            "field": "id"
          },
          "operator": "eq",
          "right": {
            "table": "t2",
            "field": "id"
          }
        }
      ]
    }
  ],
  "_source": ["f", "t2.f"]
}

+-------------+---------------+
| f           | t2.f          |
+-------------+---------------+
| hello world | goodbye world |
+-------------+---------------+
1 row in set (0.00 sec)

{
  "took": 1,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 2,
        "_score": 1680,
        "t2._score": 1680,
        "_source": {
          "f": "hello world",
          "t2.f": "goodbye world"
        }
      }
    ]
  }
}

В JSON API запросах полнотекстовый поиск по таблицам структурируется иначе, чем в SQL:

POST /search
{
  "table": "t1",
  "query": {
    "query_string": "hello"
  },
  "join": [
    {
      "type": "left",
      "table": "t2",
      "query": {
        "match": {
          "*": "goodbye"
        }
      },
      "on": [
        {
          "left": {
            "table": "t1",
            "field": "id"
          },
          "operator": "eq",
          "right": {
            "table": "t2",
            "field": "id"
          }
        }
      ]
    }
  ]
}

{
  "took": 1,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 1680,
        "t2._score": 1680,
        "_source": {
          "f": "hello world",
          "t2.id": 1,
          "t2.f": "goodbye world"
        }
      }
    ]
  }
}

SELECT * FROM t1 
LEFT JOIN t2 ON t1.id = t2.id 
WHERE MATCH('database', t1);

POST /search
{
  "table": "t1",
  "query": {
    "query_string": "database"
  },
  "join": [
    {
      "type": "left",
      "table": "t2",
      "on": [
        {
          "left": {
            "table": "t1",
            "field": "id"
          },
          "operator": "eq",
          "right": {
            "table": "t2",
            "field": "id"
          }
        }
      ]
    }
  ]
}

+------+-----------------+-------+------+
| id   | f               | t2.id | t2.f |
+------+-----------------+-------+------+
|    3 | database search |  NULL | NULL |
+------+-----------------+-------+------+
1 row in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 3,
        "_score": 1680,
        "t2._score": 0,
        "_source": {
          "f": "database search",
          "t2.id": 0,
          "t2.f": ""
        }
      }
    ]
  }
}

POST /search
{
  "table": "t1",
  "query": {
    "query_string": "database"
  },
  "join": [
    {
      "type": "left",
      "table": "t2",
      "query": {
        "query_string": "nonexistent"
      },
      "on": [
        {
          "left": {
            "table": "t1",
            "field": "id"
          },
          "operator": "eq",
          "right": {
            "table": "t2",
            "field": "id"
          }
        }
      ]
    }
  ]
}

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 0,
    "total_relation": "eq",
    "hits": []
  }
}

3. Тип JOIN влияет на фильтрацию: INNER JOIN требует выполнения условий объединения и запроса, тогда как LEFT JOIN возвращает совпадающие строки левой таблицы даже при несоответствии условий правой таблицы.

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

1. Поиск по конкретным таблицам:

   • SQL: Каждая функция MATCH() должна указывать, в какой таблице искать: MATCH('term', table_name)
   • JSON: Используйте корневое поле "query" для основной таблицы и поле "query" внутри каждого определения объединения для объединённых таблиц

2. Гибкость синтаксиса запроса: JSON API поддерживает синтаксис как "query_string", так и "match" для полнотекстовых запросов

3. Влияние на производительность: Полнотекстовый поиск по обеим таблицам может повлиять на производительность запроса, особенно при больших объёмах данных. Рекомендуется использовать соответствующие индексы и размеры пакетов.

4. Обработка NULL/значений по умолчанию: При LEFT JOIN, если нет совпадающей записи в правой таблице, оптимизатор запроса решает, сначала ли оценивать полнотекстовые условия или условия фильтрации, исходя из производительности. SQL возвращает значения NULL, а JSON API — значения по умолчанию (0 для чисел, пустые строки для текста).

5. Поведение фильтрации: Запросы к объединённым таблицам действуют как фильтры — они ограничивают результаты записями, удовлетворяющими и условиям объединения, и условиям запроса.

6. Поддержка полнотекстовых операторов: Все операторы полнотекстового поиска поддерживаются в JOIN-запросах, включая фразы, близость, поиск по полям, NEAR, кворум и расширенные операторы.

7. Вычисление оценки релевантности: Каждая таблица поддерживает собственный балл релевантности, доступный через table_name.weight() в SQL или table_name._score в JSON-ответах.

Опираясь на предыдущие примеры, рассмотрим более продвинутый сценарий, где мы комбинируем объединения таблиц с фасетированием и полнотекстовым поиском по нескольким таблицам. Это демонстрирует всю мощь возможностей JOIN в Manticore с комплексной фильтрацией и агрегацией.

SELECT orders.product, name, orders.details.price, orders.tags
FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id
WHERE orders.details.price > 500
AND MATCH('laptop | phone | tablet', orders)
AND MATCH('alice | bob', customers)
ORDER BY orders.id ASC
FACET orders.details.warranty;

POST /search
{
  "table": "customers",
  "query":  {
      "bool": {
          "must": [
          {
              "range": {
                  "orders.details.price": {
                      "gt": 500
                  }
               },
               "query_string": "alice | bob"
          ]
      }
  },
  "join": [
    {
      "type": "left",
      "table": "orders",
      "query": {
          "query_string": "laptop | phone | tablet"
      },
      "on": [
        {
          "left": {
            "table": "customers",
            "field": "id"
          },
          "operator": "eq",
          "right": {
            "table": "orders",
            "field": "customer_id"
          }
        }
      ]
    }
  ],
  "_source": ["orders.product", "name", "orders.details.price", "orders.tags"],
  "sort": [{"orders.id": "asc"}],
  "aggs": {
    "warranty_facet": {
      "terms": {
        "field": "orders.details.warranty"
      }
    }
  }
}

+-----------------+---------------+----------------------+-------------+
| orders.product  | name          | orders.details.price | orders.tags |
+-----------------+---------------+----------------------+-------------+
| Laptop Computer | Alice Johnson |                 1200 | 101,102     |
| Smart Phone     | Bob Smith     |                  800 | 103         |
+-----------------+---------------+----------------------+-------------+
2 rows in set (0.00 sec)
+-------------------------+----------+
| orders.details.warranty | count(*) |
+-------------------------+----------+
| 2 years                 |        1 |
| 1 year                  |        1 |
+-------------------------+----------+
2 rows in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 3,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 1,
        "orders._score": 1565,
        "_source": {
          "name": "Alice Johnson",
          "orders.tags": [
            101,
            102
          ],
          "orders.product": "Laptop Computer"
        }
      },
      {
        "_id": 2,
        "_score": 1,
        "orders._score": 1565,
        "_source": {
          "name": "Bob Smith",
          "orders.tags": [
            103
          ],
          "orders.product": "Smart Phone"
        }
      },
      {
        "_id": 1,
        "_score": 1,
        "orders._score": 1565,
        "_source": {
          "name": "Alice Johnson",
          "orders.tags": [
            101,
            104
          ],
          "orders.product": "Tablet Device"
        }
      }
    ]
  },
  "aggregations": {
    "warranty_facet": {
      "buckets": [
        {
          "key": "2 years",
          "doc_count": 1
        },
        {
          "key": "1 year",
          "doc_count": 2
        }
      ]
    }
  }
}

Для запросов в объединении можно задать отдельные параметры: для левой и правой таблиц. Синтаксис — OPTION(<table_name>) для SQL-запросов и один или несколько подобъектов в "options" для JSON-запросов.

SELECT product, customers.email, customers.name, customers.address, customers.weight()
FROM orders
INNER JOIN customers
ON customers.id = orders.customer_id
WHERE MATCH('maple', customers)
OPTION(customers) field_weights=(address=1500);

POST /search
{
  "table": "orders",
  "options": {
    "customers": {
      "field_weights": {
        "address": 1500
      }
    }
  },
  "join": [
    {
      "type": "inner",
      "table": "customers",
      "query": {
        "query_string": "maple"
      },
      "on": [
        {
          "left": {
            "table": "orders",
            "field": "customer_id"
          },
          "operator": "eq",
          "right": {
            "table": "customers",
            "field": "id"
          }
        }
      ]
    }
  ],
  "_source": ["product", "customers.email", "customers.name", "customers.address"]
}

+---------+-------------------+----------------+-------------------+--------------------+
| product | customers.email   | customers.name | customers.address | customers.weight() |
+---------+-------------------+----------------+-------------------+--------------------+
| Laptop  | alice@example.com | Alice Johnson  | 123 Maple St      |            1500680 |
| Tablet  | alice@example.com | Alice Johnson  | 123 Maple St      |            1500680 |
+---------+-------------------+----------------+-------------------+--------------------+
2 rows in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 2,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 1,
        "customers._score": 15000680,
        "_source": {
          "product": "Laptop",
          "customers.email": "alice@example.com",
          "customers.name": "Alice Johnson",
          "customers.address": "123 Maple St"
        }
      },
      {
        "_id": 3,
        "_score": 1,
        "customers._score": 15000680,
        "_source": {
          "product": "Tablet",
          "customers.email": "alice@example.com",
          "customers.name": "Alice Johnson",
          "customers.address": "123 Maple St"
        }
      }
    ]
  }
}

При выполнении объединений таблиц Manticore Search обрабатывает результаты пакетами для оптимизации производительности и использования ресурсов. Вот как это работает:

• Как работает пакетная обработка:

  • Сначала выполняется запрос к левой таблице, и результаты накапливаются в пакет.
  • Этот пакет затем используется как входные данные для запроса к правой таблице, который выполняется как единая операция.
  • Такой подход минимизирует количество запросов к правой таблице, повышая эффективность.

• Настройка размера пакета:

  • Размер пакета можно настроить с помощью опции поиска join_batch_size.
  • Также он настраивается в разделе searchd конфигурационного файла.
  • Размер пакета по умолчанию — 1000, но вы можете увеличить или уменьшить его в зависимости от задачи.
  • Установка join_batch_size=0 полностью отключает пакетную обработку, что может быть полезно для отладки или специфических сценариев.

• Особенности производительности:

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

Для дальнейшей оптимизации операций объединения Manticore Search использует механизм кэширования запросов, выполняемых по правой таблице. Вот что важно знать:

• Как работает кэширование:

  • Каждый запрос к правой таблице определяется условиями JOIN ON.
  • Если одни и те же условия JOIN ON повторяются в нескольких запросах, результаты кэшируются и переиспользуются.
  • Это позволяет избежать избыточных запросов и ускорить последующие операции объединения.

• Настройка размера кэша:

  • Размер кэша объединений можно настроить с помощью опции join_cache_size в разделе searchd конфигурационного файла.
  • Размер кэша по умолчанию — 20MB, но вы можете изменить его в зависимости от нагрузки и доступной памяти.
  • Установка join_cache_size=0 полностью отключает кэширование.

• Особенности использования памяти:

  • Каждый поток поддерживает собственный кэш, поэтому общий объём памяти зависит от количества потоков и размера кэша.
  • Убедитесь, что на сервере достаточно памяти для кэша, особенно при высокой конкуренции запросов.

Распределённые таблицы, состоящие только из локальных таблиц, поддерживаются как слева, так и справа в запросах с объединением. Однако распределённые таблицы, включающие удалённые таблицы, не поддерживаются.

При использовании JOIN в Manticore Search учитывайте следующие моменты:

1. Выбор полей: При выборе полей из двух таблиц в JOIN не используйте префикс для полей левой таблицы, но используйте префикс для полей правой таблицы. Например:

   SELECT field_name, right_table.field_name FROM ...

2. Условия JOIN: Всегда явно указывайте имена таблиц в условиях JOIN:

   JOIN ON table_name.some_field = another_table_name.some_field

3. Выражения с JOIN: При использовании выражений, объединяющих поля из обеих таблиц, задавайте псевдоним для результата выражения:

   SELECT *, (nums2.n + 3) AS x, x * n FROM nums LEFT JOIN nums2 ON nums2.id = nums.num2_id

4. Фильтрация по псевдонимам выражений: Нельзя использовать псевдонимы выражений, включающих поля из обеих таблиц, в условии WHERE.

5. JSON-атрибуты: При объединении по JSON-атрибутам необходимо явно приводить значения к нужному типу:

   -- Правильно:
   SELECT * FROM t1 LEFT JOIN t2 ON int(t1.json_attr.id) = t2.json_attr.id
   -- Неправильно:
   SELECT * FROM t1 LEFT JOIN t2 ON t1.json_attr.id = t2.json_attr.id

6. Обработка NULL: Можно использовать условия IS NULL и IS NOT NULL для объединённых полей:

   SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.name IS NULL
   SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.name IS NOT NULL

7. Использование ANY с MVA: При использовании функции ANY() с мультизначными атрибутами в JOIN задавайте псевдоним для мультизначного атрибута из присоединённой таблицы:

   SELECT *, t2.m AS alias
   FROM t
   LEFT JOIN t2 ON t.id = t2.t_id
   WHERE ANY(alias) IN (3, 5)

Следуя этим рекомендациям, вы сможете эффективно использовать JOIN в Manticore Search для объединения данных из нескольких индексов и выполнения сложных запросов.

Manticore позволяет использовать произвольные арифметические выражения как через SQL, так и через HTTP, включая значения атрибутов, внутренние атрибуты (ID документа и вес релевантности), арифметические операции, несколько встроенных функций и пользовательские функции. Ниже приведён полный справочный список для быстрого доступа.

+, -, *, /, %, DIV, MOD

Доступны стандартные арифметические операторы. Арифметические вычисления с использованием этих операторов могут выполняться в трёх различных режимах:

1. с использованием чисел с плавающей запятой одинарной точности, 32-битных по стандарту IEEE 754 (по умолчанию),
2. с использованием знаковых 32-битных целых чисел,
3. с использованием знаковых 64-битных целых чисел.

Парсер выражений автоматически переключается в целочисленный режим, если ни одна операция не приводит к значению с плавающей точкой. В противном случае используется режим с плавающей точкой по умолчанию. Например, a+b будет вычислено с использованием 32-битных целых чисел, если оба аргумента 32-битные целые; или с использованием 64-битных целых, если оба аргумента целые, но один из них 64-битный; или в формате с плавающей точкой в остальных случаях. Однако a/b или sqrt(a) всегда будут вычисляться в формате с плавающей точкой, так как эти операции возвращают нецелочисленный результат. Чтобы избежать этого, можно использовать IDIV(a,b) или форму DIV b. Кроме того, a*b не будет автоматически повышать разрядность до 64-бит при аргументах 32-бит. Чтобы обеспечить 64-битный результат, используйте BIGINT(), но учтите, что если присутствуют операции с нецелочисленными значениями, BIGINT() будет просто проигнорирован.

<, > <=, >=, =, <>

Операторы сравнения возвращают 1.0, когда условие истинно, и 0.0 в противном случае. Например, (a=b)+3 вычисляется как 4, когда атрибут a равен атрибуту b, и как 3, когда a не равен. В отличие от MySQL, сравнения на равенство (т.е. операторы = и <>) включают небольшой порог равенства (по умолчанию 1e-6). Если разница между сравниваемыми значениями находится в пределах порога, они считаются равными.

Операторы BETWEEN и IN в случае многозначных атрибутов возвращают true, если хотя бы одно значение соответствует условию (аналогично ANY()). Оператор IN не поддерживает JSON-атрибуты. Оператор IS (NOT) NULL поддерживается только для JSON-атрибутов.

AND, OR, NOT

Логические операторы (AND, OR, NOT) ведут себя ожидаемо. Они являются левосторонне ассоциативными и имеют самый низкий приоритет по сравнению с другими операторами. NOT имеет более высокий приоритет, чем AND и OR, но всё же ниже, чем любой другой оператор. AND и OR имеют одинаковый приоритет, поэтому рекомендуется использовать скобки, чтобы избежать путаницы в сложных выражениях.

&, |

Эти операторы выполняют побитовое И и ИЛИ соответственно. Операнды должны быть целочисленных типов.

• ABS()
• ALL()
• ANY()
• ATAN2()
• BIGINT()
• BITDOT()
• BM25F()
• CEIL()
• CONCAT()
• CONTAINS()
• COS()
• CRC32()
• DATE_HISTOGRAM()
• DATE_RANGE()
• DAY()
• DOUBLE()
• EXP()
• FIBONACCI()
• FLOOR()
• GEODIST()
• GEOPOLY2D()
• GREATEST()
• HOUR()
• HISTOGRAM()
• IDIV()
• IF()
• IN()
• INDEXOF()
• INTEGER()
• INTERVAL()
• LAST_INSERT_ID()
• LEAST()
• LENGTH()
• LN()
• LOG10()
• LOG2()
• MAX()
• MIN()
• MINUTE()
• MIN_TOP_SORTVAL()
• MIN_TOP_WEIGHT()
• MONTH()
• NOW()
• PACKEDFACTORS()
• POLY2D()
• POW()
• RAND()
• RANGE()
• REGEX()
• REMAP()
• SECOND()
• SIN()
• SINT()
• SQRT()
• SUBSTRING_INDEX()
• TO_STRING()
• UINT()
• YEAR()
• YEARMONTH()
• YEARMONTHDAY()
• WEIGHT()

В интерфейсе HTTP JSON поддерживаются выражения через script_fields и expressions.

{
    "table": "test",
    "query": {
        "match_all": {}
    }, "script_fields": {
        "add_all": {
            "script": {
                "inline": "( gid * 10 ) | crc32(title)"
            }
        },
        "title_len": {
            "script": {
                "inline": "crc32(title)"
            }
        }
    }
}

{
    "table":"movies_rt",
    "script_fields":{
        "cond1":{
            "script":{
                "inline":"actor_2_facebook_likes =296 OR movie_facebook_likes =37000"
            }
        },
        "cond2":{
            "script":{
                "inline":"IF (IN (content_rating,'TV-PG','PG'),2, IF(IN(content_rating,'TV-14','PG-13'),1,0))"
            }
        }
    },
    "limit":10,
    "sort":[
        {
            "cond2":"desc"
        },
        {
            "actor_1_name":"asc"
        },
        {
            "actor_2_name":"desc"
        }
    ],
    "profile":true,
    "query":{
        "bool":{
            "must":[
                {
                    "match":{
                        "*":"star"
                    }
                },
                {
                    "equals":{
                        "cond1":1
                    }
                }
            ],
            "must_not":[
                {
                    "equals":{
                        "content_rating":"R"
                    }
                }
            ]
        }
    }
}

По умолчанию значения выражений включаются в массив _source набора результатов. Если источник выборочный (см. Выбор источника), имя выражения можно добавить в параметр _source в запросе. Обратите внимание, что имена выражений должны быть в нижнем регистре.

{
  "table": "test",
  "query": { "match_all": {} },
  "expressions":
  {
      "add_all": "( gid * 10 ) | crc32(title)",
      "title_len": "crc32(title)"
  }
}

SQL SELECT оператор и HTTP /search эндпоинт поддерживают ряд опций, которые можно использовать для тонкой настройки поведения поиска.

SELECT ... [OPTION <optionname>=<value> [ , ... ]] [/*+ [NO_][ColumnarScan|DocidIndex|SecondaryIndex(<attribute>[,...])]] /*]

POST /search
{
    "table" : "table_name",
    "options":
    {
        "optionname": "value",
        "optionname2": <value2>
    }
}

SELECT * FROM test WHERE MATCH('@title hello @body world')
OPTION ranker=bm25, max_matches=3000,
field_weights=(title=10, body=3), agent_query_timeout=10000

POST /search
{
    "table" : "test",
    "query": {
      "match": {
        "title": "hello"
      },
      "match": {
        "body": "world"
      }
    },
    "options":
    {
        "ranker": "bm25",
        "max_matches": 3000,
        "field_weights": {
            "title": 10,
            "body": 3
        },
        "agent_query_timeout": 10000
    }
}

+------+-------+-------+
| id   | title | body  |
+------+-------+-------+
|    1 | hello | world |
+------+-------+-------+
1 row in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 1,
        "_score": 10500,
        "_source": {
          "title": "hello",
          "body": "world"
        }
      }
    ]
  }
}

Поддерживаемые опции:

Целое число. Включает или отключает гарантированную точность агрегатов при выполнении запросов groupby в нескольких потоках. По умолчанию 0.

При выполнении запроса groupby он может выполняться параллельно на простой таблице с несколькими псевдо-шардами (если включен pseudo_sharding). Аналогичный подход работает с RT таблицами. Каждый шард/чанк выполняет запрос, но количество групп ограничено max_matches. Если наборы результатов из разных шардов/чанков содержат разные группы, подсчёты групп и агрегаты могут быть неточными. Обратите внимание, что Manticore пытается увеличить max_matches до max_matches_increase_threshold на основе количества уникальных значений атрибута groupby (получаемых из вторичных индексов). Если это удаётся, потери точности не будет.

Однако, если количество уникальных значений атрибута groupby велико, дальнейшее увеличение max_matches может быть не лучшей стратегией, так как это может привести к снижению производительности и увеличению использования памяти. Установка accurate_aggregation в 1 заставляет groupby-запросы выполняться в одном потоке, что решает проблему точности. Обратите внимание, что выполнение в одном потоке принудительно только тогда, когда max_matches нельзя установить достаточно высоким; в противном случае запросы с accurate_aggregation=1 всё равно будут выполняться в нескольких потоках.

В целом, установка accurate_aggregation в 1 обеспечивает точность подсчёта групп и агрегатов в RT таблицах и простых таблицах с pseudo_sharding=1. Недостаток в том, что запросы будут выполняться медленнее, так как будут вынуждены работать в одном потоке.

Однако, если у нас есть RT таблица и простая таблица с одинаковыми данными, и мы выполняем запрос с accurate_aggregation=1, мы всё равно можем получить разные результаты. Это происходит потому, что демон может выбрать разные настройки max_matches для RT и простой таблицы из-за настройки max_matches_increase_threshold.

Целое число. Максимальное время в миллисекундах ожидания завершения удалённых запросов, см. этот раздел.

0 или 1 (по умолчанию 1). boolean_simplify=1 включает упрощение запроса для ускорения его выполнения.

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

Строка, пользовательский комментарий, который копируется в файл журнала запросов.

Целое число. Указывает максимальное количество обрабатываемых совпадений. Если не задано, Manticore автоматически выберет подходящее значение.

drop table if exists t
--------------
Query OK, 0 rows affected (0.02 sec)
--------------
create table t(a int)
--------------
Query OK, 0 rows affected (0.04 sec)
--------------
insert into t(a) values(1),(2),(3),(1),(2),(3)
--------------
Query OK, 6 rows affected (0.00 sec)
--------------
select avg(a) from t option cutoff=1 facet a
--------------
+----------+
| avg(a)   |
+----------+
| 1.000000 |
+----------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---
+------+----------+
| a    | count(*) |
+------+----------+
|    1 |        1 |
+------+----------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

--------------
select avg(a) from t facet a
--------------
+----------+
| avg(a)   |
+----------+
| 2.000000 |
+----------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---
+------+----------+
| a    | count(*) |
+------+----------+
|    1 |        2 |
|    2 |        2 |
|    3 |        2 |
+------+----------+
3 rows in set (0.00 sec)
--- 3 out of 3 results in 0ms ---

Целое число. По умолчанию 3500. Эта опция задаёт порог, ниже которого подсчёты, возвращаемые count distinct, гарантированно точны в пределах простой таблицы.

Допустимые значения варьируются от 500 до 15500. Значения вне этого диапазона будут ограничены.

Если эта опция установлена в 0, включается алгоритм, обеспечивающий точные подсчёты. Этот алгоритм собирает пары {group, value}, сортирует их и периодически устраняет дубликаты. Результат — точные подсчёты в пределах простой таблицы. Однако этот подход не подходит для наборов данных с высокой кардинальностью из-за высокого потребления памяти и медленного выполнения запросов.

Если distinct_precision_threshold установлен в значение больше 0, Manticore использует другой алгоритм. Он загружает подсчёты в хеш-таблицу и возвращает размер таблицы. Если хеш-таблица становится слишком большой, её содержимое переносится в структуру данных HyperLogLog. В этот момент подсчёты становятся приближенными, так как HyperLogLog — вероятностный алгоритм. Этот подход поддерживает фиксированное максимальное использование памяти на группу, но с компромиссом в точности подсчётов.

Точность HyperLogLog и порог для перехода от хеш-таблицы к HyperLogLog выводятся из настройки distinct_precision_threshold. Важно использовать эту опцию с осторожностью, так как удвоение её значения также удвоит максимальное количество памяти, необходимое для подсчётов. Максимальное использование памяти можно примерно оценить по формуле: 64 * max_matches * distinct_precision_threshold, хотя на практике подсчёты часто используют меньше памяти, чем в худшем случае.

0 или 1 (по умолчанию 0). Расширяет ключевые слова точными формами и/или звёздочками, когда это возможно. Подробнее см. expand_keywords.

Именованный список целых чисел (веса пользователя для ранжирования по полям).

Пример:

SELECT ... OPTION field_weights=(title=10, body=3)

Использовать глобальную статистику (частоты) из файла global_idf для вычисления IDF.

Кавычками, через запятую перечисленные флаги вычисления IDF. Известные флаги:

• normalized: вариант BM25, idf = log((N-n+1)/n), согласно Робертсону и др.
• plain: простой вариант, idf = log(N/n), согласно Спарку-Джонсу
• tfidf_normalized: дополнительно делить IDF на количество слов в запросе, чтобы TF*IDF попадал в диапазон [0, 1]
• tfidf_unnormalized: не делить дополнительно IDF на количество слов в запросе, где N — размер коллекции, а n — количество совпадающих документов

Исторически стандартный IDF (обратная частота документа) в Manticore эквивалентен OPTION idf='normalized,tfidf_normalized', и эти нормализации могут вызывать несколько нежелательных эффектов.

Во-первых, idf=normalized приводит к штрафованию ключевых слов. Например, если вы ищете the | something и the встречается более чем в 50% документов, то документы с обоими ключевыми словами the и something получат меньший вес, чем документы только с ключевым словом something. Использование OPTION idf=plain этого избегает. Простой IDF варьируется в диапазоне [0, log(N)], и ключевые слова никогда не штрафуются; в то время как нормализованный IDF варьируется в диапазоне [-log(N), log(N)], и слишком частые ключевые слова штрафуются.

Во-вторых, idf=tfidf_normalized приводит к дрейфу IDF между запросами. Исторически IDF также делился на количество ключевых слов в запросе, что обеспечивало, что сумма sum(tf*idf) по всем ключевым словам оставалась в диапазоне [0,1]. Однако это означало, что запросы вроде word1 и word1 | nonmatchingword2 присваивали разные веса одному и тому же набору результатов, так как IDF для word1 и nonmatchingword2 делились на 2. Использование OPTION idf='tfidf_unnormalized' решает эту проблему. Учтите, что факторы ранжирования BM25, BM25A, BM25F() будут соответственно скорректированы при отключении этой нормализации.

Флаги IDF могут комбинироваться; plain и normalized взаимоисключающие; tfidf_unnormalized и tfidf_normalized также взаимоисключающие; и неуказанные флаги в таких взаимоисключающих группах по умолчанию принимают свои исходные настройки. Это означает, что OPTION idf=plain эквивалентно полному указанию OPTION idf='plain,tfidf_normalized'.

Задает режим сегментации Jieba для запроса.

При использовании китайской сегментации Jieba иногда полезно использовать разные режимы сегментации для токенизации документов и запроса. Полный список режимов см. в jieba_mode.

Именованный список целых чисел. Веса пользователя для ранжирования по таблицам.

0 или 1, автоматически суммирует DF по всем локальным частям распределённой таблицы, обеспечивая согласованный (и точный) IDF для локально шардированной таблицы. По умолчанию включено для дисковых чанков RT-таблицы. Термины запроса с подстановочными знаками игнорируются.

0 или 1 (по умолчанию 0). Установка low_priority=1 выполняет запрос с пониженным приоритетом, перепланируя его задачи в 10 раз реже, чем запросы с нормальным приоритетом.

Целое число. Максимальное количество совпадений на запрос.

Максимальное количество совпадений, которое сервер хранит в ОЗУ для каждой таблицы и может вернуть клиенту. По умолчанию 1000.

Введено для контроля и ограничения использования ОЗУ, настройка max_matches определяет, сколько совпадений будет храниться в памяти при поиске по каждой таблице. Каждое найденное совпадение всё равно обрабатывается, но в памяти сохраняются только лучшие N из них, которые в итоге возвращаются клиенту. Например, если в таблице для запроса найдено 2 000 000 совпадений, редко нужно получить их все. Вместо этого нужно просканировать все, но выбрать только "лучшие" 500, например, по какому-то критерию (например, по релевантности, цене или другим факторам) и показать эти 500 совпадений пользователю постранично по 20-100 совпадений. Отслеживание только лучших 500 совпадений гораздо эффективнее по памяти и CPU, чем хранение всех 2 000 000, их сортировка и затем отбрасывание всего, кроме первых 20 для страницы результатов. max_matches контролирует N в этом количестве "лучших N".

Этот параметр существенно влияет на использование ОЗУ и CPU на запрос. Значения от 1000 до 10 000 обычно приемлемы, но более высокие лимиты следует использовать с осторожностью. Бездумное увеличение max_matches до 1 000 000 означает, что searchd должен выделить и инициализировать буфер для совпадений на миллион записей для каждого запроса. Это неизбежно увеличит использование ОЗУ на запрос и в некоторых случаях заметно повлияет на производительность.

Дополнительную информацию о влиянии на поведение опции max_matches см. в max_matches_increase_threshold.

Целое число. Устанавливает порог, до которого может быть увеличен max_matches. По умолчанию 16384.

Manticore может увеличить max_matches для повышения точности groupby и/или агрегаций при включённом pseudo_sharding, если обнаружит, что количество уникальных значений атрибута groupby меньше этого порога. Потеря точности может возникать, когда pseudo-sharding выполняет запрос в нескольких потоках или когда RT-таблица проводит параллельные поиски в дисковых чанках.

Если количество уникальных значений атрибута groupby меньше порога, max_matches будет установлено в это число. В противном случае будет использоваться значение max_matches по умолчанию.

Если max_matches было явно задано в опциях запроса, этот порог не действует.

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

Вы также можете включить режим гарантированной точности groupby/aggregate с помощью опции accurate_aggregation.

Устанавливает максимальное время выполнения поискового запроса в миллисекундах. Должно быть неотрицательным целым числом. Значение по умолчанию — 0, что означает «не ограничивать». Локальные поисковые запросы будут остановлены после истечения указанного времени. Обратите внимание, что если вы выполняете поиск, который обращается к нескольким локальным таблицам, это ограничение применяется к каждой таблице отдельно. Имейте в виду, что это может немного увеличить время отклика запроса из-за накладных расходов, связанных с постоянным отслеживанием времени остановки запроса.

Целое число. Максимальное предсказанное время поиска; см. predicted_time_costs.

none позволяет заменять все термины запроса их точными формами, если таблица была построена с включённым index_exact_words. Это полезно для предотвращения стемминга или лемматизации терминов запроса.

MySQL [(none)]> select * from tbl where match('-donald');
ERROR 1064 (42000): index t: query error: query is non-computable (single NOT operator)
MySQL [(none)]> select * from t where match('-donald') option not_terms_only_allowed=1;
+---------------------+-----------+
| id                  | field     |
+---------------------+-----------+
| 1658178727135150081 | smth else |
+---------------------+-----------+

Выберите из следующих вариантов:

• proximity_bm25
• bm25
• none
• wordcount
• proximity
• matchany
• fieldmask
• sph04
• expr
• export

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

Позволяет указать конкретное целочисленное значение зерна для запроса ORDER BY RAND(), например: ... OPTION rand_seed=1234. По умолчанию для каждого запроса автоматически генерируется новое и уникальное значение зерна.

Целое число. Количество повторных попыток в распределённом режиме.

Целое число. Задержка между повторными попытками в распределённом режиме, в миллисекундах.

Строка. Токен прокрутки для постраничного вывода результатов с использованием подхода Scroll pagination.

• pq — очередь с приоритетом, установлена по умолчанию
• kbuffer — обеспечивает более быструю сортировку для уже предварительно отсортированных данных, например, данных таблицы, отсортированных по id Набор результатов одинаков в обоих случаях; выбор одного из вариантов может просто улучшить (или ухудшить) производительность.

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

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

SELECT * FROM index WHERE MATCH ('yes@no') OPTION token_filter='mylib.so:blend:@'

Ограничивает максимальное количество расширенных ключевых слов для одного подстановочного знака, значение по умолчанию 0 означает отсутствие ограничения. Для дополнительной информации смотрите expansion_limit.

SELECT * FROM students where age > 21 /*+ SecondaryIndex(age) */

mysql -P9306 -h0 --comments