pomoc w analizie
jerry - 28-08-2006 00:53
pomoc w analizie
Witam,
Stoję przed wyborem silnika DB (MySQL, PostgreSQL) dla aplikacji
zbierającej dane o dostepności hostów. Aplikacja pobiera z bazy liste
hostów, pinguje i zapisuje wyniki do bazy.
Szacując liczbę insertów dziennie można założyć:
- liczba hostów do badania: 10 000
- pingi co 10 min
co daje 1 440 000 nowych rekordow dziennie.
Najnowsze dane będą prezentowane via www, reszta dostępna przez
archiwum, lub wykorzystana przy generowaniu statystyk dostepności
poszczególnych hostów.
Zastanawiam się który serwer lepiej nadaje się dla takiej ilości danych.
Czy PostgreSQL ma tablice partycjonowane lub inne mechanizmy pozwalające
zarządzać dużą ilością danych?
JT - 06-09-2006 01:40
jerry wrote:
> Witam,
> Stoję przed wyborem silnika DB (MySQL, PostgreSQL) dla aplikacji
> zbierającej dane o dostepności hostów. Aplikacja pobiera z bazy liste
> hostów, pinguje i zapisuje wyniki do bazy.
> Szacując liczbę insertów dziennie można założyć:
> - liczba hostów do badania: 10 000
> - pingi co 10 min
> co daje 1 440 000 nowych rekordow dziennie.
Baza bazą, a zastanawiałeś się nad Obciążeniem serwera
pingującego? Tysiąc pingów na minutę?
A co do bazy - po pierwsze: musisz trzymać rekordy z dni poprzednich?
Może wystarczy przetworzyć je na raport zbiorczy i usunąć rekordy z
bazy? Po drugie: może uda CI się skompatować dane - czemu każdy
ping ma oznaczać jeden insert? Może jakoś zbiorowo - jeden rekord
przechowujący wyniki pingowania z godziny, doby itp.? Przy odpowiednim
upakowaniu (binarnym) danych nie powinno być dużo.
I na koniec - pewnie masz świadomość, że część sprawdzanych
hostów nie bedzie odpowiadać na pingi, bo będą np. zablokowane na
routerze.
--
JT
jerry - 06-09-2006 01:40
> Baza bazą, a zastanawiałeś się nad Obciążeniem serwera
> pingującego? Tysiąc pingów na minutę?
Tak, analizuję ten problem na poziomie aplikacji (współbieżność). Tysiąc
pingów na minutę to teoretyczna wartość brzegowa. Widzę tu niemniej
poważne wąskie gardło rozwiązania.
> A co do bazy - po pierwsze: musisz trzymać rekordy z dni poprzednich?
Muszę być przygotowany na to, że ktoś zarzyczy sobie raport postaci:
dostępność hosta o danym IP w minionym
roku/miesiącu/tygodniu/dniu/godzinie jeszcze nie ustalone w jakiej
postaci ale w każdym razie muszę trzymać dane archiwalne.
> Może wystarczy przetworzyć je na raport zbiorczy i usunąć rekordy z
> bazy?
Taką opcję także biorę pod uwagę.
Po drugie: może uda CI się skompatować dane - czemu każdy
> ping ma oznaczać jeden insert?
Pierwsze rozwiązanie jest bardzo proste ale nieefektowne: jest tabela
przechowująca listę hostów do odpytania oraz tabela z wynikami
przechowująca klucz do hostów oraz datę badania (ping) i czas odpowiedzi
(null = host niedostępny). Jednak dane będą tutaj rosły w trudnym do
zarządzania tempie. Stąd też prośba o pomoc w analizie ;-)
Pozdrawiam,
kubik - 08-09-2006 01:53
Jakiego rodzaju dane zapisujesz do bazy? Czy zapisujesz tylko fakt iż
host odpowiedział, czy też zapisujesz także czas odpowiedzi? Bo
jeżeli to pierwsze, to wystarczy zapisywać pingi, na które host nie
odpowiedział - co znacznie ograniczy liczby składowanych informacji.
--
pozdrawiam
Adam Kubiczek
http://kubiczek.net/
JT - 08-09-2006 01:54
jerry wrote:
> Tak, analizuję ten problem na poziomie aplikacji (współbieżność). Tysiąc
> pingów na minutę to teoretyczna wartość brzegowa. Widzę tu niemniej
> poważne wąskie gardło rozwiązania.
Może masz możliwość pracy rozproszonej?
> Muszę być przygotowany na to, że ktoś zarzyczy sobie raport postaci:
> dostępność hosta o danym IP w minionym
> roku/miesiącu/tygodniu/dniu/godzinie jeszcze nie ustalone w jakiej
> postaci ale w każdym razie muszę trzymać dane archiwalne.
Raczej pomyśl o archiwizacji zewnętrznej, bo danych całorocznych
raczej nie przechowasz, chyba że nie płacisz za hostingowe megajbaty
:D
Policzmy: wyliczyłeś 1 440 000 pingów dziennie. Niech każdy rekord
zajmuje (klucz do hosta, dataczas, wynik w ms) 16 bitów + 14 bitów +
12 bitów, zaokrąglając do ósemek to wyjdzie 6 bajtów. Z jednego
dnia zbierze się zatem nieco ponad 8 MB danych. Czyli rocznie prawie 3
GB! Do przełknięcia? Jeśli tak - to nie ma problemu.
> > Może wystarczy przetworzyć je na raport zbiorczy i usunąć rekordy z
> > bazy?
> Taką opcję także biorę pod uwagę.
Ustal, z kim tam to ustalasz, jak ma wyglądać raport roczny,
miesięczny, tygodniowy, dzienny. Może uda się zrobić coś
podobnego, jak robią programy do statystyk WWW - po opracowaniu danych
miesięcznych w formie raportu, logi z tego miesiąca można usunąć,
nie tracąc samego raportu.
> Pierwsze rozwiązanie jest bardzo proste ale nieefektowne: jest tabela
> przechowująca listę hostów do odpytania oraz tabela z wynikami
> przechowująca klucz do hostów oraz datę badania (ping) i czas odpowiedzi
> (null = host niedostępny). Jednak dane będą tutaj rosły w trudnym do
> zarządzania tempie. Stąd też prośba o pomoc w analizie ;-)
Jakim sprzętem, jaką bazą dysponujesz?
Dopuszczasz inny model bazy, niż opisałeś? Można np. tworzyć
tabele dzienne, co ułatwia poruszanie się po bazie narzędziami
ogólnymi (chyba, że napiszesz do tego jakąś specjalną aplikację).
Zebrać wyniki - to jedno, a móc je potem łatwo odczytywać i
interpretować - to drugie.
Gdybym ja się miał zabrać za projektowanie bazy do tego zadania,
raczej kombinowałbym z tabelami dziennymi i uwolnił się od
daty/czasu w każdym rekordzie. Wiersz w tabeli składałby się
wyłącznie z klucza do hosta oraz 144 kolumn (lub jednej kolumny z
wierszem 144-elementowym), gdzie numer kolumny/elementu określałby
kolejną "dziesięciominutówkę". Oczywiście traci się wtedy
informację o dokładnej minucie i sekundach, pytanie jednak, czy taka
informacja jest istotna?
A zysk jaki! Codziennie pojawiałaby się nowa tabela (z datą w
nazwie!) o objętości około 10 000 hostów x (16 bitów klucz + 144 x
16 bitów ping) = około 2,8 MB. Czyli 66% zysku :)
Dalej można by "upychać" zapisując czas odpowiedzi nie na pełnych
16 bitach (bo i po co? Wystarczy pewnie ze 12!). Trochę gimnastyki z
operacjami bitowymi :))
Tylko podrzucam Ci koncepcję, wybór rozwiązania i ta nalezy do
Ciebie :)
Powodzenia!
JT
jerry - 08-09-2006 01:55
> Jakiego rodzaju dane zapisujesz do bazy? Czy zapisujesz tylko fakt iż
> host odpowiedział, czy też zapisujesz także czas odpowiedzi? Bo
> jeżeli to pierwsze, to wystarczy zapisywać pingi, na które host nie
> odpowiedział - co znacznie ograniczy liczby składowanych informacji.
Wciąż trwa analiza. Jeżeli raporty miałyby dotyczyć jedynie
awarii(generalnie braku odpowiedzi na ping) serwera w danym okresie
rzeczywiście informacja o odpowiedzi wystarczyłyby. Jeżeli jednak
potrzebne będą także czasy odpowiedzi sytuacja się komplikuje.
jerry - 08-09-2006 01:55
> Może masz możliwość pracy rozproszonej?
Nie takie rozwiązanie nie jest brane pod uwagę.
> Ustal, z kim tam to ustalasz, jak ma wyglądać raport roczny,
> miesięczny, tygodniowy, dzienny. Może uda się zrobić coś
> podobnego, jak robią programy do statystyk WWW - po opracowaniu danych
> miesięcznych w formie raportu, logi z tego miesiąca można usunąć,
> nie tracąc samego raportu.
To rzeczywiście jak na razie najlepsza koncepcja. Raporty można
składować także w tabelach ale już w postaci przetworzonej - gotowej do
wyświetlenia.
> Dopuszczasz inny model bazy, niż opisałeś?
Oczywiście, to na razie wstępny etap analizy.
> Można np. tworzyć
> tabele dzienne, [....]
Dokładnie przeanalizuję tą koncepcję.
> Tylko podrzucam Ci koncepcję, wybór rozwiązania i ta nalezy do
> Ciebie :)
Dziękuję za poświęcony czas i cenne przemyślenia!
Pozdrawiam,
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Jak =?ISO-8859-2?Q?zamieni=E6_dwa_pola_jednej_kolumny_?==?ISO-8859-2?Q?w_dw=F3ch_rekordach_za_pomoc=B1_jednego_zapyt? ==?ISO-8859-2?Q?ania=3F?=
Import za =?ISO-8859-2?Q?pomoc=B1_EMS_Data_Import_for_?==?ISO-8859-2?Q?MySQL_-_polskie_litery=2E?=
=?iso-8859-2?q?Przentacja,_probelm=2E_Prosz=EA_o_pomoc=2E?=
=?iso-8859-2?q?Panie_i_Panowie-prosz=EA_o_pomoc_ze_skanerem=2E_ARCUS_II=2ECUDA?=
=?iso-8859-2?q?[apache]_restart_za_pomoc=B1_cron'a_i_too_many_open_files? =
btrieve 6.15; geo-info2000; mala wydajnosc sieci - prosba o pomoc
[MSSQL] Wykonanie DTS za =?ISO-8859-2?Q?pomoc=B1_triggera?=
[Oracle] =?ISO-8859-2?Q?Pro=B6ba_o_pomoc_przy_zapytaniu?=
=?ISO-8859-2?Q?pro=B6ba_o_pomoc_w_wyborze_sprz=EAtu?=
[Prosba o pomoc, Crosspost] Stary monitor+ stara karta grafiki
zanotowane.pldoc.pisz.plpdf.pisz.plmelooonka.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
