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

• qcache_max_bytes — ограничение на использование ОЗУ для хранения кэшированных запросов. По умолчанию 16 МБ. Установка qcache_max_bytes в 0 полностью отключает кэш запросов.
• qcache_thresh_msec — минимальное время выполнения запроса (в миллисекундах) для кэширования. Запросы, которые выполняются быстрее этого времени, не будут кэшироваться. По умолчанию 3000 мс, или 3 секунды.
• qcache_ttl_sec — время жизни кэшированной записи. Запросы будут храниться в кэше в течение этого времени. По умолчанию 60 секунд, или 1 минута.

Эти настройки можно изменять на лету с помощью оператора SET GLOBAL:

mysql> SET GLOBAL qcache_max_bytes=128000000;

Эти изменения применяются немедленно, и кэшированные наборы результатов, которые больше не соответствуют ограничениям, сразу же удаляются. При уменьшении размера кэша на лету выигрывают наиболее недавно использованные (MRU) наборы результатов.

Кэш запросов работает следующим образом. Когда он включен, каждый результат полнотекстового поиска полностью сохраняется в памяти. Это происходит после полнотекстового сопоставления, фильтрации и ранжирования, то есть по сути мы сохраняем пары {docid,weight} для total_found. Сжатые совпадения могут занимать в среднем от 2 до 12 байт на совпадение, в основном в зависимости от дельт между последовательными docid. После завершения запроса мы проверяем пороги времени выполнения и размера, и либо сохраняем сжатый набор результатов для повторного использования, либо отбрасываем его.

Обратите внимание, что влияние кэша запросов на ОЗУ не ограничивается qcache_max_bytes! Если, например, выполняется 10 параллельных запросов, каждый из которых совпадает с до 1 млн совпадений (после фильтров), то пиковое временное использование ОЗУ будет в диапазоне от 40 МБ до 240 МБ, даже если запросы достаточно быстрые и не кэшируются.

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

• Полнотекстовая часть внутри MATCH() должна совпадать посимвольно. Добавьте один дополнительный пробел — и для кэша запросов это уже другой запрос.
• Ранжировщик (и его параметры, если есть, для пользовательских ранжировщиков) должен совпадать посимвольно.
• Фильтры должны быть надмножеством исходных фильтров. Вы можете добавить дополнительные фильтры и всё равно попасть в кэш. (В этом случае дополнительные фильтры будут применены к кэшированному результату.) Но если вы уберёте какой-то фильтр, это будет уже новый запрос.

Записи кэша истекают по TTL и также инвалидируются при ротации таблицы, или при выполнении TRUNCATE, или ATTACH. Обратите внимание, что в настоящее время записи не инвалидируются при произвольных записях в RT-таблицы! Поэтому кэшированный запрос может возвращать устаревшие результаты в течение времени жизни TTL.

Вы можете просмотреть текущий статус кэша с помощью SHOW STATUS через переменные qcache_XXX:

mysql> SHOW STATUS LIKE 'qcache%';
+-----------------------+----------+
| Counter               | Value    |
+-----------------------+----------+
| qcache_max_bytes      | 16777216 |
| qcache_thresh_msec    | 3000     |
| qcache_ttl_sec        | 60       |
| qcache_cached_queries | 0        |
| qcache_used_bytes     | 0        |
| qcache_hits           | 0        |
+-----------------------+----------+
6 rows in set (0.00 sec)

Сопоставления в первую очередь влияют на сравнения строковых атрибутов. Они определяют как кодировку набора символов, так и стратегию, которую Manticore использует для сравнения строк при выполнении ORDER BY или GROUP BY с участием строкового атрибута.

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

Во-первых, строки с однобайтовой кодировкой (ASCII, ISO-8859-1 или Windows-1251) нужно обрабатывать иначе, чем строки в UTF-8, которые могут кодировать каждый символ переменным числом байт. Следовательно, нам нужно знать тип набора символов, чтобы правильно интерпретировать сырые байты как значимые символы.

