База данных для управления большими объемами (системных) метрик

Question

Я смотрю на создание системы для управления и отчетности статистики по производительности веб-страниц. Я буду собирать намного больше статистики, чем доступно в стандартных форматах журналов (около 20 метрик), но по сравнению с большинством типов приложений баз данных, базовая структура данных будет очень простой. Моя проблема в том, что я буду накапливать много данных - в районе 100 000 записей (то есть наборов метрик) в час.

Конечно, ресурсы очень ограничены!

Чтобы можно было разумно взаимодействовать с данными, мне нужно было бы объединить каждую метрику в одну минуту, с разбивкой по URL, затем для чего-то более чем на 1 день, объединить в 10-минутные ячейки, затем в 1 неделя, почасовые корзины.

На начальном этапе я хочу предоставить представление (предпочтительно в виде графиков) последнего часа данных, с возможностью для пользователей пролистывать / опускать определенные иерархии URL-адресов (которые не всегда отображаются непосредственно на иерархия, выраженная в пути URL) и для просмотра различных временных периодов.

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

Я посмотрел на Мондриана , однако из документации, которую я посмотрел, не видно, можно ли отбросить более детальную информацию при сохранении консолидированных представлений данных.

RRDTool выглядит многообещающе с точки зрения управления консолидацией данных, но выглядит довольно ограниченным с точки зрения запроса набора данных в качестве многомерной / реляционной базы данных.

На что еще мне смотреть?

Answer 1

Ваш ответ с упоминанием Graphite является отличным решением, если вы готовы управлять экземпляром Graphite (и, вероятно, вы также будете использовать Statsd ) самостоятельно. Кроме того, существует множество других размещенных приложений, которые начинают предлагать такую ​​функциональность. Есть StatHat , Librato Metrics и продукт моей собственной компании Инструментальная . Он определенно может справиться с метрической нагрузкой, которую вы запрашиваете при нашем самом низком плане - у нас есть официальный клиент (Ruby) , Statsd-совместимый прокси и документированный способ отправлять сообщения нашему сборщику самостоятельно, а также хороший способ получить ваши метрики обратно через наш API на случай, если вы захотите создать свой собственный уровень представления вне наших графиков.

Answer 2

Попробуйте использовать InfluxDB (http://influxdb.com/) база данных распределенных временных рядов с открытым исходным кодом.

Имеет удобный интерфейс для размещения таких метрик, как

[
  {
    "name" : "hd_used",
    "columns" : ["value", "host", "mount"],
    "points" : [
      [23.2, "serverA", "/mnt"]
    ]
  }
]

Вы можете легко визуализировать свои метрики, используя Grafana (http://grafana.org/)

Answer 3

Это вопросы и ответы довольно старые, но я недавно нашел что-то, что выглядит так, как будто это соответствует моим требованиям - Графит .Все еще нужно запустить установку, но она выглядит очень многообещающе.

Answer 4

Все равно не удалось найти ничего подходящего: (

Несмотря на то, что я могу получать данные с такой скоростью в MySQL, он начинает немного ломиться, когда я пытаюсь консолидировать / удалить старые данные низкого уровня. Так что я думаю, что мне придется посмотреть на создание уровня агрегации поверх СУБД и переключиться на систему noSQL - и написать все самому: (

Answer 5

Мондриан требует, чтобы вы предоставили свои собственные базы данных;Мондриан плюс PostgreSQL, возможно, стоит попробовать.Конечно, вы можете удалить все, что захотите, с помощью своей собственной базы данных.

Answer 6

Я бы просто использовал стандартную базу данных .. Как SQL Server .. с Analysis Services наверху (если вы начинаете получать миллионы строк)

Answer 7

В icCube довольно просто получить измерение времени с различной гранулярностью во времени (для примера измерения "диапазон / полоса" вы можете посмотреть здесь ) , Затем кубы могут быть построены из файлов CSV. Его интерфейс XMLA позволяет вам затем использовать любой XMLA-совместимый инструмент отчетности. У вас есть оценка того, насколько большими будут ваши типичные наборы данных?