Jak dużo robi wam baza? Opcje

[Sedziwoj]

Prosta rzeczy, ile różnych obliczeń, operacji itp. robicie w bazie, a ile w tym czym programujecie (bo do PHP nie musimy się ograniczać)?
Bo ja dość sporo operacji, jeśli mogę przerzucam na bazę, z prostego powodu zrobi to szybciej, nie tylko że można sobie funkcje pisać w czym się podoba (prawie) ale też że niektóre rzeczy są optymalizowane.
Wiadomo count() itp. rzeczy robi się na bazie, ale czasem można o wiele więcej, np. system trigger'ów które robią odpowiednie akcje zależne, zamiast pisania tego w kodzie aplikacji. Różne obliczenia na danych z bazy, gdzie zwraca się tylko wynik.

Jak to u Was wygląda, bo kiedyś spotkałem się z opinią że lepiej nie używać niczego co oferują bazy, bo przy wdrążeniu na inną bazę robią się schody.

[Black-Berry]

U mnie okoł 1/5 czasu wykonywania całości to baza. Zauważyłem jednak, że im mniej zapytań stosuję tym lepiej wszystko działa. Nie chodzi tylko o ilość ale też o ich złożoność. Moim zdaniem im mniej robi baza tym lepiej bo zawsze możesz postawić 3 maszyny które wykonują kod a tylko jedną która obsługuje bazę. Jeśli masz więcej niż jedną bazę to sprawy mogą sie skąplikować. To jednak czyste teoretyzowanie

Pozdrawiam.

Ten post edytował Black-Berry 12.09.2008, 13:26:57

[nospor]

bo przy wdrążeniu na inną bazę robią się schody

Wystarczy wdrozyc na inny hosting i juz masz problem.
W prywatnej pracy unikam triggerow i funkcji itp.
Czesto mam klienta co ma hosting gdzie nie ma mysql5 i juz bym mial problem.
Nawet jak ma mysql5 to nie ma prawa na zakladanie triggerow i znowu zonk.

W pracy, gdzie mamy wlasne serwery wszystko co sie da idzie na baze.

[kwiateusz]

jakiś czas temu ktoś dawał link jak różne firmy radzą sobie z dużym trafficiem i tak mi sie zapamiętał ebay gdzie była maksyma żeby język robił wszystko, a baza minimum bo łatwiej postawić kilka serwerów które będą wykonywać skrypty/programy niż kolejną bazę ustawiając wszystkie opcje dot. replikacji itp

[Cysiaczek]

Myślę, że ~nospor ma sporo racji, bo jeśli piszemy system dedykowany, to możemy dać bazie więcej pracy. Jeśli jest to jednak system, który musi być instalowalny na różnych platformach, to lepiej grzebać w aplikacji. Myślę więc, że na to pytanie jest jedna, znienawidzona przez wielu maksyma: "zależy od okoliczności"

Pozdrawiam.

[Black-Berry]

Myślę więc, że na to pytanie jest jedna, znienawidzona przez wielu maksyma: "zależy od okoliczności"

Jak będziemy mieli takie podejście to nigdy nie znajdziemy odpowiedzi na nasze pytania

Zastanawiam się... Po co właściwie baza miałaby wykonywać cokolwiek poza selectami i updatami? Moim zdaniem jeśli coś mieści się w wydajności 50%:50% (silnik/baza) to zawsze powinniśmy wybierać silnik. Replikowanie się baz danych to śliski temat i na pewno podczas takich operacji coś się może zepsuć częściej niż replikacja silnika.

Swego czasu było na forum dużo tematów o cachowaniu zapytań do bazy. Jak dla mnie to straszna głupota. Jeśli mamy system który tylko 10% czasu poświęca na zapytania to zwiększenie wydajności zapytań o 50% daje nam tylko 5% przyrostu wydajności całkowitej. Dlatego jeśli mamy mało obciążoną bazę to możemy dać jej spokój a nasze wysiłki skierowac w poprawę wydajności silnika np cachując cały render strony. W ten sposób za jednym zamachem cachujemy także zapytania do bazy.

[fernet]

Dla mnie baza danych jak sama nazwa wskazuje to baza z danymi a nie jakies (liczydlo) i uj mnie strzela jak widze wpisy dat z jakims kosmicznym formatowaniem zamiast znaczkow czasu. Nie rozumiem kolesi z mysql ktorzy rozwijaja swoj produkt w tym kierunku chyba im sie nudzi.

[athabus]

