Pull to refresh
59
4.4
Sergey Nikolaev @ManticoreSearch

CEO

Send message

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 требуется сперва создать таблицу. Понятно, что это весьма неудобно для логов. Эта проблема уже решена, готовим к релизу.

Да. И Ё->Е из коробки поддерживается, а Й->И нет, т.к. ситуация тут совсем другая, чем с Ё.

Поэкспериментировать с дефолтными настройками можно так:

mysql> drop table if exists t; create table t(f text); call keywords('Ё ё Й й', 't');
Query OK, 0 rows affected (0.03 sec)

Query OK, 0 rows affected (0.04 sec)

+------+-----------+------------+
| qpos | tokenized | normalized |
+------+-----------+------------+
| 1    | е         | е          |
| 2    | е         | е          |
| 3    | й         | й          |
| 4    | й         | й          |
+------+-----------+------------+
4 rows in set (0.00 sec)

Ваш пример непонятен:

  • filter1/2 - что это? "filter" или это такие имена агрегаций просто

  • "terms" в трёх местах на трёх уровнях - что это?

То ли вы имеете в виду multi_terms, то ли что-то ещё. Не хочу гадать. Если вы приведёте конкретный пример в синтаксисе Эластика, то я постараюсь сконвертировать его в SQL и буду рад, если это не удастся сделать. Значит будет повод задуматься о расширении синтаксиса.

А можно конкретный пример что можно через JSON и нельзя через SQL?

Что вы подразумеваете под неподдержкой schemaless в Manticore?

Подразумеваю автодетект типов полей на основании первого документа (и возможную корректировку через какое-то время, есть такая идея)

Получается, в Manticore нельзя добавить поле realtime или всего лишь нет автодобавления нового поля?

Поле добавить можно. Автодетекта типа нет.

Вся красота JSON — в аналитике, позволяющая строить многоэтажные агрегации, которые ко всему прочему легко машиночитаемы

Согласен, поэтому для поиска в Мантикоре JSON нормальный. Nested boolean query вот добавили в последней версии https://manual.manticoresearch.com/Searching/Filters#Nested-bool-query
А для управления нодой пока что SQL через mysql и через HTTP (/sql?mode=raw)

Information

Rating
942-nd
Registered
Activity