W dniu 2010-03-24 21:15, Marek pisze:
>
>> Kolejny raz napiszę, że to bzdurne podejście.
>
> To prawda - lecz nie rozwijasz wątku. Bzdurne bo Ty stosujesz inne
> rozwiązanie? To słaby argument.

Premature optimization is the root of all evil. Na pewno to wiesz.

>> Przyznaj się, że gubisz
>> się w kodzie przy ilości tabel > 1, a nie teorie sobie dorabiasz.
>
> Po pierwsze tabel mam 96 i jakoś nie gubię się w tym, po drugie
> chciałbym abyś wykazał iż tyle samo czasu CPU zajmie zapytanie
> składające się z SELECT * FROM tabela oraz SELECT * FROM tabela JOIN
> inna_tabela JOIN jeszcze_inna JOIN kolejna. Nie wiem na czym opierasz
> swoje twierdzenie, że takie rozbudowywanie zapytań SQL w niczym nie
> szkodzi. Otrzymałem skrajnie odmienne wyniki pomiarów.

Te różnice wydajności nie powinny być kryterium projektowym.
Denormalizacja to raczej wyjątkowa sprawa.

>> Szczególnie, że dalej twierdzisz, że wrzucasz kontent do cache, co
>> powinno dodatkowo niwelować narzut na bazę. Tak w ogóle, MySQL też
>> potrafi keszować sobie zapytania, czyli oszczędzasz co najwyżej na
>> czasie generowania treści.
>
> Akurat nie stosuję MySQL'a aby wypowiadać się w sprawie tej bazy lecz
> wydaje mi się ciekawym zagadnienie cache'owania zapytań przez samą bazę.
> Nie wyobrażam sobie jak taki mechanizm może funkcjonować jeśli baza "nie
> wie" co najczęściej będzie czytane i jak dalej przetwarzane i w związku
> z tym co należy cacheować. W innych bazach: PostgreSQL, M$ SQL nie
> zaobserwowałem takiego mechanizmu o jakim piszesz dla zapytań typu
> SELECT * FROM tabela WHERE tabela_id=losowy_id (bo nie można przewidzieć
> o jaki ID będzie zapytanie). Zapytanie pochłania znacznie więcej taktów
> CPU niż odczyt z cache tych samych informacji a już nie wspomnę o danych
> przetworzonych wstępnie - głównie to jest przedmiotem cacheowania w moim
> CMS a nie same zapytania SQL. Są to np. wyniki rekurencyjnych zapytań
> SQL często powtarzanych przy odwiedzaniu serwisu WWW - np. dla struktur
> menu, kategorii i innych hirerchii, wstępnie przetworzone fragmenty
> stron WWW, które nie muszą być dynamicznie aktualizowane itp.

PostgreSQL chyba nie ma, a MySQL ma.
Keszowanie przetworzonych wyników jest OK, ale... tym bardziej po co
optymalizować zapytania? :-)

PS: Takty CPU liczyłem za czasów Z80, sądziłem, że to historia :-)

artur

do góry

Tak w ogóle to przepraszam za OT.

artur

do góry

W dniu 2010-03-27 18:24, Artur Muszyński pisze:

> Premature optimization is the root of all evil. Na pewno to wiesz.

Gdzieś powyżej napisałem, że cache'owanie stosuję na dużo wyższym
poziomie niż baza danych. Dotyczy ono wstępnie przetworzonej treści, co
do której mam pewność, że można ją cach'eować.

> Te różnice wydajności nie powinny być kryterium projektowym.
> Denormalizacja to raczej wyjątkowa sprawa.

Niestety muszą być - na współdzielonych serwerach. Na indywidualnym
serwerze można sobie pozwolić na więcej...

> PostgreSQL chyba nie ma, a MySQL ma.
> Keszowanie przetworzonych wyników jest OK, ale... tym bardziej po co
> optymalizować zapytania? :-)

Są różne moduły w CMS... W jednej z realizacji czasem zdarza się, że
wykonuje się za jednym zamachem do 400 tys. zapytań. Ich optymalizacja
spowodowała dwa rzędy wielkości różnicy w czasie wykonywania tej lawiny
zapytań.

> PS: Takty CPU liczyłem za czasów Z80, sądziłem, że to historia :-)

Oj nie... To zakamuflowana praktyka współczesności :-) W regulaminach
mniej profesjonalnych firm providerskich masz w regulaminach korzystania
wzmiankę o tym, że konto WWW nie może zakłócać pracy innych kont bo
będzie blokada. Co oznacza "zakłócać" to wie wyrocznia zwana
właścicielem serwera. Dowiadujesz się pewnego dnia, że przeszkadzasz
innym i nie dowiesz się nawet w jaki sposób i co poprawić.

U bardziej profesjonalnych dostawców samodzielnie monitorujesz co i ile
CPU pożera aby mieć możliwość przeprowadzenia optymalizacji kodu lub
SQL. Opłaty są naliczane za transfer jak i za zużycie CPU oddzielnie.

do góry