Need for Speed, czyli rozważania dotyczące prędkości Opcje

[DeyV]

Od dawna stosowane są mechanizmy służące do zapisywania wyników z bazy danych w plikach tekstowych, w celu przyspieszenie pracy skryptów (cash). I jest to całkiem logiczne, szczególnie w przypadku bardziej złożonych zapytań.
Jednak ostatnio, chyba wraz z pojawieniem się najnowszej wersji xmb_forum (Partagium) zwróciłem uwagę na nową tendencję: zastępowanie plików tekstowych bazą danych. W forum tym wszystkie pliki szablonów (templates) zostały umieszczone w bazie. I przyznam się szczerze, że mocno mnie to zaskoczyło. Bo choć do zalet stosowania zapisu w bazie chyba nikogo nie trzeba przekonywać (łatwość w aktualizacji, katalogowaniu, brak problemów z nadawaniem CHMOD itp.) to jednak przekonany byłem, że rozwiązanie takie musi być o wiele wolniejsze.
Skłoniło mnie to do przeprowadzenia serii testów. Umieszczam tu kilka z wyników, które mam nadzieję skłonią Was do zastanowienie się nad tym tematem. Wszystkie zostały wykonane przy pomocy malutkiego skryptu zapisującego i przeliczającego wyniki, który można ściągnąć stąd:
www.mStudio.nQ.pl/download/scrypty/czas/czas.zip na Windows XP, z Apachem 1,3, php 4.3 oraz MySQL 3.23
A tu jest przykład kodu testów

A1. wyświetlamy zawartość małego pliku (1,4 KB) z pliku tekstowego (wyniki w sekundach):

Ilość prób=20
średni czas = 0.00299039483070
max czas=0.0046200752;
min_czas= 0.0020439625
suma = 0.0598078966

A2. Ten sam tekst z bazy MySQL zawierającej tylko ten jeden rekord:

Ilość prób=20
średni czas = 0.00293679833412 (mniej niż z pliku !)
max czas=0.0047850609;
min_czas= 0.0023930073
suma = 0.0587359667

A3. Taki sam tekst, lecz z tabeli zawierającej około 200 rekordów

Ilość prób=20
średni czas = 0.00319704413414
max czas=0.0045739412
min_czas= 0.0025489330
suma = 0.0639408827

-----------------------------

B1. wyświetlamy zawartość pliku (61 KB) z pliku tekstowego (wyniki w sekundach):

Ilość prób=20
średni czas = 0. 07095720171928
max czas=0. 1114130020;
min_czas= 0. 0573480129
suma = 1. 4191440344

B2. Ten sam tekst z bazy MySQL zawierającej tylko ten jeden rekord:

Ilość prób=20
średni czas = 0. 09079620242119  
max czas=0. 1551539898;
min_czas= 0. 0670330524
suma = 1. 8159240484

B3. Taki sam tekst, lecz z tabeli zawierającej około 200 rekordów

Ilość prób=20
średni czas = 0. 08866938948631
max czas=0. 1459870338
min_czas= 0. 0688790083
suma = 1. 7733877897

Podsumowanie:
Pliki rzeczywiście zazwyczaj są szybsze, ale nie tak bardzo, jak by się mogło wydawać. Zaskakujące efekty dało również porównanie wyników MySQL. Okazało się, że wielkość bazy (przynajmniej w porównaniu 1-200) nie ma wpływu na prędkość wykonywania zapytań. Czasami wręcz (sic!) większa baza jest szybsza...
Co o tym sądzicie?

[itsme]

Jezeli chodzi o mnie to ja zawsze bylem bazodanowcem i wszystko pakowalem w baze. mySQL daje to czego z txt nie osiągniesz - dane statystyczne - praca z baza z zalozenia jest znacznie latwiejsza.

Szybkosc otwierania strony to jeden z glownych czynnikow na ktory zwraca uwage uzytkownik internetu. I w momencie kiedy mySQL szwankuje na serverze to czas otwierania strony moze maaaaxymalnie sie zwiekszyc. Dzis mialem ta przykrosc na home.pl (wielki dostawca ale mySQL szwankuje tam juz od tygodnia).

Konczac jestem zawsze i wszedzie za baza danych ....

Pozdrawiam

[scanner]

Odkąd przerzucilem sie z plików na BD, to nie mam zamiaru wracać. Od zawsze otwieranie, zamykanie i operacje na plikach byly czyms czego nie lubiłem. A to że czasami troszke wolniejsze? Niech będzie i wolniejsze, jesli tylko jest wygodniejsze.

