Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.lang.php > #15300 > unrolled thread

zawijanie logów

Started byniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
First post2017-01-19 18:18 +0100
Last post2017-01-22 09:27 -0800
Articles 17 — 8 participants

Back to article view | Back to pl.comp.lang.php


Contents

  zawijanie logów niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-01-19 18:18 +0100
    Re: zawijanie logów niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-01-19 18:20 +0100
    Re: zawijanie logów "Stokrotka" <ortografia.nowa@gazeta.pl> - 2017-01-19 18:37 +0100
      Re: zawijanie logów niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-01-19 19:02 +0100
      Re: zawijanie logów "Darek" <darekpn2@wp.pl> - 2017-01-19 20:15 +0100
    Re: zawijanie logów Adam <a.g@poczta.onet.pl> - 2017-01-19 22:24 +0100
      Re: zawijanie logów niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-01-20 17:17 +0100
        Re: zawijanie logów Rafal Podsiadly <spinacz24@gmail.com> - 2017-01-20 23:30 -0800
          Re: zawijanie logów Borys Pogoreło <borys@pl.edu.leszno> - 2017-01-21 11:29 +0100
            Re: zawijanie logów Rafal Podsiadly <spinacz24@gmail.com> - 2017-01-21 04:13 -0800
              Re: zawijanie logów w systemie siła 'PO/EU <NOSPAMtestowanije@go2.pl> - 2017-01-21 16:05 +0100
              Re: zawijanie logów Roman Tyczka <noemail@because.no> - 2017-01-21 23:47 +0100
                Re: zawijanie logów Borys Pogoreło <borys@pl.edu.leszno> - 2017-01-22 21:34 +0100
              Re: zawijanie logów Borys Pogoreło <borys@pl.edu.leszno> - 2017-01-22 21:34 +0100
        Re: zawijanie logów "Darek" <darekpn2@wp.pl> - 2017-01-21 19:17 +0100
          Re: zawijanie logów w systemie siła 'PO/EU <NOSPAMtestowanije@go2.pl> - 2017-01-21 19:21 +0100
    Re: zawijanie logów Rafal Podsiadly <spinacz24@gmail.com> - 2017-01-22 09:27 -0800

#15300 — zawijanie logów

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-19 18:18 +0100
Subjectzawijanie logów
Message-ID<o5qse2$jes$1@node2.news.atman.pl>
jeśli dla uproszczenia przyjąć, że do bazy logujemy wszystkie wejścia na 
stronę to jak zrobić najlepiej zawijanie?

czyli jak kasować najstarsze wpisy zostawiając N ostatnich?

nie żebym z gębą na pączki...

mój pomysł jest taki:

ilczę conutem ilość wpisów

sprawdzam czy kwalifikują się do kasowania

odczcytuję 100 najstarszych wpisów poprzez select z sortowniem po dacie

wyszukuję w nich największy ID

kasuję wszystkie wpisy i id<ID...

co Panowie na to? ogólnie to ja nawet nie jestem programistą, nie 
dopuścili mnie na politechnice warszawskiej, więc jakby Ktoś coś to z 
góry dzięki?

[toc] | [next] | [standalone]


#15301

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-19 18:20 +0100
Message-ID<o5qsh1$jes$2@node2.news.atman.pl>
In reply to#15300
nie do końca ogarniam sortowanie,
czy sortowanie odbywa sie po sprawdzeniu warunku czy przed?

[toc] | [prev] | [next] | [standalone]


#15302

From"Stokrotka" <ortografia.nowa@gazeta.pl>
Date2017-01-19 18:37 +0100
Message-ID<o5qtgf$8ps$1@usenet.news.interia.pl>
In reply to#15300
> jeśli dla uproszczenia przyjąć, że do bazy logujemy wszystkie wejścia na
> stronę to jak zrobić najlepiej zawijanie?
>
> czyli jak kasować najstarsze wpisy zostawiając N ostatnich?
>
> nie żebym z gębą na pączki...
>
> mój pomysł jest taki:
>
> ilczę conutem ilość wpisów
>
> sprawdzam czy kwalifikują się do kasowania
>
> odczcytuję 100 najstarszych wpisów poprzez select z sortowniem po dacie
>
> wyszukuję w nich największy ID
>
> kasuję wszystkie wpisy i id<ID...
>
> co Panowie na to? ogólnie to ja nawet nie jestem programistą, nie 
> dopuścili mnie na politechnice warszawskiej, więc jakby Ktoś coś to z góry 
> dzięki?

Co znaczy "czy kwalifikują się do kasowania"
I wydaje mi się, że poza ilością powinien być conajmniej drugi warunek na 
datę (ma być dość stara).

-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. 

[toc] | [prev] | [next] | [standalone]


#15303

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-19 19:02 +0100
Message-ID<o5qv07$lnd$1@node2.news.atman.pl>
In reply to#15302
oj tam nie domyślasz się?

jeśli count zwróci 100 mln

to przy wpisie 100 mln + 100 kasuje...

[toc] | [prev] | [next] | [standalone]


#15304

From"Darek" <darekpn2@wp.pl>
Date2017-01-19 20:15 +0100
Message-ID<588110ed$0$5156$65785112@news.neostrada.pl>
In reply to#15302

Użytkownik "Stokrotka"  napisał w wiadomości grup 
dyskusyjnych:o5qtgf$8ps$1@usenet.news.interia.pl...


> jeśli dla uproszczenia przyjąć, że do bazy logujemy wszystkie wejścia na
> stronę to jak zrobić najlepiej zawijanie?
>
> czyli jak kasować najstarsze wpisy zostawiając N ostatnich?
>
> nie żebym z gębą na pączki...
>
> mój pomysł jest taki:
>
> ilczę conutem ilość wpisów
>
> sprawdzam czy kwalifikują się do kasowania
>
> odczcytuję 100 najstarszych wpisów poprzez select z sortowniem po dacie
>
> wyszukuję w nich największy ID
>
> kasuję wszystkie wpisy i id<ID...
>
> co Panowie na to? ogólnie to ja nawet nie jestem programistą, nie 
> dopuścili mnie na politechnice warszawskiej, więc jakby Ktoś coś to z góry 
> dzięki?

Co znaczy "czy kwalifikują się do kasowania"
I wydaje mi się, że poza ilością powinien być conajmniej drugi warunek na
datę (ma być dość stara).

-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom.

Jak w piosence -
Spotkali się (...)
Miejscowa idiotka z tutejszym kretynem."
:) 


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]


#15305

FromAdam <a.g@poczta.onet.pl>
Date2017-01-19 22:24 +0100
Message-ID<o5raq9$42h$1@usenet.news.interia.pl>
In reply to#15300
W dniu 2017-01-19 o 18:18, niepełnosprawny intelektualnie 'POPIS/EU pisze:
> jeśli dla uproszczenia przyjąć, że do bazy logujemy wszystkie wejścia na
> stronę to jak zrobić najlepiej zawijanie?
>
> czyli jak kasować najstarsze wpisy zostawiając N ostatnich?
>
> nie żebym z gębą na pączki...
>
> mój pomysł jest taki:
>
> ilczę conutem ilość wpisów
>
> sprawdzam czy kwalifikują się do kasowania
>
> odczcytuję 100 najstarszych wpisów poprzez select z sortowniem po dacie
>
> wyszukuję w nich największy ID
>
> kasuję wszystkie wpisy i id<ID...
>

A co w przypadku, gdy cały log będzie miał 80 rekordów?



-- 
Pozdrawiam.

Adam

[toc] | [prev] | [next] | [standalone]


#15306

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-20 17:17 +0100
Message-ID<o5td6b$vp0$2@node1.news.atman.pl>
In reply to#15305
> A co w przypadku, gdy cały log będzie miał 80 rekordów?

no to wtedy ktoś dostaje grant i problemu nie ma...

NA TEMAT proszę!

[toc] | [prev] | [next] | [standalone]


#15308

FromRafal Podsiadly <spinacz24@gmail.com>
Date2017-01-20 23:30 -0800
Message-ID<8e09f7fd-d703-41cd-ad76-e3f9088dcb6a@googlegroups.com>
In reply to#15306
Trochę teorii.
1. Zbierając logi w jednej tabeli dochodzisz do pewnego ograniczenia.
(Jedna tabela jest jednym plikiem w systemie bazodanowym).
Z czasem pojawia się problem miejsca i szybkość z jaką otwiera system bazodanywy pliki. Pytanie do ilu rekordów maksymalnie jesteś w stanie sobie pozwolić. 
100 rekordów to znacznie za mało by mieć dobrą analizę błędów logów. Możesz taką ilość osiągnąć w kilka sekund.

PS: Dopiero fragmentacja tabeli powoduje fizyczne usunięcie z niej miejsca.

Wyjściem z rozwiązania jest budowanie Tabel które przechowują archiwum w okresach miesięcznych. arch_xxxx_xx 
usuwanie danych ograniczało by się do usunięciu tabeli.

Rozpiszmy to na zbiory danych
1. jedna tabela -> dane_insert(id, data, dane) 
- odpalamy crone który cyklicznie uruchamiamy 1 dziennie. Sprawdza ilość rekordów 
usuń wszystko z warunkiem id < (count(archiwum) - 100) - (max_id)

Trochę kombinowania... PS: dellete wykonuje następujące operacje.

Odszukuje rekord o danym id następnie sprawdza czy rekord jest używany, zablokowany i dokonuje próbę zmiany statusu rekordu na usunięty aby można było w przyszłości przy fragmentacji zwolnić miejsce.

Efekt dość spora ilość operacji wykonywana przez silnik bazy danych.

2. Rozwiązanie (tabela archiwum odpowiadająca archiwum) 
Odczyt danych przez widok, zapisywanie danych przez procedurę.
Usuwanie danych przez trunce -> delette table.

Na przykład zamiast przechowywać dane rekordy w ilości 100. Przechowujemy x miesięcy.

Efekt usuwanie szybsze. Mniejsze tabele zapewniają lepszą 
elastyczność systemu. PS: jeśli danych masz mało to można rozdzielić to na lata.

[toc] | [prev] | [next] | [standalone]


#15312

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2017-01-21 11:29 +0100
Message-ID<1msexbzgq0x9n.36yxdlhgjrzg.dlg@40tude.net>
In reply to#15308
Dnia Fri, 20 Jan 2017 23:30:05 -0800 (PST), Rafal Podsiadly napisał(a):

> Z czasem pojawia się problem miejsca i szybkość z jaką otwiera system
> bazodanywy pliki. Pytanie do ilu rekordów maksymalnie jesteś w stanie
> sobie pozwolić. 

W sensownej bazie z dobrze założonymi indeksami wielkość tabeli praktycznie
nie ma znaczenia przy odczycie. Niepotrzebnie to komplikujesz, bardziej
baza się spoci przy takim krojeniu na kawałki, niż przy dopisywaniu nowych
rekordów i wyszukiwaniu.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15313

FromRafal Podsiadly <spinacz24@gmail.com>
Date2017-01-21 04:13 -0800
Message-ID<9fbd91d1-2a2a-4772-a096-2449e95c6910@googlegroups.com>
In reply to#15312
Wrzuć do mysql 1TB danych.

[toc] | [prev] | [next] | [standalone]


#15314

Fromw systemie siła 'PO/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-21 16:05 +0100
Message-ID<o5vtb5$g73$1@node1.news.atman.pl>
In reply to#15313
po roku zbierania logów (w sumie praktycznie same przeglądarki)
mam tak

http://zsyp.eu/smieci/baza-index.JPG

nie wiem czy to normalne, czy index jest za duży?

[toc] | [prev] | [next] | [standalone]


#15319

FromRoman Tyczka <noemail@because.no>
Date2017-01-21 23:47 +0100
Message-ID<1ksjvev6m71dh$.dlg@tyczka.com>
In reply to#15313
On Sat, 21 Jan 2017 04:13:56 -0800 (PST), Rafal Podsiadly wrote:

> Wrzuć do mysql 1TB danych.

Użyj postgressa, mysql to zabawka a nie "sensowna baza danych".

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]


#15323

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2017-01-22 21:34 +0100
Message-ID<1c3nawo3cn5mx.u8a57mko89wu$.dlg@40tude.net>
In reply to#15319
Dnia Sat, 21 Jan 2017 23:47:09 +0100, Roman Tyczka napisał(a):

>> Wrzuć do mysql 1TB danych.
> 
> Użyj postgressa, mysql to zabawka a nie "sensowna baza danych".

Zależy do czego, replikację i skalowanie mają rozwiązane bardzo dobrze.
Przykładowo UBER się zwinął z Postgresa, bo baza u nich nie dała rady od
pewnej skali: https://eng.uber.com/mysql-migration/

Facebook też ma sporo rozwiązań oparte o MySQL.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15322

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2017-01-22 21:34 +0100
Message-ID<768nycqu9l9q.1wimyb80ztvoc$.dlg@40tude.net>
In reply to#15313
Dnia Sat, 21 Jan 2017 04:13:56 -0800 (PST), Rafal Podsiadly napisał(a):

> Wrzuć do mysql 1TB danych.

I w czym widzisz problem w tym przypadku, bo nie rozumiem? Logi to głównie
dopisywanie nowych rekordów, z rzadkim wyszukaniem po dacie, czasem po
innym kryterium. Jeśli będziesz na tym 1TB robić jakieś większe operacje,
to bez odpowiedniego zaprojektowania tabeli wszystko siądzie, ale to
dotyczy praktycznie każdej bazy.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15317

From"Darek" <darekpn2@wp.pl>
Date2017-01-21 19:17 +0100
Message-ID<5883a644$0$15196$65785112@news.neostrada.pl>
In reply to#15306
Witam tutejszego kretyna :) A gdzie miejscowa idiotka ?

Użytkownik "niepełnosprawny intelektualnie 'POPIS/EU"  napisał w wiadomości 
grup dyskusyjnych:o5td6b$vp0$2@node1.news.atman.pl...

> A co w przypadku, gdy cały log będzie miał 80 rekordów?

no to wtedy ktoś dostaje grant i problemu nie ma...

NA TEMAT proszę! 


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]


#15318

Fromw systemie siła 'PO/EU <NOSPAMtestowanije@go2.pl>
Date2017-01-21 19:21 +0100
Message-ID<o608qu$ori$1@node2.news.atman.pl>
In reply to#15317
ooo, zdecydowany grantobiorca, cześć kurwo...

[toc] | [prev] | [next] | [standalone]


#15321

FromRafal Podsiadly <spinacz24@gmail.com>
Date2017-01-22 09:27 -0800
Message-ID<22471169-3a5e-4395-bb4b-40c0c477c3f5@googlegroups.com>
In reply to#15300
Przy tak małych wynikach po co je usuwać po 100 wynikach.
A tak zapytam czy zrzucasz informacje o momencie zapisu rekordu NOW(), usunięcie wszystkich danych starszych niż rok było by lepsze.

A najlepsze Dump + gzip tabeli(by mieć archiwum a tak na wszelki wypadek) -> i zresetowanie jej (truncate). Od razu masz fragmentacje tabeli.

[toc] | [prev] | [standalone]


Back to top | Article view | pl.comp.lang.php


csiph-web