Zgodzę się z tym co napisał Black-Bery że cachowanie zapytań do bazy z reguły ma mały sens. Również raczej staram się cachować całe akcje gdy tylko jest to możliwe.
Ogólnie raczej jestem z tych co przerzucają wszystko na kod. Z bazy korzystam raczej na zasadzie odczyt/zapis. Jakoś nie mogę się przekonać do stosowania trigerrów itp (choć wiem, że to błąd) - raczej daje takie rzeczy w modelu. Powód jest prosty - podczas kodowania łatwiej mi jest połapać się, gdy wszystko mam w jednym miejscu. I tak już śledzenie wszystkich wyzwalaczy w modelu jest trudne a co dopiero gdy przerzucimy część kodu na bazę.
Z drugiej strony wyzwlacze w bazie mają tą zaletę, że nie usunie się ich przypadkowo przy refactoringu.

Co do współdzielonych hostingów to zauważam taką tendencję, że bazy zazwyczaj są wąskimi gardłami - przemawia to dodatkowo na korzyść kodu. Baza często nie jest tak dokładnie monitorowana jak same skrypty przez co zdarzają się userzy wykonujący masakryczne zapytania.

[sf]

Jak to u Was wygląda, bo kiedyś spotkałem się z opinią że lepiej nie używać niczego co oferują bazy, bo przy wdrążeniu na inną bazę robią się schody.

Ja się nie zgodzę z nospor i stwierdzam, że należy używać triggerów. Zresztą ja mu się dziwie, że robi projekty na wersji poniżej MySQL5 bo technicznie te serwisy są w tyle za konkurencją. Zresztą na nazwa już nie ma baz poniżej MySQL5.

Natomiast przenoszenie serwisu z jednej bazy na inną jest sprawą dość delikatną. Kiedyś jak byłem młodszy to jeszcze się w to bawiłem, ale aktualnie to klient musi spełnić wymagania sprzętowe, które zostają określone na samym początku zawarcia umowy. Przecież serwer to jest bardzo mała część ceny serwisu więc w ogóle nie ma mowy by dostosowywać się do tego co sobie kupił kiedyś klient.

[Black-Berry]

No dobrze ale pokazałeś że to nie musi być problem w przypadku kiedy serwis nie jest na tyle duży aby trzeba było duplikować sprzętu. A jakie to ma korzyści? Jasne, że jeśli mamy serię zapytań to warto z niego zrobić jedno triggerem ale chyba lepiej nie przesadzać i stosowac to tylko jeśli znacząco ma się przez to poprawić wydajność. SQL i PHP to tak samo języki skryptowe i nie wydaje mi się żeby przepuszczenie pętli przez trigger działało szybciej niż przepuszczenie jej przez PHP. No chyba że robimy pętlę zapytań To wtedy jak najbardziej trigger żeby za każdym razem nie zwracać wyników.

Ten post edytował Black-Berry 13.09.2008, 08:10:16

[chlebik]

Swego czasu było na forum dużo tematów o cachowaniu zapytań do bazy. Jak dla mnie to straszna głupota. Jeśli mamy system który tylko 10% czasu poświęca na zapytania to zwiększenie wydajności zapytań o 50% daje nam tylko 5% przyrostu wydajności całkowitej.

A co w przypadku aplikacji gdzie baza stanowi 90% Akurat mialem okazje glownie z takimi pracowac - jedna co prawda smigala na dedyku w firmie, a terminale staly obok wiec szybkosc spora. Ale Teraz z kolei pracuje przy tworzeniu aplikacji, ktora prawie w kazdej akcji ciagnie z bazy od cholery requestow - w tym momencie (pomimo poteznych serwerow, zarowno bazy jak i www, load-balancera i innych tego typu) wrzucanie rzeczy do cache'a jest nieunikniona koniecznoscia.

Ten post edytował chlebik 13.09.2008, 09:31:48

[kwiateusz]

no to chyba logiczne ze jak 90% aplikacji to baza to trzeba ja cachowac... mozna to łątwo wywnioskowac z wypowiedzi ~Black-Berry

[Sedziwoj]

Natomiast przenoszenie serwisu z jednej bazy na inną jest sprawą dość delikatną. Kiedyś jak byłem młodszy to jeszcze się w to bawiłem, ale aktualnie to klient musi spełnić wymagania sprzętowe, które zostają określone na samym początku zawarcia umowy. Przecież serwer to jest bardzo mała część ceny serwisu więc w ogóle nie ma mowy by dostosowywać się do tego co sobie kupił kiedyś klient.

No właśnie nie do końca, bo trafi Ci się olbrzymi klient korporacyjny, który używa w całej firmie jednego typu bazy, to dla widzimisię nie ustawi innej, bo musi mieć nowe osoby techniczne itp. itd. Więc czasem bywa że mimo dużych projektów, trzeba zmienić bazę na taką co klient chce.

Jak widać pojawia się problem z rzucaniem pewnych operacji na bazę, jeśli jest ona mocno obciążona. (teraz nie mam głowy aby to przemyśleć, zrobię to później)

