CALL AUTOCOMPLETE и select ... option fuzzy=1 - новые команда и опция. Их отличия от CALL SUGGEST/KEYWORDS и описаны в статье. Вкратце: использовать CALL SUGGEST/KEYWORDS сложно, а новые фичи - легко.
Да. С нашей с вами точки зрения неправильно. С чьей-то (кто считает, что если фильтр неприменим к чему-то, то он должен просто игнорироваться, а усложнять UI не стоит) правильно. В любом случае это open source проект: если кто-то сделает PR до того, как мы сделаем то, что задумали, то мы с радостью его примем. Спасибо, что подсветили эту проблему.
Мы решили, что нужно распространять фильтр Open / Closed на комментарии тоже. У самих комментариев такого статуса нет, но у родительских объектов он есть, вот его и будем использовать. Делать будем через новую фичу в мантикоре - JOIN. Это будет отличной демонстрацией этой функциональности.
Потому что тут вы не фильтруете по pull requests (search in "Everywhere") и то, что выделено - это комментарий, а не pull request. Текст pull request'а для этого комментария приведён просто для справки. Но раз это интуитивно непонятно, то видимо нужно доработать UI.
Grafana: всё ещё в планах. Сделали Manticore Buddy, через который задача решится проще. С mysqldump, например, всё получается. Логи в Мантикору можно загружать из logstash или напрямую из beats, т.е. Мантикора умеет прикидываться Эластиком в плане запросов на запись данных. Но в Manticore 6 требуется сперва создать таблицу. Понятно, что это весьма неудобно для логов. Эта проблема уже решена, готовим к релизу.
filter1/2 - что это? "filter" или это такие имена агрегаций просто
"terms" в трёх местах на трёх уровнях - что это?
То ли вы имеете в виду multi_terms, то ли что-то ещё. Не хочу гадать. Если вы приведёте конкретный пример в синтаксисе Эластика, то я постараюсь сконвертировать его в SQL и буду рад, если это не удастся сделать. Значит будет повод задуматься о расширении синтаксиса.
CALL AUTOCOMPLETE и select ... option fuzzy=1 - новые команда и опция. Их отличия от CALL SUGGEST/KEYWORDS и описаны в статье. Вкратце: использовать CALL SUGGEST/KEYWORDS сложно, а новые фичи - легко.
Да. С нашей с вами точки зрения неправильно. С чьей-то (кто считает, что если фильтр неприменим к чему-то, то он должен просто игнорироваться, а усложнять UI не стоит) правильно. В любом случае это open source проект: если кто-то сделает PR до того, как мы сделаем то, что задумали, то мы с радостью его примем. Спасибо, что подсветили эту проблему.
Мы решили, что нужно распространять фильтр Open / Closed на комментарии тоже. У самих комментариев такого статуса нет, но у родительских объектов он есть, вот его и будем использовать. Делать будем через новую фичу в мантикоре - JOIN. Это будет отличной демонстрацией этой функциональности.
Потому что тут вы не фильтруете по pull requests (search in "Everywhere") и то, что выделено - это комментарий, а не pull request. Текст pull request'а для этого комментария приведён просто для справки. Но раз это интуитивно непонятно, то видимо нужно доработать UI.
Поправили в интро. Спасибо.
Пофиксили.
Пофиксили
Да, вижу, обсужу с разработчиками. Спасибо.
Только что попробовал ввести https://github.com/manticoresoftware/manticoresearch-go - всё сработало. Вот так делал:
Что вводите?
Благодарим за бдительность, сучок спилили)
Спасибо за статью!
Зарелизили 6.0.4 - https://manual.manticoresearch.com/Changelog
Темпоральных таблиц в планах нет :( Никогда об этом даже не думали.
Grafana: всё ещё в планах. Сделали Manticore Buddy, через который задача решится проще. С mysqldump, например, всё получается.
Логи в Мантикору можно загружать из logstash или напрямую из beats, т.е. Мантикора умеет прикидываться Эластиком в плане запросов на запись данных. Но в Manticore 6 требуется сперва создать таблицу. Понятно, что это весьма неудобно для логов. Эта проблема уже решена, готовим к релизу.
Да. И Ё->Е из коробки поддерживается, а Й->И нет, т.к. ситуация тут совсем другая, чем с Ё.
Поэкспериментировать с дефолтными настройками можно так:
Ваш пример непонятен:
filter1/2 - что это? "filter" или это такие имена агрегаций просто
"terms" в трёх местах на трёх уровнях - что это?
То ли вы имеете в виду multi_terms, то ли что-то ещё. Не хочу гадать. Если вы приведёте конкретный пример в синтаксисе Эластика, то я постараюсь сконвертировать его в SQL и буду рад, если это не удастся сделать. Значит будет повод задуматься о расширении синтаксиса.
А можно конкретный пример что можно через JSON и нельзя через SQL?
Подразумеваю автодетект типов полей на основании первого документа (и возможную корректировку через какое-то время, есть такая идея)
Поле добавить можно. Автодетекта типа нет.
Согласен, поэтому для поиска в Мантикоре JSON нормальный. Nested boolean query вот добавили в последней версии https://manual.manticoresearch.com/Searching/Filters#Nested-bool-query
А для управления нодой пока что SQL через mysql и через HTTP (
/sql?mode=raw
)Вот статья на английском https://manticoresearch.com/blog/manticore-alternative-to-elasticsearch/