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

Question

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

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

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

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

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

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

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

(наш проект написан на Java и Python)

Answer 1

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

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

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

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

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

Answer 2

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

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

CouchDB имеет клиентские библиотеки для Java и Python, но в конце концов это просто RESTful HTTP API, так что любая библиотека HTTP должны сделать трюк так же хорошо.

Answer 3

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