# Manticore Search 3.0.0 is now available

Мы рады объявить о выпуске Manticore Search 3.0.0, нашего долгожданного первого крупного релиза. Это первая версия Manticore, нарушающая совместимость индексов со старыми версиями.

Загрузки доступны [здесь](https://manticoresearch.com/downloads/) и на [странице Manticore Github](https://github.com/manticoresoftware/manticoresearch/releases/tag/3.0.0). Docker‑образ доступен в [Docker Hub](https://hub.docker.com/r/manticoresearch/manticore).

### Ключевые изменения


Одной из крупных проблем Manticore Search 2 было ограничение в 4 ГБ строк/JSON‑атрибутов на индекс. Чтобы обойти это ограничение, данные приходилось шардинговать по нескольким индексам. Версия 3 переосмысливает хранение индексов, снимая это ограничение и позволяя уменьшить количество шардов (или просто использовать один индекс), а также полностью оптимизировать RealTime‑индекс до одного чанка в случаях, затронутых ограничением.

Совместимость индексов нарушена, поскольку новое хранилище индексов имеет другую структуру. Существующие индексы, созданные в Manticore 2, не могут быть загружены в Manticore 3, но их можно легко обновить с помощью [инструмента конвертации](https://docs.manticoresearch.com/latest/html/command_line_tools_reference/index_converter_command_reference.html).

Также нет ограничений на динамическое обновление атрибутов (с использованием [UPDATE](https://docs.manticoresearch.com/latest/html/sphinxql_reference/update_syntax.html)). Ранее строковые атрибуты можно было обновлять только командой REPLACE, а для JSON‑атрибутов можно было обновлять только скалярные значения ключей.

Списки kill‑list для обычных индексов теперь применяются при загрузке/ротации индекса, а не при каждом запросе. Индекс, содержащий kill‑list, должен определить [список индексов](https://docs.manticoresearch.com/latest/html/conf_options_reference/index_configuration_options.html#killlist-target), для которых kill‑list будет применяться при загрузке/ротации. Это устраняет необходимость задавать определённый порядок поиска по индексам, как раньше. Если вы ротируете несколько индексов одновременно, Manticore Search выполнит умную ротацию: сначала будут ротированы индексы, не попадающие в kill‑list, а в конце — индексы, отмеченные в kill‑list.

Идентификаторы документов теперь являются положительными знаковыми 64‑битными целыми числами, ранее они были беззнаковыми 64‑битными целыми.
  
  
### Другие улучшения


Добавлена функция [CONCAT()](https://docs.manticoresearch.com/latest/html/searching/expressions,_functions,_and_operators.html#expr-func-concat) — позволяет объединять две и более строк. Если нужно объединять нестроковые аргументы, можно дополнительно использовать TO_STRING().

Репликация получила несколько улучшений:

 - [node_address](https://docs.manticoresearch.com/latest/html/conf_options_reference/searchd_program_configuration_options.html#node-address) директива — позволяет указать сетевой адрес узла

 - [JOIN CLUSTER](https://docs.manticoresearch.com/latest/html/replication.html#join-cluster) обеспечивает более простой синтаксис, позволяя указать только адрес и порт одного из узлов кластера с помощью конструкции 'AT'

 - [ALTER CLUSTER](https://docs.manticoresearch.com/latest/html/replication.html#nodes-management) обновление узлов кластера — для обновления списка узлов в кластере

 - список узлов выводится в SHOW STATUS



  
  
### Заметки о производительности


Запросы AND обычно работают быстрее в v3. Ускорение зависит от частоты ключевых слов. Тесты, включающие топ‑1000 из коллекции, показали небольшие приросты в случае множества часто встречающихся ключевых слов (~10 %) и более 60 % когда некоторые ключевые слова находились в конце топ‑1000. Реже встречающиеся ключевые слова должны давать ещё больший прирост.

Поиск с подстановками несколько процентов быстрее в v3. Поиск OR в некоторых случаях может быть несколько процентов медленнее (не более 9 % в проведённых тестах); эта проблема будет решена в будущих релизах. RT‑индексы с большим количеством дисковых чанков теперь работают значительно быстрее.

Благодаря ранним тестировщикам v3 уже работает в продакшене тысячи часов. Ниже представлены несколько наблюдаемых улучшений:

v3 лучше в плане фрагментации ОЗУ:

![img](./manticore-search-3-0-0-is-now-available/ram_fragmentation_v2_3-1200x222.png)

Некоторые пользователи, уже тестирующие v3 в продакшене, сообщают о лучшей средней производительности по сравнению с 2.8:

![img](./manticore-search-3-0-0-is-now-available/query_times_v2_3-1200x569.png)
  
  
### Что нужно знать перед обновлением?


Вам потребуется переиндексировать все индексы или использовать [инструмент конвертации](https://docs.manticoresearch.com/latest/html/command_line_tools_reference/index_converter_command_reference.html#index-converter-command-reference).

Если вы используете kill‑list, в объявлении индексов требуются [изменения](https://docs.manticoresearch.com/latest/html/getting-started/migrate_from_manticore2.html#kill-list). RT‑индексы не должны содержать данных в RAM‑чанке (выполните FLUSH RAMCHUNK) во время конвертации.

Для распределённых конфигураций миграция может начинаться с дата‑узлов (агентов) к мастер‑узлам, так как **мастер‑узел, работающий на v2, может взаимодействовать с агентами, работающими на v3**.

Ничего не изменилось в синтаксисе поисковых запросов! Все протоколы подключения не требуют обновлений или изменений для работы с Manticore 3. Как только индексы загружены, существующие клиенты могут просто подключиться к новой версии.

Полный перечень изменений и шагов миграции можно найти в [руководстве по миграции](https://docs.manticoresearch.com/latest/html/getting-started/migrate_from_manticore2.html).

Хотя Manticore 3 был тщательно протестирован в продакшене несколькими ранними пользователями, могут оставаться некоторые проблемы. Мы будем благодарны, если вы сообщите о любой проблеме в [трекер GitHub](https://github.com/manticoresoftware/manticoresearch/issues).

Для полного списка изменений в версии 3.0.0 обратитесь к [заметке о выпуске](https://docs.manticoresearch.com/latest/html/releasenotes.html#version-3-0-0-6-may-2019).
  
  
### Будущие заметки


Что касается HTTP‑протокола, ожидайте следующие изменения в будущих релизах: эндпоинт **/search** будет устаревшим, а формат ответа **/sql** будет таким же, как у эндпоинта **/json**.