Приветствую
Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа
Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
Здравствуйте, Sheridan, Вы писали:
S>Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа S>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
Для счетчиков и реляционные неплохо подходят (на разумных объемах). Может тебе вообще RRDtool за глаза хватит.
BigTable тебе не нужна IMHO. Но если хочется, начни с LevelDB, она похожа и как раз на C++.
Вероятно, я неправильно понял. Я думал нужно NoSQL на C++ написанное что-нибудь. А так как вариант можно из JavaScript (ну а его в свою очередь, встроить в ваше приложение через V8)
Здравствуйте, wildwind, Вы писали:
S>>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
W>Для счетчиков и реляционные неплохо подходят (на разумных объемах).
Вот именно. Я хочу дать возможность настраивать эти пределы. Представь себе срезы нагрузки процессоров нескольких стоек с разницей в секунду. Тут имхо реляционные загнутся.
W>Может тебе вообще RRDtool за глаза хватит.
емнип оно имеет свойство усреднять данные по истечении настраиваемого предела. Не нравится мне оно, хотя да, как вариант.
W>BigTable тебе не нужна IMHO. Но если хочется, начни с LevelDB, она похожа и как раз на C++.
Как то подозрительно хитро там выборка срезов по времени...
зы Я NoSQL не трогал никогда, поэтому могу говорить глупые вещи. Просто поправь, если что.
Здравствуйте, zubactik, Вы писали:
Z>Вероятно, я неправильно понял. Я думал нужно NoSQL на C++ написанное что-нибудь. А так как вариант можно из JavaScript (ну а его в свою очередь, встроить в ваше приложение через V8)
Да, движок на с\с++. Ну и работа с ним из с\с++ будет...
Не хотелось бы посредников (читай-тормоза) иметь между базой и использованием данных...
Здравствуйте, Sheridan, Вы писали:
S> S>>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое? S> W>Для счетчиков и реляционные неплохо подходят (на разумных объемах). S> Вот именно. Я хочу дать возможность настраивать эти пределы. Представь себе срезы нагрузки процессоров нескольких стоек с разницей в секунду. Тут имхо реляционные загнутся.
Это тебе просто пограться с noSQL, мониторингом и прочим или реальная задача найти ботлнеки и/или периоды простоя?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, wildwind, Вы писали:
S>>>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
W>>Для счетчиков и реляционные неплохо подходят (на разумных объемах). S>Вот именно. Я хочу дать возможность настраивать эти пределы. Представь себе срезы нагрузки процессоров нескольких стоек с разницей в секунду. Тут имхо реляционные загнутся.
С разницей в секунду не загнутся. Даже 1000 записей в секунду не проблема. Если что можно прикрутить кеширование и заливать в бд данные пакетом.
S>Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа S>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
Сколько данных планируется хранить/обрабатывать? Что данные из себя представляют? Нужно просто суммы считать, или нужны еще и графики или гистограммы?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую S>Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа S>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
Для этих задач хорошо подходят time series databases. Например graphite или InfluxDb
Здравствуйте, Sheridan, Вы писали:
S> S>>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
S> W>Для счетчиков и реляционные неплохо подходят (на разумных объемах).
S> Вот именно. Я хочу дать возможность настраивать эти пределы. Представь себе срезы нагрузки процессоров нескольких стоек с разницей в секунду. Тут имхо реляционные загнутся.
Это сколько в TPS? Думаю, не загнутся, особенно если буферизовать и батчить.
S> Как то подозрительно хитро там выборка срезов по времени...
Что именно хитро? Не сложнее BerkeleyDB IMHO. У тебя разве не срезы?
S> зы Я NoSQL не трогал никогда, поэтому могу говорить глупые вещи. Просто поправь, если что.
Да я и сам не особо трогал. Но если ты вообразил, что NoSQL устроены так же сложно, как реляционные, но совсем по-другому, и в них нужно серьезно погружаться, ты ошибаешься. Там все намного проще. Key-value, и то и другое слабо типизировано. Ссылки. Иногда дополнительные индексы, иногда итераторы. Вот и все, в основном.
Здравствуйте, Dziman, Вы писали:
D>Это тебе просто пограться с noSQL, мониторингом и прочим или реальная задача найти ботлнеки и/или периоды простоя?
Я хочу нарисовать инструмент, который сможет это всё. Начал уже давно, потихоньку иногда пилю...
Здравствуйте, BlackEric, Вы писали:
W>>>Для счетчиков и реляционные неплохо подходят (на разумных объемах). S>>Вот именно. Я хочу дать возможность настраивать эти пределы. Представь себе срезы нагрузки процессоров нескольких стоек с разницей в секунду. Тут имхо реляционные загнутся. BE>С разницей в секунду не загнутся. Даже 1000 записей в секунду не проблема. Если что можно прикрутить кеширование и заливать в бд данные пакетом.
У меня был опыт уже
Здравствуйте, ELazin, Вы писали:
S>>Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа S>>Если я правильно почитал гугл — мне нужно чтототипа bigtable, но на c\c++. Под линупс. Есть такое?
EL>Сколько данных планируется хранить/обрабатывать? Что данные из себя представляют? Нужно просто суммы считать, или нужны еще и графики или гистограммы?
Нужно просто хранить. И, соответственно, выбирать. Ну, как минимум срезы по дате-времени от... до...
Это данные от счетчиков производительности железа.
Считать ничего не надо, для этого R есть, он же и графики нарисует.
Здравствуйте, Sheridan, Вы писали:
BE>>С разницей в секунду не загнутся. Даже 1000 записей в секунду не проблема. Если что можно прикрутить кеширование и заливать в бд данные пакетом. S>У меня был опыт уже
EL>>Сколько данных планируется хранить/обрабатывать? Что данные из себя представляют? Нужно просто суммы считать, или нужны еще и графики или гистограммы? S>Нужно просто хранить. И, соответственно, выбирать. Ну, как минимум срезы по дате-времени от... до... S>Это данные от счетчиков производительности железа. S>Считать ничего не надо, для этого R есть, он же и графики нарисует.
Т.е. просто временные ряды? А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени?
Здравствуйте, ELazin, Вы писали:
EL>>>Сколько данных планируется хранить/обрабатывать? Что данные из себя представляют? Нужно просто суммы считать, или нужны еще и графики или гистограммы? S>>Нужно просто хранить. И, соответственно, выбирать. Ну, как минимум срезы по дате-времени от... до... S>>Это данные от счетчиков производительности железа. S>>Считать ничего не надо, для этого R есть, он же и графики нарисует.
EL>Т.е. просто временные ряды?
Похоже на то.
EL>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени?
Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"
По времени хранения... Думаю ориентироваться минимум на год.
Здравствуйте, Sheridan, Вы писали: EL>>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени? S>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"
Нужно определиться с макс. пропускной способностью и количеством параметров, которые нужно мониторить. Если их много и они могут часто добавляться, то RRD будет плохо работать. Нужно брать какую-нибудь нормальную базу данных, а еще лучше — базу данных для временных рядов. И от этого же будет зависеть то, сколько памяти сожрет хранение данных на глубину в один год.
Помимо этого, я бы не советовал использовать встраиваемую БД, лучше использовать отдельный сервер, пусть даже в начале БД будет работать на той же машине. В этом случае, если твое приложение начнет портить память — оно не сможет испортить твою базу данных.
Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
Здравствуйте, ELazin, Вы писали:
EL>Здравствуйте, Sheridan, Вы писали: EL>>>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени? S>>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее"
EL>Нужно определиться с макс. пропускной способностью и количеством параметров, которые нужно мониторить. Если их много и они могут часто добавляться, то RRD будет плохо работать. Нужно брать какую-нибудь нормальную базу данных, а еще лучше — базу данных для временных рядов. И от этого же будет зависеть то, сколько памяти сожрет хранение данных на глубину в один год.
Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде.
EL>Помимо этого, я бы не советовал использовать встраиваемую БД, лучше использовать отдельный сервер, пусть даже в начале БД будет работать на той же машине. В этом случае, если твое приложение начнет портить память — оно не сможет испортить твою базу данных.
Конечно отдельный сервер. По другому тут никак.
EL>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
с графаной?
Здравствуйте, Sheridan, Вы писали:
EL>>А сколько их планируется и сколько по каждому из них будет обновлений в единицу времени? S>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее" S>По времени хранения... Думаю ориентироваться минимум на год.
А зачем это надо хранить год?
Всегда думал, что подобные системы больше для более-менее оперативного мониторинга, нет? Зачем может быть нужна инфа, как там трафик гулял по тому или иному сфичу год назад?
Здравствуйте, paucity, Вы писали:
S>>По времени хранения... Думаю ориентироваться минимум на год. P>А зачем это надо хранить год? P>Всегда думал, что подобные системы больше для более-менее оперативного мониторинга, нет? Зачем может быть нужна инфа, как там трафик гулял по тому или иному сфичу год назад?
Год — для анализа, чтобы увидеть тенденции и на них реагировать.
Вот например, использование дискового пространства на одном из моих серверов (да, не трафик, но наглядно)
Вид за день
Вид за месяц
Вид за год
Только за год видно что места становится меньше, но пока что еще некритично. Года через три только можно будет думать о расширении, если чистки не помогут.
Так и с трафиком. Только чуть по другому.
S>Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде.
А какая схема использовалась? По опыту — 1-1.5гб/сутки это слезы. Это легко вытянет и graphite на слабенькой машине.
EL>>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг. S>с графаной? http://grafana.org/
Здравствуйте, ELazin, Вы писали:
S>>Ну, на моей практике бывало пополнение 1-1,5гб\сутки. Мускуль выжил только на ssd в рейде. EL>А какая схема использовалась? По опыту — 1-1.5гб/сутки это слезы. Это легко вытянет и graphite на слабенькой машине.
Это был zabbix. Что он там с БД (мускуль и постгрес пробовал) делал — хз, но упиралось всё в диск. Лишь ssd помогли.
EL>>>Можно потрогать graphite или prometeus. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг. S>>с графаной? EL>http://grafana.org/
О, спасибо, интересная штука. Возможно и с ней клиента сделаю.
Здравствуйте, Sheridan, Вы писали:
S>Трудно сказать... От "трогаем за проц\память\диск раз в минуту четыре с половиной сервера" до "высасываем все доступные статы по каждому порту каждого свича провайдера как можно быстрее" S>По времени хранения... Думаю ориентироваться минимум на год.
Я полагаю, для такой задачи нет ничего быстрее, чем дописывать записи в хвост линейного файла. Если редкая потеря данных не очень критична, можно даже с "транзакционностью" не очень заморачиваться, и доверитс ОС скидывать кеш на диск по ее собственному усмотрению. Тогда в случае чего последние записи могут быть утеряны или оборваны. Время от времени файл завершать и начинать новый; старые выбрасывать. И поверх этого навесить какую-нибудь незамысловатую базу, чтобы искать по файлам было проще (база должна выдавать примерно, откуда и до куда смотреть, чтобы не прочесывать все файлы с начала и до конца).
Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется).
Pzz>Я полагаю, для такой задачи нет ничего быстрее, чем дописывать записи в хвост линейного файла. Если редкая потеря данных не очень критична, можно даже с "транзакционностью" не очень заморачиваться, и доверитс ОС скидывать кеш на диск по ее собственному усмотрению. Тогда в случае чего последние записи могут быть утеряны или оборваны. Время от времени файл завершать и начинать новый; старые выбрасывать. И поверх этого навесить какую-нибудь незамысловатую базу, чтобы искать по файлам было проще (база должна выдавать примерно, откуда и до куда смотреть, чтобы не прочесывать все файлы с начала и до конца).
Это не будет работать, так как данные от разных источников могут приходить со смещенными метками времени, поэтому прежде чем писать на диск, их нужно кешировать и сортировать. Данные часто агрегируются на хостах и отправляются пачками раз в Х секунд (statsd так работает, например). В итоге, данные в файле у тебя будут вперемешку и что-то ты не сможешь найти, с помощью индекса.
Pzz>Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется).
В случае современных TSDB это не так, так как там есть сжатие. Допустим, один элемент данных это 24 байта (id — 8 байт, метка времени — 8 байт, значение — 8 байт). Допустим у нас в системе установлен SSD, который может записывать данные в лог последовательно со скоростью 100Мб/сек. Пропускная способность в результате будет порядка 4 миллионов значений в секунду. Но по факту, 24 байта на значение это очень дорого. Если мы пишем со скоростью 100К значений в секунду, то за сутки сожрем примерно 200Гб. За год — под 100Тб.
В то же время, современные TSDB умеют сжимать эти данные примерно до 3х байт на элемент данных. Пропускная способность от этого страдает, так как процесс записи становится CPU bound, но зато вместо 200Гб в сутки, можно ограничиться 25Гб (при той же скорости записи). Это примерно 10Тб в год, не так уж много.
Здравствуйте, ELazin, Вы писали:
EL>Это не будет работать, так как данные от разных источников могут приходить со смещенными метками времени, поэтому прежде чем писать на диск, их нужно кешировать и сортировать. Данные часто агрегируются на хостах и отправляются пачками раз в Х секунд (statsd так работает, например). В итоге, данные в файле у тебя будут вперемешку и что-то ты не сможешь найти, с помощью индекса.
Всякая проблема имеет, однако, решение.
Во-первых, можно проставлять временные метки по часам принимающего хоста. Это может даже и правильно. Во-вторых, можно искать с запасом (скажем, плюс-минус 10 минут, в надежде, что настолько часы не врут).
Pzz>>Это будет работать на скорости, близкой к скорости аппаратуры (упрется в диск, разумеется). EL>В случае современных TSDB это не так, так как там есть сжатие. Допустим, один элемент данных это 24 байта (id — 8 байт, метка времени — 8 байт, значение — 8 байт). Допустим у нас в системе установлен SSD, который может записывать данные в лог последовательно со скоростью 100Мб/сек. Пропускная способность в результате будет порядка 4 миллионов значений в секунду. Но по факту, 24 байта на значение это очень дорого. Если мы пишем со скоростью 100К значений в секунду, то за сутки сожрем примерно 200Гб. За год — под 100Тб.
Линейный файл тоже никто не мешает сжимать по ходу записи. Только скорость, боюсь, очень сильно просядет.
Современный винчестер и современная SSD в режиме линейной записи дают примерно одинаковую скорость. Но только место на диске стоит на порядок дешевле, чем на флешке. Флешку имеет смысл использовать, когда доступ идет случайный, там она очень сильно выигрывает за счет отсутствия необходимости чего-либо механически крутить или перемещать.
Pzz>Всякая проблема имеет, однако, решение.
Конечно имеет, в данном случае это кеширование в памяти и сортировка перед записью на диск.
Pzz>Во-первых, можно проставлять временные метки по часам принимающего хоста. Это может даже и правильно.
Это точно неправильно. Я приводил пример statsd, который накапливает в себе данные за flush interval и потом отправляет все скопом. Flush interval может быть 10 секунд, а может и минуту. В случае devops задач тебе может потребоваться связать какое-нибудь событие на графике, например с данными в логе на удаленной машине или в кибане, тут то окажется что метки времени отличаются и все это бесполезно абсолютно.
Pzz>Во-вторых, можно искать с запасом (скажем, плюс-минус 10 минут, в надежде, что настолько часы не врут).
Это да, но помимо этого, тебе придется каждый раз сортировать данные, когда ты захочешь их прочитать и проанализировать, ну или просто, несколько графиков в одном окне нарисовать.
Pzz>Линейный файл тоже никто не мешает сжимать по ходу записи. Только скорость, боюсь, очень сильно просядет.
Ну будешь ты сжимать gzip-ом каким-нибудь на лету. Будет не 24 байта на элемент данных а 22. Я сам не проверял, но КМК, все будет плохо. Алгоритмы сжатия временных рядов сильно круче жмут чем generic алгоритмы. Те же метки времени обычно имеют фикс. шаг (и точность) и соответственно хорошо жмутся с помощью тупого delta-RLE. Для float-ов есть свой аналог delta-encoding, который жмет оч. хорошо, если у тебя не совершенно случайные данные.
Pzz>Современный винчестер и современная SSD в режиме линейной записи дают примерно одинаковую скорость. Но только место на диске стоит на порядок дешевле, чем на флешке. Флешку имеет смысл использовать, когда доступ идет случайный, там она очень сильно выигрывает за счет отсутствия необходимости чего-либо механически крутить или перемещать.
На самом деле это не так, скорость последовательной записи на SSD сильно выше (зависит от конкретного SSD и его интерфейса).
Возможно и с ней клиента сделаю.
