/KlientSerwerMySql
Z Brain-wiki
Spis treści
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 master-slave
- 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] (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}]
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)