Разработка (рекурсивного) объекта журнала для системы регистрации событий - PullRequest
Новая
       9

Разработка (рекурсивного) объекта журнала для системы регистрации событий

1 голос
/ 17 января 2011

Я разрабатываю систему, которая должна хранить события. Каждое событие имеет три основных свойства:
1. метка времени (64 бита)
2. ключ (что это).
3. значение (фактическое значение для события).

Ключи событий обычно являются строками, значения событий - почти всегда числами.

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

NB. Для краткости оставим отметку времени. 

key: hits // might be per hour, might be in the last second, the key is application specific, its up to the user to figure out how often his application reports this event to us.
value: 12000
 // and here the drilldown starts.
 key: US
 value: 5000
  key: State1
   value: 2000
    key: City1
    value: 500
 key: UK
 value: 5000
  key: StateN
   value: 20
 // to an arbitrary level.

Итак, как вы можете видеть выше, значение фактически превращается в дерево. Можно было бы сказать, ну почему бы не хранить каждый к / в независимо и поддерживать «родительский ключ», это было бы неэффективно из-за увеличения записи (и, в конечном итоге, при поиске событий, чтение при загрузке). было бы гораздо эффективнее выписать их за одну операцию и прочитать весь объект за один раз.

Мне интересно, как лучше спроектировать это. Объекты - это, по сути, класс C ++ (хотя для обеспечения совместимости это на самом деле инфраструктура сериализации, а именно, буферные / управляющие протоколы).

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

Вы проектировали что-то подобное раньше? Мысли? Как вы думаете, как лучше всего это сделать?

Заранее спасибо.

P.S .: Ожидается несколько миллионов событий в день, и мы будем строить графики на основе данных.

Ответы [ 2 ]

0 голосов
/ 17 января 2011

Одна идея, которая приходит в голову, также дает вашим записям четвертое свойство: идентификатор записи родительского журнала. С помощью ORM, подобного ActiveRecord, вы можете сформировать естественное дерево. Например: 

class LogEntry < ActiveRecord::Base
    has_one :parent_log_entry
    has_many :log_entries
end

(Это, конечно, неправильно, но вы поймете).

Существуют различные реализации схемы ActiveRecord на разных языках, так что это не зависит от языка (и БД).

0 голосов
/ 17 января 2011

Можете ли вы расширить определение файла журнала, указав тег типа "группа" или "пакет"?

Например:

группа: ключ США: State1
значение: 7000
ключ: State2
значение: 65191

группа: Великобритания ...

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

...