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
    • 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
Made with Slides.com