NoSQL User Group Cologne

Transkript

1 NoSQL User Group Cologne Dieser Vortrag wurde im Rahmen eines Treffens der NoSQL User Group Cologne am gehalten. Wir treffen uns immer am ersten Mittwoch des Monats. Weitere Informationen zur User Group: Website Twitter Mailingliste

2 MySQL goes NOSQL? NOSQL UG Cologne Jan

3 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)

4 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)

5 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)

6 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

7 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

8 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!

9 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?

10 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

11 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 Web- Technologien wie z. B. JSON, REST, HTTP Ease of use: simple Protokolle, Verzicht auf RDBMS- Features wie z. B. SQL, ACID, Transaktionen High performance: Ziel ist Maximierung queries/sek.

12 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

13 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

14 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.)

15 InnoDB_Memcache Umsetzung memcached innerhalb von MySQL (als daemon plugin = Thread in mysqld) ansprechbar über memcache-protocol (text und binary) auf Port (änderbar) umgeht komplett das normale MySQL- Client/Server-Protokoll inkl. SQL parsing, optimizing usw. greift intern direkt auf die InnoDB-API zu

16 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)

17 InnoDB_Memcache

18 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

19 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

20 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)

21 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;

22 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

23 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

24 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

25 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

26 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

27 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!

28 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)

29 InnoDB_Memcache Voraussetzungen Linux und MySQL technology preview Verfügbarbarkeit nur als technology preview in Lab-Version nicht empfohlen für Produktiveinsatz Download: Links with_memcached

30 MySQL Cluster memcached es gibt auch eine Lab-Version für MySQL Cluster memcache ist hier als transparente Caching- Lö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

31 HandlerSocket Community-Lösung mit ähnlichem Prinzip Ziel: Umgehung des SQL-Overheads bereits vor ca. 1 Jahr veröffentlicht

32 HandlerSocket Umsetzung Zugriff auf Low level-operationen von InnoDB über zusätzliches daemon plugin umgeht komplett das normale MySQL-Client/Server- Protokoll 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)

33 HandlerSocket Zugriff auf folgende low level-funktionen PK/unique lookup non-unique Index lookups index range scans insert update delete

34 HandlerSocket

35 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

36 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

37 HandlerSocket Autor: Akira Higuchi, DeNA Co., Ltd. Download: Voraussetzungen Percona Server (MySQL-Fork) 5.1.5x oder höher ODER MariaDB (MySQL-Fork) 5.3 ODER MySQL 5.1 (Plugin kompilieren) Link ng-mysql-as-nosql-story-for.html