NoSQL User Group Cologne

NoSQL User Group Cologne
Dieser Vortrag wurde im Rahmen eines Treffens der
NoSQL User Group Cologne am 07.09.2011 gehalten.
Wir treffen uns immer am ersten Mittwoch des Monats.
Weitere Informationen zur User Group:
Website
Twitter
Mailingliste
MySQL goes NOSQL?
07.09.2011 - NOSQL UG Cologne
Jan
Bestandsaufnahme MySQL
• Vorteile (simplifiziert)
– „the world‘s most popular open source database“
– kommerzieller Support von mehreren Anbietern und
aktive Community
– „modulare“ Architektur: Datenbank-Server-Kern mit
verschiedenen Storage engine-Back ends (MyISAM,
InnoDB, Memory, …) und Plugins (seit MySQL 5.1)
– Storage engines nach Wahl einsetzbar
(ACID vs. non-ACID)
Bestandsaufnahme MySQL
• Vorteile (simplifiziert)
– einfach aufzusetzen und „vergebende“
Standardkonfiguration (errors => warnings)
– read scaling über Replikation & Slaves möglich
• Nachteile (simplifiziert)
– kein write scaling: Replikation = shared-everything,
Datenbank kann nicht größer werden als ein
physischer Server
(Multi-Master-Setup ist zwar möglich, aber nicht
transparent für Applikation)
Bestandsaufnahme MySQL
• Nachteile (simplifiziert)
– relativ ineffizient und nutzlos für (B)LOB-Storage
– RDBMS-Overhead
• Datenbankschema zwingend erforderlich
• SQL parsing und optimizing auch bei Queries (z. B. primary
Key-Zugriffe)
• ausgelegt auf zeilenbasierte Zugriffspattern (row store)
Herausforderungen für MySQL
(und andere RDBMS)
• mit Standard-MySQL können writes nicht sinnvoll
skaliert werden
– Beschränkung der Datenmenge auf einen physischen
Server (=Limit) oder
– handgebautes Sharding über mehrere Server
(=potenziell fehleranfällig)
• Daten sind in der Praxis tw. unstrukturiert oder
semi-strukturiert
(in SQL: JSON => BLOB, XML => BLOB)
– in MySQL schwer auswertbar, außerdem ineffizient
Herausforderungen für MySQL
(und andere RDBMS)
• Datenbank-Features werden nicht für alle Daten
benötigt oder können von anderen Layern
übernommen werden
– Authentifizierung / Zugriffsrechte?
– können ja auch Firewall oder web server lösen!
• SQL-Overhead für viele Zugriffspattern sinnlos
(z. B. primary key access):
– Query parsing
– Query optimierung
– Joins
Herausforderungen für MySQL
(und andere RDBMS)
• ACID-Anforderungen gelten nicht immer
gleichermaßen für alle Arten von Daten (z. B.
Caches, Sessions, Counter, …)*
– tw. nur systemweite Konfigurationsmöglichkeit für
ACID-Eigenschaften => alle Daten werden gleich
(teuer) behandelt
– eventual consistency oder sogar no consistency wäre
oft ausreichend und wünschenswert um mehr
Durchsatz zu erreichen
* anwendungsfallabhängig!
Herausforderungen für MySQL
(und andere RDBMS)
• starres Datenbank-Schema behindert oft die
Entwicklung und ist in vielen Fällen Overkill
– ALTER TABLE ist eine blockierende Operation
(=Downtime, zumindest in MySQL)
– relationales Modell passt nicht:
• welche Spalten hat ein JSON-Objekt?
• ist referenzielle Integrität bei eventual consistency
überhaupt sinnvoll?
Bestandsaufnahme NOSQL
• NOSQL ist seit ca. 3-4 Jahren ein Hype-Thema
• entstanden u.a. als Reaktion auf spezielle
Probleme, die von MySQL und anderen RDBMS
nur unzureichend gelöst werden
• meist als Ersatz oder Ergänzung für RDBMS im
Einsatz
• NoSQL-Produkte lösen die genannten Probleme
tw., aber nicht alle gleichzeitig
Bestandsaufnahme NOSQL
• unterschiedliche Produkte und Schwerpunkte
– Skalierung: write scaling durch shared-nothing oder
shared-something (wg. high availability/failover)
– Schemafreiheit: Dokumentenorientierung, column
families etc.
– Integration: gutes Zusammenspiel mit WebTechnologien wie z. B. JSON, REST, HTTP
– Ease of use: simple Protokolle, Verzicht auf RDBMSFeatures wie z. B. SQL, ACID, Transaktionen
– High performance: Ziel ist Maximierung queries/Sek.
MySQL + NOSQL im Parallelbetrieb
• NOSQL-Lösungen sind oft sehr spezialisiert
• MySQL (oder anderes RDBMS) oft noch für
andere Anwendungsfälle im Einsatz
• Kombinationslösung verkompliziert die
Infrastruktur und die Entwicklung
• Datenaustausch zwischen NOSQL und MySQL
(oder anderem RDBMS) muss selbst realisiert
werden
NOSQL integriert in MySQL
• ein weiterer Ansatz besteht darin, bestimmte
NOSQL-Features direkt in MySQL zu integrieren
• der Ansatz löst ebenfalls nicht alle Probleme,
aber verbessert einige Aspekte
• es gibt folgende vorhandene Lösungen
– Oracle: InnoDB_Memcache
– Oracle: MySQL Cluster memcached
– Community: HandlerSocket
InnoDB_Memcache
• Von Oracle bereitgestellte Lösung mit
Memcache(d) als front end für InnoDB
• Memcache(d):
– RAM-basierter Caching-Service
– 3rd party-Produkt
– Daten sind flüchtig
• InnoDB
– transaktionale Storage engine für MySQL
– ACID-Eigenschaften (durability, Transaktionen usw.)
InnoDB_Memcache
• Umsetzung
– memcached innerhalb von MySQL
(als daemon plugin = Thread in mysqld)
– ansprechbar über memcache-Protocol (text und
binary) auf Port 11211 (änderbar)
– umgeht komplett das „normale“ MySQLClient/Server-Protokoll inkl. SQL parsing, optimizing
usw.
– greift intern direkt auf die InnoDB-API zu
InnoDB_Memcache
• bietet verschiedene Zugriffsmodi
– cache_only: nur Memcache
– innodb_only: nur InnoDB
– caching: beides in Kombination
(einstellbar für jeweils GET-, SET-, DELETE-Operationen)
InnoDB_Memcache
http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/
InnoDB_Memcache
• Interessant ist insbesondere der kombinierte
Modus mit transparentem Fallback („caching“)
• Lesen
– wenn Key in Memcache vorhanden, bediene Anfrage
aus Memcache
– Wenn Key nicht in Memcache vorhanden, suche Key in
InnoDB, speichere in Memcache und antworte
• Schreiben
– Wert für den Key wird in Memcache und InnoDB
gespeichert
InnoDB_Memcache
• möglich ist jetzt auch die Nutzung des
Memcache-Protokolls für reine InnoDB-Zugriffe
• damit wird InnoDB zum Key-Value-Store ohne
vorgeschalteten SQL-Overhead
InnoDB_Memcache
• Konfiguration über InnoDB-Tabellen
– innodb_memcache.cache_policy:
Cache-Policy (innodb_only, cache_only, caching)
– Innodb_memcache.containers:
Datenbanktabelle für persistenten Storage (Tabelle
muss bestimmten Anforderungen genügen)
– innodb_memcache.config_options:
weitere Konfiguration (aktuell nur Separator für
mehrspaltige Operationen)
InnoDB_Memcache
CREATE TABLE IF NOT EXISTS `containers` (
`name` varchar(50) not null primary key,
`db_schema` VARCHAR(250) NOT NULL,
`db_table` VARCHAR(250) NOT NULL,
`key_columns` VARCHAR(250) NOT NULL,
`value_columns` VARCHAR(250),
`flags` VARCHAR(250) NOT NULL DEFAULT "0",
`cas_column` VARCHAR(250),
`expire_time_column` VARCHAR(250),
`unique_idx_name_on_key` VARCHAR(250) NOT NULL
) ENGINE = InnoDB;
InnoDB_Memcache
Beispiel (bereitgestellt im InnoDB_Memcache-Build):
INSERT INTO innodb_memcache.containers VALUES
("aaa", "test", "demo_test“, "c1", "c2", "c3", "c4", "c5",
"PRIMARY");
-- We create a InnoDB table `demo_test` in the `test` database
and insert an entry into contrainers table to tell InnoDB
Memcache that we have such InnoDB table as back store:
-- c1 -> key
-- c2 -> value
-- c3 -> flags
-- c4 -> cas
-- c5 -> exp time
-- PRIMARY -> use primary key to search
InnoDB_Memcache
• memcache kennt kein USE …;
• aktuell kann immer nur eine Tabelle aus einer
Datenbank als InnoDB-Back end konfiguriert
werden
• alle Daten landen in derselben InnoDB-Tabelle
InnoDB_Memcache
• Vorteile
– benutzt memcache-Protokoll:
sehr simpel, kein Overhead für SQL parsing,
optimizing oder Authentifizierung
– kompatibel zu memcache:
nutzbar mit allen Anwendungen, die bereits
memcache nutzen/unterstützen, erweitert
Memcache um Persistenz
InnoDB_Memcache
• Vorteile
– InnoDB im Hintergrund:
Memcache ist durable, ACID!
– zusätzlicher Zugriffskanal:
Daten sind in InnoDB vorhanden und können weiterhin
„normal“ per SQL abgefragt werden
– nur ein Datenbestand:
simplere Infrastruktur: kein separater Memcache,
keine redundanten Datenbestände
keine Differenzen zwischen persistenten Daten und
Cache, automatische Cache-Invalidation! **
** wenn alle Zugriffe über innodb_memcache ablaufen
InnoDB_Memcache
• Nachteile
– noch nicht für Produktion empfohlen
– nicht als stabil deklariert, kann sich bis zu einem
„richtigen“ Release noch deutlich ändern
– ziemlicher Hack
InnoDB_Memcache
• Nachteile
– skaliert nicht über die Grenzen eines physischen
MySQL-Servers hinaus
– klaut Ressourcen des potenziellen Bottlenecks
Datenbank/MySQL
– Security: hebelt MySQL-Authentifizierung aus
– nur eine Tabelle als persistenter Storage
– unintuitives Standardverhalten bei Commits
– writes per SQL-Zugriffsmodus invalidieren die
Werte im Memcache nicht, Inkonsistenzgefahr!
InnoDB_Memcache
• Fallstricke
– InnoDB-Commit bewirkt I/O (fsync) für durability
– Commit in InnoDB_Memcache erfolgt daher
standardmäßig erst nach 32 Schreiboperationen
– andere MySQL-Sessions sehen die nicht
committeten Daten zunächst noch nicht
– Fixes
• SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED (=dirty reads)
• Commit-Rate erhöhen (=mehr fsyncs = mehr I/O)
InnoDB_Memcache
• Voraussetzungen
– Linux und MySQL 5.6.2 technology preview
• Verfügbarbarkeit
– nur als „technology preview“ in Lab-Version
– nicht empfohlen für Produktiveinsatz
– Download: http://labs.mysql.com/
• Links
– http://blogs.innodb.com/wp/2011/04/nosql-toinnodb-with-memcached/
– http://blogs.oracle.com/mysql/entry/nosql_to_mysql_
with_memcached
MySQL Cluster memcached
• es gibt auch eine Lab-Version für MySQL Cluster
• memcache ist hier als transparente CachingLösung in MySQL Cluster eingebaut
• ähnlich InnoDB_Memcache, aber mit MySQL
Cluster als Back end
• MySQL Cluster ermöglicht Skalierung (shared
nothing und shared something für high
availability) über mehrere physische Server
HandlerSocket
• Community-Lösung mit ähnlichem Prinzip
• Ziel: Umgehung des SQL-Overheads
• bereits vor ca. 1 Jahr veröffentlicht
HandlerSocket
• Umsetzung
• Zugriff auf Low level-Operationen von InnoDB über
zusätzliches daemon plugin
• umgeht komplett das „normale“ MySQL-Client/ServerProtokoll inkl. SQL parsing, optimizing usw.
• greift intern auf die Handler-API von MySQL zu
• Ports 9998 (read) und 9999 (write)
• Thread (worker) pool
• eigenes, textbasiertes Protokoll
• Multi-Query-Unterstützung (mehrere Operationen in
einem Request möglich)
HandlerSocket
• Zugriff auf folgende low level-Funktionen
•
•
•
•
•
•
PK/unique lookup
non-unique Index lookups
index range scans
insert
update
delete
HandlerSocket
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html
HandlerSocket
• Vorteile
– InnoDB im Hintergrund:
bewährte Storage engine mit durability
– Zusätzlicher Zugriffskanal:
Daten sind in InnoDB vorhanden und können
weiterhin „normal“ per SQL abgefragt werden
– nur ein Datenbestand:
keine Differenzen zwischen Daten bei SQL-Zugriff
und bei Zugriff über HandlerSocket**
** Query cache ist aber noch broken
HandlerSocket
• Nachteile
– Non-Standard-Protokoll:
eigene (aber simple) Implementierung im Client
erforderlich
– nicht bundled:
nur in MySQL-Forks vorhanden bzw. als Plugin, aber
nicht in einem „offiziellen“ MySQL-Release
– Weiterentwicklung unklar:
keine wirklichen Releases oder Roadmap, Adoption
durch Community unbekannt
– „Bugs“:
aktuell kein auto_increment als Return bei INSERT
MySQL query cache wird nicht invalidiert bei writes
HandlerSocket
• Autor: Akira Higuchi, DeNA Co., Ltd.
• Download:
https://github.com/ahiguti/HandlerSocket-Pluginfor-MySQL
• Voraussetzungen
• Percona Server (MySQL-Fork) 5.1.5x oder höher ODER
• MariaDB (MySQL-Fork) 5.3 ODER
• MySQL 5.1 (Plugin kompilieren)
• Link
• http://yoshinorimatsunobu.blogspot.com/2010/10/usi
ng-mysql-as-nosql-story-for.html