MVCC: PostgreSQL, Oracle ? =?ISO-8859-2?Q?mo=BFe_jednak_Fire?==?ISO-8859-2?Q?bird_=3F?=
HM - 02-12-2005 11:41
MVCC: PostgreSQL, Oracle ? =?ISO-8859-2?Q?mo=BFe_jednak_Fire?==?ISO-8859-2?Q?bird_=3F?=
Witam Grupowiczów,
Znalazłem taki dokument:
http://firebird.sourceforge.net/doc/..._vs_oracle.htm
Jest to synteza dwoch whitepaperow - jeden Ibma, drugi Oracla.
Mniej więcej w 2/3 dokumentu jest pokazane zachowanie Oracla9i w
sytuacji dwóch konkurencyjnych transakcji. Ten przykład został
skonstuowany w celu pokazania słabych stron MVCC Oracla.
Goście od Firebirda skonfrontowali z tym scenariuszem swoją bazę (a ja
skonfrontowałem to z PostgreSQLem 8.1 i zachował się tak jak Oracle).
Wychodzi na to że Oracle i PostgreSQL nie zachowują się tak dobrze jak
Firebird. (w sensie data consistency)
Czyżby zatem Firebird był najlepszą implementacją MVCC ? Czy ktoś mógłby
sprawdzić ten scenariusz z SQL Serverem 2005 ?
Hubert
Robert Grabowski - 02-12-2005 11:41
HM wrote:
> Witam Grupowiczów,
>
[...]
>
> Wychodzi na to że Oracle i PostgreSQL nie zachowują się tak dobrze jak
> Firebird. (w sensie data consistency)
>
> Czyżby zatem Firebird był najlepszą implementacją MVCC ?
Z dokumentu to nie wynika. Posługująć się tym przykładem, aby poprawnie
zarezerować miejsce w samolocie w Orale i PostgreSQLu należałoby zrobić
select for update tego konkretnego rekordu w obu transakcjach i problemu
by nie było. Można też zmienić poziom izolacji traskacji na SERIALIZABLE
i też problemu by nie było.
Widać raport pisał kompletny ignorant, bez wiedzy, w jaki sposób robi
się poprawnie współbieżny dostęp do tych samych rekordów - w
szczególności ich modyfikację. W przypadku opisanym w raporcie, gdy
update rekordu zależy od jego bieżącego stanu, należy przewidzieć
możliwość wyścigu i się przed tym zabezpieczyć używając select for
update lub uerlocks. Należy to robić zawsze, bez względu na aktualne
zachowanie silnika bazy danych. Bez tego typu zabezpieczeń aplikacja
poprawnie działająca na FB 1.5 może na wersji 3.0 zacząć działać tak,
jak na Oracle (jak to opisuje autor).
> Czy ktoś mógłby sprawdzić ten scenariusz z SQL Serverem 2005 ?
W zależności od poziomu izolacji transakcji SQL Server 2005 zachowa się
tak samo, jak Oracle lub Firebird. Chyba.
>
> Hubert
pozdrawiam
Robert Grabowski
HM - 02-12-2005 11:41
Robert Grabowski wrote:
>> Czyżby zatem Firebird był najlepszą implementacją MVCC ?
> Z dokumentu to nie wynika. Posługująć się tym przykładem, aby poprawnie
> zarezerować miejsce w samolocie w Orale i PostgreSQLu należałoby zrobić
> select for update tego konkretnego rekordu w obu transakcjach i problemu
> by nie było. Można też zmienić poziom izolacji traskacji na SERIALIZABLE
> i też problemu by nie było.
Sprawdzałeś to ? Moim zdaniem izolacja SERIALIZABLE nic tu nie da. i
uwzglednienie "race conditions" jest trudniejsze niż w Firebirdzie.
> Widać raport pisał kompletny ignorant, bez wiedzy, w jaki sposób robi
> się poprawnie współbieżny dostęp do tych samych rekordów - w
> szczególności ich modyfikację.
Ok ignoranci z firmy IBM, uczestniczacy przy produkcji DB2 ;-)
> update rekordu zależy od jego bieżącego stanu, należy przewidzieć
> możliwość wyścigu i się przed tym zabezpieczyć używając select for
> update lub uerlocks. Należy to robić zawsze, bez względu na aktualne
> zachowanie silnika bazy danych. Bez tego typu zabezpieczeń aplikacja
> poprawnie działająca na FB 1.5 może na wersji 3.0 zacząć działać tak,
> jak na Oracle (jak to opisuje autor).
Zauważ że Firebird był robiony od samego początku z MVCC , a nie jak
postgreSQL czy Oracle (od wersji 7 i 8).
>> Czy ktoś mógłby sprawdzić ten scenariusz z SQL Serverem 2005 ?
> W zależności od poziomu izolacji transakcji SQL Server 2005 zachowa się
> tak samo, jak Oracle lub Firebird. Chyba.
Zauważyłeś że pytanie było skierowane do kogoś kto ma SQL Server 2005 i
może to sprawdzić ? ;-)
Robert Grabowski - 03-12-2005 15:50
HM wrote:
> Robert Grabowski wrote:
>
>>> Czyżby zatem Firebird był najlepszą implementacją MVCC ?
>>
>> Z dokumentu to nie wynika. Posługująć się tym przykładem, aby
>> poprawnie zarezerować miejsce w samolocie w Orale i PostgreSQLu
>> należałoby zrobić select for update tego konkretnego rekordu w obu
>> transakcjach i problemu by nie było. Można też zmienić poziom izolacji
>> traskacji na SERIALIZABLE i też problemu by nie było.
>
>
> Sprawdzałeś to ? Moim zdaniem izolacja SERIALIZABLE nic tu nie da. i
> uwzglednienie "race conditions" jest trudniejsze niż w Firebirdzie.
>
>
>> Widać raport pisał kompletny ignorant, bez wiedzy, w jaki sposób robi
>> się poprawnie współbieżny dostęp do tych samych rekordów - w
>> szczególności ich modyfikację.
>
>
> Ok ignoranci z firmy IBM, uczestniczacy przy produkcji DB2 ;-)
>
Chodziło mi o ten test. Nie ma w nim ani słowa o blokowaniu rekordów,
tabel, ani o poziomie izolacji transakcji. Jak można w tym momencie
pretensje, że serwer bazy danych zrobił to, co mu kazano. Miał zrobić
update tabeli i ją zrobił. Co więcej, pierwsza transakcja na pewno
zablokowała rekord przy update, ale już przy commit rekord został
zwolniony i druga transakcji mogła spokojnie go zmodyfikować.
[...]
>
> Zauważ że Firebird był robiony od samego początku z MVCC , a nie jak
> postgreSQL czy Oracle (od wersji 7 i 8).
>
Być może. Nie wnikam w to. Chciałem tylko napisać, że przytoczony w tym
raporcie przykład nie pokazuje wyższości jednej bazy nad drugą, gdyż nie
jest napisany zgodnie z podstawowymi zasadami - brak blokowania rekordów.
>>> Czy ktoś mógłby sprawdzić ten scenariusz z SQL Serverem 2005 ?
>>
>> W zależności od poziomu izolacji transakcji SQL Server 2005 zachowa
>> się tak samo, jak Oracle lub Firebird. Chyba.
>
>
> Zauważyłeś że pytanie było skierowane do kogoś kto ma SQL Server 2005 i
> może to sprawdzić ? ;-)
W zależności od wybranego poziomu izolacji transakcji w MSSQL 2005 masz
MVCC lub nie. Chyba. :)
pozdrawiam
Robert Grabowski
Grzegorz Szyszlo - 03-12-2005 15:50
Robert Grabowski napisał(a):
> Z dokumentu to nie wynika. Posługująć się tym przykładem, aby poprawnie
> zarezerować miejsce w samolocie w Orale i PostgreSQLu należałoby zrobić
> select for update tego konkretnego rekordu w obu transakcjach i problemu
> by nie było. Można też zmienić poziom izolacji traskacji na SERIALIZABLE
> i też problemu by nie było.
przeciez serializable to ostatnia brzytwa ratunku ;)
w systemach sprawozdawczych jak najbardziej. ale w systemach
gdzie pracuje masa userow, wymagajacych jak najszybszego dostepu
do danych i jak najkrotszych blokad?
co do reszty zgoda.
co do MS SQL, tutaj wystepuje problem transakcji przez blokady,
przez co napisanie systemu produkcyjnego, w ktorym by bez
wiekszych problemow dzialaly roznego rodzaju raportowania
na dlugich transakcjach na biezacych danych, jest prawdziwym
wyzwaniem, czesto uwienczonym porażką.
znik.
Robert Grabowski - 03-12-2005 15:50
HM wrote:
> Robert Grabowski wrote:
>
>>> Czyżby zatem Firebird był najlepszą implementacją MVCC ?
>>
[...]
>
> Sprawdzałeś to ? Moim zdaniem izolacja SERIALIZABLE nic tu nie da. i
> uwzglednienie "race conditions" jest trudniejsze niż w Firebirdzie.
>
Właśnie to sprawidzłem. Przy izolacji transakcji serializable w
drugiej transakcji test wywalił się na punkcie 6, tak samo, jak w FB.
Zapewniem Ci, że w Oracle będzie tak samo.
Pytanie, jaki poziom izolacji transakcji, jak wykonywano testy w FB?
pozdrawiam
Robert Grabowski
Robert Grabowski - 03-12-2005 15:50
Grzegorz Szyszlo wrote:
> Robert Grabowski napisał(a):
>
[...]
>
> przeciez serializable to ostatnia brzytwa ratunku ;)
> w systemach sprawozdawczych jak najbardziej. ale w systemach
> gdzie pracuje masa userow, wymagajacych jak najszybszego dostepu
> do danych i jak najkrotszych blokad?
>
Ja serializable podałem Tu, jak jedno z rozwiązań - jednym z
najgorszych. Czasami lepiej jest użyć serializable i przy zgłoszeniu
błędu "could not serialize access due to concurrent update" ponowić
wykonanie operacji.
Za to zupełnie bezpiecznie mona używać w postgresql'u serializable
dla transakcji, które tylko czytają dane z bazy - chyba, że nie? :)
pozdrawiam
Robert Grabowski
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 03-12-2005 15:51
HM wrote:
> Witam Grupowiczów,
>
> Znalazłem taki dokument:
>
> http://firebird.sourceforge.net/doc/..._vs_oracle.htm
>
> Jest to synteza dwoch whitepaperow - jeden Ibma, drugi Oracla.
> Mniej więcej w 2/3 dokumentu jest pokazane zachowanie Oracla9i w
> sytuacji dwóch konkurencyjnych transakcji. Ten przykład został
> skonstuowany w celu pokazania słabych stron MVCC Oracla.
>
> Goście od Firebirda skonfrontowali z tym scenariuszem swoją bazę (a ja
> skonfrontowałem to z PostgreSQLem 8.1 i zachował się tak jak Oracle).
No u mnie na 8.0 działa jak najbardziej poprawnie. Mógłbyś podać co robisz?
--
P.M.
Ronald Kuczek - 03-12-2005 15:51
Użytkownik HM napisał:
> Witam Grupowiczów,
>
> Znalazłem taki dokument:
>
> http://firebird.sourceforge.net/doc/..._vs_oracle.htm
>
> Jest to synteza dwoch whitepaperow - jeden Ibma, drugi Oracla.
> Mniej więcej w 2/3 dokumentu jest pokazane zachowanie Oracla9i w
> sytuacji dwóch konkurencyjnych transakcji. Ten przykład został
> skonstuowany w celu pokazania słabych stron MVCC Oracla.
>
> Goście od Firebirda skonfrontowali z tym scenariuszem swoją bazę (a ja
> skonfrontowałem to z PostgreSQLem 8.1 i zachował się tak jak Oracle).
>
> Wychodzi na to że Oracle i PostgreSQL nie zachowują się tak dobrze jak
> Firebird. (w sensie data consistency)
>
> Czyżby zatem Firebird był najlepszą implementacją MVCC ? Czy ktoś mógłby
> sprawdzić ten scenariusz z SQL Serverem 2005 ?
Cześć,
Jak ktoś nie umie korzystać z Oracle,DB2 albo Postgresa to może popełnić
taki dokument, w innym wypadku to by mu się nie zdarzyło. BTW. MVCC to
jedna z najmocniejszych stron Postgresa, za którą dość drogo płacimy
(vide count performance). Jedna rzecz to fakt - SELECT FOR UPDATE ...
NOWAIT było do wersji 8.1 marzeniem, dzisiaj jest faktem więc nie ma o
co kopii kruszyć. Firebird jest łatwy,lekki i niezły ale porównywanie go
np. do Oracle to grube nieporozumienie, to jakby zestawiać Toyotę
Avensis z Ferrari Testarossa, nie ta klasa. Było nie było - ubogi SQL w
porównaniu choćby z Postgresem (choćby doprowadzający mnie do rozpaczy
brak case when...), performance w porównaniu do choćby Sybase ASA
nietęgi, oj jeszcze musi się ta baza rozwijać ... Jest fajna, niezła,
darmowa ale bez przesady.
Pozdrawiam
Rony
Marcin 'goral' Goralski - 05-12-2005 19:19
HM wrote:
> Witam Grupowiczów,
>
> Znalazłem taki dokument:
>
> http://firebird.sourceforge.net/doc/..._vs_oracle.htm
Akurat, mowiac malo technicznie, zachowanie Oracle jest jak najbardziej
poprawne. Transakcja 2 nie ma prawa zobaczyc, ze to siedzenie _nie jest
wolne_, poniewaz ani nie zostalo zarezerwowane (brak tego kroku w
transakcji 1), ani tez operacja rezerwacji nie zostala potwierdzona
commitem przed tym, kiedy transakcja 2 zaczela czytac dane.
Nie wnikam juz w blokowanie rekordow, bo napisali to przedmowcy, ale
zasada jest taka, ze wszystkie transakcje widza dane oryginalne (wziete
z rollback segm), dopoki transakcja modyfikujaca dany blok nie zakonczy
sie commitem.
marcin
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle 19g +Insert +Insert +Insert...
MSSQL Express czy Oracle Express
[Oracle, Toad] Zaladowanie obiektu w TOAD
[Oracle][Reports30] 10G nie dziala razem z Reports3.0
[Oracle] catalog.sql i catproc.sql - bledy
klient oracle (zmiana domyslna klienta oracla)
[oracle] [xml] XML na bazie istniejacej struktury ?
[Oracle] W jaki sposób skopiować całą zawartość schemy jednego użytkownika do nowo utworzonego użytkownika?
klient Oracle 10g SE a Windows 98 SE
Oracle Standard Edition One - czym sie rozni od wersji standard iexpress?
zanotowane.pldoc.pisz.plpdf.pisz.plbajkomoda.xlx.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 |
|
