Dieser
Post führt den vorherigen
Artikel über PBXT weiter.
Diesmal werden mit unterschiedlicher Concurrency SELECTs auf die - 300.000.000 Rows enthaltene - Tabelle gelassen. Zur Erinnerung:
Eine Info, die beim vorherigen Post hätte erwähnt werden müssen ist die Größe der Tabelle.
Da die Datenmenge zu groß ist, habe ich mich entschieden die Daten via Boxplots darzustellen. Diese Tests dienen nur sich dem Thema PBXT(InnoDB) zu nähern. Tests haben im Allgemeinen zu viele Freiheitsgrade um mehr als das zu liefern. Aber dies sollte jedem Bekannt sein.
Die SELECT-Tests bestanden aus 100x1.000 Abfragen. Unterschieden wurde zwischen hot und uniform. Während bei hot ein Definitionsbereich von [1,10.000] existierte (für die WHERE-Bedingung), ging es bei uniform über die ganze Tabelle [1,300.000.000]
Ich will mir nicht die Freiheit nehmen, die Daten zu interpretieren. Bei diesem Test war ich überrascht, dass InnoDB nicht gnadenlos gewann, da `id3` ja immer im selben Block wie der PK ist.
PBXT schlägt sich erschreckend gut. Schön ist an der Graphik zu sehen wie der Durchsatz für beide Engines einer Glockenkurve gleich verläuft. Sollte dies mehr mit dem Server als mit den Engines zu tun haben, dann freue ich mich schon auf Tests mit der MySQL 5.5 :)
Wie zu erwarten geht der Durchsatz - alsbald auf alle 300.000.000 Rows zugegriffen wird etwas runter. Eine Erklärung für das Verhalten von könnte sein, dass PBXT gerade mit einigen Hintergrundjobs beschäftigt war. Andere Testreihen (auf einem anderen Rechner und anderer Version) hatten bei 128 keinen Drop im Durchsatz.
Ich für meinen Teil war/bin überrascht, wie gut sich PBXT schlug. Gerade bei SELECTs via PK hätte ich erwartet, dass InnoDB hier eindeutig die Nase vorne hat.
Viel Spaß
Erkan
Diesmal werden mit unterschiedlicher Concurrency SELECTs auf die - 300.000.000 Rows enthaltene - Tabelle gelassen. Zur Erinnerung:
CREATE
TABLE
`rein`
(
`id` int(11) NOT NULL AUTO_INCREMENT,
`id2` int(11) NOT NULL,
`id3` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `id2` (`id2`)
) ENGINE=PBXT DEFAULT CHARSET=latin1
Zur Ausgangstabelle:
Eine Info, die beim vorherigen Post hätte erwähnt werden müssen ist die Größe der Tabelle.
PBXT:
1.2G rein-5.xtr
7.6G rein.xtd
9.8G rein.xti
InnoDB:
22G rein.ibd
Da die Datenmenge zu groß ist, habe ich mich entschieden die Daten via Boxplots darzustellen. Diese Tests dienen nur sich dem Thema PBXT(InnoDB) zu nähern. Tests haben im Allgemeinen zu viele Freiheitsgrade um mehr als das zu liefern. Aber dies sollte jedem Bekannt sein.
SELECT
Die SELECT-Tests bestanden aus 100x1.000 Abfragen. Unterschieden wurde zwischen hot und uniform. Während bei hot ein Definitionsbereich von [1,10.000] existierte (für die WHERE-Bedingung), ging es bei uniform über die ganze Tabelle [1,300.000.000]
SELEC
T
id3 from rein where ID=@id
Ich will mir nicht die Freiheit nehmen, die Daten zu interpretieren. Bei diesem Test war ich überrascht, dass InnoDB nicht gnadenlos gewann, da `id3` ja immer im selben Block wie der PK ist.
SELECT
id3 from rein where ID=@id
PBXT schlägt sich erschreckend gut. Schön ist an der Graphik zu sehen wie der Durchsatz für beide Engines einer Glockenkurve gleich verläuft. Sollte dies mehr mit dem Server als mit den Engines zu tun haben, dann freue ich mich schon auf Tests mit der MySQL 5.5 :)
SELECT
count(id3) from rein where id2=@id
SELECT
count(id3) from rein where id2=@id
Wie zu erwarten geht der Durchsatz - alsbald auf alle 300.000.000 Rows zugegriffen wird etwas runter. Eine Erklärung für das Verhalten von könnte sein, dass PBXT gerade mit einigen Hintergrundjobs beschäftigt war. Andere Testreihen (auf einem anderen Rechner und anderer Version) hatten bei 128 keinen Drop im Durchsatz.
Ich für meinen Teil war/bin überrascht, wie gut sich PBXT schlug. Gerade bei SELECTs via PK hätte ich erwartet, dass InnoDB hier eindeutig die Nase vorne hat.
Viel Spaß
Erkan
Jetzt kommentieren