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