[DeyV]

Jednak pojawia się pytanie: Jak daleko się posuwać?
Przecież można by w bazie przechowywać praktycznie wszystko.
Już wspomniałem o plikach cashu - może zamiast plików warto by używać mechanizmów zapisujących wyniki trudniejszych zapytań z bazy właśnie w bazie?
Na innym Topicu na tym forum poruszony jest temat przechowywania zmiennych sesjowych w bazie. Czy ma to sens?
A może posuniemy się do skrajności, i zaczniemy przechowywać w bazie również pliki, choćby grafikę?
Czy gdzieś tu zaczyna się paranoja?

[kurtz]

Od dawna stosowane są mechanizmy służące do zapisywania wyników z bazy danych w plikach tekstowych, w celu przyspieszenie pracy skryptów (cash).

cos co moze umkleo - kiedy umiejetnie cachujemy "ile sie da" wyniki skryptow (chociaz ich fragmentow) jestesmy nie tylko dostarczyc tresc szybciej ale i funkcjonowac w miare stabilnie gdy wlasnie zabraklo bazy danych (np padla).

wczoraj uswiadomilem sobie ze jesli wystarczajaco dobrze sie usiadzie to nawet gdy bedziemy mieli krytyczne padniecie bazy danych seriws bedzie chodzil zachowujac wszystkie pozory.

[dragossani]

Prędkość liniowego odczytu danych z bazy jest zwykle porównywalna z odczytem z systemu plików. Tutaj nie ma co szukać przewagi któregoś z rozwiązań - jeśli wszystko jest dobrze skonfigurowane to różnice powinny być na poziomie błędu statystycznego.
Co innego jeśli chcemy czegoś poszukać - tutaj baza jest absolutnie bezkonkurencyjna. Dlatego jeśli potrzebujemy wydajności, najlepiej trzymać co się da w bazie danych i zadbać równocześnie o to, żeby sama baza i sprzęt na którym pracuje były skonfigurowane optymalnie. Na co warto zwrócić uwagę?

Jeśli to możliwe, należy przygotować sobie osobną maszynę dla bazy danych i połączyć szybką sieciówką z serwerem www. Najważniejszymi elementami serwera bazodanowego są dyski twarde i pamięć ram. Jeśli chodzi o dyski to świetnie podnosi wydajność konfiguracja typu raid-0. Jeśli musimy liczyć się z kosztami to możemy zacząć od kupna płyty głównej z kontrolerem raid (zwykle różnica cenowa jest niewielka) i dwóch identycznych dysków twardych ATA. Dobrze jeśli dysk ma 8MB cache - przy intensywnym użytkowaniu jest to ważne. Dla przykładu w hurtowni Maxtor DiamondMax +9 80 GB (ATA/133, 8MB cache) kosztuje około 500 PLN. Połączenie dwóch takich dysków w system raid-0 daje nam jeden dysk o pojemności 160GB, w dodatku o wydajności 195% pojedynczego. Jeśli ktoś cierpi na nadmiar gotówki to polecam specjalny kontroler scsi raid i do tego kilka dysków takich jak np. Seagate Cheetah X15K.3 36.7 GB - to cudeńko ma 15.000 obr./min i średni czas dostępu na poziomie 4,3 ms - tylko niestety słono kosztuje. Ram powinien być szybki, ale nie należy przesadzić. DDR-433MHz Corsair we wspólpracy z Athlonem 2000+ zachowuje się nieprzewidywalnie. Najlepiej zadbać po prostu o synchronizację procesora z ramem. Czyli np. Athlon 2600+ (szyna 333MHz) i DDR-RAM Kingston'a 333MHz to najzdrowsze zestawienie.

Kilka słów o konfiguracji MySQL'a. Zakładam, że jeśli ktoś wydał kasę na sprzęt to teraz chce oszczędzić na sofcie i instaluje na serwerze linuxa - słuszne posunięcie. :wink: Jak powinien wyglądać plik konfiguracyjny MySQL'a? Oczywiście muszą w nim być podstawowe informacje:

Kod

[mysqld]

#kodowanie znaków

language = polish

default-character-set = latin2



#katalog z danymi

datadir = /home/mysql/data



#pliki logów

log = /var/log/mysql/mysqld.log

