Приветствую
Как бы ранее не интересовался сабжем, а сейчас решил потрогать, а может и задействовать для хранения данных от всяких счетчиков производительности железа
Если я правильно почитал гугл — мне нужно чтототипа 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. Они оба интегрируются с графаной, что оч. здорово, если ты пишешь мониторинг.
