SlideShare ist ein Scribd-Unternehmen logo
1 von 37
Downloaden Sie, um offline zu lesen
HandlerSocket und ähnliche Technologien –

         NoSQL für MySQL

Internet Briefing Developer Konferenz
      8. Dezember 2011, Zürich

             Oli Sennhauser
         Senior MySQL Consultant, FromDual

        oli.sennhauser@fromdual.com
FromDual
●   FromDual bietet neutral und unabhängig:
    ●   Beratung für MySQL (vor Ort und remote)
    ●   Remote-DBA / MySQL Betrieb
    ●   Support für MySQL/Galera (synchrone Replikation)
    ●   Support für MySQL (Basic und Silber)
    ●   Schulung für MySQL
●   Consulting Partner der Open Database Alliance
    (ODBA.org)
●   Oracle Silber Partner (OPN)
●   Mehr Informationen unter:
                    http://www.fromdual.com
Kunden
Inhalt
●   NoSQL Trends
●   SQL Overhead
●   HandlerSocket
●   NDB-API
●   BLOB Streaming Engine
●   Handler Interface
●   Graph Storage Engine
●   Memcache API für MySQL
●   Spider
Trends

MySQL    NoSQL
Wo liegt das Problem?

                        Storage Engine Anteil

                         SQL Overhead



●   SQL Overhead ist 70 – 80% für einfache Queries (~ 1
    ms)!
●   mit NO SQL → könnten wir bis zu 5 x schneller werden
●   SQL ist gemacht für komplexe Abfragen
●   NoSQL löst typischerweise einfache Abfragen
Woher rührt der Overhead?
             Application / Client

  Thread            Connection         mysqld
  Cache              Manager                                      Parser
                                            Optimizer
                      User Au-
                    thentication
                                       Access Control
                    Command                                          Table Open
  Logging
                    Dispatcher                                      Cache (.frm, fh)
                                        Table Manager
   Query            Query Cache                                     Table Definition
   Cache              Module                                        Cache (tbl def.)

                                    Handler Interface


  MyISAM   InnoDB    Memory   NDB     PBMS        Aria   XtraDB    Federated-X   ...
Was können wir dagegen tun?
●   HandlerSocket (2010)
●   NDB-API (1997!)
●   PrimeBase Streaming Engine (2008)
●   Handler Interface (2001/2011)
●   Memcached (ab 2006, 2011)
●   OQGRAPH SE (2009)
●   Memcached API für MySQL (2011)
●   Spider (2008)
HandlerSocket
●   20. Oktober 2010, Yoshinori Matsunobu:
    Using MySQL as a NoSQL - A story for ex-
    ceeding 750,000 qps on a commodity server
                                                      Application / Client


                   Connection                mysqld                                        Connection
                    Manager                                     Parser                      Manager
                                               Optimizer
                     User Au-                                                               HandlerSocket
                   thentication
                                                                                               Plugin
                                            Access Control         Table Manager
                       Command
                       Dispatcher

                   Query Cache                                                         SE-API   Worker
                     Module                                                                     Threads
                                          Handler Interface

     MyISAM   InnoDB     Memory     NDB       PBMS    Aria    XtraDB   Federated-X   ...
SELECT


# SELECT * FROM test.test where id = 42;

use Net::HandlerSocket;

my $args = { host => 'master', port => 9998 };
my $hs = new Net::HandlerSocket($args);

my $res = $hs->open_index(0, 'test', 'test', 'PRIMARY', 'id,data,ts');

$res = $hs->execute_single(0, '=', [ '42' ], 1, 0);
shift(@$res);
for (my $row = 0; $row < 1; ++$row) {
  print "$idt$datat$tsn";
}

$hs->close();
Infos
●   Selber compilieren (einfach!)
●   7.5 mal mehr Durchsatz?!?
●   Funktioniert mit MySQL 5.5.8 und MariaDB
●   Schneller als mem-
    cached!?!
●   Im Percona-Server
    12.3
Features / Funktionalität
●   Ermöglicht ganz andere Abfragemuster (siehe auch
    Handler Interface)
●   Viele concurrent Connections
●   Hochperformant (200 – 700%)
●   Keinen doppelten Cache (vs. MySQL und memcached)
●   Keine Dateninkonsistenz (vs. MySQL und memcached)
●   Crash-safe
●   SQL Zugriff ebenfalls möglich (z. B. für komplexe
    Reportingabfragen)
