Як зберігати "n" днів журналів веб-сервера на сервері Sql?

Для більш швидкого звітування та аналізу ефективності ми хочемо вставити наші журнали веб-сервера в сервер Sql. Це дозволить нам побачити закономірності, проблеми, уповільнення руху, майже в режимі реального часу.

У нас є демон, який слухає події запиту / відповіді з нашого балансира навантажень і масових вставок у базу даних.

Однак ми отримуємо близько 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 з двома стовпцями: ім'я таблиці та дата_сторінки_створені. У свій код, який створює нову щоденну таблицю (що завантажує веб-журнали), додайте інший запис, щоб заповнити таблицю Daily_tables іменем створеної таблиці та часовою міткою (поточний час дати). Створіть роботу агента SQL, який запускатиме скрипт TSQL щотижня. TSQL повинен видалити всі назви таблиць (Таблиця_мення) з Daily_tables з часовою позначкою Date_table_create, яка старше 7 днів.

Сподіваюся, це те, що ви шукали :)