Альтернативные базы данных для использования при помещении журналов IIS в базу данных с использованием LogParser

Question

Мы запустили несколько сценариев, которые используют LogParser для выгрузки наших журналов IIS в базу данных SQL Server.

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

Реализовав это только для одной системы, и за последние 2-3 недели у нас уже есть база данных объемом 5 ГБ с примерно 10 миллионами записей.

Это делает любые запросы к этой базе данных довольно медленными и, несомненно, вызовет проблемы с хранилищем, если мы продолжим регистрировать, как мы.

Может кто-нибудь предложить какие-либо альтернативные базы данных, которые мы могли бы использовать для этих данных, которыебыло бы более эффективно для таких журналов?Я бы особенно заинтересовался любым опытом использования Google BigTable или Amazon SimbleDB.

Подходит ли какой-либо из них для представления запросов?COUNTs, GROUP BYS, PIVOTs?

Answer 1

Я тоже сталкивался с подобной проблемой раньше. Так как файл журнала рос настолько быстро, я начал думать, подходит ли это для использования базы данных для журнала IIS. Есть два момента, о которых вам следует подумать:

1. В большинстве случаев мы IIS журнал не может предоставить полезную информацию напрямую, нам нужно проанализировать ее для получения статистической информации.
2. Кроме того, в большинстве случаев журналы IIS не обязательно должны быть готовы в базе данных для запроса.

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

Answer 2

Я бы посмотрел на ваши индексы. 10М рядов действительно не так уж много. Если вы используете SQL Server '05 или '08, вы можете выполнить запрос с помощью «Показать фактический план выполнения», и он предложит, какие индексы вы должны создать, чтобы увеличить скорость этого запроса.

Еще одна вещь, с которой я столкнулся в производительности запроса KILLS, - использование неверного типа данных. Например, если вы указали дату и время в виде строки и вам нужно выполнить CONVERT в своем запросе. Вы также можете получить кофе или ужин в этот момент (кстати, это было значение по умолчанию для входа в систему счетчика производительности БД в Windows).

Также в зависимости от того, в какой версии (Разработка, Предприятие, Стандарт) вы можете реализовать разбиение. Таким образом, разделите по дате, а затем, когда вы получите данные за определенный период времени, вы будете запрашивать только соответствующие данные. Я считаю, что версия SQL-сервера для разработчиков имеет все корпоративные функции, если вы хотите поиграть с разделами. MySQL также позволяет создавать разделы, мы запускаем базу данных 150 ГБ с USB-накопителя. Это разделено по дате (день, я верю), и мы обычно запрашиваем только на прошлой неделе. Его расплывчатый раскол.

Отказ от ответственности: я не администратор баз данных, но это то, что мы сделали и, похоже, работают хорошо.

Answer 3

Я думаю, что стоимость хранения будет вашей самой большой проблемой. Даже если вы идете по облачному маршруту, я сомневаюсь, что вы сможете управлять затратами на такой объем данных. Мое предложение состояло бы в том, чтобы переместить данные в ультра-дешевое хранилище и развернуть решение, которое может эффективно работать с этими данными.

Например, вы можете переместить файлы журналов с вашего сервера (серверов) на локальный компьютер с огромным жестким диском (и подходящим решением для резервного копирования), а затем запустить инструменты локально, которые могут анализировать данные. Анализатор журнала эффективен, если вы можете работать с небольшим подмножеством этих данных. Вы можете запустить базу данных локально, но даже оптимизированные запросы могут выполняться медленно.

Вы можете приобрести инструмент анализа журналов, например WebLog Expert , для работы с этими файлами.

Answer 4

Как часто вы обновляли свои индексы?Какого рода запросы к данным вы выполняете?

Возможно, вы можете выполнять обычную сортировку данных в конце каждого дня, чтобы ускорить другие запросы?(создайте новые таблицы с этой сопоставленной информацией)

Как таблица посещений страницы может иметь запись для каждого дня о том, сколько раз была достигнута эта страница - таким образом, вам не нужно выполнять полное сканирование таблицыпри каждом запросе вы просто нажимаете на таблицу посещений.

В уникальной таблице хостов могут быть записи о времени ожидания, сколько страниц они просмотрели, количество загруженных файлов, общая пропускная способность, отказ от сеанса, уникальные файлы cookie (разные пользователи, возможно, за прокси-серверами или межсетевыми экранами).

Какой график очистки вы планируете, если таковой имеется?

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

Это все, что вам нужно построить с хранилищем значений ключей (например, simpledb или bigtable).