InfluxDB — это база данных временных рядов с открытым исходным кодом, разработанная InfluxData. Он написан на Go и фокусируется на запросах и хранении данных временных рядов с высокой производительностью. InfluxDB широко используется для хранения данных системного мониторинга,
Это также база данных временных рядов с открытым исходным кодом без дополнительных зависимостей, используемая для записи показателей, событий и выполнения анализа данных. Что такое база данных временных рядов?
Что такое база данных временных рядов, самое простое определение состоит в том, что формат данных содержит данные в поле «Отметка времени», такие как температура окружающей среды в определенное время, коэффициент использования ЦП и т. д. Но какие данные не содержат Timestamp? Почти все данные могут быть помечены полем Timestamp. Более важным свойством данных временных рядов является то, как их запрашивать, включая фильтрацию данных, вычисления и т. д. Общие данные временных рядов имеют следующие две характеристики:
простая структура данных Большой объем данных Под так называемой простой структурой можно понимать то, что метрика будет иметь только одно значение в определенный момент времени, а сложной структуры (вложенности, иерархии и т. д.) и отношений (ассоциации, первичных и внешних ключей и т. д.) не существует. ).
Еще одной важной особенностью является большой объем данных, поскольку данные временных рядов генерируются, собираются и отправляются большим количеством отслеживаемых источников данных, таких как хосты, устройства IoT, терминалы или приложения.
1. Введение в InfluxDB
Основные возможности InfluxDB 1. На основе временных рядов поддерживать функции корреляции, связанные со временем (такие как максимум, минимум, суммирование и т. д.)
2. Измеримость: вы можете выполнять расчеты с большими объемами данных в режиме реального времени.
3. На основе событий: поддерживает произвольные данные о событиях.
Ключевые особенности InfluxDB 1. Без структуры (без схемы): может быть любое количество столбцов
2. Масштабируемость
3. Поддержка ряда функций, таких как минимум, максимум, сумма, количество, среднее, медиана и т. д., для облегчения статистики.
4. Встроенная поддержка HTTP, встроенный HTTP API
5. Мощный SQL-подобный синтаксис
6. Автономный интерфейс управления, простой в использовании
Документы официального сайта:docs.influx data.com/influx дБ/V1…
2. Установка InfluxDB
В этой статье в качестве примера используется операционная система RedHat и CentOS, чтобы представить установку последней версии InfluxDB. Пользователи RedHat и CentOS могут установить последнюю версию InfluxDB напрямую с помощью диспетчера пакетов yum.
cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
После добавления в исходный код yum вы можете запустить следующие команды для установки и запуска службы InfluxDB:
sudo yum install influxdb
Последняя версия 1.7.3-1
3. Запуск InfluxDB
1. Запуск сервера Если он установлен через пакет, его можно запустить с помощью следующего оператора:
запуск службы sudo influxdb Это запускает сервер
2. Клиент Используйте influx в usr/bin для входа на сервер Influx. Вы также можете добавить путь к переменной среды, чтобы использовать приток где угодно.
команда для запуска клиента, как показано ниже:
Более ранние версии InfluxDB поставлялись с веб-интерфейсом управления, введите в браузереhttp://IP-адрес сервера:8083Вы можете войти на страницу веб-управления.
Однако, начиная с версии 1.3, интерфейс веб-администрирования больше недоступен в InfluxDB. Официальное использование Chronograf для запроса данных, записи данных и улучшения инструментов для управления базами данных заменяет веб-интерфейс управления.
Позже мы подробно познакомим вас с Chronograf.
4. Операции, связанные с InfluxDB
1. Включите аутентификацию
Создать администратора
Измените файл конфигурации, чтобы включить аутентификацию
Перезапустите InfluxDB:
systemctl restart influxdb
войти снова
Клиентский инструмент подключается к базе данных:
Примечание. Параметр -precision здесь указывает, что формат временной метки — rfc3339, или этот параметр можно опустить.
2. Родственные понятия Термины, связанные с influxDB
база данных: база данных.
измерение: Таблица в базе данных. Это контейнер тега, поля и времени, для измерения influxDB поле обязательно и не может быть отсортировано по полю;
Тег является необязательным, тег можно использовать для индексации, тег хранится в виде строки.
точки: ряд данных в таблице.
Концепции, уникальные для influxDB
(1) Точка состоит из метки времени (времени), данных (поля) и метки (тегов).
время: время каждой записи данных, которое также является основным индексом, автоматически генерируемым базой данных;
поля: значения различных записей;
теги: различные проиндексированные свойства.
InfluxDB не требует определения схемы, что означает, что вы можете добавлять измерения, теги и поля в любое время.
(2) серия
Все данные в базе данных нужно отображать через диаграммы, и этот ряд представляет данные в этой таблице, которые можно нарисовать в виде нескольких линий на диаграмме: рассчитанных по расположению и сочетанию тегов.
По сути, серия — это точка измерения или кривая, тогда политика хранения, измерение и набор тегов вместе образуют уникальный идентификатор последовательности точек измерения позиционирования.
Точка, которая является значением нескольких полей в одно и то же время ряда, составляет точку, фактически это точка на кривой.
Сравнение существительных в influxDB и традиционных базах данных
(3) политика хранения
Политика хранения, которая используется для определения того, как долго хранить данные, сколько резервных копий хранить, а также политики кластера и т. д.
3. Связанные операции
Посмотреть базу данных:
Создайте базу данных:
Вставить данные:
InfluxDB хранит данные в формате Line Protocol.
Формат Line Protocol: Фиксированный формат Point, записываемый в базу данных. Формат следующий:
<measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [unix-nano-timestamp]
Например:
> INSERT cpu,host=serverA,region=us_west value=0.64
в:
cpu - это имя таблицы
host=serverA,region=us_west — тег
значение=0,64 это поле
Данные запроса:
influxDB поддерживает операторы, подобные SQL, и синтаксис конкретного запроса аналогичен.
Например: выберите * из процессора
Примечание. Кластерная функция InfluxDB больше не имеет открытого исходного кода. Чтобы использовать службу кластера, вам необходимо приобрести Enterprise Edition.
Основное различие между версией с открытым исходным кодом и корпоративной версией заключается в том, что корпоративная версия InfluxDB поддерживает кластеры, а версия с открытым исходным кодом - нет. Кроме того, корпоративная версия предоставляет расширенные функции резервного копирования/восстановления, а версия с открытым исходным кодом - нет .
Но производительности автономной версии InfluxDB также достаточно для поддержки бизнеса малых и средних компаний.
4. Политика хранения данных
InfluxDB может обрабатывать тысячи фрагментов данных в секунду, для сохранения всех этих данных потребуется много места для хранения, и иногда нам может не понадобиться хранить все исторические данные.
Поэтому InfluxDB ввела политики хранения данных (Retention Policies), которые позволяют нам настраивать время хранения данных. Политика хранения данных InfluxDB используется для определения времени, в течение которого данные хранятся в InfluxDB, или для определения сохранения данных в течение определенного периода.
База данных может иметь несколько политик хранения, но каждая политика должна быть уникальной.
стратегия запросов
Вы можете просмотреть существующие политики базы данных с помощью следующего оператора:
Телеграф базы данных имеет только одну стратегию, и значение каждого поля следующее:
name: Имя, это имя примера — autogen. Когда вы создаете базу данных, InfluxDB автоматически создаст для базы данных стратегию под названием autogen, которая сохранит данные навсегда. Вы можете переименовать эту политику и отключить автоматическое создание политики в файле конфигурации InfluxDB.
продолжительность: время хранения данных, 0 означает неограниченное shardGroupDuration: время хранения shardGroup, которая является базовой структурой хранения InfluxDB. replicaN: полное название REPLICATION, количество реплик default: Является ли это политикой по умолчанию. Здесь есть два понятия:
осколок:
Шард — важное понятие в InfluxDB, которое связано с политикой хранения (политикой хранения данных). Каждая стратегия хранения включает множество сегментов, и каждый сегмент хранит данные в течение определенного периода времени.
И повторения нет, например данные с 7:00 до 8:00 попадают в shard0, а данные с 8:00 до 9:00 попадают в shard1. Каждый сегмент соответствует базовому механизму хранения TSM с независимым кэшем, файлами wal и tsm.
Когда создается база данных, автоматически создается политика хранения по умолчанию для постоянного сохранения данных. Соответствующий период времени данных, хранящихся в осколках в соответствии с этой политикой хранения, составляет 7 дней, что составляет 168 часов, как показано в приведенном выше запросе.
Если создается новая политика хранения и время хранения данных установлено на 1 день, временной интервал для хранения данных в одном сегменте составляет 1 час, а данные дольше 1 часа будут храниться в следующем сегменте.
группа осколков:
Группа осколков — это логический контейнер осколков.
Создать политику
грамматика:
CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]
: Предложение SHARD DURATION определяет временной интервал для хранения каждой группы сегментов.Это предложение недопустимо в стратегии постоянного хранения. Этот пункт является необязательным. Продолжительность группы сегментов по умолчанию определяется продолжительностью политики.
Пример 1: Создание политики для телеграфа базы данных
CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 1d REPLICATION 1
Пример 2: Создать политику по умолчанию для телеграфа базы данных
CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 24h REPLICATION 1 DEFAULT
Изменить политику
грамматика:
ALTER RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> SHARD DURATION <duration> DEFAULT
удалить политику
грамматика:
DROP RETENTION POLICY <retention_policy_name> ON <database_name>
Примечание. Если стратегия, используемая таблицей, не является стратегией по умолчанию, вы должны явно указать имя стратегии при выполнении операции, иначе произойдет ошибка.
Сборник команд InfluxDB:
SHOW MEASUREMENTS -- Запрос таблиц, содержащихся в текущей базе данных
SHOW FIELD KEYS -- просмотреть поля всех таблиц в текущей базе данных
SHOW series from pay -- просмотреть ключевые данные
SHOW TAG KEYS FROM "pay" -- просмотреть значение ключа тега в ключе
SHOW TAG VALUES FROM "pay" WITH KEY = "merId" -- просмотреть значение, соответствующее указанному ключевому значению тега в ключе
SHOW TAG VALUES FROM cpu WITH KEY IN ("region", "host") WHERE service = 'redis'
УДАЛИТЬ СЕРИИ ИЗ
ПОКАЗАТЬ НЕПРЕРЫВНЫЕ ЗАПРОСЫ -- просмотреть постоянно выполняемые команды
ПОКАЗАТЬ ЗАПРОСЫ -- просмотреть последнюю выполненную команду
KILL QUERY -- команда завершения
SHOW RETENTION POLICIES ON mydb -- просмотреть сохраненные данные
Данные запроса
SELECT * FROM /.*/ LIMIT 1 -- запросить первую строку всех таблиц в текущей базе данных
select * from pay order by time desc limit 2
select * from db_name."Имя ПОЛИТИКИ".measurement_name --Укажите данные таблицы в сохранении данных в базе данных запроса ПОЛИТИКА имя хранения данных
удалить данные
удалить из "запроса" -- удалить все данные в таблице, тогда таблица не существует
drop MEASUREMENT "query" -- удалить таблицу (обратите внимание, что данные будут сохранены и удалены с помощью удаления)
DELETE FROM cpu
DELETE FROM cpu WHERE time < '2000-01-01T00:00:00Z'
DELETE WHERE time < '2000-01-01T00:00:00Z'
DROP DATABASE "testDB" -- удалить базу данных
DROP RETENTION POLICY "dbbak" ON mydb -- удалить зарезервированные данные как данные dbbak
DROP SERIES from pay where tag_key='' -- удалить тег в ключе
SHOW SHARDS -- просмотреть файлы хранилища данных
DROP SHARD 1
SHOW SHARD GROUPS
SHOW SUBSCRIPTIONS
5.Chronograf
Influxdb закрыл встроенную функцию веб-управления 8086 после версии 1.3 и требует отдельного инструмента для управления ею. И этот инструмент — Хронограф.
По сути, Chronograf — неотъемлемая часть технологического стека TICK. TICK — это пакет мониторинга, запущенный InfluxdDB, который выполняет восходящую и нисходящую работу баз данных временных рядов, таких как сбор индикаторов, анализ и рисование, что в некоторой степени имитирует пакет системы анализа журналов ELK. ТИК содержит:
Телеграф: сбор данных
InfluxDB: прием и хранение данных
Хронограф: отображение сводки данных, будильник и т. д.
Kapacitor: обработка данных, например, политики мониторинга и т. д.
Скачать Хронограф
ссылка для скачивания :portal.influxdata.com/downloads
Установить Хронограф
Запустить Хронограф
systemctl start chronograf
Посетите Хронограф
ввод в браузереhttp://IP:8888
Спросите:
Богатый интерфейс, простой запрос, просмотр, статистический анализ и т. Д., Очень удобный в использовании.
5. Резервное копирование и восстановление данных
Формат команды для резервного копирования данных
influxd backup -database [name] [path-to-backup]
Удаленное резервное копирование:
influxd backup -database myinfo -host 0.0.0.0:8088 /home/gooagoo/influxDB/backup
Замените 0.0.0.0 на IP-адрес
Формат команды для восстановления данных
influxd restore [ -metadir | -datadir ] <path-to-meta-or-data-directory> <path-to-backup>
6. Комплексный кейс: Telegraf + InfluxDB + Grafana
1.Telegraf
Telegraf — это программа-агент, написанная на Go, которую можно использовать для сбора системной и служебной статистики и которая является частью стека технологий TICK. Он имеет подключаемый модуль ввода, который может напрямую получать данные индикатора из системы и получать данные индикатора из сторонних API. Вы даже можете получить данные метрик через Kafka. Он также имеет выходные плагины, которые могут отправлять собранные метрики в различные хранилища данных, службы и очереди сообщений. Такие как InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, MQTT и другие.
Скачайте и установите Телеграф
wget https://dl.influxdata.com/telegraf/releases/telegraf-1.9.3-1.x86_64.rpm
sudo yum install telegraf-1.9.3-1.x86_64.rpm
telegraf -version
Если ваш телеграф установлен, расположение его конфигурационного файла:
/etc/telegraf/telegraf.conf
Отредактируйте файл конфигурации, чтобы указать нашу настроенную базу данных Influxdb в качестве желаемого источника вывода:
[[outputs.influxdb]]
urls=["http://localhost:8086"]
Запускаем сервис и добавляем автозагрузку:
sudo systemctl start telegraf.service
sudo service telegraf status
sudo systemctl enable telegraf.service
Проверьте, какие данные собирает Telegraf в конфигурации по умолчанию на InfluxDB:
> show databases
> use telegraf
> show measurements
> SHOW FIELD KEYS
Как настроить:
# Read metrics about cpu usage
# 读取有关CPU使用情况的指标
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false
## If true, compute and report the sum of all non-idle CPU states.
report_active = false
# Read metrics about disk usage by mount point
# 通过mount point读取有关磁盘使用情况的指标
[[inputs.disk]]
## Ignore mount points by filesystem type.
ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"]
# Read metrics about disk IO by device
# 通过device读取有关磁盘IO的指标
[[inputs.diskio]]
# Get kernel statistics from /proc/stat
# 通过/proc/stat获取内核统计信息
[[inputs.kernel]]
# no configuration
# Read metrics about memory usage
# 读取有关内存使用量的指标
[[inputs.mem]]
# no configuration
# Get the number of processes and group them by status
# 获取进程的数量并按状态分组
[[inputs.processes]]
# no configuration
# Read metrics about swap memory usage
# 读取有关交换内存使用量的指标
[[inputs.swap]]
# no configuration
# Read metrics about system load & uptime
# 读取有关系统负载和运行时间的指标
[[inputs.system]]
# no configuration
Как найти метрики и собрать данные
Telegraf в основном делится на входные плагины и входные плагины. Его каталог исходного кода соответствует плагинам/входам и плагинам/выходам соответственно. Вам нужно только обратиться к официальному файлу телеграфа, чтобы найти нужный плагин, и затем перейдите в соответствующий каталог исходного кода, чтобы найти соответствующий файл .md.Подсказка для получения соответствующей информации для настройки.
После включения службы телеграфа вы обнаружите, что в InfluxDB есть библиотека телеграфа с несколькими измерениями, что означает, что наш сбор данных прошел успешно. После того, как у нас есть данные, нам нужно позаботиться о том, как агрегировать данные и отображать их.
2. Дисплей Графана
Пожалуйста, обратитесь к вики для загрузки и установки базовой конфигурации: Grafana, инструмент мониторинга и анализа для графиков больших данных.
Вот краткое объяснение того, как использовать Grafana для отображения соответствующих данных, собранных Telegraf.
Доступ после запуска сервисаhttp://ip:3000, порт по умолчанию — 3000, который можно изменить в файле конфигурации. После авторизации следуем подсказкам для настройки источника данных, в качестве источника данных выбираем InfluxDB:
Заполните соответствующие элементы конфигурации InfluxDB в соответствии с информацией о конфигурации.
Затем создайте панель инструментов:
Сначала мы выбираем способ импорта шаблона для предварительного просмотра эффекта, а затем узнаем о соответствующей конфигурации графана/дашборда Здесь мы выбираем официальный набор Телеграфа: системный дашборд, адрес. Пожалуйста, настройте свой телеграф в соответствии с его подсказками. Затем выберите import->Upload.jsonFile в информационных панелях, чтобы импортировать загруженный шаблон:
Посмотреть Результаты:
Функции Grafana очень богаты и не могут быть подробно описаны здесь, пожалуйста, обратитесь к официальной документации для получения дополнительной информации:docs.grafana.org/
7. Руководство по масштабированию оборудования InfluxDB
Один узел или кластер? Экземпляры InfluxDB с одним узлом полностью открыты. Для кластеров InfluxDB требуется наш коммерческий продукт с закрытым исходным кодом. Экземпляры с одним узлом не обеспечивают избыточность. Если сервер недоступен, записи и запросы немедленно завершатся ошибкой.
Кластеризация обеспечивает высокую доступность и избыточность. Несколько копий данных распределяются по нескольким серверам, и потеря любого одного сервера не окажет существенного влияния на кластер. Если ваши требования к производительности относятся к среднему или низкому диапазону нагрузки,
Затем вы можете использовать экземпляр InfluxDB с одним узлом. Если хотя бы одно из ваших требований к производительности попадает в категорию невыполнимых, вам может потребоваться использовать кластер для распределения нагрузки между несколькими серверами.
1. Одиночный узел
Примечание. Влияние запросов на систему сильно различается.
Простой запрос:
Несколько функций и никаких регулярных выражений
время ограничено минутами, часами или сутками
Обычно выполняется от нескольких миллисекунд до десятков миллисекунд
Умеренный запрос:
Есть несколько функций и одно или два регулярных выражения
Также возможны сложные предложения GROUP BY или выборочные диапазоны времени в несколько недель.
Обычно выполняется за сотни или тысячи миллисекунд
Сложный запрос:
Имеет несколько функций агрегирования или преобразования или несколько регулярных выражений
Очень большие таймфреймы, которые можно замерить за месяцы или годы
Обычно требуется много секунд для выполнения
Рекомендации по низкой нагрузке:
ЦП: 2-4 ядра
Оперативная память: 2-4 ГБ
IOPS: 500
Рекомендации по умеренной нагрузке:
ЦП: 4-6 ядер
Оперативная память: 8-32 ГБ
IOPS: 500-1000
Рекомендации по высокой нагрузке:
ЦП: 8+ ядер
Оперативная память: 32+ ГБ
IOPS: 1000+
2. Кластер
мета узел
Кластер должен иметь как минимум три независимых метаузла, чтобы пережить потерю сервера. Кластер с 2n+1 метаузлами может выдержать потерю n метаузлов. Кластер должен иметь нечетное количество метаузлов. Нет причин иметь четное количество метаузлов, и это может вызвать проблемы с некоторыми конфигурациями.
Метаузлы не требуют большой вычислительной мощности. Независимо от нагрузки кластера мы рекомендуем следующее для метаузлов:
обычно рекомендуется
ЦП: 1-2 ядра
Оперативная память: 512 МБ - 1 ГБ
IOPS: 50
узел данных
Кластер только с одним узлом данных работает, но не имеет избыточности данных. Избыточность задается коэффициентом репликации в политике хранения записанных данных. Кластер может потерять n-1 узлов данных и по-прежнему возвращать полные результаты запроса, где n — коэффициент репликации.
Для оптимального распределения данных внутри кластера InfluxData рекомендует четное количество узлов данных. Рекомендации по оборудованию для кластерных узлов данных аналогичны рекомендациям для отдельных экземпляров. Узлы данных всегда должны иметь как минимум 2 ядра ЦП, поскольку они должны обрабатывать обычный трафик чтения и записи, а также трафик чтения и записи внутри кластера.
Узлы данных в кластере обрабатывают меньшую пропускную способность, чем автономные экземпляры на том же оборудовании, из-за накладных расходов на связь кластера.
Примечание. Влияние запросов на систему сильно различается.
Простой запрос:
Несколько функций и никаких регулярных выражений
время ограничено минутами, часами или сутками
Обычно выполняется от нескольких миллисекунд до десятков миллисекунд
Умеренный запрос:
Есть несколько функций и одно или два регулярных выражения
Также возможны сложные предложения GROUP BY или выборочные диапазоны времени в несколько недель.
Обычно выполняется за сотни или тысячи миллисекунд
Сложный запрос:
Имеет несколько функций агрегирования или преобразования или несколько регулярных выражений
Очень большие таймфреймы, которые можно замерить за месяцы или годы
Обычно требуется много секунд для выполнения
рекомендация по низкой нагрузке
ЦП: 2 ядра
Оперативная память: 2-4 ГБ
IOPS: 1000
Рекомендация по умеренной нагрузке
Процессор: 4-6
Память: 8-32 ГБ
IOPS: 1000+
Рекомендация по высокой нагрузке
Процессор: 8+
Оперативная память: 32+ ГБ
IOPS: 1000+
Корпоративный веб-узел
Корпоративные веб-серверы в основном представляют собой HTTP-серверы с аналогичными требованиями к нагрузке. Для большинства приложений он не должен быть очень мощным. Кластер может использовать только один веб-сервер, но для резервирования несколько веб-серверов могут быть подключены к одной серверной базе данных Postgres.
Примечание. В производственном кластере не следует использовать базу данных SQLite, так как она не допускает резервных веб-серверов и не справляется с высокими нагрузками так изящно, как Postgres.
обычно рекомендуется
ЦП: 1-4 ядра
Оперативная память: 1-2 ГБ
IOPS: 50
Восемь, автономный тест производительности InfluxDB
Официальная эталонная конфигурация оборудования:
Два SSD. Одна часть хранит influxdb/wal, а другая часть хранит influxdb/data Не менее 8G памяти
Тест производительности виртуальной машины InfluxDB, запишите результаты здесь для дальнейшего использования.
Операционная система: CentOS Linux версии 7.5.1804.
Версия InfluxDB: V1.7.4
ЦП: ЦП Intel(R) Xeon(R) E5-2403 0 @ 1,80 ГГц, 4x 4-ядерных ЦП
Память: 16G
Жесткий диск: механический жесткий диск
Пакетная запись официального руководства:
Пакет точек можно отправить в базу данных с помощью одного HTTP-запроса к конечной точке записи. Это делает запись HTTP API более эффективной за счет значительного сокращения накладных расходов HTTP.
InfluxData рекомендует размер пакета от 5000 до 10 000 точек, но для разных случаев использования лучше использовать значительно меньшие или большие пакеты.
Результат до оптимизации (запись): один поток пишет данных больше примерно 1200Вт, запись не проходит, памяти не хватает
Результат после многократных оптимизаций (пишет):
Полная производительность сканирования таблицы
Производительность условного запроса
запрос измерения времени
Совокупная производительность запросов
Для одного и того же измерения большой объем данных записывается пакетами, а затем считывается несколькими потоками.По мере увеличения объема данных скорость чтения снижается.
Если это разные измерения, а чтение и запись являются разными измерениями, то чтение и запись не влияют друг на друга.
Серверы должны иметь ограничения конфигурации памяти, чтобы свести к минимуму риск запуска OOM внутренними процессами.
Текущее поведение:
В системе есть несколько мест, где может происходить много распределений, что может быть связано с риском OOM.
Как правило, это происходит, когда:
Запросы — часто использование слишком широких фильтров приводит к одновременной загрузке слишком большого количества серий, например операции select * (подтверждение существует)
Индексация в памяти — ряды с высокой кардинальностью (ряды), вызывающие рост индекса и процессы OOM (подтверждено существование)
Запись. Многие текущие большие пакеты и медленная запись на диск вызывают создание большого количества внутренних буферов во время ожидания записи/синхронизации диска. (подтвердить наличие)
Сжатие. В некоторых случаях можно загружать большие серии для более оптимальной дедупликации и разделения точек. (пока не нашел)