Presentations
Templates
Features
Teams
Pricing
Log in
Sign up
Log in
Sign up
Menu
MySQL/MariaDB
Performance + Cluster
13.05.2014
MySQL
RDBMS
R
elational
D
atabase
M
anagement
S
ystem
1983 Michael "Monty" Widenius > 1995 MySQL AB > 2008 Sun Microsystems > 2009 Oracle
Open Source
GPL 2, Entwicklung wird von Oracle geleitet
ACID
> Transaktionen
A
tomicity
"alles oder nichts", Transaktion wird nur im ganzen ausgeführt oder garnicht
C
onsistency
nur valide Daten mit Erfüllung aller Regeln/Abhängikeiten werden geschrieben
I
solation
Sicherstellung, dass jede Transaktion unabhängig von anderen abgeschlossen werden kann
D
urability
dauerhafte Speicherung, Daten sind auch nach einem Crash noch konsistent
MVCC
M
ulti
v
ersion
C
oncurrency
C
ontrol
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
single point of failure
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
alle Master sind aktiv
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
Danke
Fragen?
Jens Nauber
Software und Server
Fahrräder und Kaffee
@_jensen
+JensNauber
MySQL/MariaDB + Performance + Clustering
By Jens Nauber
Made with Slides.com
MySQL/MariaDB + Performance + Clustering
1,181
Jens Nauber
Software engineer and DevOps.
_jensen
More from
Jens Nauber