Post
#1
|
|
|
Administrator serwera Grupa: Przyjaciele php.pl Postów: 909 Pomógł: 0 Dołączył: 12.08.2003 Skąd: /var/www/wroclaw.php Ostrzeżenie: (0%)
|
Dla testów przeniosłem logi serwera Apache do MySQLa...
Niestety zaskoczyła mnie jedna rzecz... Log od 29 marca, g. 02:53 do 31 marca do godziny 23:59 urusł do 42 294 rekordów (6.9 MB) Log dla kwietnia już liczy ponad 70 tys. rekordów... Jak zrobić by zapytania do bazy danych nie trwały po pare (naście) sec. ? Przykładowe zapytanie do bazy [sql:1:627e450951]SELECT `useragent` , count(*) AS count FROM `log_042004` GROUP BY `useragent` ORDER BY count DESC LIMIT 10;[/sql:1:627e450951] Nie wiedziałem jak inaczej zobrazować strukturę bazy, więc wrzucam wam kod ją tworzący... [sql:1:627e450951]CREATE TABLE `log_032004` ( `id` int(11) NOT NULL auto_increment, `d` char(2) default NULL, `H` char(2) default NULL, `i` char(2) default NULL, `s` char(2) default NULL, `method` char(3) NOT NULL default '', `url` text NOT NULL, `query` text NOT NULL, `referer` text NOT NULL, `rhip` varchar(15) NOT NULL default '', `useragent` varchar(255) NOT NULL default '', `https` char(2) NOT NULL default '', PRIMARY KEY (`id`) ) TYPE=MyISAM AUTO_INCREMENT=42301;[/sql:1:627e450951] Już zrobiłem, by każdy miesiąc był zapisywany do kolejnej tabeli, ale perspektywa zbierania 11500 kolejnych rekordów statystyk nie rysuje się kolorowo... Jak zoptymalizować tą bazę i/lub zapytania by to chodziło szybciej (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) |
|
|
|
![]() |
Post
#2
|
|
|
Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław |
1. dlaczego data w 4 polach, zamiast w 1? Pola date, lub timestamp zajmują około 3 bajtów. Tak - jest tego kilka razy więcej. ( o ile dobrze zrozumiałem znaczenie kolumn d, i , h, s)
2. jeśli potrzebujesz tylko liczbę różnych przegądarek w danym dniu, godzinie itp, zrobiłbym to nieco inaczej. Podzieliłbym te informacje na 2 tabele. W 1 przechowywałbym wszystkie informacje o tym skąd, jaki adres, przeglądarka itp. było. Z uwagi na to, że są to dane w miarę często powtażające - nie ma sensu zapisywać ich tysiące razy. Tak więc - można tylko sprawdzić, czy taka kombinacja jeszcze się nie pojawiła - jeśli już jest - wystarczy w 2 tabeli zwiększyć jakiś licznik dla tego typu wpisu, albo nawet datę zdażenia i id tego typu wpisu. 3. nie widzę sensu by generować kolejne tabele dla takich danych. MySQL bardzo dobrze radzi sobie z tabelami któe mają nawet mln rekordów, więc jeśli będą dobrze przygotowane indexy (np. koniecznie po dacie) to powinno to chodzić dobrze nawet przy bardzo dużych ilościach danych i sporym ruchu. |
|
|
|
Bakus Optymalizacja bazy danych [nie chodzi OPTIMIZE] 11.04.2004, 01:54:39
Dravo tworzenie indexow dla najbardziej uzywanych koloum... 11.04.2004, 08:37:18
Bakus Pomysł z kolejnymi tabelami przyszedł po zobaczeni... 11.04.2004, 15:34:47
DeyV no ale ja nie widzę problemu.
Przeciez w ten spos... 11.04.2004, 15:42:17 ![]() ![]() |
|
Aktualny czas: 26.12.2025 - 22:51 |