/KlientSerwerMySql

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)