Mam aplikację która rejestruje zdarzenia. Tabela w której są
przechowywane informacje posiada trzy kolumny:
data (format YYYY-MM-DD), typ zdarzenia oraz liczba wystąpień.
Zdarzenia zgłaszane są przez zewnętrzne procesy.
Dwa procesy mogą zgłosić ten sam typ zdarzenia.
Obecnie jest to robione tak, że aplikacja robi select sprawdzając czy
dane zdarzenie wystąpiło bieżącego dnia. Jeśli wystąpiło, zwiększa
liczbę wystąpień, jeśli nie, dodaje nowy rekord do tabeli.

Wydaje mi się, że to rozwiązanie posiada pewną wadę.
Według mnie, w sytuacji gdy pewien typ zdarzenia nie został jeszcze
zarejestrowany bieżącego dnia a dwa procesy zgłoszą to zdarzenie
jednocześnie w tabeli pojawią się dwa wpisy dla jednego typu
zdarzenia.

Jak zabezpieczyć się przed tą sytuacją?
Aplikacja napisana jest w PHP. Baza danych to postgresql.


Pozdrawiam

do góry

Misiek NA <p...@g...com> wrote:

> Mam aplikację która rejestruje zdarzenia. Tabela w której są
> przechowywane informacje posiada trzy kolumny:
> data (format YYYY-MM-DD), typ zdarzenia oraz liczba wystąpień.
> Zdarzenia zgłaszane są przez zewnętrzne procesy.
> Dwa procesy mogą zgłosić ten sam typ zdarzenia.
> Obecnie jest to robione tak, że aplikacja robi select sprawdzając czy
> dane zdarzenie wystąpiło bieżącego dnia. Jeśli wystąpiło, zwiększa
> liczbę wystąpień, jeśli nie, dodaje nowy rekord do tabeli.
>
> Wydaje mi się, że to rozwiązanie posiada pewną wadę.
> Według mnie, w sytuacji gdy pewien typ zdarzenia nie został jeszcze
> zarejestrowany bieżącego dnia a dwa procesy zgłoszą to zdarzenie
> jednocześnie w tabeli pojawią się dwa wpisy dla jednego typu
> zdarzenia.
>
> Jak zabezpieczyć się przed tą sytuacją?
> Aplikacja napisana jest w PHP. Baza danych to postgresql.

Najprościej opakować dostęp do tabeli transkacją. Albo dodawaj
do tabelki tylko datę i typ, a jakimś widokiem obliczaj ilości.
W sumie wszystko zależy od tego, jak często są zgłaszane zdarzenia
i jak często potrzebujesz te informacje odczytać.

w.

do góry

On 10 Kwi, 12:11, Misiek NA <p...@g...com> wrote:

> Wydaje mi się, że to rozwiązanie posiada pewną wadę.
> Według mnie, w sytuacji gdy pewien typ zdarzenia nie został jeszcze
> zarejestrowany bieżącego dnia a dwa procesy zgłoszą to zdarzenie
> jednocześnie w tabeli pojawią się dwa wpisy dla jednego typu
> zdarzenia.
>
> Jak zabezpieczyć się przed tą sytuacją?

A dlaczego chcesz się przed nią zabezpieczać?
Może właśnie najprościej byłoby wrzucać do bazy wszystkie zdarzenia a
fakt że jest ich w bazie N oznacza, że... że było ich N?
Przy takim rozwiązaniu samo wrzucanie jest już proste i bezpiecznie,
bo jest to jeden zwykły insert. Z punktu widzenia wielodostępu jest to
najlepsze co można zrobić.

Pytanie podstawowe: ile może być zdarzeń tego samego typu w ciągu
dnia?
Pytanie pomocnicze: jaki *problem* chcesz rozwiązać "kompresując" je z
użyciem licznika?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

do góry

On 10 Kwi, 22:49, Maciej Sobczak <s...@g...com> wrote:
> > Jak zabezpieczyć się przed tą sytuacją?
>
> A dlaczego chcesz się przed nią zabezpieczać?
> Może właśnie najprościej byłoby wrzucać do bazy wszystkie zdarzenia a
> fakt że jest ich w bazie N oznacza, że... że było ich N?
> Przy takim rozwiązaniu samo wrzucanie jest już proste i bezpiecznie,
> bo jest to jeden zwykły insert. Z punktu widzenia wielodostępu jest to
> najlepsze co można zrobić.
>
> Pytanie podstawowe: ile może być zdarzeń tego samego typu w ciągu
> dnia?
> Pytanie pomocnicze: jaki *problem* chcesz rozwiązać "kompresując" je z
> użyciem licznika?
>

