MySQL/MariaDB
Performance + Cluster
13.05.2014
MySQL
- RDBMS
- Relational Database Management System
- 1983 Michael "Monty" Widenius > 1995 MySQL AB > 2008 Sun Microsystems > 2009 Oracle
- Open Source
- GPL 2, Entwicklung wird von Oracle geleitet
-
ACID > Transaktionen
-
Atomicity "alles oder nichts", Transaktion wird nur im ganzen ausgeführt oder garnicht
-
Consistency nur valide Daten mit Erfüllung aller Regeln/Abhängikeiten werden geschrieben
- Isolation Sicherstellung, dass jede Transaktion unabhängig von anderen abgeschlossen werden kann
- Durability dauerhafte Speicherung, Daten sind auch nach einem Crash noch konsistent
-
MVCC
- Multiversion Concurrency Control
- Vermeidung von Deadlocks durch Steuerung der Transaktionen
- Storage Engines
- MyISAM, InnoDB, CSV, Memory
Storage engines
-
MyISAM
-
schnell, Volltextsuche, OpenGIS
-
am besten für viele Lesezugriffe geeignet
-
keine Transaktionen und Crash-Recovery
-
InnoDB
-
Transaktionen, ACID konform, Foreign
Keys, In-Memory
-
Indexing/Caching, Volltext (ab 5.6)
-
Crash-Recovery
MariaDB
-
branch/fork von MySQL
-
rückwärtskompatibel zu MySQL
-
2009 Monty Program AB (Michael "Monty" Widenius) > 2009 erste Version > 2013 SkySQL
-
gesamter Code ist Open Source
-
Entwicklung unabhängig von Oracle möglich
-
weitere Storage Engines
-
Aria (MyISAM + Crash-Recovery)
-
XtraDB (InnoDB + Optimierungen)
-
SPIDER (Sharding)
-
Cassandra (NoSQL)
-
CONNECT (Externe Datenquellen)
-
neue Feautures
-
Dynamic Columns (Key-Value in einer Spalte, unstrukturierte Daten)
-
Virtual Columns (Berechnung aus anderen Spalten, nur XtraDB , Aria, MyISAM)
-
NoSQl mit HandlerSocket (CRUD on XtraDB/SPIDER)
-
Authentifizierungsplugins
Percona Server
-
branch/fork von MySQL
-
rückwärtskompatibel zu MySQL
-
geringe Abweichung zu MySQL
-
konzentrieren sich auf Performanceverbesserungen und Analysetools
-
XtraDB Stroage Engine Entwickler
Single Server
-
1 READ/WRITE-Server
-
einfache Verwaltung
-
Skalierung über die Infratruktur
-
Problem
-
WRITE-/READ-Locking
-
Performance
-
single point of failure
PerformanceAnalyse
-
SHOW PROCESSLIST
-
slow_query_log
-
EXPLAIN
-
MySQL Query Analyzer / Percona Toolkit (pt-query-digest)
-
Benchmark (sysbench (Disk IO/MySQL) / mysqlslap)
-
In-Code Analyzer (New Relic, Bullet)
PErformance verbessern
-
Indexing
-
Lockingmechanismen verstehen
-
InnoDB/XtraDB:
-
ALTER TABLE (tmp Table - Table Lock), INSERT/UPDATE/DELETE (Row-Level Lock)
-
MyISAM
-
ALTER TABLE/INSERT/UPDATE/DELETE (Table Lock)
-
Foreign Key (constraints)
-
Infrastruktur (Scale Up)
-
performante Disk-I/O (SSD, RAID, SAN)
-
performanter Netzwerkstack (InfiniBand, GbE, Link Aggregation)
-
my.cnf Tuning
-
caches (query_cache_size) und buffers (innodb_buffer_pool_size)
Master-Slave(s)-Replikation
-
1 Write-Server / x Read-Server
-
Skalierung der Read-Server möglich
-
Problem
-
Schreibzugriffe gehen nur an einen Server
-
single point of failure (High Availability to rescue, DRBD)
-
Applikation muss Schreib- und Lesezugriffe getrennt verwalten
(Multi)-Master-Master Replikation
-
parallel schreibend und lesender Zugriff
- Skalierung der Read-/Write-Server gleichzeitig
-
Problem
-
single point of failure gelöst?
-
nicht ACID konform
-
Split Brain nicht auflösbar
CLUSTER
-
divide and conquer
-
shard = Partitionierung und Replikation (Scale Out)
-
Partitioning
-
Daten werden zerstückelt und über mehrere Server verteilt gespeichert
-
jeder einzelen Server ist fähig, die Daten zu manipulieren und per Abfrage bereit zustellen
-
weniger Datensätze pro Server, geringere Indexgröße, Steigerung der Performance
-
horizentale Skalierung > mehr Server, Daten können schneller gespeichert/gelesen werden
-
Replikation
-
Daten werden über mehrere Server repliziert
-
Sicherheit erhöht (single point of failure ausgeschlossen)
CLUSTER PROBLEME
-
Theorie einfach, Praxis schwer
-
Strategie ist abhängig von Daten und Infrastruktur
-
Konsitenz der Daten muss gesichert sein
-
single point of failure
-
"shared nothing" Ansatz
-
Sharding in Applikation oder transparent (Proxy/Cluster)
-
Code/Applikationssupport
-
Hibernate ORM, Ruby ActiveRecord
-
Struktur wird komplexer, Operationen auf den Datensätzen komplexer
- JOIN/ALTER/UPDATE/DELETE
-
De-Normalisierung
MySQL Cluster
-
auto-sharding
-
benutzt NDB Cluster
-
ACID konform, Transaktionen
-
Daten werden im Netzwerk gespeichert, nicht lokal
-
Abspeicherung der Datentabellen in Data Nodes
-
Data Nodes
-
ndbd Prozeß
-
In-Memory Storage
-
Replikation über Data Nodes = Node Groups
-
Management Node(s)
-
Konfiguration, Monitoring, Arbitration (Schiedsrichter bei split brain)
-
API Node
-
C++, Java/JPA, SQL Nodes (MySQL Server), NoSQL, Memcached, node.js, REST
-
Master-Slave Replikation / Geo Replikation / Online Backup
-
MySQL Cluster Carrier Grade Edition (CGE)
-
Enterprise Tools (MySQL Cluster Manager)
MySQL CLuster
-
je mehr Data Nodes umsomehr Netzwerktraffic
-
Foreign Key constraints ab Version 7.3
-
jede Node einer Node Group sollte auf einem anderen Host laufen
-
Verkehr zwischen den Nodes ist nicht verschlüsselt
-
SQL Node nutzt per default nur eine NDB-API Verbindung
-
Connection Pooling (ndb-cluster-connection-pool > 1)
Galera Cluster
-
Multi-Master Cluster
-
Percona Cluster, MariaDB Galera Cluster
-
XtraDB/InnoDB storage engine + Galera Replikationsplugin
- wsrep Replikations-API
-
MyISAM möglich (experimentell)
-
synchrone Replikation bei Transaktionscommit
- automatische Provisioning der Nodes
-
Arbitrator (split brain)
MariaDB Spider
-
Storage Engine Plugin (ab MariaDB 10.0.4)
-
Database Level Sharding
-
Verbindung zu einer Tabelle auf einem Remote-Server
-
Speicherung der Daten auf dem Remote Server in normalen Storage Engines
-
Verbindungsdaten des Remote-Servers werden
im CREATE-Kommentar angegeben
-
Shardinginformationen werden im PARTITION-Kommentar
angeben
-
Volltextsuche, NoSQL
-
Vorteil: Zugriff über eine MySQL-Verbindung
-
Plugins
-
Vertical Partitioning (Column Level)
-
HandlerSocket (NoSQL)
Loadbalancer
-
keine komplizierte Konfiguration in der Applikation
-
HAProxy
-
HA mit Keepalived and Virtual IP
-
MySQL Proxy
Jens Nauber
Software und Server
Fahrräder und Kaffee
@_jensen
+JensNauber
Made with Slides.com