Wydajność w bazach danych odgrywa kluczową rolę, więc optymalizacja i wprowadzanie nowych mechanizmów jest nieuniknione. Engine MEMORY w MySQLu od pewnego czasu już istnieje, to chciałbym przedstawić ten typ tabeli jako alternatywa dla cache zapisywanego w pliku na dysku.

Czym jest MEMORY?

Typ MEMORY, wcześniej HEAP (od wersji 4.1 rekomendowaną nazwą jest MEMORY) - jest to jeden z licznych typów w tabeli charakteryzujący się sposobem przechowywania danych. Jak sama nazwa wskazuje dane są przechowywane w pamięci operacyjnej, więc odczyt, jak i operacje na danych są wykonywane “błyskawicznie”. Jednym z największych problemóww związanych z wydajnością baz danych są operacje wejścia/wyjścia (zapisu/odczytu danych z HDD). Minusem jest to że po wyłączeniu zasilania dane z pamięci operacyjnej są usuwane. Definicja tabel jest trzymana na dysku (nazwa tabeli .frm), więc struktura po wyłączeniu zasilania nie zmienia się.

Gdzie stosować tabele MEMORY?

Głównym zastosowanie tego typu tabel jest tworzenie rozmaitych buforów cache i przechowywanie tymczasowych informacji, których utrata nie powoduje większych szkód a operacje na danych w pamięci mogą przyśpieszyć działanie serwisów WWW.

Czy MEMORY lepsze od cache zapisanego do pliku?

Trudno powiedzieć, z jednej strony na pewno tak bo dane są trzymane tylko w pamięci i operowanie na nich wykonywane jest bez wykorzystania operacji wejścia/wyjścia ale minusem jest proces nawiązywania połączenia, następnie etap parsowania, sprawdzania i wykonania zapytania. Wszystko zależy od przeznaczenia i oczywiście danych ale na pewno tego typu tabele są alternatywą do cache zapisywanego do pliku, który jest obecnie najczęściej wykorzystywany.

Jak używać tabel MEMORY?

Tabele MEMORY w budowanie i wykorzystaniu nie różnią się niczym szczególnym. Jedną z znaczących różnic jest to, że pewne typy pól nie występują (Blob, Text), wiąże się to z miejscem zajmowanym w pamięci. Kolejną zmiana jest użycie indexu.

Definiowanie i użycie tabel MEMORY

Definiowanie tabeli:

CREATE TABLE tabela (id INT) ENGINE = MEMORY

Użycie Tabeli:

SELECT * FROM tabela

Na forum php.pl pojawił się post z pytaniem czy zastosowanie prepared statements wpływa na wydajność zapytań.

Troszeczkę teorii:

Jak to wygląda od strony ORACLE:

Zanim dane zostaną zwrócone z bazy danych, po odebraniu odpowiedniego kodu baza danych Oracle musi wykonać określone czynności:

• tworzenie kursora
• proces parsowania zapytania jeśli nie istnieje w obszarze wspólnym. Na proces ten również wchodzi kilka etapów:
  • analiza zapytania - sprawdzenie czy zapytanie składniowo jest poprawne
  • sprawdzenie odwołań do obiektów
  • sprawdzenie uprawnień
  • modyfikacja zapytania, w celu uzyskania zapytania równoważnemu danemu, ale wykonywanemu efektywniej
  • przygotowanie planów wykonania na podstawie statystyk, wskazówek
  • wybranie najlepszego planu wykonania (najmniejszy koszt wykonania)
  • zapisanie do obszaru wspólnego

  Wykorzystanie wcześniejszego zapytania jest możliwe tylko wtedy, kiedy:

  • tekst zapytania jest taki sam (wchodzą w to również komentarze i białe znaki),
  • polecenie musi odwoływać sie do tych samych obiektów w bazie danych,
  • zmienne wiązane muszą się tak samo nazywać i być tego samego typu.

• przygotowanie zapytania
• podwiązanie zmiennych
• wykonanie zapytania
• zwrócenie rekordów do użytkownika

Jeśli do bazy danych jest wysyłane takie samo zapytanie proces parowania nie jest wykonywany, przez co wydajność wzrasta bo pewna czść operacji jest pomijana.

Czy zawsze stosować takie rozwiązanie?

Są przypadki zapytań dla których najlepszy plan pierwszego wykonania dla pewnych parametrów jest nieoptymalny i zaleca się nie stosowanie zmiennych wiązanych.

MySQL:

Jeśli chodzi o bazę danych MySQL mechanizmy nie są aż tak bardzo zaawansowane ale pewne rzeczy są zaimplementowane.

Więcej na stronie: http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

Jak PDO wpływa na wydajność