Во-вторых, нам также нужны правила сортировки, специфичные для языка. Например, при сортировке по правилам США в локали en_US, акцентированный символ ï (маленькая буква i с умлаутом) должен располагаться где-то после z. Однако при сортировке по французским правилам и локали fr_FR он должен располагаться между i и j. Другой набор правил может вообще игнорировать акценты, позволяя произвольно смешивать ï и i.

В-третьих, в некоторых случаях требуется сортировка с учётом регистра, а в других — без учёта регистра.

Сопоставления инкапсулируют всё следующее: набор символов, языковые правила и чувствительность к регистру. В настоящее время Manticore предоставляет четыре сопоставления:

1. libc_ci
2. libc_cs
3. utf8_general_ci
4. binary

Первые два сопоставления опираются на несколько стандартных вызовов библиотеки C (libc) и, следовательно, могут поддерживать любую локаль, установленную в вашей системе. Они обеспечивают сравнения без учёта регистра (_ci) и с учётом регистра (_cs) соответственно. По умолчанию они используют локаль C, фактически сводя сравнения к побайтовым. Чтобы изменить это, нужно указать другую доступную локаль с помощью директивы collation_libc_locale. Список локалей, доступных в вашей системе, обычно можно получить с помощью команды locale:

$ locale -a
C
en_AG
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NG
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
es_ES
fr_FR
POSIX
ru_RU.utf8
ru_UA.utf8

Конкретный список локалей системы может отличаться. Обратитесь к документации вашей ОС для установки дополнительных необходимых локалей.

Локали utf8_general_ci и binary встроены в Manticore. Первая — это универсальное сопоставление для данных UTF-8 (без так называемой языковой адаптации); оно должно вести себя аналогично сопоставлению utf8_general_ci в MySQL. Вторая — простое побайтовое сравнение.

Сопоставление можно переопределить через SQL на уровне сессии с помощью оператора SET collation_connection. Все последующие SQL-запросы будут использовать это сопоставление. В противном случае все запросы будут использовать сопоставление по умолчанию сервера или указанное в директиве конфигурации collation_server. В настоящее время Manticore по умолчанию использует сопоставление libc_ci.

Сопоставления влияют на все сравнения строковых атрибутов, включая те, что внутри ORDER BY и GROUP BY, поэтому в зависимости от выбранного сопоставления могут возвращаться результаты с разным порядком или группировкой. Обратите внимание, что сопоставления не влияют на полнотекстовый поиск; для этого используйте charset_table.

Когда Manticore выполняет запрос полного сканирования, он может либо использовать простой скан для проверки каждого документа по фильтрам, либо применять дополнительные данные и/или алгоритмы для ускорения выполнения запроса. Manticore использует оптимизатор на основе стоимости (CBO), также известный как «оптимизатор запросов», чтобы определить, какой подход выбрать.

CBO также может улучшить производительность полнотекстовых запросов. Подробнее см. ниже.

CBO может решить заменить один или несколько фильтров запроса одним из следующих элементов, если он определит, что это улучшит производительность:

1. docid индекс использует специальный вторичный индекс только по docid, хранящийся в файлах с расширением .spt. Помимо улучшения фильтров по идентификаторам документов, docid индекс также используется для ускорения поиска соответствия docid к rowid и для ускорения применения больших списков исключений (killlists) при запуске демона.
2. Колоннарное сканирование опирается на колоннарное хранение и может использоваться только для колоннарного атрибута. Оно сканирует каждое значение и проверяет его по фильтру, но при этом сильно оптимизировано и обычно быстрее стандартного подхода.
3. Вторичные индексы создаются по умолчанию для всех атрибутов (кроме JSON). Они используют PGM индекс вместе с встроенным инвертированным индексом Manticore для получения списка rowid, соответствующих значению или диапазону значений. Вторичные индексы хранятся в файлах с расширениями .spidx и .spjidx. Для информации о том, как создавать вторичные индексы по JSON-атрибутам, см. json_secondary_indexes.

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

