База данных временных рядов (TSDB).

Теория

Реляционные базы основаны на том что есть таблица, содержащая строки и столбцы. Таблицы обычно предназначены для определенных целей. Они эффективны, масштабируемые и т.д. Но ключевой аспект в том что они имеют индекс, который делает их медленными при росте данных.
При добавлении новых записей, при наличии индексов, СУБД будет многократно переиндексировать данные для быстрого доступа к ним ⇒ производительность со временем снижается.

БД временных рядов работают иначе, Данные так же хранятся в «коллекциях», но эти «коллекции» имеют общий знаменатель - они объединены со временем. Т.е. для каждой точки, которую вы можете сохранить, есть связанная с ней временная метка.

Сделан акцент на быстром приеме данных и скорость не теряется с увеличением размера БД. Используется индексация связанная со временем.

Присутствует встроенная т.н. политика хранения данных, которая позволяет очищать ненужные данные.

Поля представляют собой непосредственно данные таблицы, вокруг которых все происходит, а теги больше носят описательный характер

Теги хранятся только в виде строк, теги проиндексированы поля нет, поэтому для поиска/фильтрации/группировок используются только теги
Учитывая индексацию, слишком уникальные данные не подойдут для тегов, иначе сильно провиснет производительность

Measurement (измерение) контейнер тегов и полей и меткой времени, по сути можно провести параллель с таблицей
«Серии» это вроде как записи

Series (временная шкала данных) - это «линии данных», комбинация измерений и тегов. Важная метрика, считается на всю базу целиком, по умолчанию установлено ограничение в миллион max-series-per-database

Нагрузка (кардинальность) серий

Серия это комбинация измерений и тегов. Считается на одну базу данных рекомендуется не более 1 миллиона, регулируется переменной «max-series-per-database», как уже было сказано выше

Растет считай экспоненциально, например есть таблица с двумя тегами, в первом три разных значения, во втором два, кол-во комбинаций 3 * 2 = 6

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

  # Кардинальность текущей БД
SHOW SERIES CARDINALITY [ON dbname]
  # В разрезе по таблицам
SHOW SERIES EXACT CARDINALITY [ON dbname]
 
  # Еще можно проверить кардинальность ключей, но вроде тоже самое (или около того)
SHOW TAG KEY CARDINALITY
SHOW TAG VALUES CARDINALITY WITH KEY = "tag1"
SHOW FIELD KEY CARDINALITY [ON dbname]
 
  # Непонятно что показывает, не общую кардинальность таблиц не одной таблицы не кол-во таблиц, хз
  # хотя есть какая то корреляция с кол-вом таблиц
SHOW MEASUREMENT CARDINALITY [ON dbname]

Point - данные одной вставки (series + timestamp)
Shard - сегмент данных, относится к физическому хранению в ОС (TSM (Time Sort Merge Tree) Engine), рассчитывается из политики хранения, разбивается например по часу. Отвечает как за хранение данных в ОС так и за операциями над ними
Выше уровнем, разбиваются на группы

Хранение данных (политика хранения, retention policy) задается к базе, есть умолчательная, можно указывать при каждой вставке данных (видимо персонально)

Авторизация

  # Авторизация агрументами
influx -username "my_username" -password "my_password"
 
  # Из оболочки (отключаем историю bash чтобы пароль не сохранялся)
set +o history
influx -execute 'show databases;' -username 'admin' -password 'wswsws'
set -o history
 
  # Интерактивный режим
> influx
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell 1.8.10
> auth

Как такового создания таблиц нет, создается при записи в нее

  # Перечень баз
show databases
create database "test"
use test
 
  # Перечень таблиц
show measurements
 
  # Запись данных в таблицу (имя таблицы, два тега, поле, последнее - временная метка в ms, указывать не обязательно)
insert cpu_usage,host=server01,region=us-west value=0.64 1434055562000000000

Политика хранения

show retention policies;
 
  # Создание политики хранения
CREATE RETENTION POLICY ON <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration> ] [DEFAULT]
CREATE RETENTION POLICY "one_day_only" ON "water_database" DURATION 1d REPLICATION 1 SHARD DURATION 1h DEFAULT 
 
  # Чистка старых данных может длится несколько часов
ALTER RETENTION POLICY "autogen" ON <dbname> DURATION 75d;

  # Размер баз
sudo du -sh /var/lib/influxdb/data/
  # Еще вроде как такой вариант есть, но хз
influx_inspect report-disk -detailed /var/lib/influxdb/data/ 

Retention policies. При записи данных, можно указывать конкретную политику хранения, либо используется умолчательная.

SHOW retention policies;
 
  # Аргумент "Default" делает ее по умолчанию
CREATE RETENTION POLICY "one_day_only" ON "NOAA_water_database" DURATION 23h60m REPLICATION 1 DEFAULT;
 
 ALTER RETENTION POLICY "what_is_time" ON "NOAA_water_database" DURATION 3w SHARD DURATION 2h DEFAULT;

Схема хранения индексов «inmem»/«TSI», первая по умолчанию, в памяти, вторая с задействованием диска, для больших кардинальностей
Данные хранятся в «../data/», файлы «*.tsm» можно удалять, через время появляются снова

Содержимое

Для перехода нужно остановить инфлюкс, сгенерировать файлы индекса, изменить пар-р в конфиге, запустить инфлюкс. Форум

  # Команда для генерации tsi индексов
sudo -u influxdb influx_inspect buildtsi -datadir /var/lib/influxdb/data/ -waldir /var/lib/influxdb/wal/ -database dbname
 
  # Должно быть удаление файлов tsm, но не работает сцуко
sudo -u influxdb influx_inspect deletetsm -sanitize ./data/*/autogen/*/*.tsm

Cмысл схож с вложенными запросами, но промежуточные метрики сохраняются и хранятся в таблице, отдельным процессом, постоянно, а не получаются «на лету» как можно было бы сделать в реляционной базе.

SHOW CONTINUOUS QUERIES
 
CREATE CONTINUOUS QUERY <Имя объекта> ON <Имя БД> BEGIN <SQL запрос> END
 
DROP CONTINUOUS QUERY <cq_name> ON <database_name>

Примеры

CREATE CONTINUOUS QUERY <Имя объекта> ON mgaimport
BEGIN
    SELECT SUM(counter) AS CountExceptRecords INTO <Имя БД>.autogen.<Имя новой таблицы> FROM mgaimport.autogen.<Существующая БД> WHERE resolution = 'exception' GROUP BY TIME(1m), db_name, log_type
END
 
CREATE CONTINUOUS QUERY BalancerRequestAccount_agr ON metrics
BEGIN
    SELECT COUNT("value") AS CountRequests INTO metrics."15_day".BalancerRequestAccount_agr2 FROM metrics.autogen.BalancerRequestAccount GROUP BY TIME(5m)
END