Высокопроизводительная архитектура ведения журналов с использованием .NET и SQL Server. - PullRequest
Новая
       6

Высокопроизводительная архитектура ведения журналов с использованием .NET и SQL Server.

0 голосов
/ 10 февраля 2012

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

Существует два типа запросов: «известный» и «неизвестный», определяемый наличием файла cookie.

В конечном итоге я хочу получить журналы в следующей форме:

Для неизвестных:

  • Количество почасовых посещений сайта

Для известных:

  • количество почасовых посещений сайта
  • число посещений на пользователя
  • # время последнего посещения каждого пользователя

Чтобыли бы ваши рекомендации для хранения этого?

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

Тем не менее, каков наилучший способ «проанализировать» необработанные данные, не блокируя таблицу во время удаления данных;таким образом, блокирует запись?

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

1 Ответ

0 голосов
/ 10 февраля 2012

Во-первых: я читал, что вы ищете ответы на SQL. Однако лично я думаю, что это не будет решением, которое вы ищете.

Такие системы, как Hadoop с такими функциями, как Map / Reduce , специально предназначены для обработки этого случая данных. Есть различные сообщения в блоге, см., Например.

Анализ Hadoop и файла журнала или это Анализ журнала и создание отчетов об инцидентах с помощью Hadoop

Некоторые преимущества:

  • масштабирование Hadoop намного дешевле, чем с RDBMS
  • агрегация может быть распределена по многим машинам
  • Карта / уменьшение не нуждается в предопределенном структурировании. Таким образом, вы не будете обречены, если есть изменения требований

Если вы придерживаетесь базы данных SQL, то в какой-то момент вы будете работать с такими проблемами, как:

  • Горизонтальное масштабирование RDBM в большинстве случаев требует времени на агрегацию. В любом случае невозможно масштабировать по горизонтали.
  • Агрегации выполняются исключительно быстро с точки зрения производительности, если у вас четко определенная структура и агрегирование по одному или нескольким индексам
  • Вам необходимо преобразовать модель с помощью тяжелых операций при изменении структуры данных
...