
Vladimir
26.08.2016
20:06:02
с mixed уже ссд скорее всего нужны

Dmitry
26.08.2016
20:06:19
и завтра попробую влить в него тестовый набор для time-series и сравнить с influx'ом

Paul
26.08.2016
20:06:39
пугает меня influx.

Vladimir
26.08.2016
20:06:54
и у них он в продакшене с 2014 года на петабайтных базах

Google

Dmitry
26.08.2016
20:06:56
он есть уже

Vladimir
26.08.2016
20:07:02
со всем HL/HA

Dmitry
26.08.2016
20:07:22
но у него есть несколько критичных проблем
если будет решение, которое будет однозначно лучше, то influx не будет
как подложка для BI инфлюкс далеко не плох
у нас в любом случае - метрики, малая часть системы
хранилище всегда можно заменить малой кровью
но у нас есть и opensource версия
и достаточно мелкие инсталляции
не хочу портить им жизнь

Vladimir
26.08.2016
20:13:02
А вы как его выбрали?

Dmitry
26.08.2016
20:16:09
кого?

Vladimir
26.08.2016
20:17:18
как вы докатились до инфлюкса?

Google

Vladimir
26.08.2016
20:17:24
с кем сравнивали
по каким критериям он выиграл?
под какие данные?

Dmitry
26.08.2016
20:19:27
почему "докатились"
у нас было несколько реализаций своего хранилища
предпоследняя редакция -- точно так же, с мимикрией под графит
как я уже сказал, интересовали в первую очередь IOPS'ы и компактность храниения
необходимо хранить точное время измерения
RRD не подходят сразу

Vladimir
26.08.2016
20:21:36
Ну то есть вам нужна хранилка евентов с мимикрией под графит?
была

Dmitry
26.08.2016
20:21:39
из графитовых смотрел еще цианид в свое время
не нужна

Vladimir
26.08.2016
20:21:42
в первую очередь эвентов

Dmitry
26.08.2016
20:21:48
не event'ов
под event'ы у нас FM есть
это его
для PM графит смотрели больше как технологию
и как протокол
мимикрию под графит сделали ради дружбы с графаной

Google

Dmitry
26.08.2016
20:23:10
пока не было своего аналогичного движка для отчетов и визуализации
собираем, в основном, различные метрики с оборудования
самые крупные проекты - сети доступа
хотя на ядре тоже попадается
кампусы там и мобильщики
короче то, что обычно называется FM и PM в терминах телекомунникационной модели
графики использует техподдержка
часто, когда клиент на проводе висит, они должны отрисовываться быстро

Алексей
26.08.2016
20:29:51
я вот что подумал. и что у меня получалось по тестам. я паралельно лил данные в инфлюкс и в прометей.
потом делал выборку - покажи последние 7 дней. в целом оба справлилсь с задачкой менее чем за секунду.
но вот если я увеличивал "позавечера" инфлюкс всегда проигрывал прометею.
примерно в 2,5 раза.

Vladimir
26.08.2016
20:31:36
@dvolodin какой баланс чтений-записи? сколько вообще записей в секунду вы хотите в сторадж видеть и какого рода запросы на чтение идут? как я понимаю чтения еще и редки?

Алексей
26.08.2016
20:31:37
видимо это вопрос открытия нужнного шарда и чтения большого колва мест из большого файла против поиска файла и чтения из маленького файла.

Dmitry
26.08.2016
20:31:56
похоже, да
задним числом он неважно пишет
а может и WAL себя так ведет

Алексей
26.08.2016
20:32:23
нет вала тут уже точно не будет
позавчера лежит в другом и условно закрытом(cold) шарде
но при этом запросы типа покажи мне все данные за позавчера должны быть быстрыми, ибо читать надо рядом.только вот ценность такого рода запросов под вопрсом...

Vladimir
26.08.2016
20:35:33
@dvolodin короче из переспективных TS стораджей, есть metrictank (от авторов графаны, см гитхаб), есть btrdb, можно заюзать кликхаус, можно в теории взять тарантул 1.7 и написать плагин для графита

Google

Dmitry
26.08.2016
20:36:06
тарантул - обычный KVS

Vladimir
26.08.2016
20:36:09
еще есть eventql, тоже интересный, но надо смотреть

Dmitry
26.08.2016
20:36:11
почему именно он
а не, скажем, aerospike?

Vladimir
26.08.2016
20:36:38
@dvolodin авторы заверяют что они тестировали похожие кейсы у себя и он быстрее аероспайка
у меня на работе список из 18-и перспективных стораджей есть, к слову )
которые надо бы потестить в какой-то момент жизни
или почитать и выкинуть 2/3 списка

Dmitry
26.08.2016
20:37:15
список и в моем документе есть

Алексей
26.08.2016
20:38:08

Vladimir
26.08.2016
20:38:18
напомни в пнд
то что мне там казалось перспективным я выше перечислять начал )

Алексей
26.08.2016
20:38:41
мне кажется было бы прикольным собрать тут ребят кто пишут метричиеские базы
было бы полезно

Dmitry
26.08.2016
20:39:03
нужно для начала прикинуть, какие характеристики инетерсны и методику тестирования

Vladimir
26.08.2016
20:39:09
eventql, clickhouse, btrdb, может быть тарантул (я правда думал его как in-memory storage взять), druid (но он не совсем про метрики, скорее агрегации)
аероспайк там тоже был
остальное не помню

Dmitry
26.08.2016
20:40:06
leveldb/hyperleveldb/rocksdb
но к ним обвязка нужна

Google

Vladimir
26.08.2016
20:40:20

Dmitry
26.08.2016
20:40:44
https://www.evernote.com/l/ADnckwK0Be5E97cZpD2V2BOwQFyJG5sJHjI
у меня там есть список

Vladimir
26.08.2016
20:40:58
metriktank
https://dalmatiner.io
@dvolodin у тебя там нет списка
то есть конечно есть, но в нем 4 базы и еще 5 движков
баз и движков много больше

Dmitry
26.08.2016
20:41:49
ну так сколько их появилось-то новых

Vladimir
26.08.2016
20:41:53
поверх риака есть две time-series обвязки - далматинер и riak ts
при этом коллега пишет for fun обвязку к riak ts для совместимости с графитом
на прием и передачу
https://github.com/dams/graphite-riakts но оно очень сильно не полное пока что
просто for fun
btrdb вообще иной подход
и звучит интересно
https://blog.acolyer.org/2016/05/04/btrdb-optimizing-storage-system-design-for-timeseries-processing/
в основе движка k-ary tree лежит

Dmitry
26.08.2016
20:44:51
это ребята, которые wired tiger делали?

Vladimir
26.08.2016
20:45:07
есть еще CitusDB - плагин к постгресу с time-series движком
правда вроде не очень хороший