Sensowna iczba wpisow w tabeli...

[jakob]

Witam,

Takie proste pytanko: czy 20 000 wpisow w 1 tabeli 5 kolumnowej to duzo jak na MySQL'owa baze postawiona na serwerze www? Zapytania beda generowane po 2-3 kolumnach...

Bardzo prosze o odpowiedz kogos kto sie zna (a najlepiej ma doswiadczenie) bo musze zaprojektowac baze i tak by bylo najprosciej - tylko nie wiem czy user nie bedzie czekal na wyswietlenie wynikow 5 minut

[dodam jeszcze, ze wpisy beda mialy gora 10 znakow]

Pozdrowka,

jakob

[Erbit]

Jesli dobrze przemyslisz indeksy, to nie bedzie czekal nawet przy 40 000 rekordow... widze, ze chyba źle zamierzasz napisać zapytania sql...

[Mion]

Sprawdź empirycznie Zrób pętle z np. 1000 iteracji a w jej ciele zapytanie wstawiające średniej długości rekord do Twojej tabeli, wywołaj skrypt 20 razy aby uzyskać docelowo 20 tysięcy rekordów i masz już gotowe środowisko testowe. Jeszcze polecam zainstalowanie licznika czasu wykonywania kodu 8)

[mrtn]

odpowiem tak 20 000 zindeksowanych pól to tyle co NIC.

Ale nie znając zapytania nie odpowiemy ci dokładnie.

Zapytanie typu LIKE '%costam%' może mulić się już na tej ilości co podałeś.

Zapytanie typu Select * where pole_1=warunek_1 and pole_2=warunek_2 to PRYSZCZ nawet dla miliona dobrze zaindeksowanych rekordów.

Daltego też 20 000 to generalnie mało - pod warunkiem, że Twój przypadek nie jest "szczególny".

[mrtn]

P.S. Wszytko to działa kiedy mówimy o SELECT - UPDATE czy INSERT są wolniejsze - czasami bardzo wyraźnie.

[pabel]

i connect. Podłączenie do bazy - nie chcę skłamać, bo dawno to oglądałem ale trwa chyba 100 x jakiegoś całkiem sporego selecta. Jeśli złą wartość podałem - to sprostujcie.

[jakob]

Na poczatek - thx za odzew

No wiec tak - chce zrobic bardzo prosta statystyke wejsc dla 4 podstron i umiescic ja w jednej tabeli:

id_wejscia | dd | mm | rrrr | podstrona

przy czym to bedzie tabela dla 1 roku (zakladajac srednio 20 wejsc dziennie X 365 dni X 4 podstrony = 20 do 30 tys wejsc rocznie). 1go stycznia rok bedzie kompaktowany do innej tabeli z samymi juz tylko przeliczonymi wynikami. Natomiast zapytanie bedzie pokazywalo ilosc odwiedzin w poszczegolnych dniach miesiaca/ poszczegolnych miesiacach roku / latach.

Na marginesie dodam, ze (jaka-taka) dokladnosc chce osiagnac przez ciastka.

Co o tym myslicie (w konteksie pierwotnego pytania of kors)?

Pozdrowka,

jakob

[Hellz]

Jeżeli tabela ma się przedstawiać w ten sposób, to ja powiem: śmiało na ciało

[pabel]

No wiec tak - chce zrobic bardzo prosta statystyke wejsc dla 4 podstron i umiescic ja w jednej tabeli:

id_wejscia | dd | mm | rrrr | podstrona

przy czym to bedzie tabela dla 1 roku (zakladajac srednio 20 wejsc dziennie X 365 dni X 4 podstrony = 20 do 30 tys wejsc rocznie).

Może warto na hostscript poszukać jakiś rozwiązań "od ręki" ? Pewnie różnych "statów" jest jak "mrówków"

[Hellz]

Poszukać, poszukać, a potem się nic własnego nie umie napisać. Najlepiej zacząć właśnie od takich prostych statów, rozbudować, rozbudować... i przy okazji podszkolić się z programowania.

[mrtn]

dokładnie - Do potrzeb statów możesz pozwolić sobie na dłuższe zapytania bo robisz je kilka razy na dzień a nie przy każdym odświeżeniu strony.

Przynzam się, że moeje pierwsze STAT-TABELE osiągneły MILION rekordów zanim porządnie wziąłem się z automatykę. Dzisiaj naaktywniejsze staty są auto-podsumowywane co 12 godzin :-).

[pabel]

Poszukać, poszukać, a potem się nic własnego nie umie napisać. Najlepiej zacząć właśnie od takich prostych statów, rozbudować, rozbudować... i przy okazji podszkolić się z programowania.

Jeśli masz dużo czasu ...

Ale jeśli nie ...

Jeśli ktoś udostepnia na licencji GPL fajny skrypt, który sam musiałbym tworzyć np. pół roku (podobna funkcjonalność) ... to tnę, kroję, wstawiam swoje ... na co licencja GPL pozwala. I wziuuu - odpalam.

[burzam]

a ja tam zawsze wolalem poswiecic te pol roku...

to procentuje, zareczam

[Elf]

a ja tam zawsze wolalem poswiecic te pol roku...

to procentuje, zareczam

76827[/snapback]

Zalezy od poziomu zaawansowania. Dla poczatkujacego to jest prawda. Dla zaawansowanego, przy projektach o duzej zlozonosci, umiejetnosc uzywania gotowego kodu (klasy, fragment, gotowce) ma kluczowe znaczenie. Szczegolnie gdy wazny jest czynnik czasu.

[br]

20tys to jest nic. Mam bazę prawie 2GB, największe tabelki po kilka milionów rekordów i raczej nie mam problemów z wydajnością. Zapytania typu like '%ble%' dla tabelki ok. miliona rekordów działają ułamki sekund (pole długości 40-50 znaków) pod warunkiem, że tabelka mieści się w RAMie, inaczej hardcore, musi ciągnąć wszystko z dysku. Jeśli dobrze ułożysz indeksy wszystko będzie zasuwać (nawet po dysku), problem w tym, ze MySQL ma czasem ograniczone możliwości pod tym względem. Choć przy 20tys jeśli tylko nie ułożysz mocno zagnieżdzonych selectów to cobyś nie robił będzie śmigać.

ps. Połączenia do bazy apache może trzymać otwarte, nie trzeba nawiązywać nowego przy każdym ściaganiu stronki.