Jak przechowywać „n” dni dzienników serwera WWW w Sql Server?

Aby przyspieszyć raportowanie i analizę wydajności, chcemy wstawić logi naszego serwera WWW do Sql Server. Pozwoli nam to zobaczyć wzorce ruchu, problemy, spowolnienia w czasie zbliżonym do rzeczywistego.

Mamy demona, który nasłuchuje zdarzeń żądania / odpowiedzi z naszego modułu równoważenia obciążenia i masowych wstawek do bazy danych.

Dostajemy jednak około 1 GB dzienników i potrzebujemy tylko około tygodnia (przynajmniej w tej surowej formie).

Jaki jest najlepszy sposób przechowywania tych danych i najlepszy sposób usuwania starych wpisów?

Mówiliśmy o przechowywaniu danych każdego dnia we własnej tabeli, np. Log_2011_04_07Zawierałby wszystkie wpisy z tego dnia, a następnie upuszczał najstarszą tabelę. Można utworzyć widok obejmujący wszystkie dzienne tabele w celu łatwego tworzenia zapytań. Czy to możliwe?

Powinieneś zajrzeć do partycjonowania.

http://technet.microsoft.com/en-us/library/dd578580%28SQL.100%29.aspx

Fajną rzeczą w partycjonowaniu jest to, że masz tylko jedną nazwę tabeli (w przeciwieństwie do podejścia z wieloma tabelami), więc instrukcje wstawiania pozostają statyczne. Działa z każdą aplikacją - jest całkowicie przejrzysty dla zapytań. Nie musisz się też martwić, co się stanie, jeśli skończysz z różnymi indeksami lub statystykami w każdej z tabel.

Tworzysz funkcję partycji, która decyduje o sposobie podziału tabeli na wiele tabel za sceną. Funkcja może przyjąć tylko jeden parametr wejściowy / pole, aw twoim przypadku będzie to pole daty. Ta funkcja może podzielić tabelę według daty, tygodnia, miesiąca lub roku - w Twoim przypadku chcesz mieć datę 24-godzinną.

Następnie zbuduj zadanie agenta SQL Server, które używa T-SQL do codziennej wymiany ostatniej partycji. Usunięcie staje się operacją metadanych i błyskawicznie się rozwija. Zamień partycję, a następnie usuń starą.

6 lat temu opracowaliśmy webstatystyczny produkt do rejestrowania, który pozwala nam śledzić każde kliknięcie wizyty użytkownika.

To, co zrobiliśmy, polegało na rejestrowaniu każdej wizyty podczas pisania, a zaplanowany demon analizuje dzienniki i normalizuje dane do późniejszego wyszukiwania. Natychmiast po przeanalizowaniu danych / rekordu został on usunięty, aby utrzymać niską strukturę danych.

W przypadku naszej następnej wersji produktu będziemy dystrybuować kolektory zbiorcze osobno na stronach internetowych, a następnie używać demona do gromadzenia danych, a następnie czyszczenia po wydaniu poleceń dla usługi masowej.

W ten sposób możemy obsłużyć „planową konserwację” bez utraty danych.

Jeśli chodzi o problem z czyszczeniem na serwerze centralnym, naszym obecnym planem jest dodanie „znaczników czasu”, aby móc archiwizować dane po np. 3 miesiące.

Myśleliśmy o tym podobnie jak tekstury MIP-MAP w grach / renderowaniu 3D. Im bardziej się zbliżasz, tym bardziej szczegółowe dane, im dalej, tym bardziej „zgrupowane” i mniej szczegółowe.

Tak więc z dnia na dzień możemy obserwować wzorce odwiedzających, ale po 3 miesiącach dane te nie są tak naprawdę istotne i kompresujemy je do mniej szczegółowych szczegółów.

Nie zdecydowaliśmy, czy podzielimy bazę danych na części, aby zachować oddzielny pr. Baza danych. Ale możemy po prostu, ponieważ istnieją pewne problemy z nazewnictwem, jeśli przechowujemy różne poziomy w tej samej bazie danych.

Mam nadzieję, że możesz użyć tego do czegoś? Nie mogę podać przykładowego kodu jako części produktu naszej firmy.

Utwórz kolejną tabelę Daily_tables z dwoma kolumnami: Table_name i Date_table_created. W kodzie, który tworzy nową tabelę dzienną (ładującą dzienniki sieciowe), dodaj kolejny wpis, aby zapełnić tabelę Daily_tables nazwą utworzonej tabeli i datownikiem (bieżąca data i godzina). Utwórz zadanie agenta SQL, które będzie uruchamiało skrypt TSQL co tydzień. TSQL powinien usunąć wszystkie nazwy tabel (nazwa_tabeli) z tabel_tabeli z datownikiem utworzonym przez tabelę_tabeli, która jest starsza niż 7 dni.

Mam nadzieję, że tego właśnie szukałeś :)