log-update = /var/log/mysql/modify.log

Logi mogą nam oczywiście zacząć rosnąć w niepochamowanym tempie, w związku z czym trzeba pomyśleć o ich rotacji. Jeśli chodzi o dostosowywanie ustawień bazy danych do specyfiki sprzętowej to warto zerknąć do przykładów w podkatalogu /support-files. Dobre dobranie buforowania pozwoli nam wycisnąć ze sprzętu co się da. Jeśli mamy niezbyt wydajną platformę sprzętową nasz plik my.cnf może wyglądać tak:

Kod

#Ustawienia globalne klientów

[client]

#password             = your_password

port                  = 3306

socket                = /tmp/mysql.sock



#Ustawienie serwera

[mysqld]

language              = polish

default-character-set = latin2

datadir               = /home/mysql/data

log                   = /var/log/mysql/mysqld.log

log-update            = /var/log/mysql/modify.log

port                  = 3306

socket                = /tmp/mysql.sock

skip-locking

set-variable          = key_buffer=16M

set-variable          = max_allowed_packet=1M

set-variable          = table_cache=64

set-variable          = sort_buffer=512K

set-variable          = net_buffer_length=8K

set-variable          = myisam_sort_buffer_size=8M



#log-bin

server-id             = 1



[mysqldump]

quick

set-variable          = max_allowed_packet=16M



[mysql]

no-auto-rehash



[myisamchk]

set-variable          = key_buffer=20M

set-variable          = sort_buffer=20M

set-variable          = read_buffer=2M

set-variable          = write_buffer=2M



[mysqlhotcopy]

interactive-timeout

Jeśli natomiast kupiliśmy sobie mocny serwer to musimy umożliwić mysql'owi wykorzystanie go odpowiednio. Co warto więc zmodyfikować?

Kod

#w sekcji mysqld

[mysqld]

set-variable = key_buffer=384M

set-variable = table_cache=512

set-variable = sort_buffer=2M

set-variable = record_buffer=2M

set-variable = thread_cache=8

set-variable = myisam_sort_buffer_size=64M

#jeśli mamy więcej niż 1 procek

set-variable = thread_concurrency=8

#w sekcji myisamchk

[myisamchk]

set-variable = key_buffer=256M

set-variable = sort_buffer=256M

To tyle w zarysie jeśli chodzi o wydajność samej bazy danych.

[Seth]

A co sadzicie o XMLu jako pewnym zamienniku bazy danych przy malych projektach ?


P.S. Doszyly mnie sluchy, ze nowy system Redmonda ma posiadac system plikow oparty o baze danych, tak wiec to co mowicie o przechowywyaniu plikow graficznych itp w bazie chyba ma jakies uzasadnienie. Poza tym sam w pracy mam doczynienia z systemem plikow opartych o baze danych.

[dragossani]

Od biedy można spróbować posłużyć się XML'em jako zamiennikiem bazy danych ale musisz wtedy obsłużyć wszystkie operacje wyszukiwania, dodawania i zamiany na poziomie php, a takie technologie jak XMLQuery są jeszcze bardzo niedojrzałe. Natomiast świetnie sprawdza się XML przechowywany w bazie danych. Do pewnego poziomu abstrakcji przechowujesz dane w polach bazy danych, a poniżej tego poziomu w XMLu (w jednym z pól bazy). Np. przechowując artykuły możesz datę publikacji, tytuł i autora przechowywać w osobnych polach, a sam artykuł z podziałem na paragrafy, sekcje, cytaty, słowa kluczowe itd. trzymać w jednym z pól w XML-u. W Oracle'u możesz nawet wydawać zapytania do wnętrza tego XML'a ale jak wiadomo na komercyjną licencję Oracle'a mało kogo stać. Postgres jeszcze tego nie umie (o MySQL'u nawet nie wspominam, bo projektanci głośno się wypowiedzieli, że nawet nie mają planów się za coś takiego brać). Mimo wszystko jest to wygodne. Można sobie wyszukać co trzeba z bazy, a potem XML + parser z php zapewnią prawidłowe formatowanie itp.

[Seth]

Czyli XML tylko jako wzorzec ?

[dragossani]

No, powiedzmy jako źródło informacji na poziomie szczegółowym.

[Seth]

juz rozumiem

[Mati]

Ja tam uważam, że każdy musi subiektywnie podejśc do tego zagadnienia. Uświadomoić sobie co jest dla niego ważniejsze = wygoda tworzenia, czy mikrosekundowe zyski w oglądaniu.

[Picia]

Heh. Nie wiem co powiedziec.
Na plikach zaczynalem ale to przeszlosc. Potem dlugo dlugo mysql.

Ostatnim czasem jednak nie korzystam z mysqla. Zaczalem uzywac PostgreSQLa i Interbase'a(FireBird).
Aktualnie mam na swoim 486 80 MHz 16 MB Ramu odpalonego php 4.2.3 i Psosstgresa 7.2 + FireBird juz nie pamietam jaki .
okolo 1-3 minut zajmuje mi wylistowanie 20000 rekordow z warunkiem (WHERE KOD=.....). Podobny okres czasu zajmuje mi wylistowanie WHERE + LIKE kilka razy . To na Interbasie - jego odpowiedniku FireBirdzie.
Własnie importuje 20000 rekordow do PostgreSQLa w ktorym robilem juz kilka rzeczy, chce porownac ich szybkosci. MySQLa porzucilem bo nie daje juz takich mozliwosci, poza tym do zastosowan komercyjnych trzeba miec na niego licencje....
Brakuje mi w ankecie czegos takiego jak Bazy Danych inne niz mysql .

Pozdrawiam

[Omega]

W sumie pliki są bardziej powszechne... W necie o free MySQL dość trudno... A dla małych porcji informacji pliki to niezłe wyjście... Ale osobiście przystaję za MySQL... 8)