1. Информацию о распределении данных внутри атрибута (гистограммы, хранящиеся в файлах .sphi). Гистограммы генерируются автоматически при индексировании данных и служат основным источником информации для CBO.
2. Информацию из PGM (вторичные индексы), которая помогает оценить количество списков документов для чтения. Это помогает оценить производительность слияния doclist и выбрать подходящий алгоритм слияния (слияние с приоритетной очередью или слияние битмапов).
3. Статистику колоннарного кодирования, используемую для оценки производительности декомпрессии колоннарных данных.
4. Колоннарное дерево min-max. В то время как CBO использует гистограммы для оценки количества документов, оставшихся после применения фильтра, ему также нужно определить, сколько документов фильтр должен был обработать. Для колоннарных атрибутов частичная оценка дерева min-max служит этой цели.
5. Полнотекстовый словарь. CBO использует статистику терминов для оценки стоимости вычисления полнотекстового дерева.

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

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

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

При работе с полнотекстовыми запросами, которые имеют фильтры по атрибутам, оптимизатор запроса выбирает между двумя возможными путями выполнения. Один — выполнить полнотекстовый запрос, получить совпадения и применить фильтры. Другой — заменить фильтры одним или несколькими описанными выше элементами, получить rowid из них и внедрить их в полнотекстовое дерево поиска. Таким образом, результаты полнотекстового поиска пересекутся с результатами полного сканирования. Оптимизатор запроса оценивает стоимость вычисления полнотекстового дерева и лучший возможный путь для вычисления результатов фильтра. Используя эту информацию, оптимизатор выбирает путь выполнения.

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

Запросы с использованием вторичных индексов и docid индексов всегда выполняются в одном потоке, так как бенчмарки показывают, что многопоточное выполнение для них малоэффективно.

В настоящее время оптимизатор учитывает только затраты CPU и не принимает во внимание использование памяти или диска.

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

Эмбеддинг — это метод представления данных — таких как текст, изображения или звук — в виде векторов в пространстве высокой размерности. Эти векторы создаются так, чтобы расстояние между ними отражало схожесть представляемых данных. Этот процесс обычно использует алгоритмы, такие как векторные представления слов (например, Word2Vec, BERT) для текста или нейронные сети для изображений. Высокая размерность векторного пространства, с большим количеством компонентов на вектор, позволяет представлять сложные и тонкие взаимосвязи между объектами. Их схожесть оценивается по расстоянию между этими векторами, часто измеряемому с помощью методов, таких как евклидово расстояние или косинусное сходство.

Manticore Search позволяет выполнять поиск k-ближайших соседей (KNN) векторов с использованием библиотеки HNSW. Эта функциональность является частью Manticore Columnar Library.

create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' );

table test_vec {
    type = rt
    ...
    rt_attr_float_vector = image_vector
    knn = {"attrs":[{"name":"image_vector","type":"hnsw","dims":4,"hnsw_similarity":"L2","hnsw_m":16,"hnsw_ef_construction":200}]}
}

Query OK, 0 rows affected (0.01 sec)

CREATE TABLE products (
    title TEXT, 
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2' 
    MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='title'
);

CREATE TABLE products_openai (
    title TEXT,
    description TEXT, 
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='openai/text-embedding-ada-002' FROM='title,description' API_KEY='...'
);

CREATE TABLE products_all (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM=''
);

INSERT INTO products (title) VALUES 
('machine learning artificial intelligence'),
('banana fruit sweet yellow');

INSERT INTO products_openai (title, description) VALUES
('smartphone', 'latest mobile device with advanced features'),
('laptop', 'portable computer for work and gaming');

INSERT INTO products (title, embedding_vector) VALUES 
('no embedding item', ());

SELECT id, knn_dist() FROM products WHERE knn(embedding_vector, 3, 'machine learning');

POST /search
{
    "table": "products",
    "knn": {
        "field": "embedding_vector",
        "query": "machine learning",
        "k": 3
    }
}

POST /search
{
    "table": "products",
    "knn": {
        "field": "embedding_vector",
        "query": [0.1, 0.2, 0.3, 0.4],
        "k": 3
    }
}

+------+------------+
| id   | knn_dist() |
+------+------------+
|    1 | 0.12345678 |
|    2 | 0.87654321 |
+------+------------+
2 rows in set (0.00 sec)

