регистрация/статистика временных рядов — масштабируемое решение

Довольно обычно запрашивать базу данных или файлы журналов для получения информации о времени безотказной работы или количестве запросов за заданный интервал времени.

По мере того, как вы собираете все больше и больше данных, SQL-запросы или сканирование журналов становятся все медленнее и медленнее (представьте, что 10 миллионов строк таблицы / строк журнала).

Типичные вопросы:

  • Сколько задач мы обработали за последние x месяцев?
  • Какова была доступность нашего сервиса за последний X период времени?
  • Среднее количество запросов за последний час выше, чем в среднем за последний 1 день?

Я хотел бы использовать некоторое хранилище ключ-значение: много сегментов с разным автоматическим истечением срока действия, чтобы мы могли изучить, например. 10 мин/1 час/1 день ведра и суммировать там все элементы и с гордостью сказать: «За последние 10 минут мы обработали 10 ^ 6 запросов».

Я уверен, что MongoDB или Redis предлагают истечение времени в ведрах — я просто немного беспокоюсь о том, будет ли реализация простой.

Как бы вы решили это? Знаете ли вы лучшие инструменты для этой задачи?

(наш проект написан на java и python)


java nosql mongodb key-value scalability
person Martin V.    schedule 23.05.2013    source источник
comment
Моя первая мысль заключалась в том, чтобы использовать AOP для сбора данных KPI, которые вы хотите, но с использованием python, я думаю, это не сработает. Некоторые мои клиенты используют Zabbix (zabbix.com) для сбора KPI Mysql и веб-сервера.   -  person Scary Wombat    schedule 23.05.2013

Ответы (3)


arrow_upward
0
arrow_downward

Я бы предложил другой концептуальный подход...

Предположим, у вас есть таблица журнала, в которой регистрируется запрос. Вот как я решил бы проблему сообщения данных журнала:

  1. Начните сохранять данные журнала в таблице.
  2. Как только таблица журнала достигает 1 миллиона записей, вы отправляете всю таблицу в хранилище данных. По сути, «архивация» данных, чтобы более медленные запросы могли попасть на них позже.
  3. Сделайте агрегированный снимок только что заархивированных данных в автономном режиме. Запустите задание, которое получает числа, которые вы ищете.
  4. Напишите код для объединения запросов в реальном времени и, при необходимости, архивных запросов.

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

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

person ryan1234    schedule 28.05.2013

arrow_upward
0
arrow_downward

CouchDB вторичные индексы/представления раскрывают ваши данные в O(log n) time, и их легко реализовать и взаимодействовать с ними, поскольку все это находится за RESTful HTTP API. Проверьте это:

  • Один вторичный индекс индексирует ваши события журнала по времени их создания и уменьшает их количество, используя встроенную функцию _count reduce.
  • Другой вторичный индекс может индексировать только события журнала, указывающие время простоя, или время безотказной работы, или 500 секунд, или единорогов. Суть в том, что все они похожи на трехстрочные функции, которые выполняются логарифмически.
  • По запросам с startkey=[timestamp for X days ago] можно считать только записи лога с этого момента.
  • Выполняя запрос с помощью reduce=false, вы можете вернуть сами записи журнала с ключами по дате создания.
  • Используйте другие встроенные функции сокращения, такие как _stats, чтобы получить статистику о ваших журналах.

В CouchDB есть клиентские библиотеки для Java и Python, но, в конце концов, это всего лишь RESTful HTTP API, поэтому любая HTTP-библиотека должна справляться с этой задачей.

person garbados    schedule 30.05.2013

arrow_upward
0
arrow_downward

Вы можете использовать RDDTool для этого. http://oss.oetiker.ch/rrdtool/ IT — очень полезная библиотека для регистрации времени. ряд данных и создавать графики с ними.

person qgicup    schedule 15.06.2013