[e-Gandalf]

MySQLa porzucilem bo nie daje juz takich mozliwosci

Jakich konkretnie? Pytanie troche podchwytliwe, wiem czego brakuje w MySQL, ale uwazam, ze w wiekszosci zastosowan widoki nie sa niezbedne, a subquery, tranzakcje itp. juz MySQL 4.1 ma.
Natomiast z cala pewnoscia MySQL jest najszybszy z wymienionych.

, poza tym do zastosowan komercyjnych trzeba miec na niego licencje....

O... to ciekawe. Mozesz podac odpowiedni fragment licencji? Kiedys trwala o tym dyskusja na pl.comp.www i stanelo na tym, ze jednak nie jest potrzebna. Ze platna licencja jest potrzebna, tylko kiedy MODYFIKUJESZ zrodla MySQLa.

[Omega]

Z tego co wiem płatna licencja jest potrzebna gdy za MySQL pobiera sie pieniądze czy jakoś tak...

[Picia]

Wlasnie najbardziej potrzebne mi sa widoki (laczenie tabel i inne...) Mozliwosc implementacji skryptow perlowych, laczenia tabeli....

Druga sprawa jest to, ze tak narawde licencji nie czytalem, ale ostatnio bardzo duzo grup dyskusyjnych zwiedzalem a tam kilka razy bylo to poruszane, ale potem tego sam poszukam w warunkach licencyjnych . Fakt faktem ze mysql jest najprostszy

[borec]

ja tam jestem za mysql

po 1. 0.001 sek to dla mnie niezbyt duzo, a wygoda jest o wieeele wieksza.
po 2. pliki zawsze doprowadzaly mnie do szalu
po 3. jak sie ma szybkiego serwa to tylko wygoda sie liczy

[e-Gandalf]

po 3. jak sie ma szybkiego serwa to tylko wygoda sie liczy

I jeszcze mala odwiedzalnosc...

Gratuluje pomyslu. Przyszlosc programisty, dla ktorego najwazniejsza jest wygoda jest zaprawde swietlana.

[squid]

Jednak pojawia się pytanie: Jak daleko się posuwać?
A może posuniemy się do skrajności, i zaczniemy przechowywać w bazie również pliki, choćby grafikę?
Czy gdzieś tu zaczyna się paranoja?

Wg mnie nie ma tu paranoi trzymanie grafiki w bazach danych to nie nowosc i w pewnych sytuacjach moze sie przydac. Co do predkosci i wydajnosci (jedno i to samo?) pliki nadaja sie do mniejszych stron ale jesli wiecej uzytkownikow kozysta z serwisy baza jest niezbedna chocby ze wzgledu na kolejkowanie zapytan typu insert i select oraz ich priorytety, bazy danych optymalizuja rowniez zapis fizyczny na dyskach inteligentnie rozmieszczajac dane (jak ktos wie co to sa B-drzewa to wie o czym mowie innych odsylam do podrecznikow algorytmiki;-)).