{
    "took": 0,
    "timed_out": false,
    "hits": {
        "total": 2,
        "total_relation": "eq",
        "hits": [
            {
                "_id": 1,
                "_score": 1,
                "_knn_dist": 0.12345678,
                "_source": {
                    "title": "machine learning artificial intelligence"
                }
            },
            {
                "_id": 2,
                "_score": 1,
                "_knn_dist": 0.87654321,
                "_source": {
                    "title": "banana fruit sweet yellow"
                }
            }
        ]
    }
}

insert into test values ( 1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821) ), ( 2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406) );

POST /insert
{
    "table":"test_vec",
    "id":1,
    "doc":  { "title" : "yellow bag", "image_vector" : [0.653448,0.192478,0.017971,0.339821] }
}
POST /insert
{
    "table":"test_vec",
    "id":2,
    "doc":  { "title" : "white bag", "image_vector" : [-0.148894,0.748278,0.091892,-0.095406] }
}

Query OK, 2 rows affected (0.00 sec)

{
    "table":"test",
    "_id":1,
    "created":true,
    "result":"created",
    "status":201
}
{
    "table":"test",
    "_id":2,
    "created":true,
    "result":"created",
    "status":201
}

select id, knn_dist() from test where knn ( image_vector, 5, (0.286569,-0.031816,0.066684,0.032926), { ef=2000, oversampling=3.0, rescore=1 } );

POST /search
{
    "table": "test",
    "knn":
    {
        "field": "image_vector",
        "query": [0.286569,-0.031816,0.066684,0.032926],
        "k": 5,
        "ef": 2000, 
        "rescore": true,
        "oversampling": 3.0
    }
}

+------+------------+
| id   | knn_dist() |
+------+------------+
|    1 | 0.28146550 |
|    2 | 0.81527930 |
+------+------------+
2 rows in set (0.00 sec)

{
    "took":0,
    "timed_out":false,
    "hits":
    {
        "total":2,
        "total_relation":"eq",
        "hits":
        [
            {
                "_id": 1,
                "_score":1,
                "_knn_dist":0.28146550,
                "_source":
                {
                    "title":"yellow bag",
                    "image_vector":[0.653448,0.192478,0.017971,0.339821]
                }
            },
            {
                "_id": 2,
                "_score":1,
                "_knn_dist":0.81527930,
                "_source":
                {
                    "title":"white bag",
                    "image_vector":[-0.148894,0.748278,0.091892,-0.095406]
                }
            }
        ]
    }
}

create table test ( title text, image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2' quantization='1bit');

Query OK, 0 rows affected (0.01 sec)

select id, knn_dist() from test where knn ( image_vector, 5, 1 );

POST /search
{
  "table": "test",
  "knn":
  {
    "field": "image_vector",
    "doc_id": 1,
    "k": 5
  }
}

+------+------------+
| id   | knn_dist() |
+------+------------+
|    2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec)

{
    "took":0,
    "timed_out":false,
    "hits":
    {
        "total":1,
        "total_relation":"eq",
        "hits":
        [
            {
                "_id": 2,
                "_score":1643,
                "_knn_dist":0.81527930,
                "_source":
                {
                    "title":"white bag",
                    "image_vector":[-0.148894,0.748278,0.091892,-0.095406]
                }
            }
        ]
    }
}

select id, knn_dist() from test where knn ( image_vector, 5, (0.286569,-0.031816,0.066684,0.032926) ) and match('white') and id < 10;

POST /search
{
    "table": "test",
    "knn":
    {
        "field": "image_vector",
        "query": [0.286569,-0.031816,0.066684,0.032926],
        "k": 5,
        "filter":
        {
            "bool":
            {
                "must":
                [
                    { "match": {"_all":"white"} },
                    { "range": { "id": { "lt": 10 } } }
                ]
            }
        }
    }
}

+------+------------+
| id   | knn_dist() |
+------+------------+
|    2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec)

{
    "took":0,
    "timed_out":false,
    "hits":
    {
        "total":1,
        "total_relation":"eq",
        "hits":
        [
            {
                "_id": 2,
                "_score":1643,
                "_knn_dist":0.81527930,
                "_source":
                {
                    "title":"white bag",
                    "image_vector":[-0.148894,0.748278,0.091892,-0.095406]
                }
            }
        ]
    }
}