Выбор записей InfluxDB с непустыми тегами становится ужасно медленным

У меня Influx v1.3. У меня есть измерение с ~ 2+ миллионами записей в течение 1 месяца и 10 тегами внутри. Из них меня интересуют user_id и article_id.

Я пытаюсь извлечь количество событий, зарегистрированных для определенного user_id с непустым article_id.

Запрос на выбор всех пользовательских событий невероятно быстр:

select count(*) from pageviews where user_id = '92363';

Запрос конкретного события для пользователя и статьи невероятно быстр:

select * from pageviews where user_id = '92363' and article_id = '879729';

Но когда я пытаюсь добавить фильтр для непустого (или пустого) article_id, запрос выполняется в течение десятков секунд.

select count(*) from pageviews where user_id = '92363' and article_id != '';
select count(*) from pageviews where user_id = '92363' and article_id !~ /.*/;

Что-то я делаю неправильно или что-то, что я должен настроить в базе данных? Это не кажется правильным. Количество пользовательских событий - ‹100, вручную я их буквально быстрее проходил.

В настоящее время я использую конфигурацию по умолчанию.

Спасибо.


influxdb
person rootpd    schedule 28.09.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

С запросами, использующими != или =~, БД должна сравниваться с каждой записью для этого тега. Если у вас 2M записей, это будет медленно. При использовании регулярных выражений (=~) еще медленнее.

Короче говоря, нет, вы не делаете ничего плохого. Этих типов запросов O(n) в influxdb, где n — количество строк, с которыми вы сравниваете.

Я бы предложил переосмыслить вашу схему, чтобы избежать таких запросов. Например, вы можете установить целочисленный тег has_article, который будет либо 0, либо 1, указывающим на наличие статьи. Затем запрос может использовать has_article = 1.

Опять же, подходит ли набор данных и модель данных для influxdb, это другой вопрос - набор данных, похоже, не является данными временных рядов.

InfluxDB — это специализированная БД временных рядов, а не хранилище данных общего назначения.

person danny    schedule 28.09.2017
comment
Большое спасибо за утверждение. Я ожидаю, что он оптимизирует запрос и проверит тег по отфильтрованным ~ 100 событиям, но, вероятно, он работает иначе, чем база данных SQL. Однако логическое обходное решение кажется достаточным. Я также обнаружил, что 1.4 будет включать SHOW CARDINALITY, который можно использовать для тегов, поэтому я также рассмотрю этот вариант. Большое спасибо! - person rootpd; 28.09.2017