/KlientSerwerMySql

Z Brain-wiki
Wersja z dnia 14:50, 23 maj 2015 autorstwa Jarekz (dyskusja | edycje) (Utworzono nową stronę "= TI:WTBD/KlientSerwerMySql = == System klient-serwer na przykładzie MySQL == Przykładem implementacji relacyjnego SBD opartego na SQL i na architekturze klient-...")
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)

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)