Zapisz jako PDF

Spis treści
1 TI:WTBD/KlientSerwerMySql
1.1 System klient-serwer na przykładzie MySQL
1.1.1 Główne cechy MySQL
1.1.2 dostępne typy tabel (backendy)
TI:WTBD/KlientSerwerMySql
System klient-serwer na przykładzie MySQL
Przykładem implementacji relacyjnego SBD opartego na SQL i na architekturze klient-serwer jest
MySQL. Jego zalety to:
jest dostępny bezpłatnie
niskie wymagania sprzętowe i administracyjne
szeroko rozpowszechniony, bdb. poziom oryginalnej dokumentacji ([1])
długo rozwijane, dojrzałe oprogramowanie
istnieje wiele książek, artykułów itd.
interfejsy we wszystkich szerzej używanych językach programowania
Ma też szereg wad:
niejasności co do przyszłego rozwoju
odstępstwa od standardu SQL
brak pełnej transakcyjności
Zalety systemów klient-serwer ujawniają się zwłaszcza w sytuacjach:
gdy wymagany jest wysoki stopień wielodostępności
konieczność centralizacji składowania danych
wysokie wymogi bezpieczeństwa
zróżnicowanie uprawnień dostępu
Najczęstsze zastosowania MySQL - jako elementu backendu aplikacji webowych - zwykle
wykorzystują jedynie część mocnych stron architektury klient-serwer. Np. złożony system uprawnień
dostępu nie jest prawie nigdy wykorzystywany w takich zastosowaniach.
Główne cechy MySQL
Danymi zarządza serwer (program mysqld), do którego dostęp mogą mieć klienci zarówno za
tej samej maszyny, jak i z maszyn zdalnych
dostęp lokalny może być realizowany przez tzw. gniazda unixowe (wysoka wydajność)
dostęp zdalny realizowany jest przez TCP/IP, domyślnie połączenia na port 3306.
Standardowo połączenia nie są szyfrowane; z założenia powinny one odbywać się w
ramach bezpiecznej sieci lokalnej, gdzie szyfrowanie stanowiłoby jedynie narzut ujemnie
wpływający na wydajność. Istnieje jednak możliwość skonfigurowania połączeń SSL/TLS.
Dane przechowywane są w plikach, w poddrzewie /var/lib/mysql (standardowo w większości
dystrybucji). Tabele (i in. obiekty) zarządzane przez daną instancję serwera pogrupowane są w
bazy danych, którym odpowiadają podkatalogi w /var/lib/mysql.
poza wyjątkowymi sytuacjami nie należy bezpośrednio sięgać do tych plików (zwłaszcza w
trakcie pracy serwera!); nie należy ich też wprost przenosić między instancjami serwera (mogą
zależeć od wersji oprogramowania, lokalne konfiguracji, ...)
dostępnych jest kilka typów tabel, o nieco różnych własnościach i charakterystykach
wydajnościowych -- np. transakcyjne i nietransakcyjne; typ tabeli można wybrać w momencie
jej tworzenia.
do eksploracji bazy czy czynności jednorazowych, wykonywanych poza aplikacją, jest narzędzie
o nazwie mysql i własnościach podobnych do programu sqlite3 (tylko lepsze). Są też bardziej
wyspecjalizowane narzędzia np. mysqladmin -- do czynności administracyjnych np. tworzenie
kont, mysqldump -- do zrzutów i transferu danych, mysqlcheck -- do sprawdzania poprawności
i do optymalizacji tabel.
istnieją też narzędzia typu GUI do zarządzania bazami, np. phpmyadmin
złożony system uprawnień pozwala definiować prawa dostępu na poziomie baz, tabel a nawet
poszczególnych kolumn, różnicując prawa do różnych operacji. Uprawnienia są ustalane na
podstawie zarówno konta (loginu), jak i adresu źródłowego połączenia. Konta mysql są
całkowicie niezależne od kont unixowych.
dość zaawansowane możliwości replikacji danych pomiędzy wiele serwerów w układzie masterslave
w definicjach tabel, inaczej niż w ~SQLite (ale podobnie, jak w większości relacyjnych SBD),
wymagane jest deklarowanie typów danych dla kolumn
Python: standardem jest python-mysqldb, zgodne w szerokim zakresie z DBAPI v. 2. Istnieją
też alternatywne implementacje: oursql (wygląda obiecująco; pomija wykorzystanie biblioteki
klienckiej w C, implementując komunikację z serwerem w Pythonie); pymysql (słabo
udokumentowane)
dostępne typy tabel (backendy)
CREATE TABLE tabela ( ... ) ENGINE = INNODB;
ALTER TABLE tabela ENGINE = MYISAM;
standard: ~MyISAM
największa szybkość operacji
niskie wymagania co do przestrzeni dyskowej
niskie wymagania pamięciowe dla operacji zmieniających dane
brak obsługi transakcji (!)
brak obsługi kluczy obcych (!)
tabele transakcyjne: InnoDB
od MySQL 4.0
obsługuje deklaracje kluczy obcych:
(w CREATE TABLE ...):
[CONSTRAINT SYMBOL] FOREIGN KEY [ID]
REFERENCES TBL_NAME (INDEX_COL_NAME,
[ON DELETE {RESTRICT | CASCADE | SET
[ON UPDATE {RESTRICT | CASCADE | SET
(INDEX_COL_NAME, ...)
...)
NULL | NO ACTION | SET DEFAULT}]
NULL | NO ACTION | SET DEFAULT}]
ew.
ALTER TABLE yourtablename
ADD [CONSTRAINT SYMBOL] FOREIGN KEY [ID] (INDEX_COL_NAME, ...)
REFERENCES TBL_NAME (INDEX_COL_NAME, ...)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
obsługuje transakcje:
SET AUTOCOMMIT = 0;
BEGIN;
INSERT ...
UPDATE ...
DELETE ...
COMMIT; (lub ROLLBACK)
tabele nie zapisywane na dysk (MEMORY)
CREATE TABLE tabela ( ... ) ENGINE = MEMORY;
dane trwają do restartu serwera (definicje pozostają)
bardzo szybkie operacje
nie dopuszczają kolumn typu BLOB ani TEXT
tabele tymczasowe (TEMPORARY)
CREATE TEMPORARY TABLE tabela ( ... )
ENGINE = MEMORY;
ENGINE może być również MyISAM i InnoDB
widziane tylko w aktualnej sesji, niszczone przy jej zamknięciu;
niewidoczne dla SHOW TABLES
ograniczenie: tylko 1 referencja w zapytaniu (niemożliwe samozłączenie)
NB. w SQLite też istnieje możliwość operowania na danych istniejących wyłącznie w
pamięci procesu, ale na poziomie całej bazy danych a nie poszczególnych tabel
tabele FEDERATED: dołączające dane z serwerów zdalnych (eksperymentalne)