[MySQL] mnostwo drobnych rekordow

0

Mam sobie baze z roznymi tabelami - np. lista typow telefonow (np. nokia z symbianem S60/S80, nokia S40 series) i lista gier...

Jest taka, w ktorej trzymam informacje, ktora gra pasuje do ktorego telefonu. W zwiazku z tym, ze gier (i jeszcze logosow, dzwonkow itp) jest sporo, a kazda pasuje do kilku telefonow, tabela sie niezle mi rozrosla - 10 mega danych i 20 mega indeksow...

struktura tabeli (1,1 miliona rekordów):

message mediumint, //max 3 miliony
type smallint, //max 400
cat smallint, //max 270
PRIMARY KEY  (message,type),
KEY cat (cat),
KEY type (type)

typ: MyISAM
message - id gry / logosa itp
type - id grupy telefonow
cat - kategoria w grupie telefonow (np. gry akcji, zrecznosciowe itp)

moje pytanie - czy dobrze zaprojektowalem tabele? Nie będzie ona często aktualizowana (raz na miesiąc), więc szybkość insertów / update nie ma znaczenia. Najważniejsza jest szybkość odczytu, następnie rozmiar

jak wykorzystuje tą tabele: zapytania beda jednego z dwóch rodzajów:

SELECT message FROM tabela WHERE type = 123 LIMIT 10,10
SELECT message FROM tabela WHERE (type = 123) AND (cat = 456) LIMIT 10,10

moje pytania:

  • jaki najlepiej użyć do tego celu mechanizm składowania danych?
  • czy dobrze założyłem indeksy? może jakieś są zbędne, lub czegoś brakuje?
0

Zasada tworzenia dobrych tabel jest prosta. Dla karzego obiektu wyobrazonego czy prawdziwego tworzy sie jedna tabele. I np. dla telefonu tworzysz jedna, gdzie sa informacje podstawowe jak model, waga itp. Nie dodaje sie do nich informacji o np. pasujacych grach gdyz wplywa to redundancje danych (wielokrotne powtarzanie tej samej gry w wielu aparatach). Dlatego dla gier tworzy sie oddzielna tabele, ktora jest porpostu powiazana na zasadzie relacyji miedzy tymi tabelami. W tym przypadku jeden do wielu - kilka telefonow moze obslugiwac ta sama gre. I tak dalej.

0
  1. masz bardzo dziwny sposób nazywania kolumn - w ogóle nie adekwatny do danych, które tam są ...
  2. ja bym zrobił tak
    telefony
    =======
    *telefon_id
    #grupa_id *
    cech_1
    cech_2
    cecha_x

indeksy
prim_key telefon_id

  • jeśli w grupie telefonu jest zapisane coś więcej oprócz jej nazwy to tak, a jak sama nazwa to można ją wrzucić do tabeli telefony, chociaż jest to nie zalecane

gry

*gra_id
typ_gry
opis
cecha_1
cecha_x

indeksy
prim_key gra_id

i połączenie

gra_tel

#telefon_id
#gra_id

nie potrzeba tu sztucznego klucza obcego
indexy
prim_key (telefon_id, gra_id) - i tak musi taki być a raczej niewskazane jest przypisanie więcej niż raz gry do telefonu
idx_1 gra_id - musi być jeśli chcesz znaleźć np. wszystkie telefony, na których możesz odpalić grę xxx

Do tej tabeli nie powinieneś wsadzać nić innego (no chyba, że masz jakieś cechy lub dane, które można określić TYLKO mając obie, tj telefon_id i gra_id, wartości.

Co do szybkości to nie wiem, czego używasz do połączenia z bazą ale poszukaj czegoś w stylu queryanalizer lub plananalyzer. Nic więcej nie mogę powiedzieć o indexach bo nie znam ani pełnych struktór tabel ani zapytań.

Ogólnie zasada jest taka, że indeks powinien być na każdej kolumnie, która występuje w warunku (WHERE, czy też po ON w złączeniach) lub po których sortujesz lub grupujesz. Jednak jeśli jakaś kolumna występuje w zapytaniu, które jest wykonywane kilka razy na dzien i to czy będzie się wykonywać 0,5 czy 2 sekundy nie ma wielkiego znaczenia, a w tablei z tą kolumną jest dużo danych to czasami lepiej sobie odpuścić indeks na takiej tabeli.

PS. 20, 40 czy nawet 100MB bazy to nie są duże bazy, to nawet nie są średnie, a fakt, że u poprzednika zapytania działały po ponad 1s świadczy o jego "wiedzy"

0

zniknal moj post, a nie dostalm maila, wiec wnioskuje, ze to blad systemu?

nie wiem, na co mi chcesz zwrocic uwage - ta tabela to sa wlasnie powiazania telefonow z grami. Chodzi Ci moze o dodatkowe pole cat?

chcialbym zaznaczyc, ze znam pojecie redundancja, relacyjnosc bazy danych ;). A na kurczowym trzymaniu sie oszczednosci miejsca polegl poprzedni programista zajmujacy sie tym projektem - u niego wyciagniecie potrzebnych danych zajmowalo po 2-3s, u mnie jest to czas rzedu setnych sekundy. Oszczednosc miejsca? moja baza zajmuje 4x wiecej, jego dziala 400x wolniej :D

