PBXT: New Kid on the Block [UPDATE]

PBXT ist eine weitere vielversprechende StorageEngine für MySQL. Eine richtige Einführung soll erst in fernerer Zukunft folgen, doch soll uns das nicht davon abhalten diese StorageEngine schon mal zu testen.
Was bietet sich mehr an, als PBXT mit dem gegenwärtigen Platzhirschen InnoDB zu vergleichen?!
Zum Testen wurde die MySQL 5.1.53 verwendet. PBXT fand in der Version 1.5.02 Beta Verwendung. Ich verwendete die Beta, da ich in der 1.0.11-7 einen Bug vermutete.

Doch vorweg einiges, was ich spontan gerne noch an Features bei PBXT sehen würde:

An das InnoDB-Plugin gewohnt, kann man schnell einiges vermissen,  was es bei PBXT nicht gibt. So wäre etwas der Art PBXT_TRX, PBXT_LOCKS etc. (in Analogie zu InnoDB) hielfreich. Auch wäre es schön zu wissen was die Hintergrundthreads von PBXT gerade machen. Ein Backuptool zum binären Sichern (aka xtrabackup/Innodb Hot Backup), wie auch die Möglichkeit Daten zu kompremieren (aka InnoDB-Barracuda) wären schön zu haben. Ein Äquivalent zu innodb_force_recovery habe ich mir auch zwei mal gewünscht.

Tests

Von PBXT habe ich quasi keine Ahnung. Hier gilt es noch viele Tests zu fahren. Bei diesen Tests sollte nicht jedem Commit ein fsync() folgen, da ich eher die StorageEngines als die Festplatten testen wollte.
Folgende (PBXT/InnoDB)Config wurde verwendet.

• InnoDB-Plugin:
  innodb_buffer_pool_size = 20G
  innodb_flush_log_at_trx_commit = 2
  innodb_log_file_size = 512M
  innodb_log_files_in_group = 3
  innodb_file_per_table
  
• PBXT:
  pbxt_trx_log_buffer_size=8M
  pbxt_index_cache_size=8G
  pbxt_data_log_threshold=256M
  pbxt_record_cache_size=12G
  pbxt_trx_log_cache_size=1G
  pbxt_flush_log_at_trx_commit=0
  pbxt_trx_log_threshold=128M
  pbxt_data_file_grow_size=50M
  pbxt_row_file_grow_size=10M
  pbxt_log_buffer_size=512M
  pbxt_data_log_cache_size=1G
  pbxt_checkpoint_frequency=64M
  pbxt_index_dirty_threshold=60
  pbxt_sweeper_priority=2
  

Autoincrement

InnoDB liebt Tabellen mit einen auto_increment PK. So hatte sich beim ersten Test PBXT in einem Bereich zu schlagen, in dem InnoDB sehr gut ist.
Mit mysqlslap wurden über 8 parallele Verbindungen (mit 8 Verbindungen hatte ich bis dato immer den besten Durchsatz auf der Maschine) 300.000.000 Zeilen in eine einfache Tabelle zu schreiben (autocommit=ON).

 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

Dies wurde - um auch Daten für die Grafik zu haben - in 300 x 1.000.000 Inserts gesplittet. So beschreibt folgende Grafik wieviel Sekunden pro 1.000.000 Inserts benötigt wurden. Sprich: Kleinere Werte sind besser.



Die ersten paar Millionen Rows laufen für PBXT zwar wunderbar. Aber dann sackt PBXT förmlich ein. Während InnoDB nahezu konstant durchmarschirt.
Trägt man auf der x-Achse die Inserts/Sekunde bekommt man sehr schnell auch ein Gefühl für die Performance.


















Von "kleinen" Tabellen abgesehen, gewinnt hier PBXT kein Land. Unangenehm sind die starken Schwankungen bei PBXT. Ob das an den Hintergrundthreads lag und wie diese die Last verarbeiten, kann ich nicht (hoffentlich noch nicht) sagen. Auffällig war allerdings, dass PBXT das RAID10 stärker zum Anschlag brachte (war fast durchgängig bei einer %util von 100%) als das InnoDB-Plugin. Mit knapp über 16000 Inserts pro Sekunde ist PBXT auch nicht wirklich langsam, aber über 60000 Inserts pro Sekunde bei InnoDB ist schon entscheidend mehr.

UUID

Doch wie sieht es mit einem Workload aus, bei der InnoDB eben nicht so schön skaliert? Nun wird als PK UUID() verwendet und zudem noch ein Text-Column.

CREATE TABLE `reinUUID` (
  `uid` char(32) NOT NULL,
  `id` int(11) NOT NULL,
  `id2` int(11) NOT NULL,
  `mail` text,
  PRIMARY KEY (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

[UPDATE: Oli Sennhauser wies mich darauf hin, dass  innodb_flush_log_at_trx_commit = 2 nicht die beste Konfiguration für InnoDB ist. Daher wurde der Test für beide auf UUID-PK gehende Tests wiederholt. Wobei sowohl für innodb_flush_log_at_trx_commit, alsauch für pbxt_flush_log_at_trx_commit.
i := Innodb, p:=pbxt die folgende Zahl gibt jeweils den Wert der Variable an.]



Hier ist ziemlich eindeutig zu sehen, wie InnoDB sich quasi verabschiedet. Nach 16000000 Rows brach ich den Versuch dann schlicht und ergeifend ab.
PBXT hatte - im Vergleich zu InnoDB - keinerlei Probleme mit diesem Workload.
Um noch ein Gefühl für die Performance zu geben, auch hier die selben Daten anders dargestellt.

















 
An dieser Grafik erkennt man gut, das auch PBXT langsamer wird. Im Vergleich zu InnoDB ist bei diesem Workload und dieser Config klar PBXT überlegen und eine interessante Wahl.


Beim nächsten mal werden UPDATEs und SELECTs auf PK und secondary Indizes verglichen. Stay tuned:)