Która z baz: [PGSQL] czy [MySQL] będzie lepsza w takim zastosowaniu (masowe UPDATE)
William - 13-03-2006 11:25
Która z baz: [PGSQL] czy [MySQL] będzie lepsza w takim zastosowaniu (masowe UPDATE)
Pojedyncza tabela zostanie załadowana bardzo dużą ilością rekordów.
Następnie zostaną na niej wykonane masowe operacje UPDATE polegające na
zmodyfikowaniu pojedynczego, wskazanego przez id rekordu dwóch pól: statusu
(int) oraz wypełnieniu opisu (varchar, ewentualnie char). Czyli mniej więcej
operacja typu:
UPDATE dane
SET status=2, opis='treść opisu'
WHERE id = 123
AND status = 1
Intuicja mi podpowiada, że MySQL może być tu szybszy od Postgresa, jeśli tak
to czy odpowiedniejszy będzie typ MyIsam czy też InnoDB ?
jerzy - 13-03-2006 11:26
> Intuicja mi podpowiada, że MySQL może być tu szybszy od Postgresa, jeśli tak
> to czy odpowiedniejszy będzie typ MyIsam czy też InnoDB ?
>
>
Zawsze mnie cieszy kiedy programista używa zwrotu "Intuicja mi podpowiada".
Mnie natomiast intuicja mówi że kiedy nie używamy kluczy obcych albo
transakcji MyIsam może być lepszy(szybszy) od InnoDB.
hi
max - 13-03-2006 11:26
jerzy napisał(a):
>
>> Intuicja mi podpowiada, że MySQL może być tu szybszy od Postgresa,
>> jeśli tak
>> to czy odpowiedniejszy będzie typ MyIsam czy też InnoDB ?
>>
>>
>
> Zawsze mnie cieszy kiedy programista używa zwrotu "Intuicja mi podpowiada".
> Mnie natomiast intuicja mówi że kiedy nie używamy kluczy obcych albo
> transakcji MyIsam może być lepszy(szybszy) od InnoDB.
> hi
A moja intuicja mówi aby zrobić testy.
Kazek Kurz - 13-03-2006 11:26
William wrote:
> Pojedyncza tabela zostanie załadowana bardzo dużą ilością rekordów.
> Następnie zostaną na niej wykonane masowe operacje UPDATE polegające na
> zmodyfikowaniu pojedynczego, wskazanego przez id rekordu dwóch pól: statusu
> (int) oraz wypełnieniu opisu (varchar, ewentualnie char). Czyli mniej więcej
> operacja typu:
> UPDATE dane
> SET status=2, opis='treść opisu'
> WHERE id = 123
> AND status = 1
> Intuicja mi podpowiada, że MySQL może być tu szybszy od Postgresa, jeśli tak
> to czy odpowiedniejszy będzie typ MyIsam czy też InnoDB ?
Moja intuicja zas mowi ze wiele mozna tu zmienic w szybkosci wykonania w
zaleznosci od przyjetej konfiguracji oraz sposobu wykonania owego update.
Co np. by sie stalo, gdyby taka operacja wykonala sie w konfiguracji w
ktorej nie logujemy transakcji?
A jak by sie powalilo, bylby to problem?
Kazek
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
William - 13-03-2006 11:27
> > UPDATE dane
> > SET status=2, opis='treść opisu'
> > WHERE id = 123
> > AND status = 1
> A jak by sie powalilo, bylby to problem?
Ale co to znaczy "powaliło" ? Update jest celowo tak banalny, że nie ma
prawa się wywalić. Inne zapytania mają inne id. Albo inaczej - ma prawo się
wywalić w przypadku jednoczesnych update na tym samym id - w poprawnym
użyciu tak sie nigdy nie stanie. Wywalić w takim sensie, że nie obchodzi
mmnie która wersja się zapisze, byleby nie wpłynęło to na (poprawne) updatey
rekordów o innych id.
Kazek Kurz - 15-03-2006 10:39
William wrote:
>>>UPDATE dane
>>> SET status=2, opis='treść opisu'
>>> WHERE id = 123
>>> AND status = 1
>>A jak by sie powalilo, bylby to problem?
> Ale co to znaczy "powaliło" ? Update jest celowo tak banalny, że nie ma
> prawa się wywalić. Inne zapytania mają inne id. Albo inaczej - ma prawo się
> wywalić w przypadku jednoczesnych update na tym samym id - w poprawnym
> użyciu tak sie nigdy nie stanie. Wywalić w takim sensie, że nie obchodzi
> mmnie która wersja się zapisze, byleby nie wpłynęło to na (poprawne) updatey
> rekordów o innych id.
Sa sytuacje w ktorych istotne jest wykonani np. wszystkich update na
calej tabeli, a w wypadku gdy sie nie uda ( powiedzmy ze braknie miejsca
na dysku) po prostu nic nie tracimy, musimy tylko cala operacje zaczac
od nowa np. zwiekszajac zasoby. To zupelnie inna sytuacja od takiej w
ktorej np. dane to dane podlegajace standardowym operacjom OLTP, np.
faktury w firmie.
napisalem,ze roznice pomiedzy bazami moga miec mniejsze znaczenie niz
warunki w ktorych sie je stosuje. Jesli kazdy update jest osobna
transakcja a masz ich 10 milionow, to motor bazy bedzie bardzo
intensywnie pisal do logow, ale wpisy do nich beda krotkie. Jesli zas 10
milionow ma sie wykonac w jednej transakcji to zapis do logow bedzie
niiny. A jesli zrezygnujesz z logowania bedzie jeszcze inaczej.
Pytanie ktora z tych operacji jest mozliwa w wymienoionych przez ciebie
motorach, oraz ktora z nich jest do zakceptowania przez ciebie.
Ponadto istneija jeszcze inne mozliwosci: striping na dyskach,
fragmentacja tabel ze wzgledu na jakies klucze, budowa odpowiednich
indexow jesli update dotyczy niektorych rekordow itp. itd.
Kwestia wykorzystania danego motoru jest wtorna bo zwykle nie mozesz
sobie wybrac na jakim motorze jest baza ale mozesz sobie wyvierac jak
motor/baza jest skonfigurowana...
kazek
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
William - 15-03-2006 10:39
Użytkownik "Kazek Kurz" <kakaz@tlendwuczasteczkowy.pl> napisał w wiadomości
news:dv4ech$meu$1@news.mm.pl...
> Sa sytuacje w ktorych istotne jest wykonani np. wszystkich update na
> calej tabeli, a w wypadku gdy sie nie uda ( powiedzmy ze braknie miejsca
> na dysku) po prostu nic nie tracimy, musimy tylko cala operacje zaczac
> od nowa np. zwiekszajac zasoby. To zupelnie inna sytuacja od takiej w
> ktorej np. dane to dane podlegajace standardowym operacjom OLTP, np.
> faktury w firmie.
> napisalem,ze roznice pomiedzy bazami moga miec mniejsze znaczenie niz
> warunki w ktorych sie je stosuje. Jesli kazdy update jest osobna
> transakcja a masz ich 10 milionow, to motor bazy bedzie bardzo
> intensywnie pisal do logow, ale wpisy do nich beda krotkie. Jesli zas 10
> milionow ma sie wykonac w jednej transakcji to zapis do logow bedzie
> niiny. A jesli zrezygnujesz z logowania bedzie jeszcze inaczej.
> Pytanie ktora z tych operacji jest mozliwa w wymienoionych przez ciebie
> motorach, oraz ktora z nich jest do zakceptowania przez ciebie.
> Ponadto istneija jeszcze inne mozliwosci: striping na dyskach,
> fragmentacja tabel ze wzgledu na jakies klucze, budowa odpowiednich
> indexow jesli update dotyczy niektorych rekordow itp. itd.
> Kwestia wykorzystania danego motoru jest wtorna bo zwykle nie mozesz
> sobie wybrac na jakim motorze jest baza ale mozesz sobie wyvierac jak
> motor/baza jest skonfigurowana...
> kazek
>
Akurat mam to sczęście, że najpierw został okreslony problem - masowe,
niezależne transakcje (docelowo nawet do 1000 na sekunde) polegające na
update pojedyńczego rekordu i mam swobodę w wyborze bazy i jej konfiguracji.
Łącznie z tym, że aplikacja kliencka może trzymać połączenia do wielu
równoległych baz i na podstawie np. ostatniej cyfry ID wykonywac update
tylko na jednej z nich. Chodziło mi generalnie o rozpatrzenie takiego
aspektu: czytałem, że Postrges dla update tworzy drugą instancję rekordu z
wyższym numerem wersji. Dla mnie (gdy nie potrzebuję transakcyjności) jest
to zachowanie obciążające - chciałbym mieć bazę, która zmodyfikuje "w
miejscu" potrzebny rekord. Stąd intuicja kierowała mnie w stronę MySQL i
MyISAm.
Kazek Kurz - 15-03-2006 10:40
William wrote:
[ciach]
> Akurat mam to sczęście, że najpierw został okreslony problem - masowe,
> niezależne transakcje (docelowo nawet do 1000 na sekunde) polegające na
> update pojedyńczego rekordu i mam swobodę w wyborze bazy i jej konfiguracji.
1000 na sekunde, oznacza 60000 na minute, oznacza kilka milionow
operacji na godzine. takie liczby bazy danych osiagaja w czasach zredu
miesiecy, wiec pomysl zeby taka baze postawic na pgsql uwazam za smieszny.
Odpowiedz sobei na nastepujace pytania:
1. jaki bedzie przyrost wielkosci bazy w ciagu minuty
2. ile transakcji musi zostac zrealizowane na minute
3. jaka jest wydajnosc kontrolera dyskowego, czy zapis jest keszowany
4. jaki jest dopuszczalny poziom straconych update, to znaczy czy mozesz
stracic np. co drogi update?
5. jak dlugo to ma trwac: chodzi o szybkie przeprowadzenie update duzej
bazy, czy o rejestracje zdarzen ( np. z systemu monitorujacego
produkcje, bilingi itp.)
Wskazana liczba update na sekunde w polaczeniu z twoim pytaniem wskazuje
na kompletny brak swiadomosci jakich nakladow wymaga taka instalacja.
Zakladajac ze jeden update zmienia jeden rekord, zas zapis wymaga
operacji na jednej 4k stronie dyskowch ( oszczedne zalozenie, zwykle
strony na dysku sa rzedu 32 k albo i wiecej) czyli 4 k bity, baza bedzie
musiala zapisac 1000 * 4k = 4 mega na sekunde co zbliza sie do
wydajnosdci starszych kontrolerow scsi. Oczywiscie nowoczesne maszyny
zapisuja wielektoc wiecej na sekunde, sam zapis zas nie bedzie za kazdym
razem dotyczyl nowej strony, jednak efekt mielenia dyskiem bedzie bardzo
wyrazny.
> Łącznie z tym, że aplikacja kliencka może trzymać połączenia do wielu
> równoległych baz i na podstawie np. ostatniej cyfry ID wykonywac update
> tylko na jednej z nich. Chodziło mi generalnie o rozpatrzenie takiego
> aspektu: czytałem, że Postrges dla update tworzy drugą instancję rekordu z
> wyższym numerem wersji. Dla mnie (gdy nie potrzebuję transakcyjności) jest
> to zachowanie obciążające - chciałbym mieć bazę, która zmodyfikuje "w
> miejscu" potrzebny rekord. Stąd intuicja kierowała mnie w stronę MySQL i
> MyISAm.
Obawiam sie ze sensowenj wydajnosci i niezawodnosci przy 1000
ZAPISACH na sekunde w seksencji losowej ( a nie jako update tabeli,
sekwencyjnei)
nie osiagniesz przy zadnej amatorskiej instalacji.
Ale moge sie mylic
kazek
--
O ktorym Wojtek Wierba napisal:
Kiedyś mówiło się "cogito ergo sum".
No Kazek chyba powiedzialby jednak:
"cogito ergo zum" co tlumaczy sie jako
"... jezdem"
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[mysql] =?ISO-8859-2?Q?Za=E6mienie=2E=2E=2E_jak_wy=B6wietli=E6?==?ISO-8859-2?Q?=2E=2E=2E?=
[mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?=
[MySQL] =?ISO-8859-2?Q?Wy=B6wietlenie_kolejnej_pozycji=2C_?==?ISO-8859-2?Q?jak=B1_mia=B3by_dany_rekord=2C_gdybym_czyta=B3 _?==?ISO-8859-2?Q?wg_konkretnych_kryteri=F3w=2E_Da_si=EA_=3F?=
[mysql 4.0.x] przenoszenie kolum =?ISO-8859-2?Q?mi=EAdzy_bazam?==?ISO-8859-2?Q?i_cd_=2E=2E=2E_?=
[MySQL] =?ISO-8859-2?Q?z=B3=B1czenie_tabeli_u=BFytkownik_i?==?ISO-8859-2?Q?_zdj=EAcia_z_wyborem_zdj=EAcia_domy=B6lnego?=
[MySQL] Jak =?ISO-8859-2?Q?wpisa=E6_do_tabeli_pozycje_dl?==?ISO-8859-2?Q?a_wierszy_gdybym_te_wiersze_wybiera=B3_w_ok?== ?ISO-8859-2?Q?re=B6lonej_kolejno=B6ci_=3F?=
Gdzie MySQL 4.1, a gdzie 5.0?
[MySQL 4.0...4.1] zabezpieczenie przed =?ISO-8859-2?Q?jednoczesn?==?ISO-8859-2?Q?=B1_edycj=B1?=
[MS SQL] "set names" (mySQL) w MS SQL
[mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
zanotowane.pldoc.pisz.plpdf.pisz.pladwokat.keep.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 |
|