●   MySQL muss nicht modifiziert/neu gebaut werden?!?
●   Funktioniert theoretisch auch für andere Storage
    Engines (ich hab's nicht ausprobiert).
NDB-API
●   1997, Mikael Ronström's Ph.D.:
    The NDB Cluster – A parallel data server for
    telecommunications applications
●   25. November 2008, Jonas Oreland:
    950'000 reads per second on 1 datanode
MySQL Cluster

    Application   Application      Application    Application    Application
     NDB-API       NDB-API
                                                 Load balancer

                                   SQL Node 1     SQL Node 2     SQL Node 3
                                                                               ...
Mgm Node 1


Mgm Node 2
                     Data Node 1            Data Node 2


                                     Sw.
                                      Sw.

                     Data Node 3            Data Node 4
INSERT


// INSERT INTO cars VALUES (reg_no, brand, color);

const NdbDictionary::Dictionary* myDict= myNdb->getDictionary();
const NdbDictionary::Table *myTable= myDict->getTable("cars");

NdbTransaction* myTrans = myNdb->startTransaction();
NdbOperation* myNdbOperation = myTrans->getNdbOperation(myTable);

myNdbOperation->insertTuple();
myNdbOperation->equal("REG_NO", reg_no);
myNdbOperation->setValue("BRAND", brand);
myNdbOperation->setValue("COLOR", color);

int check = myTrans->execute(NdbTransaction::Commit);

myTrans->close();
SELECT

// SELECT * FROM cars;

const NdbDictionary::Dictionary* myDict= myNdb->getDictionary();
const NdbDictionary::Table *myTable= myDict->getTable("cars");

myTrans = myNdb->startTransaction();
myScanOp = myTrans->getNdbScanOperation(myTable);
myScanOp->readTuples(NdbOperation::LM_CommittedRead)

myRecAttr[0] = myScanOp->getValue("REG_NO");
myRecAttr[1] = myScanOp->getValue("BRAND");
myRecAttr[2] = myScanOp->getValue("COLOR");

myTrans->execute(NdbTransaction::NoCommit);

while ((check = myScanOp->nextResult(true)) == 0) {

  std::cout << myRecAttr[0]->u_32_value() << "t";
  std::cout << myRecAttr[1]->aRef() << "t";
  std::cout << myRecAttr[2]->aRef() << std::endl;
}
myNdb->closeTransaction(myTrans);
Benchmarks und Zahlen
●    ./flexAsynch -ndbrecord -temp -con 4 -t
     16 -p 312 -l 3 -a 2 -r 2
●    Aus der MySQL Cluster Test-Suite
     (src/storage/ndb/test/ndbapi)
●    16 number of concurrent threads (-t)       ●    4 concurrent connections (-con)
●    312 number of parallel operation per       ●    2 number of records (-r ?)
     thread                                     ●    1 32-bit word per attribute
●    3 iterations (-l)
                                                ●    1 ndbmtd (1 NoOfRepl.)
●    2 attributes per table (8 bytes) (-a)



    insert   average:   506506/s   min:   497508/s   max:   522613/s stddev: 2%
    update   average:   503664/s   min:   495533/s   max:   507833/s stddev: 1%
    delete   average:   494225/s   min:   474705/s   max:   518272/s stddev: 3%
    read     average:   980386/s   min:   942242/s   max:   1028006/s stddev: 2%
Lehren
●   Beobachtungen:
    ●   CPU's sind nicht am Limit. "Irgendwo" ist noch Potential !?!
    ●   Wenn übertrieben wird: CPU ist überlastet und Performance
        fällt auf 14%!
●   Schummeleien:
    ●   Schau die Parameter genau an!
    ●   Mit allen anderen Konfigurationen erhielt ich schlechteren
        Durchsatz!
    ●   Sobald eine IP anstatt localhost verwendet wird: 89%
        Durchsatz
●   Lehren:
    ●   Traue keinen Benchmarks, die Du nicht selber manipuliert
        hast!
Neuere Resultate
●   Michael Ronström, April/Mai 2011:
    ●   6.82M reads per second
    ●
        2.46M updates per second

                                      MySQL Cluster Performance
                        8000000

                        7000000

                        6000000

                        5000000

                        4000000                                     Read / s
                  ops




                                                                    Update / s
                        3000000

                        2000000

                        1000000

                             0
                                  4          8            16   32
                                           # data nodes




●   Mehr als lineares Skalieren scheint möglich (Caching-Effekte)!
Und wenn wir uns das nicht antun
wollen?
●   Ab MySQL Cluster 7.1 (7.0)
BLOB Streaming Projekt
●   BLOB's sind nicht geeignet fürs RDBMS!
●   April 2008, Paul McCullagh: Introduction to
    the BLOB Streaming Project
●   5. März 2010, Barry Leslie: Upload 1000+
    BLOB's per second!
Vorteile von BLOB's in der
Datenbank
●   alt: RDBMS sind nicht schnell mit dem Speichern
    von BLOB's → BLOB's NICHT in der Datenbank
    speichern
●   neu: Mit NoSQL Technologien wird es viel besser!
●   Mit PBSE: atomare Transaktionen → Keine ins
    Nirgendwo zeigende Referenzen.
●   BLOB's im normalen Datenbank-Backup !?!
●   BLOB's können repliziert werden
●   BLOB's in der DB skalieren besser. Die meisten
    Filesysteme performen schlecht mit mehr als 2
    Millionen Dateien ?
Das Handler Interface
●   Oktober 2001, MySQL Handbuch: A new
    HANDLER interface to MyISAM tables
●   27. Dezember 2010, Stephane Varoqui:
    Using MySQL as a NoSQL: a story for
    exceeding 450'000 qps with MariaDB
●   10. Januar 2011, Stephane Varoqui: 20% to
    50% improvement in MariaDB 5.3 Handler
    Interface using prepared statement
Überspringen des Overheads mit
dem Handler Interface
             Application / Client

  Thread            Connection         mysqld
  Cache              Manager                                      Parser
                                            Optimizer
                      User Au-
                    thentication
                                       Access Control
                    Command                                          Table Open
  Logging
                    Dispatcher                                      Cache (.frm, fh)
                                        Table Manager
   Query            Query Cache                                     Table Definition
   Cache              Module                                        Cache (tbl def.)

                                    Handler Interface


  MyISAM   InnoDB    Memory   NDB     PBXT        Aria   XtraDB    Federated-X   ...
HANDLER Beispiel

# MySQL
# SELECT * FROM family;
                                    HANDLER tbl OPEN
HANDLER   family OPEN;
                                    HANDLER tbl READ idx (..., ..., …)
HANDLER   family
                                      WHERE ... LIMIT ...
   READ   `PRIMARY` = (id)
  WHERE   id = 1;
                                    HANDLER   tbl   READ idx FIRST
HANDLER   family CLOSE;
                                      WHERE   ...   LIMIT ...
                                    HANDLER   tbl   READ idx NEXT
                                      WHERE   ...   LIMIT ...
# With MariaDB 5.3
                                    HANDLER   tbl   READ idx PREV
                                      WHERE   ...   LIMIT ...
HANDLER family OPEN;
                                    HANDLER   tbl   READ idx LAST
PREPARE stmt
                                      WHERE   ...   LIMIT ...
   FROM 'HANDLER family
            READ `PRIMARY` = (id)
                                    HANDLER   tbl   READ FIRST
           WHERE id = ?';
                                      WHERE   ...   LIMIT ...
set @id=1;
                                    HANDLER   tbl   READ NEXT
EXECUTE stmt USING @id;
                                      WHERE   ...   LIMIT ...
DEALLOCATE PREPARE stmt;
HANDLER family CLOSE;
                                    HANDLER tbl CLOSE
Use persistent connections!!!
Charakteristik des Handler
Interfaces
●   HANDLER ist schneller als SELECT:
    ●  Weniger Parsing
     ● Kein Optimizer Overhead


     ● Weniger Query-Checking Overhead


     ● Die Tabelle muss zwischen zwei Handler-Anfragen

       nicht gelocket werden
●   KEINE konsistente Sicht auf die Daten (dirty reads
    sind erlaubt)
●   Optimierungen sind möglich, welche SELECT nicht
    zulässt
●   Traversieren der Daten auf eine Art, welche schwierig
    bis unmöglich mit SELECT zu erlangen ist
Neu aus den MySQL Labs
●   Memcached Plugin für InnoDB (5.6)
Neu aus den MySQL Labs
●   Memcached API für MySQL Cluster (7.2)
Eine Graphen Storage Engine
●   5. Mai 2009, Arjen Lentz: OQGRAPH
    Computation Engine for MySQL, MariaDB &
    Drizzle




●   In MariaDB 5.1 ff.
●   Verfügbar für MySQL 5.0 ff.
●   Seit kurzem auch persistent!
Wie fühlt sich das an?
●   Es ist ähnlich wie die MEMORY SE (Persistenz, Locking,
    trx)
                                        Node
●   Wir sprechen in:
    ●   Node/Item/Vertex und
    ●   Edge/Connection/Link
●   Edges haben eine Richtung                    Edge
●   Wir können Netzwerke und Hierarchien abbilden
    ●   (Familienbeziehungen, Freunde von Freunden, kürzeste
        Strecke von A nach B)
●   Um mit der OQGRAPH SE zu sprechen brauchen wir
    “latches” (welcher Algorithmus zu verwenden ist)
●   Es ist eine “computational engine” nicht eine Storage
    Engine!
Einfaches Beispiel: Meine Familie

                                        SELECT   f1.name AS parent, f2.name AS child
INSERT INTO family VALUES                 FROM   relation AS r
  (1, 'Grand-grand-ma')                   JOIN   family f1 ON f1.id = r.origid
, (2, 'Grand-ma')                         JOIN   family f2 ON f2.id = r.destid;
, (3, 'Grand-uncle')
, (4, 'Grand-aunt')                     +----------------+-------------+
, (5, 'Grand-pa')                       | parent         | child       |
, (6, 'Mother')                         +----------------+-------------+
, (7, 'Uncle 1')                        | Grand-grand-ma | Grand-ma    |
, (8, 'Uncle 2')                        | Grand-grand-ma | Grand-uncle |
, (9, 'Father')                         | Grand-grand-ma | Grand-aunt |
, (10, 'Me')                            | Grand-ma       | Mother      |
, (11, 'Sister');                       | Grand-ma       | Uncle 1     |
                                        | Grand-ma       | Uncle 2     |
INSERT INTO relation (origid, destid)   | Grand-pa       | Mother      |
VALUES                                  | Grand-pa       | Uncle 1     |
  (1, 2), (1, 3), (1, 4)                | Grand-pa       | Uncle 2     |
, (2, 6), (2, 7), (2, 8)                | Mother         | Me          |
, (5, 6), (5, 7), (5, 8)                | Mother         | Sister      |
, (6, 10), (6, 11)                      | Father         | Me          |
, (9, 10), (9, 11);                     | Father         | Sister      |
                                        +----------------+-------------+
Netzwerk-Abfragen

                                                 SELECT   r.weight, r.seq, f.name
SELECT GROUP_CONCAT(f.name SEPARATOR ' -> ')       FROM   relation AS r
       AS path                                     JOIN   family AS f ON (r.linkid = f.id)
  FROM relation AS r                              WHERE   r.latch = 2
  JOIN family AS f ON (r.linkid = f.id)             AND   r.destid = 10;
 WHERE latch = 1
   AND origid = 1
   AND destid = 10                               +--------+------+----------------+
ORDER BY seq;                                    | weight | seq | name            |
                                                 +--------+------+----------------+
+--------------------------------------------+   |      3 |    6 | Grand-grand-ma |
| path                                       |   |      2 |    5 | Grand-pa       |
+--------------------------------------------+   |      2 |    4 | Grand-ma       |
| Grand-grand-ma -> Grand-ma -> Mother -> Me |   |      1 |    3 | Father         |
+--------------------------------------------+   |      1 |    2 | Mother         |
                                                 |      0 |    1 | Me             |
                                                 +--------+------+----------------+
latch = 1: Find shortest path (Dijkstra)
                                                 latch = 2: Find originating nodes
Sharding mit der Spider-SE
Übersicht


Technologie                r/w        Trx    Sprachen
MySQL                      ja / ja     ja    “alle”, SQL
HandlerSocket              ja / ja    nein   C++, Perl, Ruby, PHP,
                                             Java, Pyhton, ...
NDB-API (MySQL Cluster)    ja / ja     ja    C++, Java, (SQL)
PBSE                       ja / ja     ja    C++, SQL
Handler Interface         ja / nein   nein   “alle”, SQL
OQGRAPH SE                 ja / ja    nein   “alle”, SQL
Memcached-API              ja / ja    nein   C++, Perl, Ruby, PHP,
                                             Java, Pyhton, ...
Zusammenfassung
●   SQL ist gut für komplexe Abfragen
●   NoSQL üblicherweise für einfache Abfragen
●   Vorsicht mit Performance-Zahlen!
●   Architektur / Programmierung wird
    komplexer
●   Bessere Performance ist möglich

●   Aber es ist verdammt interessant!
Literatur
●   Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity
    server: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-
    nosql-story-for.html
●   950k reads per second on 1 datanode:
    http://jonasoreland.blogspot.com/2008/11/950k-reads-per-second-on-1-
    datanode.html
●   Scalable BLOB Streaming Infrastructure for MySQL and Drizzle:
    http://www.blobstreaming.org/
●   HandlerSocket: Why did our version not take off?
    http://pbxt.blogspot.com/2010/12/handlersocket-why-did-out-version-did.html
●   Using MySQL as a NoSQL: a story for exceeding 450000 qps with MariaDB:
    http://varokism.blogspot.com/2010/12/using-mysql-as-nosql-story-for_27.html
●   HANDLER Syntax: http://dev.mysql.com/doc/refman/5.5/en/handler.html
●   GRAPH Computation Engine – Documentation:
    http://openquery.com/graph/doc
Q&A



                Fragen ?

              Diskussion?


  Wir haben noch Zeit für persönliche und
         individuelle Beratungen...


              www.fromdual.com

Weitere ähnliche Inhalte

Was ist angesagt?

MySQL - New Features 5.6
MySQL - New Features 5.6MySQL - New Features 5.6
MySQL - New Features 5.6
FromDual GmbH
 
DOAG: NoSQL with MySQL
DOAG: NoSQL with MySQLDOAG: NoSQL with MySQL
DOAG: NoSQL with MySQL
FromDual GmbH
 
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQLInternet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
FromDual GmbH
 

Was ist angesagt? (20)

NoSQL with MySQL
NoSQL with MySQLNoSQL with MySQL
NoSQL with MySQL
 
MySQL Backup/Recovery
MySQL Backup/RecoveryMySQL Backup/Recovery
MySQL Backup/Recovery
 
MySQL - New Features 5.6
MySQL - New Features 5.6MySQL - New Features 5.6
MySQL - New Features 5.6
 
MySQL-Server im Teamwork - Replikation und Cluster
MySQL-Server im Teamwork - Replikation und ClusterMySQL-Server im Teamwork - Replikation und Cluster
MySQL-Server im Teamwork - Replikation und Cluster
 
MySQL Beispiele aus der Praxis - Wie setzen Kunden MySQL ein?
MySQL Beispiele aus der Praxis - Wie setzen Kunden MySQL ein?MySQL Beispiele aus der Praxis - Wie setzen Kunden MySQL ein?
MySQL Beispiele aus der Praxis - Wie setzen Kunden MySQL ein?
 
MySQL für Oracle DBA's
MySQL für Oracle DBA'sMySQL für Oracle DBA's
MySQL für Oracle DBA's
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 
MySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA'sMySQL Performance Tuning für Oracle-DBA's
MySQL Performance Tuning für Oracle-DBA's
 
DOAG: NoSQL with MySQL
DOAG: NoSQL with MySQLDOAG: NoSQL with MySQL
DOAG: NoSQL with MySQL
 
MySQL Cluster with Galera Cluster for MySQL
MySQL Cluster with Galera Cluster for MySQLMySQL Cluster with Galera Cluster for MySQL
MySQL Cluster with Galera Cluster for MySQL
 
Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?Der Datenbank-Backup ist gemacht - was nun?
Der Datenbank-Backup ist gemacht - was nun?
 
MySQL Backup
MySQL BackupMySQL Backup
MySQL Backup
 
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQLInternet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
Internet Briefing 2010: Performance Tuning & Scale-Out mit MySQL
 
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-ReplikationWeltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
 
MySQL Performance Tuning für Entwickler
MySQL Performance Tuning für EntwicklerMySQL Performance Tuning für Entwickler
MySQL Performance Tuning für Entwickler
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 
MySQL HA and Security
MySQL HA and SecurityMySQL HA and Security
MySQL HA and Security
 
Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo LatschnerNagios Conference 2007 | Vmware Monitoring by Ingo Latschner
Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner
 
Helma Workshop
Helma WorkshopHelma Workshop
Helma Workshop
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
 

Ähnlich wie Internet Briefing 2011: NoSQL with MySQL

OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
AWS Germany
 

Ähnlich wie Internet Briefing 2011: NoSQL with MySQL (20)

Präsentation MySQL auf dem T3CM12
Präsentation MySQL auf dem T3CM12Präsentation MySQL auf dem T3CM12
Präsentation MySQL auf dem T3CM12
 
OOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDBOOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDB
 
Froscon 2012 DWH
Froscon 2012 DWHFroscon 2012 DWH
Froscon 2012 DWH
 
Renderscript in Android 3.x
Renderscript in Android 3.xRenderscript in Android 3.x
Renderscript in Android 3.x
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
 
Rex - Infrastruktur als Code
Rex - Infrastruktur als CodeRex - Infrastruktur als Code
Rex - Infrastruktur als Code
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der Wahl
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
 
JavaScript Performance
JavaScript PerformanceJavaScript Performance
JavaScript Performance
 
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
 
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDASchulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
 
Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!
 
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickBig Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
 
Scaling Rails
Scaling RailsScaling Rails
Scaling Rails
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point Admins
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
 
mongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - GrundlagenmongoDB im Einsatz - Grundlagen
mongoDB im Einsatz - Grundlagen
 
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas GelfOSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
 
An Introduction to Ruby On Rails
An Introduction to Ruby On RailsAn Introduction to Ruby On Rails
An Introduction to Ruby On Rails
 

Mehr von FromDual GmbH

Mehr von FromDual GmbH (19)

MariaDB/MySQL pitfalls - And how to come out again...
MariaDB/MySQL pitfalls - And how to come out again...MariaDB/MySQL pitfalls - And how to come out again...
MariaDB/MySQL pitfalls - And how to come out again...
 
MariaDB / MySQL tripping hazard and how to get out again?
MariaDB / MySQL tripping hazard and how to get out again?MariaDB / MySQL tripping hazard and how to get out again?
MariaDB / MySQL tripping hazard and how to get out again?
 
PXC 5.5 to MariaDB 10.4 Galera Cluster Migration Workshop
PXC 5.5 to MariaDB 10.4 Galera Cluster Migration WorkshopPXC 5.5 to MariaDB 10.4 Galera Cluster Migration Workshop
PXC 5.5 to MariaDB 10.4 Galera Cluster Migration Workshop
 
IT Tage 2019 MariaDB 10.4 New Features
IT Tage 2019 MariaDB 10.4 New FeaturesIT Tage 2019 MariaDB 10.4 New Features
IT Tage 2019 MariaDB 10.4 New Features
 
MariaDB 10.4 New Features
MariaDB 10.4 New FeaturesMariaDB 10.4 New Features
MariaDB 10.4 New Features
 
MariaDB 10.2 New Features
MariaDB 10.2 New FeaturesMariaDB 10.2 New Features
MariaDB 10.2 New Features
 
PERFORMANCE_SCHEMA and sys schema
PERFORMANCE_SCHEMA and sys schemaPERFORMANCE_SCHEMA and sys schema
PERFORMANCE_SCHEMA and sys schema
 
MySQL Security SLAC 2015
MySQL Security SLAC 2015MySQL Security SLAC 2015
MySQL Security SLAC 2015
 
MySQL Replikation - Die Eier legende Wollmilchsau?
MySQL Replikation - Die Eier legende Wollmilchsau?MySQL Replikation - Die Eier legende Wollmilchsau?
MySQL Replikation - Die Eier legende Wollmilchsau?
 
Reading MySQL fingerprints
Reading MySQL fingerprintsReading MySQL fingerprints
Reading MySQL fingerprints
 
High-availability with Galera Cluster for MySQL
High-availability with Galera Cluster for MySQLHigh-availability with Galera Cluster for MySQL
High-availability with Galera Cluster for MySQL
 
MySQL always-up with Galera Cluster
MySQL always-up with Galera ClusterMySQL always-up with Galera Cluster
MySQL always-up with Galera Cluster
 
HA with Galera
HA with GaleraHA with Galera
HA with Galera
 
MySQL Indexierung CeBIT 2014
MySQL Indexierung CeBIT 2014MySQL Indexierung CeBIT 2014
MySQL Indexierung CeBIT 2014
 
Need for Speed: Mysql indexing
Need for Speed: Mysql indexingNeed for Speed: Mysql indexing
Need for Speed: Mysql indexing
 
MySQL for Oracle DBAs
MySQL for Oracle DBAsMySQL for Oracle DBAs
MySQL for Oracle DBAs
 
MySQL High Availability Solutions
MySQL High Availability SolutionsMySQL High Availability Solutions
MySQL High Availability Solutions
 
MySQL Security
MySQL SecurityMySQL Security
MySQL Security
 
MySQL Performance Tuning Variables
MySQL Performance Tuning VariablesMySQL Performance Tuning Variables
MySQL Performance Tuning Variables
 

Internet Briefing 2011: NoSQL with MySQL

  • 1. HandlerSocket und ähnliche Technologien – NoSQL für MySQL Internet Briefing Developer Konferenz 8. Dezember 2011, Zürich Oli Sennhauser Senior MySQL Consultant, FromDual oli.sennhauser@fromdual.com
  • 2. FromDual ● FromDual bietet neutral und unabhängig: ● Beratung für MySQL (vor Ort und remote) ● Remote-DBA / MySQL Betrieb ● Support für MySQL/Galera (synchrone Replikation) ● Support für MySQL (Basic und Silber) ● Schulung für MySQL ● Consulting Partner der Open Database Alliance (ODBA.org) ● Oracle Silber Partner (OPN) ● Mehr Informationen unter: http://www.fromdual.com
  • 4. Inhalt ● NoSQL Trends ● SQL Overhead ● HandlerSocket ● NDB-API ● BLOB Streaming Engine ● Handler Interface ● Graph Storage Engine ● Memcache API für MySQL ● Spider
  • 5. Trends MySQL NoSQL
  • 6. Wo liegt das Problem? Storage Engine Anteil SQL Overhead ● SQL Overhead ist 70 – 80% für einfache Queries (~ 1 ms)! ● mit NO SQL → könnten wir bis zu 5 x schneller werden ● SQL ist gemacht für komplexe Abfragen ● NoSQL löst typischerweise einfache Abfragen
  • 7. Woher rührt der Overhead? Application / Client Thread Connection mysqld Cache Manager Parser Optimizer User Au- thentication Access Control Command Table Open Logging Dispatcher Cache (.frm, fh) Table Manager Query Query Cache Table Definition Cache Module Cache (tbl def.) Handler Interface MyISAM InnoDB Memory NDB PBMS Aria XtraDB Federated-X ...
  • 8. Was können wir dagegen tun? ● HandlerSocket (2010) ● NDB-API (1997!) ● PrimeBase Streaming Engine (2008) ● Handler Interface (2001/2011) ● Memcached (ab 2006, 2011) ● OQGRAPH SE (2009) ● Memcached API für MySQL (2011) ● Spider (2008)
  • 9. HandlerSocket ● 20. Oktober 2010, Yoshinori Matsunobu: Using MySQL as a NoSQL - A story for ex- ceeding 750,000 qps on a commodity server Application / Client Connection mysqld Connection Manager Parser Manager Optimizer User Au- HandlerSocket thentication Plugin Access Control Table Manager Command Dispatcher Query Cache SE-API Worker Module Threads Handler Interface MyISAM InnoDB Memory NDB PBMS Aria XtraDB Federated-X ...
  • 10. SELECT # SELECT * FROM test.test where id = 42; use Net::HandlerSocket; my $args = { host => 'master', port => 9998 }; my $hs = new Net::HandlerSocket($args); my $res = $hs->open_index(0, 'test', 'test', 'PRIMARY', 'id,data,ts'); $res = $hs->execute_single(0, '=', [ '42' ], 1, 0); shift(@$res); for (my $row = 0; $row < 1; ++$row) { print "$idt$datat$tsn"; } $hs->close();
  • 11. Infos ● Selber compilieren (einfach!) ● 7.5 mal mehr Durchsatz?!? ● Funktioniert mit MySQL 5.5.8 und MariaDB ● Schneller als mem- cached!?! ● Im Percona-Server 12.3
  • 12. Features / Funktionalität ● Ermöglicht ganz andere Abfragemuster (siehe auch Handler Interface) ● Viele concurrent Connections ● Hochperformant (200 – 700%) ● Keinen doppelten Cache (vs. MySQL und memcached) ● Keine Dateninkonsistenz (vs. MySQL und memcached) ● Crash-safe ● SQL Zugriff ebenfalls möglich (z. B. für komplexe Reportingabfragen) ● MySQL muss nicht modifiziert/neu gebaut werden?!? ● Funktioniert theoretisch auch für andere Storage Engines (ich hab's nicht ausprobiert).
  • 13. NDB-API ● 1997, Mikael Ronström's Ph.D.: The NDB Cluster – A parallel data server for telecommunications applications ● 25. November 2008, Jonas Oreland: 950'000 reads per second on 1 datanode
  • 14. MySQL Cluster Application Application Application Application Application NDB-API NDB-API Load balancer SQL Node 1 SQL Node 2 SQL Node 3 ... Mgm Node 1 Mgm Node 2 Data Node 1 Data Node 2 Sw. Sw. Data Node 3 Data Node 4
  • 15. INSERT // INSERT INTO cars VALUES (reg_no, brand, color); const NdbDictionary::Dictionary* myDict= myNdb->getDictionary(); const NdbDictionary::Table *myTable= myDict->getTable("cars"); NdbTransaction* myTrans = myNdb->startTransaction(); NdbOperation* myNdbOperation = myTrans->getNdbOperation(myTable); myNdbOperation->insertTuple(); myNdbOperation->equal("REG_NO", reg_no); myNdbOperation->setValue("BRAND", brand); myNdbOperation->setValue("COLOR", color); int check = myTrans->execute(NdbTransaction::Commit); myTrans->close();
  • 16. SELECT // SELECT * FROM cars; const NdbDictionary::Dictionary* myDict= myNdb->getDictionary(); const NdbDictionary::Table *myTable= myDict->getTable("cars"); myTrans = myNdb->startTransaction(); myScanOp = myTrans->getNdbScanOperation(myTable); myScanOp->readTuples(NdbOperation::LM_CommittedRead) myRecAttr[0] = myScanOp->getValue("REG_NO"); myRecAttr[1] = myScanOp->getValue("BRAND"); myRecAttr[2] = myScanOp->getValue("COLOR"); myTrans->execute(NdbTransaction::NoCommit); while ((check = myScanOp->nextResult(true)) == 0) { std::cout << myRecAttr[0]->u_32_value() << "t"; std::cout << myRecAttr[1]->aRef() << "t"; std::cout << myRecAttr[2]->aRef() << std::endl; } myNdb->closeTransaction(myTrans);
  • 17. Benchmarks und Zahlen ● ./flexAsynch -ndbrecord -temp -con 4 -t 16 -p 312 -l 3 -a 2 -r 2 ● Aus der MySQL Cluster Test-Suite (src/storage/ndb/test/ndbapi) ● 16 number of concurrent threads (-t) ● 4 concurrent connections (-con) ● 312 number of parallel operation per ● 2 number of records (-r ?) thread ● 1 32-bit word per attribute ● 3 iterations (-l) ● 1 ndbmtd (1 NoOfRepl.) ● 2 attributes per table (8 bytes) (-a) insert average: 506506/s min: 497508/s max: 522613/s stddev: 2% update average: 503664/s min: 495533/s max: 507833/s stddev: 1% delete average: 494225/s min: 474705/s max: 518272/s stddev: 3% read average: 980386/s min: 942242/s max: 1028006/s stddev: 2%
  • 18. Lehren ● Beobachtungen: ● CPU's sind nicht am Limit. "Irgendwo" ist noch Potential !?! ● Wenn übertrieben wird: CPU ist überlastet und Performance fällt auf 14%! ● Schummeleien: ● Schau die Parameter genau an! ● Mit allen anderen Konfigurationen erhielt ich schlechteren Durchsatz! ● Sobald eine IP anstatt localhost verwendet wird: 89% Durchsatz ● Lehren: ● Traue keinen Benchmarks, die Du nicht selber manipuliert hast!
  • 19. Neuere Resultate ● Michael Ronström, April/Mai 2011: ● 6.82M reads per second ● 2.46M updates per second MySQL Cluster Performance 8000000 7000000 6000000 5000000 4000000 Read / s ops Update / s 3000000 2000000 1000000 0 4 8 16 32 # data nodes ● Mehr als lineares Skalieren scheint möglich (Caching-Effekte)!
  • 20. Und wenn wir uns das nicht antun wollen? ● Ab MySQL Cluster 7.1 (7.0)
  • 21. BLOB Streaming Projekt ● BLOB's sind nicht geeignet fürs RDBMS! ● April 2008, Paul McCullagh: Introduction to the BLOB Streaming Project ● 5. März 2010, Barry Leslie: Upload 1000+ BLOB's per second!
  • 22. Vorteile von BLOB's in der Datenbank ● alt: RDBMS sind nicht schnell mit dem Speichern von BLOB's → BLOB's NICHT in der Datenbank speichern ● neu: Mit NoSQL Technologien wird es viel besser! ● Mit PBSE: atomare Transaktionen → Keine ins Nirgendwo zeigende Referenzen. ● BLOB's im normalen Datenbank-Backup !?! ● BLOB's können repliziert werden ● BLOB's in der DB skalieren besser. Die meisten Filesysteme performen schlecht mit mehr als 2 Millionen Dateien ?
  • 23. Das Handler Interface ● Oktober 2001, MySQL Handbuch: A new HANDLER interface to MyISAM tables ● 27. Dezember 2010, Stephane Varoqui: Using MySQL as a NoSQL: a story for exceeding 450'000 qps with MariaDB ● 10. Januar 2011, Stephane Varoqui: 20% to 50% improvement in MariaDB 5.3 Handler Interface using prepared statement
  • 24. Überspringen des Overheads mit dem Handler Interface Application / Client Thread Connection mysqld Cache Manager Parser Optimizer User Au- thentication Access Control Command Table Open Logging Dispatcher Cache (.frm, fh) Table Manager Query Query Cache Table Definition Cache Module Cache (tbl def.) Handler Interface MyISAM InnoDB Memory NDB PBXT Aria XtraDB Federated-X ...
  • 25. HANDLER Beispiel # MySQL # SELECT * FROM family; HANDLER tbl OPEN HANDLER family OPEN; HANDLER tbl READ idx (..., ..., …) HANDLER family WHERE ... LIMIT ... READ `PRIMARY` = (id) WHERE id = 1; HANDLER tbl READ idx FIRST HANDLER family CLOSE; WHERE ... LIMIT ... HANDLER tbl READ idx NEXT WHERE ... LIMIT ... # With MariaDB 5.3 HANDLER tbl READ idx PREV WHERE ... LIMIT ... HANDLER family OPEN; HANDLER tbl READ idx LAST PREPARE stmt WHERE ... LIMIT ... FROM 'HANDLER family READ `PRIMARY` = (id) HANDLER tbl READ FIRST WHERE id = ?'; WHERE ... LIMIT ... set @id=1; HANDLER tbl READ NEXT EXECUTE stmt USING @id; WHERE ... LIMIT ... DEALLOCATE PREPARE stmt; HANDLER family CLOSE; HANDLER tbl CLOSE Use persistent connections!!!
  • 26. Charakteristik des Handler Interfaces ● HANDLER ist schneller als SELECT: ● Weniger Parsing ● Kein Optimizer Overhead ● Weniger Query-Checking Overhead ● Die Tabelle muss zwischen zwei Handler-Anfragen nicht gelocket werden ● KEINE konsistente Sicht auf die Daten (dirty reads sind erlaubt) ● Optimierungen sind möglich, welche SELECT nicht zulässt ● Traversieren der Daten auf eine Art, welche schwierig bis unmöglich mit SELECT zu erlangen ist
  • 27. Neu aus den MySQL Labs ● Memcached Plugin für InnoDB (5.6)
  • 28. Neu aus den MySQL Labs ● Memcached API für MySQL Cluster (7.2)
  • 29. Eine Graphen Storage Engine ● 5. Mai 2009, Arjen Lentz: OQGRAPH Computation Engine for MySQL, MariaDB & Drizzle ● In MariaDB 5.1 ff. ● Verfügbar für MySQL 5.0 ff. ● Seit kurzem auch persistent!
  • 30. Wie fühlt sich das an? ● Es ist ähnlich wie die MEMORY SE (Persistenz, Locking, trx) Node ● Wir sprechen in: ● Node/Item/Vertex und ● Edge/Connection/Link ● Edges haben eine Richtung Edge ● Wir können Netzwerke und Hierarchien abbilden ● (Familienbeziehungen, Freunde von Freunden, kürzeste Strecke von A nach B) ● Um mit der OQGRAPH SE zu sprechen brauchen wir “latches” (welcher Algorithmus zu verwenden ist) ● Es ist eine “computational engine” nicht eine Storage Engine!
  • 31. Einfaches Beispiel: Meine Familie SELECT f1.name AS parent, f2.name AS child INSERT INTO family VALUES FROM relation AS r (1, 'Grand-grand-ma') JOIN family f1 ON f1.id = r.origid , (2, 'Grand-ma') JOIN family f2 ON f2.id = r.destid; , (3, 'Grand-uncle') , (4, 'Grand-aunt') +----------------+-------------+ , (5, 'Grand-pa') | parent | child | , (6, 'Mother') +----------------+-------------+ , (7, 'Uncle 1') | Grand-grand-ma | Grand-ma | , (8, 'Uncle 2') | Grand-grand-ma | Grand-uncle | , (9, 'Father') | Grand-grand-ma | Grand-aunt | , (10, 'Me') | Grand-ma | Mother | , (11, 'Sister'); | Grand-ma | Uncle 1 | | Grand-ma | Uncle 2 | INSERT INTO relation (origid, destid) | Grand-pa | Mother | VALUES | Grand-pa | Uncle 1 | (1, 2), (1, 3), (1, 4) | Grand-pa | Uncle 2 | , (2, 6), (2, 7), (2, 8) | Mother | Me | , (5, 6), (5, 7), (5, 8) | Mother | Sister | , (6, 10), (6, 11) | Father | Me | , (9, 10), (9, 11); | Father | Sister | +----------------+-------------+
  • 32. Netzwerk-Abfragen SELECT r.weight, r.seq, f.name SELECT GROUP_CONCAT(f.name SEPARATOR ' -> ') FROM relation AS r AS path JOIN family AS f ON (r.linkid = f.id) FROM relation AS r WHERE r.latch = 2 JOIN family AS f ON (r.linkid = f.id) AND r.destid = 10; WHERE latch = 1 AND origid = 1 AND destid = 10 +--------+------+----------------+ ORDER BY seq; | weight | seq | name | +--------+------+----------------+ +--------------------------------------------+ | 3 | 6 | Grand-grand-ma | | path | | 2 | 5 | Grand-pa | +--------------------------------------------+ | 2 | 4 | Grand-ma | | Grand-grand-ma -> Grand-ma -> Mother -> Me | | 1 | 3 | Father | +--------------------------------------------+ | 1 | 2 | Mother | | 0 | 1 | Me | +--------+------+----------------+ latch = 1: Find shortest path (Dijkstra) latch = 2: Find originating nodes
  • 33. Sharding mit der Spider-SE
  • 34. Übersicht Technologie r/w Trx Sprachen MySQL ja / ja ja “alle”, SQL HandlerSocket ja / ja nein C++, Perl, Ruby, PHP, Java, Pyhton, ... NDB-API (MySQL Cluster) ja / ja ja C++, Java, (SQL) PBSE ja / ja ja C++, SQL Handler Interface ja / nein nein “alle”, SQL OQGRAPH SE ja / ja nein “alle”, SQL Memcached-API ja / ja nein C++, Perl, Ruby, PHP, Java, Pyhton, ...
  • 35. Zusammenfassung ● SQL ist gut für komplexe Abfragen ● NoSQL üblicherweise für einfache Abfragen ● Vorsicht mit Performance-Zahlen! ● Architektur / Programmierung wird komplexer ● Bessere Performance ist möglich ● Aber es ist verdammt interessant!
  • 36. Literatur ● Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as- nosql-story-for.html ● 950k reads per second on 1 datanode: http://jonasoreland.blogspot.com/2008/11/950k-reads-per-second-on-1- datanode.html ● Scalable BLOB Streaming Infrastructure for MySQL and Drizzle: http://www.blobstreaming.org/ ● HandlerSocket: Why did our version not take off? http://pbxt.blogspot.com/2010/12/handlersocket-why-did-out-version-did.html ● Using MySQL as a NoSQL: a story for exceeding 450000 qps with MariaDB: http://varokism.blogspot.com/2010/12/using-mysql-as-nosql-story-for_27.html ● HANDLER Syntax: http://dev.mysql.com/doc/refman/5.5/en/handler.html ● GRAPH Computation Engine – Documentation: http://openquery.com/graph/doc
  • 37. Q&A Fragen ? Diskussion? Wir haben noch Zeit für persönliche und individuelle Beratungen... www.fromdual.com