podsumowujac: ta tabela nie ma byc "dobra", ma byc szybka...

i dodatkowe pytanie - co da usuniecie klucza glownego? (z juz wprowadzonymi danymi do tabeli)

a poza tym struktura bazy jest juz calkiem inna, zmienily sie dane wejsciowe...

co do rozmiaru - skoro 120mb / 1 milion rekordow to mala baza (dane wejsciowe), to jaka bylaby srednio-mala? ;) (zeby nie bylo - zdaje sobie sprawe, ze to duza baza nie jest)

pytam co da usuniecie klucza glownego, poniewaz po aktualizacji bazy nic sie w niej nie zmienia, wiec pilnowanie, czy przypadkiem nie ma 2 takich samych mija sie z celem?

a kolumny nazwalem adekwatnie do oznaczenia kolumn w bazie wejsciowej...

nie potrzeba tu sztucznego klucza obcego

??

co do czasow dzialania - teraz na moim serwerze jak sie strona generuje w 2-3s (w tym 0.5-2s na samo polecenie mysql_connect()) to jest szybko :/. Takie phpbb przema generuje sie w 20s :[

0
tomkiewicz napisał(a)

co do rozmiaru - skoro 120mb / 1 milion rekordow to mala baza (dane wejsciowe), to jaka bylaby srednio-mala? ;) (zeby nie bylo - zdaje sobie sprawe, ze to duza baza nie jest)
no to powiedzmy, że to jest średnio mała.

pytam co da usuniecie klucza glownego, poniewaz po aktualizacji bazy nic sie w niej nie zmienia, wiec pilnowanie, czy przypadkiem nie ma 2 takich samych mija sie z celem?
tu nie wiem o co Ci chodzi bo nie wiem do czego się to odnosi

a kolumny nazwalem adekwatnie do oznaczenia kolumn w bazie wejsciowej...
to pogratulować twórcy pierwowzoru...

nie potrzeba tu sztucznego klucza obcego
??
no a czego nie rozumiesz w tym stwierdzeniu?

0
Misiekd napisał(a)

pytam co da usuniecie klucza glownego, poniewaz po aktualizacji bazy nic sie w niej nie zmienia, wiec pilnowanie, czy przypadkiem nie ma 2 takich samych mija sie z celem?
tu nie wiem o co Ci chodzi bo nie wiem do czego się to odnosi

w skrocie - mam sobie tabele z kluczem, laduje do niej dane (czyli polaczenia telefon-gra). Czy po zakonczeniu importu moge wywalic klucz? chyba nie bedzie potrzebny (i tak jest zalozony indeks i na telefon i na gre)

Misiekd napisał(a)

to pogratulować twórcy pierwowzoru...

wapster.pl... na szczescie ostatnio zmienili baze na "normalniejsza"

0

indeksy musisz mieć dwa ale nie takie jak masz tylko takie jak Ci napisałem wcześniej

prim_key (telefon_id, gra_id) - i tak musi być, a przy okazji można go zrobić głównym to wyłapie wszystki duble
idx_1 (gra_id)

0

a wyjasnisz, dlaczego akurat indeks na dwie kolumny, a nie tylko na telefon? Skoro we "where" mam tylko telefon?

Poza tym dlaczego musi byc - jest bez i dziala :D

no i jak pisalem nie zalezy mi na wychwytywaniu dubli - nie ma takiej mozliwosci, zeby powstaly

cos czuje, ze nie jestes przyjaznie nastawiony ;). a moze to moje przemeczenie...

0
tomkiewicz napisał(a)

a wyjasnisz, dlaczego akurat indeks na dwie kolumny, a nie tylko na telefon? Skoro we "where" mam tylko telefon?

no ale ja tam widziałem też zapytanie z warunkiem na dwóch kolumnach :>

Poza tym dlaczego musi byc - jest bez i dziala :D

wiesz działa a DZIAŁA to dwie różne rzeczy :)

no i jak pisalem nie zalezy mi na wychwytywaniu dubli - nie ma takiej mozliwosci, zeby powstaly

jak to mówią przezorny zawsze ubezpieczony a jeśli jeszcze dodatkowo nic nie tracisz bo sprawdzanie jest niejako "przy okazji" to tylko się cieszyć

cos czuje, ze nie jestes przyjaznie nastawiony ;). a moze to moje przemeczenie...

ale dlaczego - po prostu mam wrażenie, że nie czytasz co piszę :)

jeszcze raz co do indeksów. A więc jak masz tabele z polami dwoma polami, nazwijmy je a i b to indeks taki
idx_1 (a, b) załątwia Ci zapytania w których po WHERE (lub ON w złączeniach) masz obie kolumny (kolejność nie gra roli, a przynajmniej na lepszych bazach) oraz zapytania gdzie po WHERE (ON w złączeniach) jest kolumna a. Jeśli po WHERE (ON) masz b to indeks ten nie jest używany i trzeba dla takich przypadków założyć drugi indeks tylko na kolumnie b

Jak pisałem gdzieś wcześniej bez zapytań nie doradzę Ci nic więcej w sprawie indeksów

1 użytkowników online, w tym zalogowanych: 0, gości: 1