Strona 1 z 2 12 OstatniOstatni
Pokaż wyniki od 1 do 10 z 19

Wątek: Odpicuj swoją bazę danych

  1. #1
    Zarejestrowany
    Dołączył
    Oct 2007
    Posty
    450

    Domyślnie Odpicuj swoją bazę danych

    Baza danych była zawsze jedną (z wielu) pięt achillesowych silnika Vallheru. Wiele zapytań zajmujących pamięć przez co mało który darmowy (a czasem nawet komercyjny) Host chciał otrzymywać nasz serwer.
    Jest jednak kilka prostych sztuczek, które mogą nam pomóc. Nie oferuję jakiegoś znacznego skoku wydajnościowego, ale zawsze jednak coś.

    Zacznijmy od podstawowych spraw:
    1) Ograniczanie zakresów ID w bazach:
    Zasięg wartości wielu rekordów w bazie jest stanowczo zawyżony. We??my na przykład tabelę players. Pole id to INT(11). Takie pole przechowuje wartości całkowite od 0 - 4 294 967 295 (lub około połowa tego gdy są wartości ujemne, ale to nie ma znaczenia). Powiedzmy sobie szczerze, czy kiedykolwiek będziemy mieć 4 miliardy graczy? Oczywiście, że nie! Id w aktualnej formie zajmuje 4 bajty pamięci. Jest na to bardzo prosty ratunek. Zmienić zakres na SMALLINT(5). Ta wartość przechowa nam 65 535 różnych numerów id co jest według mnie zupełnie wystarczającą wartością. Oszczędzamy aż 50% pamięci.
    Zamiana jest bardzo prosta. Uruchamiamy phpMyAdmina, otwieramy strukturę bazy players i obok wiersza id klikamy na uroczy . Wewnątrz INT wystarczy zmienić na SMALLINT a 11 na 5 (poniżej). Zatwierdzamy i gotowe.

    Ale to nie wszystko. Przeglądając bazy danych można dojśc do wniosku, że wszystkie ID (lub owner, zależnie od tabeli) większości baz danych zmieszczą się spokojnie w wartości SMALLINT. Możemy tą regułę zastosować prawie wszędzie. Uwaga! Wyjątkiem byłyby tabele chat, mail, equipment, log, logs. Jednak tam wystarczy MEDIUMINT(6 lub 7).

    Oczywiście nie należy poprzestawać na ID. Jest jeszcze wiele pól którym twórcy dali zbyt dużo miejsca, które nigdy nie zostanie wykorzystane. Na podobnej zasadzie polecałbym przejrzeć lwią część tabel i zmniejszyć zakresy INTów. Ja już nie pamiętam ale u mnie było ich chyba koło 50.

    Podobnie można się zastanowić nad typami Double. Czy wartość 11 nie jest zbyt duża? W większości przypadków DOUBLE(7,2) będzie w zupełności wystarczające a i tak przesadzone.

    2) Indeksy:
    Indeksowanie pól tabeli przyśpiesza wyszukiwanie względem tych pól w klauzuli WHERE. Indeksowanie to nic innego jak sortowanie wartości tabeli względem tego pola. Oczywistym jest więc, że łatwiej znale??ć liczbę 1234 w 10 000 liczb posortowanych od najmniejszej do największej, niż gdyby tego sortowania nie było. Ale dopisanie liczby 1234.5 do naszego zbioru już takie łatwe nie będzie bo nie możemy tej liczby wstawić byle gdzie. Musi wylądować na swoim miejscu.

    To cała idea indeksowania. Sortowanie przyśpiesza wykonywanie zapytań względem posortowanego pola (SELECT ... WHERE ...) ale spowalnia zapytania UPDATE, INSERT czy DELETE i zwiększa przestrzeń na dysku, jaką potrzebuje baza.
    Na swoje szczęście MySQL sam generuje indeksy dla najczęstszych odwołań. Jednak warto go sprawdzać pod tym kątem bo nie zawsze robi to trafnie. Dobrym pomysłem jest też przewidzenie względem których pól będziemy w danej tabeli wyszukiwać. Najczęstszemu polecam nadać PRIMARY KEY (przy tworzeniu tabeli - ), a reszcie mniej ważnych INDEX. Tylko pamiętajcie by nie przesadzić! Najczęściej wykonujemy zapytania select. Ale są tabele, do których częściej się zapisuje dane niż je pobiera. Tam nie ma sensu ustawiać wielu Indeksów.


    3) Optymalizacja zapytania:
    Przejd??my teraz do samych skryptów. Chcę tu powiedzieć w sumie o jednej rzeczy, mianowicie LIMIT. Wiele jest takich zapytań, że pobieramy z nich tylko jeden rekord. W większości przypadków (na szczęście nie w każdym) baza po wyszukaniu jednego pasującego rekordu... szuka dalej kolejnych! Ona nie jest tak mądra jak my i nie wie, że pasująca wartość może być jedna (no chyba że jest na niej Primary Key albo UNIQUE INDEX). Trzeba jej na to zwrócić uwagę. A jest to proste. Jedną z metod jest dodanie na końcu zapytania: LIMIT 1
    Wtedy baza wie, że jak znajdzie wartość to nie musi szukać kolejnych co oczywiście oszczędza nam zmarnowanego czasu.
    Pierniki górą!

  2. #2
    Grupa MmoCenter Awatar Kiri
    Dołączył
    Sep 2007
    Posty
    1,741

    Domyślnie

    1 - Na dzień dzisiejszy to są drobnostki bo i tak niewiele to da miejsca, a tego to dostajemy od hostów pod dostatkiem...

    Zdecydowanie więcej zajmują wszelakie teksty (varchar i text) - ot taki przykład ode Mnie gdzie poczta to średnio 85-90% całej wielkości bazy - jedna wiadomość to zeżre więcej miejsca niż zmienianie tych wszystkich int'ów na mniejsze...

    I nad mediumint'em dla mail by się dwa razy zastanowiła czy wystarczy (u Mnie doszło do wartosci milionowych po kilku miesiącach). Chyba że czyścimy poczte truncate'm. (ale nie DELETE'm!)


    2 - Trzeba jeszcze wiedzieć CZYM rózni się PRIMARY KEY od zwykłego INDEXu... bo ten pierwszy jest jeszcze UNIKATOWY i daje możliwosc dodania auto_zwiększania wartości przy insercie bo nie zawsze się stosuje primary key
    Sio, nie pomagam via PM !



  3. #3
    Aktywny
    Dołączył
    Jul 2008
    Posty
    866

    Domyślnie

    To akurat nie jest największy problem Vallheru.
    Po prostu ILO??? ZAPYTA?? jest wrogiem.

    Są zapytania w pętli.. np. przy wyciąganiu graczy z więzienia..

  4. #4
    Programista
    Dołączył
    Dec 2008
    Posty
    776

    Domyślnie

    Zgadzam się Kiri, że poczta zajmuje najwięcej miejsca, dlatego w Santic Engine jest dobrze pomyślny limit znaków we wiadomości i limit skrzynki, to trochę jednak zmniejsza

  5. #5
    Aktywny
    Dołączył
    Jul 2008
    Posty
    866

    Domyślnie

    Można zrobić automatyczne kasowanie się wiadomości.
    Co X resetów LUB tak jak w dzienniku. Bo wiem, że nikomu nie chce się kasować wiadomości.. :/

  6. #6
    Grupa MmoCenter Awatar Kiri
    Dołączył
    Sep 2007
    Posty
    1,741

    Domyślnie

    humh... liczenie znaków w poczcie to trochę zabójcze jest, szczególnie dla wartości 10000 jak to ma miejsce w santicu...

    A co do automatycznej kasacji to Ja tak mam - w każdą niedzielę starsze niż 7 dni (przeczytane i niezapisane) lecą do piachu. Ponadto pocztę mam rozbitą na 3 tabele - odebrane, wysłane i zapisane
    Sio, nie pomagam via PM !



  7. #7
    Aktywny
    Dołączył
    Jul 2008
    Posty
    866

    Domyślnie

    Zabójcze? Co Ty mówisz. Od czego od JS?

  8. #8
    Programista
    Dołączył
    Dec 2008
    Posty
    776

    Domyślnie

    Taaa, tylko że potem masz dodatkowy spam, że ktoś pocztę stracił jak zapomniał zapisać

  9. #9
    Grupa MmoCenter Awatar Kiri
    Dołączył
    Sep 2007
    Posty
    1,741

    Domyślnie

    Tak czy owak weryfikacje via serwer (php) trza zrobić...

    A dodatkowego SPAMu nie mam bo jak byk na poczcie mam napisane że jest kasacja...
    Sio, nie pomagam via PM !



  10. #10
    Zasłużony Awatar sazian
    Dołączył
    Jul 2008
    Posty
    1,721

    Domyślnie

    Kiri:
    często wspominasz o swojej grze ale nigdzie nie widzę adresu do niej możesz go podać ??

Strona 1 z 2 12 OstatniOstatni

Informacje o wątku

Użytkownicy przeglądający ten wątek

Aktualnie 1 użytkownik(ów) przegląda ten wątek. (0 zarejestrowany(ch) oraz 1 gości)

Podobne wątki

  1. Baza danych
    Przez edou w dziale Kings of Chaos
    Odpowiedzi: 0
    Ostatni post / autor: 22-06-2010, 13:27
  2. CBA.pl i baza danych
    Przez Konradq w dziale Pytania dotyczące silnika Xnova
    Odpowiedzi: 3
    Ostatni post / autor: 19-06-2010, 08:48
  3. Baza danych
    Przez Nie zarejestrowany w dziale Race
    Odpowiedzi: 24
    Ostatni post / autor: 11-02-2010, 20:52
  4. Baza Danych SQL
    Przez Patryk457 w dziale Pytania dotyczące silnika Xnova
    Odpowiedzi: 0
    Ostatni post / autor: 23-05-2008, 15:45
  5. baza danych ?
    Przez pablo w dziale Support Ugameli
    Odpowiedzi: 7
    Ostatni post / autor: 16-02-2008, 00:48

Zakładki

Uprawnienia umieszczania postów

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •