Дизайн для простой базы данных для потока событий - PullRequest
Новая
       16

Дизайн для простой базы данных для потока событий

2 голосов
/ 12 января 2010

Для личного проекта я хочу записать поток несвязанных событий, чтобы потом собрать простую статистику. Каждое событие может иметь [дико] разные данные, связанные с ним.

Я ищу несколько советов о том, как это структурировать. Поскольку это небольшой проект, мои главные цели:

  • Простота настройки
  • Простота использования (то есть без странных объединений)

Производительность не критична, и я буду единственным пользователем.

Чтобы дать вам представление о том, к чему я стремлюсь, вот мой текущий план:

Таблица: Определения событий

Колонки:

  • ID
  • Имя
  • Тип
  • Опции

Таблица: События

Колонки:

  • ID
  • Definition_ID
  • Option_Values ​​
  • Примечания

Допустим, у нас есть два определения событий, например:

ID: 0; Имя: Pigeon_Released; Тип: Время; Опции: ноль

ID: 1; Имя: Fed_Pigeon; Тип: Fixed_List; Опции: хлеб, крекеры, тофу

Затем мы регистрируем некоторые события:

ID: 0; Definition_ID: 1; Option_Values: хлеб; Примечания: ноль

ID: 1; Definition_ID: 1; Option_Values: тофу; Примечания: «он ворчал»

ID: 2; Definition_ID: 0; Option_Values: 12:34:56; Примечания: «Я тоже ворковал»

Значения параметров будут принудительно введены в программу.

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

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

Ответы [ 4 ]

2 голосов
/ 12 января 2010

Фактически, у вас есть «большой двоичный объект» данных, который в принципе может содержать что угодно, а затем определение схемы, чтобы сказать, как следует интерпретировать большой двоичный объект 

it's a date

или 

it's one of these values

Это вполне разумно для личного проекта.Недостатком подхода «blob» является то, что при выполнении запросов может быть что-то вроде несоответствия импеданса.Если вам нужно работать с содержимым большого двоичного объекта, это будет немного громоздко.

Еще один комментарий: ваша таблица определений может стать ограничительной, вы хотите поместить в свой BLOB-объект более сложные структурированные данные.

Интересно, поможет ли использование XML в качестве вашего блоба?Затем схемы XML определяют содержимое BLOB-объектов, возможно, вам вообще не нужна таблица определения событий.Есть ли в вашей базе данных (как некоторые) возможности XML, которые вы могли бы использовать?

1 голос
/ 13 января 2010

Я попробовал небольшой проект с rulecore, чтобы разработать систему, немного похожую на вашу. Я использовал базу данных mysql для хранения потока событий, а затем отправил их в пакетном режиме на rulecore, где я создал около 20 правил. Формат события rulecore очень прост с именованными свойствами, которые могут содержать что угодно. Я сделал это тоже, так как моя первая попытка с SQL-запросами привела к сложной схеме и очень длинным и трудным для понимания запросам. Правила правил правил были намного проще.

1 голос
/ 12 января 2010

Большинство событийных приложений используют XML для определения событийных объектов. Хотя у многих есть SQL-подобный язык, они не используют базовые СУБД. Вы можете проверить Марко из ruleCore , который прошел через все упражнения по разработке своего собственного приложения CEP и написал об этом в блоге.

Даже потоковые движки, такие как StreamBase и Coral8 требуют схемы для потоков событий во время разработки, поэтому даже они могут не соответствует вашему требованию для "wildly different data".

Итак, в конце вам может понадобиться что-то вроде: 

<event>
    <head>
        <id>12784536</id>
        <type_id>51</type_id>
        <time_stamp>2008-12-11T13:25:57.014Z</time_stamp>
        <source_id>862</source_id>
    </head>
    <body>
        <!-- Event specific data here -->
    </body>
</event>
1 голос
/ 12 января 2010

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

Попробуйте вместо этого использовать Очередь сообщений .

Хорошо, если вам нужно хранить и сравнивать события, это другое. Когда я слышу «событие», я предполагаю, что это просто для уведомления в режиме реального времени. Поэтому мое предложение об очереди сообщений может быть неуместным в этом случае.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...