Problem polega na tym, że ta aplikacją jest już częścią pewnego
systemu. Zmiana tej części systemu wymusiłaby zmianę pozostałych
części.
Niestety obawiam się, że to mogłaby się skończyć co najmniej źle:/
Gdybym miał pisać tą aplikację samodzielnie od podstaw, to zrobiłbym
tak jak zaproponowałeś.

Zdarzeń takich może być około 10k - 50k na dzień, przy czym mogą
pojawiać się one w partiach po 1k - 5k z częstotliwością do 3 na
sekundę.

do góry

Misiek NA pisze:
> Mam aplikację która rejestruje zdarzenia. Tabela w której są
> przechowywane informacje posiada trzy kolumny:
> data (format YYYY-MM-DD), typ zdarzenia oraz liczba wystąpień.
> Zdarzenia zgłaszane są przez zewnętrzne procesy.
> Dwa procesy mogą zgłosić ten sam typ zdarzenia.
> Obecnie jest to robione tak, że aplikacja robi select sprawdzając czy
> dane zdarzenie wystąpiło bieżącego dnia. Jeśli wystąpiło, zwiększa
> liczbę wystąpień, jeśli nie, dodaje nowy rekord do tabeli.
>
> Wydaje mi się, że to rozwiązanie posiada pewną wadę.
> Według mnie, w sytuacji gdy pewien typ zdarzenia nie został jeszcze
> zarejestrowany bieżącego dnia a dwa procesy zgłoszą to zdarzenie
> jednocześnie w tabeli pojawią się dwa wpisy dla jednego typu
> zdarzenia.
>
> Jak zabezpieczyć się przed tą sytuacją?
Jak nie chcesz kombinować z transakcjami (co zazwyczaj jest poprawnym
rozwiązaniem) to:
klucz podstawowy/uniq na parze (data,typ)
sprawdzasz czy wpis istnieje
A) tak - robisz update, który zapewni blokadę na poziomie wiersza
B) nie - wstawiasz:
B)a) udało się - było to pierwsze wstawienie
B)b) nie udało się z powodu naruszenia ograniczeń uniq - rekord już
istnieje - idź do A)

Ewentualnie, jeżeli zbiór typów zdarzeń jest dość skończony to
generujesz wpisy z wartością 0 na najbliższy miesiąc a potem tylko z
update lecisz.

--
Pozdrawiam
Michoo

do góry

On 11 Kwi, 01:00, Misiek NA <p...@g...com> wrote:

> Problem polega na tym, że ta aplikacją jest już częścią pewnego
> systemu. Zmiana tej części systemu wymusiłaby zmianę pozostałych
> części.

Odpowiednio ułożone widoki mogą tu pomóc, jeśli te inne kawałki
systemu tylko czytają tą część bazy.

Możesz podzielić bazę na część bieżącą i archiwalną. Bieżąca to np.
dzisiejszy dzień i tam robisz szybkie wpisy przez zwykły insert, być
może wielokrotnie zduplikowane. Archiwalna to przeliczone już (tzn.
policzone) okresowo wpisy z tabeli bieżącej. Na to wszystko widok o
odpowiedniej nazwie, gdzie jest unia części archiwalnej i bieżącej
(też przezliczonej).

W ten sposób możesz mieć pewną przestrzeń roboczą w bazie na szybkie i
niekonfliktowe wstawianie nowych danych - a dla pozostałej części
systemu widok pokazujący wpisy z liczbą wystąpień.

> Zdarzeń takich może być około 10k - 50k na dzień, przy czym mogą
> pojawiać się one w partiach po 1k - 5k z częstotliwością do 3 na
> sekundę.

A muszą być w bazie natychmiast? Czy jest możliwe, aby system je
zliczał przed wpisaniem do bazy? Sztuczne opóźnienie może być dowolne,
od kilku sekund do całego dnia.
W ten sposób można zmniejszyć częstotliwość odwołań do bazy - a przez
to też ryzyko konfliktów w wielodostępie. Oczywiście nadal trzeba te
potencjalne konflikty obsłużyć, ale ich realny wpływ na działanie
systemu będzie mniejszy albo żaden.

--
Maciej Sobczak * http://www.inspirel.com

do góry