PDO udostępnia funkcje do tzw bind’a (w literaturze polskiej spotkałem się z określeniem zmienna wiązana), w którym możemy przekazać wartość jaka ma być podstawiona pod zmienną, która w późniejszym etapie zostanie wysłana do bazy. Możemy wysłać zapytanie tylko jeden raz, następnie podstawiać wielokrotnie a następnie wykonywać. Dodatkowo PDO chroni przed atakami SQL Injection.

Post z forum.php.pl: http://forum.php.pl/mysqli-prepared-statements-t54025.html

Używając PostgreSQL’a możemy wykorzystywać kilka języków proceduralnych:

• PL/pgSQL podobny składnią do języka PL/SQL w bazie Oracle
• języki skryptowe: PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh i PL/Tcl
• kompilowane: C, C++, PL/Java
• PL/R

PostgreSQL jest często wykorzystywany przez programistów serwisów WWW (konfiguracja w postaci PostgreSQL + PHP) to mimo tego, że istnieje język plPHP to obecnie najpopularniejszym językiem jest PL/pgSQL - dlatego pewnie, że wywodzi się od PL/SQL (Oracle).

Zastanawiam się dlaczego tak się dzieje, co powoduje że nie używa się pozostałych języków? Weźmy na przykład Ruby - oczywiście w bazie PostgreSQL mamy możliwość jego wykorzystania. PL/Ruby jest rozwijany od 2002 roku, mimo wielkiej popularności Ruby wśród programistów PHP język raczej nie należy do tych prężnie się rozwijających. C, C++ dlaczego nie? Prawie każdy programista miał styczność z tymi językami a jednak PL/pgSQL.

Przeglądając TODO Postgresa i MySQLa widać, że developerzy tych baz starają się implementować większość funkcjonalności, które firma Oracle wprowadziła do swojej bazy jakiś czas temu. Tak czy inaczej Oracle jest pionierem na rynku jeśli chodzi o bazy danych i wprowadzenie zmian lub dodanie nowych mechanizmów powoduje, że reszta systemów bazodanowych podąża za nimi.

Czy warto wdrożyć plPHP czy PL/Ruby? Każdy musi na to pytanie sobie sam odpowiedzieć.

Dla osób chcących wdrożyć się w PL/Ruby lub plPHP zapraszam na:

PL/Ruby
plPHP

Obecnie w repozytoriach Ubuntu Dapper najnowszą wersją pgadmin3 jest wersja 1.2.x. Nasuwa się więc pytanie jak zainstalować wersje 1.4.x. Jest kilka możliwości - najłatwiejszą z nich będzie wykorzystanie paczek z Debiana. Poniżej przedstawię w jaki sposób pobrać paczki z Debiana i przerobić tak aby pasowały do Ubuntu Dapper.

Pierwszą rzeczą jaką musimy zrobić jest usunięcie zainstalowanej wersji pgadmin3.

sudo apt-get remove pgadmin3 pgadmin3-data

Następnie musimy dodać nowe wpisy do repozytoriów (plik /etc/apt/sources.list)

Repozytorium PostgreSQL (obecnie najnowszą wersją jest 1.4)

deb ftp://ftp3.us.postgresql.org/pub/postgresql/pgadmin3/release/debian stable pgadmin

deb-src ftp://ftp3.us.postgresql.org/pub/postgresql/pgadmin3/release/debian stable pgadmin

Lub wpisy do repozytoriów Debiana (obecnie najnowszą wersją jest 1.4.3-1)
deb-src http://http.us.debian.org/debian unstable main

Kolejnym krokiem jest aktualizacja bazy danych pakietów

sudo apt-get update

Po zaktualizowaniu bazy pakietów instalujemy “dpkg-dev”, który zawiera narzędzie do budowania pakietów.

sudo apt-get install dpkg-dev

Przechodzimy do etapu budowania pakietu, w przypadku pgadmina wymagane są: pgadmin3 pgadmin3-data. Pobierane są źródła a następnie budowane są pakiety.

sudo apt-get build-dep pgadmin3 pgadmin3-data
sudo apt-get -b source pgadmin3 pgadmin3-data

Budowanie pakietów może chwile potrwać. Wynikiem będą 2 pliki o rozszerzeniu .deb w aktualnym katalogu. (pgadmin3_1.4.3-1_i386.deb, pgadmin3-data_1.4.3-1_all.deb)

Końcowym etapem jest instalacja:

dpkg -i pgadmin3_1.4.3-1_i386.deb pgadmin3-data_1.4.3-1_all.deb

Jeśli wszystko przebiegło poprawnie pozostaje nam tylko uruchomienie pgadmin3:

/usr/bin/pgadmin3

lub

pgadmin3

Jak na każdym blogu musi być ten pierwszy post. Mam nadzieję że z biegiem czasu postów jak i komentarzy będzie przybywać.

O czym będę pisał, hmmmmm począwszy od SQLa a skończywszy na PHP. Zagadnienia związane z MySQL coś z nowości, PostgreSQL, Oracle. Mam nadzieję że moje chęci nie skończą się na pierwszym poście.