Для более быстрой отчетности и анализа производительности мы хотим вставить логи нашего веб-сервера в Sql Server. Это позволит нам видеть модели трафика, проблемы, замедления почти в режиме реального времени.
У нас есть демон, который прослушивает события запроса / ответа от нашего балансировщика нагрузки и массовых вставок в базу данных.
Тем не менее, мы получаем около 1 ГБ журналов в день, и нам нужно только около недели (по крайней мере, в этом виде).
Каков наилучший способ сохранить эти данные и лучший способ удалить старые записи?
Мы говорили о том, чтобы хранить данные каждого дня в отдельной таблице, например Log_2011_04_07, иметь все записи за этот день, а затем отбрасывать самую старую таблицу. Можно было бы создать представление, охватывающее все дневные таблицы, для удобства запросов. Возможно ли это?
источник
Ответы:
Вы должны посмотреть на разделение.
http://technet.microsoft.com/en-us/library/dd578580%28SQL.100%29.aspx
Крутая вещь в разделении состоит в том, что у вас есть только одно имя таблицы (в отличие от подхода с несколькими таблицами), поэтому ваши операторы вставки остаются статичными. Он работает с каждым приложением - он полностью прозрачен для запросов. Вам не нужно беспокоиться о том, что произойдет, если вы получите разные индексы или статистику по каждой из таблиц.
Вы создаете функцию разделения, которая решает, как разбить таблицу на несколько таблиц за сценой. Функция может принимать только один входной параметр / поле, и в вашем случае это будет поле даты. Функция может разбить таблицу по дате, неделе, месяцу или году - в вашем случае вам понадобится дата, 24-часовой период.
Затем создайте задание агента SQL Server, которое использует T-SQL для замены последнего раздела каждый день. Удаление становится операцией метаданных, и это происходит очень быстро. Поменяйте местами раздел, затем выкиньте старый.
источник
6 лет назад мы разработали продукт для веб-статистики, который позволяет нам отслеживать каждый клик посетителя.
То, что мы сделали, - регистрировали каждый визит, как вы писали, и чтобы запланированный демон анализировал журналы и нормализовал данные для дальнейшего поиска позже. Как только данные / запись были проанализированы, они были удалены, чтобы сохранить структуру данных низкой.
Для нашей следующей версии продукта мы будем раздельно собирать массовые коллекторы на веб-сайтах, а затем использовать демон для сбора данных и последующей очистки, выполняя команды для массовых сервисов.
Таким образом, мы можем обрабатывать «плановое обслуживание» без потери данных.
Что касается проблемы очистки на центральном сервере, наш текущий план состоит в том, чтобы добавить «временные метки», чтобы иметь возможность архивировать данные, например, после. 3 месяца.
Мы думали, что это так же, как текстуры MIP-MAP в 3D играх / рендеринге. Чем ближе вы подходите, тем более подробные данные, чем дальше, тем более «сгруппированы» и менее детализированы.
Таким образом, изо дня в день мы можем наблюдать шаблоны посетителей, но через 3 месяца эти данные уже не актуальны, и мы сжимаем данные в меньшее количество деталей.
Мы не решили, будем ли мы разбивать базу данных на куски, чтобы сохранить разделенный на «уровне детализации» pr. база данных. Но мы можем это сделать, поскольку есть некоторые проблемы с именами, если мы храним разные уровни в одной базе данных.
Надеюсь, вы можете использовать это для чего-то? Я не могу предоставить вам пример кода, как его часть продукта нашей компании.
источник
Создайте еще одну таблицу Daily_tables с двумя столбцами: Table_name и Date_table_created. В коде, который создает новую ежедневную таблицу (которая загружает веб-журналы), добавьте еще одну запись, чтобы заполнить таблицу Daily_tables именем созданной таблицы и отметкой времени (текущая дата и время). Создайте задание агента SQL, которое будет запускать скрипт TSQL каждую неделю. TSQL должен удалить все имена таблиц (Table_name) из Daily_tables с отметкой времени Date_table_created, которая старше 7 дней.
Надеюсь, это то, что вы искали :)
источник