mysql+php - =?ISO-8859-2?Q?wydajno=B6=E6_przy_olbrzymiej_i?==?ISO-8859-2?Q?lo=B6ci_rekord=F3w?=
Mik - 28-08-2007 00:07
mysql+php - =?ISO-8859-2?Q?wydajno=B6=E6_przy_olbrzymiej_i?==?ISO-8859-2?Q?lo=B6ci_rekord=F3w?=
Witam!
Mam kilka tabel powiązanych ze sobą. Na nich użytkownicy wykonują
zapytania (wyszukiwarka na stronie). Jedna z tabel będzie mieć w
przyszłości kilkadziesiąt tysięcy rekordów. Nie mam pomysłu jak zrobić
wyszukiwanie po takich wielkich tabelach.. staram się generalnie całe
obciążenie przy wyszukiwaniu przerzucić na mysql - czyli nie robię
czegoś w rodzaju:
while($odp=mysql_fetch_array($pyt))
{
$pyt2=$query......
$odp2=mysql_fetch....
....
}
to tylko przykład, korzystam z funkcji adodb, to przedstawiłem tak obrazowo.
Nie mam pomysłu jak to zorganizować. Zastanawiałem się nad stworzeniem
tabeli w której dla danej sesji (w php) są przechowywane wyniki.. Tylko
qrcze nie mam czasu za bardzo na poszukiwanie sposobów :((( Macie jakieś
rozwiązania?
Chyba, że obciążenie mysql przy takiej ilości rekordów jest pomijalne..
aczkolwiek w to wątpię...
pozdr.
Mik
red - 28-08-2007 00:07
Mik pisze:
> Nie mam pomysłu jak to zorganizować.
Kwestia napisania dobrych zapytań. Ale bez schematu to sobie można...
> Chyba, że obciążenie mysql przy takiej ilości rekordów jest pomijalne..
> aczkolwiek w to wątpię...
Ostatnio robiłem wyszukiwanie (niezbyt zoptymalizowane, z jakimiś
cudacznymi joinami, bo nie było czasu :) ) dla bazy ponad 60tys rekordów
i nie widzę żadnego problemu z wydajnością.
Mik - 28-08-2007 00:07
red pisze:
> Mik pisze:
>> Nie mam pomysłu jak to zorganizować.
>
> Kwestia napisania dobrych zapytań. Ale bez schematu to sobie można...
>
hmm.. musiałbym wkleić konstrukcję tabeli tutaj? :-)
>> Chyba, że obciążenie mysql przy takiej ilości rekordów jest
>> pomijalne.. aczkolwiek w to wątpię...
>
> Ostatnio robiłem wyszukiwanie (niezbyt zoptymalizowane, z jakimiś
> cudacznymi joinami, bo nie było czasu :) ) dla bazy ponad 60tys rekordów
> i nie widzę żadnego problemu z wydajnością.
ekstra :) Także póki co olewam, bo strasznie tragicznie mnie
przycisnęło.. Najwyżej później będę robić poprawki.
Ostatecznie rozbijam na 3 zapytania - wyniki z jednego są użyte w drugim
(where galid in $poprzedni_wynik) - zrobiłem tak, ponieważ tylko jedna
tabela będzie gigantem, pierwsze zaptanie zwróci max 40 wyników, drugie
około 200, a 3 resztę.. tak mi wyjdzie najszybciej..
pozdr.
Mik
chester - 28-08-2007 00:07
Mik pisze:
> Mam kilka tabel powiązanych ze sobą. Na nich użytkownicy wykonują
> zapytania (wyszukiwarka na stronie).
> Jedna z tabel będzie mieć w
> przyszłości kilkadziesiąt tysięcy rekordów. Nie mam pomysłu jak zrobić
> wyszukiwanie po takich wielkich tabelach..
To jest mikrotabelka ;-)
Duże to mają po 2 000 000 rekordów i więcej :-)
Ja bym w ogóle olał ten akurat aspekt przy takiej ilości przeszukiwanych
rekordów, przy dzisiejszych procesorach większym problemem będzie bardzo
duża ilość użytkowników niż rozmiar tabeli.
> Nie mam pomysłu jak to zorganizować. Zastanawiałem się nad
> stworzeniem tabeli w której dla danej sesji (w php) są przechowywane
> wyniki.. Tylko qrcze nie mam czasu za bardzo na poszukiwanie sposobów
> :((( Macie jakieś rozwiązania?
Nie wiem, w czym piszesz. Ale jeśli to dość statyczna wyszukiwarka, to
może skuś się na coś w stylu Zend_Cache?
Można sobie podebrać samo 'keszowanie' bo jest dość niezależne od reszty
Zend_Framework i użyć - zapewne przyspieszy choć to raczej przy bardzo
dużej ilości zapytań, a nie przy takiej ilości rekordów.
> Chyba, że obciążenie mysql przy takiej ilości rekordów jest pomijalne..
> aczkolwiek w to wątpię...
To nie wątp. Jeśli nie jest pomijalne to zmień serwer :-) Bo IMO powinno
być to pomijalne.
A zajechać bazę można i 10 rekordami jak zapytanie jest odpowiednio
nieoptymalne ;-)
chester
red - 28-08-2007 00:08
Mik pisze:
> ekstra :) Także póki co olewam, bo strasznie tragicznie mnie
> przycisnęło.. Najwyżej później będę robić poprawki.
Dokładnie tak :-) Jak Ci bazka stuknie z milion rekordów, wtedy się
pomartwisz.
> Ostatecznie rozbijam na 3 zapytania - wyniki z jednego są użyte w drugim
> (where galid in $poprzedni_wynik) - zrobiłem tak, ponieważ tylko jedna
> tabela będzie gigantem, pierwsze zaptanie zwróci max 40 wyników, drugie
> około 200, a 3 resztę.. tak mi wyjdzie najszybciej..
Zrzuć jak najwięcej na bazę danych. PHP jest wolniejsze od silnika bazy,
więc zrób podzapytania, a nie rozbijaj na 3 oddzielne.
Exe Very Cute - 28-08-2007 00:08
red pisze:
> Zrzuć jak najwięcej na bazę danych. PHP jest wolniejsze od silnika bazy,
> więc zrób podzapytania, a nie rozbijaj na 3 oddzielne.
No jest to prawda co piszesz, jednak nie zawsze takie rozwiązanie jest
najbardziej optymalne. Np. masz serwer bazy i serwer aplikacji. Serwer
bazy ma load 1.8 a aplikacji 0.6. Co robisz? ;] Bo ja zrzucam część
obowiązków na skrypty, a w ogóle to cacheuję, cacheuję, cacheuję...
Pozdr
Exe Very Cute
red - 28-08-2007 00:08
Exe Very Cute pisze:
> No jest to prawda co piszesz, jednak nie zawsze takie rozwiązanie jest
> najbardziej optymalne. Np. masz serwer bazy i serwer aplikacji. Serwer
> bazy ma load 1.8 a aplikacji 0.6. Co robisz? ;] Bo ja zrzucam część
> obowiązków na skrypty, a w ogóle to cacheuję, cacheuję, cacheuję...
Co robię? Zmieniam serwery? :-) Nie no, tak ja piszesz zależy to od
konkretnej sytuacji. Choć poważne hostingi powinny sobie z tym radzić w
taki sposób, że najsilniejsze są właśnie serwery pod BD.
A SBD nie mają przypadkiem jakichś algorytmów cacheowania zapytań?
=?ISO-8859-2?Q?Rafa=B3_Korszu=F1?= - 28-08-2007 00:08
Exe Very Cute pisze:
> red pisze:
>
>> Zrzuć jak najwięcej na bazę danych. PHP jest wolniejsze od silnika bazy,
>> więc zrób podzapytania, a nie rozbijaj na 3 oddzielne.
>
> No jest to prawda co piszesz, jednak nie zawsze takie rozwiązanie jest
> najbardziej optymalne. Np. masz serwer bazy i serwer aplikacji. Serwer
> bazy ma load 1.8 a aplikacji 0.6. Co robisz? ;] Bo ja zrzucam część
> obowiązków na skrypty, a w ogóle to cacheuję, cacheuję, cacheuję...
>
> Pozdr
> Exe Very Cute
>
JA postępuję tak zrzucam max na bazy danych a wyniki zapytań keszuje na
maksymalny dostępny czas
Rafał
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.lang.php
Exe Very Cute - 28-08-2007 00:08
Rafał Korszuń pisze:
>
> JA postępuję tak zrzucam max na bazy danych a wyniki zapytań keszuje na
> maksymalny dostępny czas
Podobnie jak ja, ale zauważ że sam mechanizm cacheu jest to także nic
innego jak zrzucenie części obowiązków na skrypty. Oszczędzając na
ilości zapytań powodujesz konieczność obliczania np. CRC/MD5 dla bloków
cacheu przy ich pobieraniu (czyt. identyfikowaniu przed pobraniem),
i/lub konieczność przeprowadzania operacji na plikach.
Ale to oczywiście tu tylko doprecyzowuję. No i chcąc być konsekwentnym,
to powiem że cache nie tylko ustawia się na określony z góry czas, ale
także na np. czas modyfikacji plików/rekordów źródłowych, pewnych
wykonywanych akcji, etc.
Pozdr
Exe Very Cute
Exe Very Cute - 28-08-2007 00:08
red pisze:
> Choć poważne hostingi powinny sobie z tym radzić w
> taki sposób, że najsilniejsze są właśnie serwery pod BD.
No to już sobie kupujesz taką maszynę jaką potrzebujesz... ja tam raczej
z gotowców nie korzystam ;]
> A SBD nie mają przypadkiem jakichś algorytmów cacheowania zapytań?
A to już pewnie zależy od technologii. Jeśli masz serwer z mysql to
pewnie trzeba by dopiero poszukać jakiś narzędzi do cacheowania lub
tworzyć je samemu, a postgres ma (ponoć) ładnie zaimplementowane
cacheowanie powtarzających się zapytań. Jestem też na 100% przekonany,
że bardziej komercyjne rozwiązania jak MSSQL czy Oracle dostarczają
gotowych rozwiązań cacheujących, choć nie używałem nigdy Oracle, a MSSQL
na niewielką skalę.
Może ktoś się wypowie w kwestii Oracle, ja się nie czuję ŻTP "na siłach" ;]
Pozdr
Exe Very Cute
chester - 28-08-2007 00:08
red pisze:
> Zrzuć jak najwięcej na bazę danych. PHP jest wolniejsze od silnika bazy,
> więc zrób podzapytania, a nie rozbijaj na 3 oddzielne.
Tu bym polemizował, niektóre silniki BD (w szczególności MySQL we
wcześniejszych wersjach) potrafiły mieć taki narzut na podzapytania, że
zdecydowanie szybciej było zrobić zapytanie, pobrać wynik i w pętli
wykonać podzapytanie.
IMO warto, szczególnie przy _nieco_ starszych BD sprawdzić czas
wykonania dla obu wariantów, bo można się nieźle zdziwić.
chester
red - 28-08-2007 00:08
chester pisze:
> Tu bym polemizował, niektóre silniki BD (w szczególności MySQL we
> wcześniejszych wersjach) potrafiły mieć taki narzut na podzapytania, że
> zdecydowanie szybciej było zrobić zapytanie, pobrać wynik i w pętli
> wykonać podzapytanie.
Nie jestem do końca pewien, ale w starszych wersjach MySQL chyba w ogóle
nie było obsługi podzapytań ;-) A procedury składowane dopiero od 5
wersji wprowadzili. I te procedurki to jedno z lepszych wyjść, jeśli
chce się 'karkołomne' operacje na danych wykonywać.
chester - 29-08-2007 00:10
red pisze:
> chester pisze:
>> Tu bym polemizował, niektóre silniki BD (w szczególności MySQL we
>> wcześniejszych wersjach) potrafiły mieć taki narzut na podzapytania,
>> że zdecydowanie szybciej było zrobić zapytanie, pobrać wynik i w pętli
>> wykonać podzapytanie.
>
> Nie jestem do końca pewien, ale w starszych wersjach MySQL chyba w ogóle
> nie było obsługi podzapytań ;-) A procedury składowane dopiero od 5
> wersji wprowadzili. I te procedurki to jedno z lepszych wyjść, jeśli
> chce się 'karkołomne' operacje na danych wykonywać.
Nie było. Ale pierwsze wersje, w których były to... cóż, lepiej żeby w
nich też ich nie było ;-)
W każdym razie nie robiłem ostatnio poważnych testów, bo i konieczność
jakichś wymyślnych podzapytań nie pojawia się co chwilę, ale jakiś rok
temu, albo i mniej, wygenerowałem potwora ;-) A wykonanie z
pośrednictwem php i pętli skróciło czas ok. 25 razy :-)
Dlatego moim zdaniem przy bardziej skomplikowanych zapytaniach z
podzapytaniami warto w przypadku MySQL sprawdzić oba warianty,
oczywiście zaczynając od testu rozwiązania z podzapytaniem. Nie musi być
źle (i chyba z ostatnimi wersjami _raczej_ już nie będzie), ale
najzwyczajniej w świecie może się tak zdarzyć, że szybciej będzie 'na
około'.
chester
=?ISO-8859-2?Q?Rafa=B3_Korszu=F1?= - 29-08-2007 00:10
Exe Very Cute pisze:
>
> Podobnie jak ja, ale zauważ że sam mechanizm cacheu jest to także nic
> innego jak zrzucenie części obowiązków na skrypty. Oszczędzając na
> ilości zapytań powodujesz konieczność obliczania np. CRC/MD5 dla bloków
> cacheu przy ich pobieraniu (czyt. identyfikowaniu przed pobraniem),
> i/lub konieczność przeprowadzania operacji na plikach.
> Ale to oczywiście tu tylko doprecyzowuję. No i chcąc być konsekwentnym,
> to powiem że cache nie tylko ustawia się na określony z góry czas, ale
> także na np. czas modyfikacji plików/rekordów źródłowych, pewnych
> wykonywanych akcji, etc.
>
> Pozdr
> Exe Very Cute
>
dlatego w chwili obecnej mam 3 warstwy keszy:
1. pamięć współdzielona pomiędzy skryptami w ramach 1 domeny (średniej
długości - pomocna przy minimalizacji krytycznych operacji -dostęp do
dysku bazy danych)
2. kesz dyskowy (najdłuższy zależny uzależniony od czynników biznesowych)
3. kesz poziomu bazy danych.
strategią przyjętą w mojej firmie jest keszowanie całych stron ew bloków
stron do kesza dyskowego, wszystkich zapytań sql'owych do pamięci
współdzielonej, a kesze poziomu baz danych pomagają nam rozładować
zapytania w czasie.
ogólnie u nas taka sytuacja była na tyle dobra, że mieliśmy sporą ilość
użytkowników przeglądających te same strony.
czynnikami które spowalniają taki model keszowania są na pewno zbyt duża
liczba plików w katalogach keszy (zwiększa się czas dostępu do keszy,
loda serwera wzrasta), oraz zbyt duża liczba małych kawałków
zaalokowanej pamięci współdzielonej, taki sam efekt uboczny jak z
keszami dyskowymi.
tak więc używani wszystkich tych mechanizmów zależy od zdrowego rozsądku.
Pozdrawiam Rafał
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.lang.php
Tomasz =?UTF-8?Q?Pi=C5=82at?= - 27-10-2007 00:00
Exe Very Cute <kshksh@poczta.xonet.pl> wrote:
>> A SBD nie mają przypadkiem jakichś algorytmów cacheowania zapytań?
>
> A to już pewnie zależy od technologii. Jeśli masz serwer z mysql to
> pewnie trzeba by dopiero poszukać jakiś narzędzi do cacheowania lub
> tworzyć je samemu,
Panie, cóż za androny Pan opowiada.
http://dev.mysql.com/doc/refman/5.1/en/query-cache.html. Query cache
jest od wersji 4.1, a od 5.1.17 obsługuje wreszcie 'prepared statemetns'.
Tylko koniecznie trzeba dokładnie przeczytać manual, bo mechanizm cache
jest dość fikuśny, trzeba o nim pamiętać przy projektowaniu zapytań. Źle
użyty może w specyficznych sytuacjach bardzo zwolnić zwracanie wyników.
Ponc
--
Kto misiowi urwał ucho?
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Gdzie MySQL 4.1, a gdzie 5.0?
[MS SQL] "set names" (mySQL) w MS SQL
oracle -> oracle lub oracle -> mysql replikacja - programy
[mysql 4.0] SELECT t1.id, t1.foo FROM t1 oraz COUNT t2 w jednym zapytaniu.
[MySQL] Zwrot tego, co pasuje i nie pasuje :-/
[pgsql] Dostosowanie składni MySQL 5.0 -> PGSQL 8.1
[mysql] galeria zdjec - numerowanie zdjec
[MySQL] Zapytanie z pliku , wynik do pliku
[mysql] CONCAT agregujący, ale nie GROUP_CONCAT()
mysql data 0000-00-00 na koniec
zanotowane.pldoc.pisz.plpdf.pisz.plmarcelq.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 |
|
