Gabalino opened merge request at / noc: Ibm nos

merge request closed by Gabalino

Gabalino opened merge request at / noc: Ibm nos

merge request closed by Gabalino

Gabalino opened merge request at / noc: Ibm nos

merge request opened by Gabalino

Gabalino opened merge request at / noc: Ibm nos

merge request opened by Gabalino

dv opened merge request at / collections: noc/noc#887 default technologies set

merge request opened by aversant

парни, приветствую. подскажите, для даных типа дата-значение, в ноке же кликхаус? можно узнать преимущества, перед тем же инфлюксом или какие еще есть варианты? мне надо хранить статистику с 10к устройств. количество данных на каждое примерно 5-6 паарметров, срок - полгода. может посоветуете?

парни, приветствую. подскажите, для даных типа дата-значение, в ноке же кликхаус? можно узнать преимущества, перед тем же инфлюксом или какие еще есть варианты? мне надо хранить статистику с 10к устройств. количество данных на каждое примерно 5-6 паарметров, срок - полгода. может посоветуете?

Преимущества с инфлюксом, меньшие требования к оборудованию.

Память, диски,

заточенность на аналитику.

как раз начал читать маны на него, потому как мускул это жопа для таких задач, да и в целом, прихожу к выводу, что мускул для новичков

думал в сторону эластика, но джава...

mysql очень печален для timesiries данных.

пример - Заббикс

ну и плюс если ожидается рост, то у инфлюкса кластер за деньги

т.е. отказоустойчивости из коробки не будет

о как, тогда курим яндекс кликхаус, вроде прям хорошо отзываются о нем, да и нок) делается опытными парнями)))

спасибо, Андерей

да, у нас был инфлюкс. Перехали на CH

в CH надо очень внимательно подходить к ключу при создании таблиц

от этого зависит объём данных, которые он лопатит при запросах

хм, тоесть не делать излишне универсальные?

если надо число длиной 2 знака, то так и делать?

я не про это)

или я еще не верными категориями мыслю)

я тока начал читать )))

если надо число длиной 2 знака, то так и делать?

это влияет на коэффициент сжатия

лучше всего сжимаются целые и строки

числа с плавающей точкой сжимаются очень плохо

поэтому, измерения лучше приводить к целым

н-р хранить не килограммы, а граммы

учту, очень полезнео замечание

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

а как лучше, его на отдельный сервер ставить?

а как лучше, его на отдельный сервер ставить?

вообще да. Базы всегда лучше на отдельные выносить. Чтобы им не мешали.

да, тем более данных будет много

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

айпи и маки не бывают десятичными. По умолчанию)

ибо бинарные

айпи и маки не бывают десятичными. По умолчанию)

ну там ip2long ) hexdec и прочая

хм, тоесть не делать излишне универсальные?

при создании таблицы указывается ключ engine=MergeTree(event_date, (site_id, event_type, article_id), 8192)

то что в скобках.

Надо хорошо подумать, каким его сделать.

по нему фильтруются запросы в where

для начала надо понять принцип мне) пока не имел дела с такими бд

по нему фильтруются запросы в where

это аналог индексов в мускуле?

это аналог индексов в мускуле?

нет

для начала надо понять принцип мне) пока не имел дела с такими бд

https://t.me/clickhouse_ru

dv opened merge request at / noc: WIP: Resource Groups: ManagedObject.termination_group migration

merge request opened by dv

В CH нет индексов в том понимании, что в mysql

для начала там нужно понять, что это колоночная база

как greenplum или vertica

таблицы хранятся не строками, а колонками

из этого два профита

если в таблце 100 колонок, а нужно только две -- размотаются только две

и колонка жмется гораздо сильнее, чем строка

так как часто там идут повторяющиеся данные или вообще относительно малое количество состояний

условно говоря - CH проще поднять колонку и профильтровать ее, чем бегать по индексу

и из этого два других свойства

нормально работает на шпинделях

из-за последовательного чтения

и очень быстро в себя засасывает данные

одна нода на среднем железе ~2.5M записей в секунду

и еще из полезных свойств как хранилище -- изначальное партиционированиие данных

решает вопрос с чисткой

но - CH сильно специализированная система

и очень быстро в себя засасывает данные

Прием или по факту?

по факту

он быстро пишет себе файл на вставку

потом при случае делает merge

LSM там

Да, но вставляет-то позже

нет

вставляет сразу

но он не любит мелких вставок

то есть лучше раз в секунду влепить миллион строк

чем тысячу раз по тысячу

Ты имеешь ввиду, этот файл уже часть бд, но он его потом аппендит в главный

поэтому ему нужен буфферизатор

LSM - сама база состоиит как бы из слоев

каждый следующий утрамбован плотнее, чем предыдущий

доступны все данные

на чтение

просто они могут занимать больше места на диске

в CH, вроде, до 9 уровней

dv opened merge request at / noc: WIP: Resource Groups: ManagedObject.termination_group migration

merge request opened by dv

поэтому ему нужен буфферизатор

Дим, подскажи пожалуйста, что подразумевается по буферизатором? напримре, есть скрипт опроса, либо активное подключение с устройства, надо собирать данные раз в 15 минут, например, а потом их сливать в СН?

dv opened merge request at / noc: WIP: Resource Groups: ManagedObject.termination_group migration

merge request opened by dv

буферизатор -- смотри наш chwriter