Dorzucę jeszcze nie poruszoną rzecz w całej tej dyskusji, jeśli z tej bazy nie korzysta tylko stronka, ale też inne aplikacje, czyli mamy zintegrowany system. Bo wtedy jeśli jakieś operacje muszą być wykonane zawsze na bazie, to przy każdym dodaniu/zmianie trzeba przerabiać kod w co najmniej dwóch aplikacji, co będzie kłopotliwe, a jak to się znajdzie na poziomie bazy, to będzie wspólne miejsce i łatwe do utrzymania.
Jeszcze poruszę taką sprawę, że przy logice na poziomie bazy, da się pilnować operacje które są wykonywane bezpośrednio na niej, bez użycia kodu aplikacji.

[Black-Berry]

Faktycznie jeśli sa 2 aplikacje korzystające z jednej bazy to problem. Zastanów się jednak co by było gdybyś napisał tony triggerów i całą logikę biznesową wrzucił na bazę ? (bo tak wypadałoby zrobić w takim wypadku). Niby wygoda jest bo wszystko w 1 miejscu. Jeśli jednak wszystko zacznie zamulać to budzisz się z ręką w nocniku bo jedyne co pozostaje to replikacje bazy.

• zapytania / zapytania + system
• 0.1117s / 0.14639s
• 0.00585s / 0.04339s
• 0.00471s / 0.05692s
• 0.18388s / 0.25378s
• 0.00512s / 0.04048s
• 0.00507s / 0.04623s
• 0.3443s / 0.37961s
• 0.2653s / 0.29963s

To są czasy działania aplikacji na serwerze anzwa.pl. Zauważcie, że czas wykonywania systemu to ok. 0.004s. i jest w miarę stały. Czasy zapytań wariują. Wniosek z tego prosty, że tylko baza zamula. Tak jak już tu było wcześniej pisane. Wydaje mi się że bazy mySQL są mniej zoptymalizowane niż PHP. Gdyby było inaczej to czemu takie wyniki ?

[Sedziwoj]

@Black-Berry
Mówisz, jak duża część, o MySQL, ja częściej stosuję PostgreSQL, a to też jest czubek góry, bo przecież mamy inne bardziej zaawansowane bazy danych, o tym trzeba pamiętać, co jest dobre dla małych stron, a co może się przydać w dużych. Czasem taniej wyjdzie rozłożyć bazę danych na wiele serwerów, niż utrzymywać kod w samych aplikacjach.
Do tego czasem to co robią funkcje na bazie, wymagało by wielokrotnych odwołań do bazy, pobierających multum danych, więc nie jestem przekonany że zawsze było by szybciej.

[Black-Berry]

Oczywiście zgadzam się, że warto przerzucać część na bazę. Ja mówię z perspektywy mojego małego CMS'a którego już piszę 3 rok samodzielnie:) W dużych firmach bazami danych zajmują się nie programiści ale goście od bazy danych i to oni pisza triggery. (Mój kolega ze studiów np jest gościem od baz żeby nie być gołosłownym). Wielkie projekty używają baz oracl'a i zajmują się nimi specjaliści. Zwykli programiści zajmują się czym innym.

Patrząc z perspektywy CMS-ów opartych o php i mySQL nie obciążałbym bazy. Jeśli jednak robisz coś innego to czemu by nie. Jednak triggerami powinien się zająć programista baz danych. Nie wydaje mi się żeby jedna osoba mogła znać się na wszystkim.

[Cysiaczek]

Nie czasy zapytań, tylko połączenie i oczekiwanie na odpowiedź z bazy. To jest wąskim gardłem. Kiedyś sprawdzałem to empirycznie - nawet na localhoście skrypt php wykonuje się dłużej, jeśli akurat źle trafi z połączeniem. Same zapytania trwają zwykle podobnie. Nie wiem z czego to wynika, ale możecie sobie sami przetestować licząc międzyczasy.

Pozdrawiam

[Black-Berry]

To jest wąskim gardłem. Kiedyś sprawdzałem to empirycznie - nawet na localhoście skrypt php wykonuje się dłużej, jeśli akurat źle trafi z połączeniem.

łoooooo!! Nie wydaje się wam że to bardzo dziwne ? Jakiś bład apacha czy coś ? Nie można przecież tak poprostu źle trafić ?

[Cysiaczek]

To policz ile się wykonuje mysql_connect()

0.020272970199585
0.019511938095093
0.021259784698486
0.006248950958252
0.0003659725189209
0.021076917648315
0.020316123962402
0.021085023880005
0.021122217178345
0.021095991134644
0.020627975463867
0.020335912704468
0.024362087249756
0.021245002746582
0.021530151367188
0.022016048431396
0.003173828125
0.021080017089844
0.030810117721558
0.020860910415649

Oczywiście to jest desktop, nie serwer - na produkcyjnym rozrzut może być mniejszy i czasy też

[Black-Berry]

No to ja już nie wiem o co chodzi. To nie może przecież działać na zasadzie losowości. To komputer a nie reaktor jądrowy.