Avatar von Ulriko
  • Ulriko

mehr als 1000 Beiträge seit 26.06.2001

Ergänzende Erklärung - Re: HANA fand ich enttäuschend

Rudi Runtime schrieb am 07.11.2017 18:19:

Yang09 schrieb am 07.11.2017 18:03:

Wie war denn das Testsetup?

Habe hier einen "normalen" PC mit 8 Kernen, 4GHz, 32GB HS und 1TB SSD.
Meine Testsoftware ist ein selbst-gebastelter JDBC Benchmark, mit dem ich gelegentlich nach Performanz-Lücken -Optimierungsmöglichkeiten suche.
HANA schaffte so 33k Inserts/sec; Postgres 25k
Wenn man bei Postgres "synchronous_commit = off" setzt, waren es immerhin 110k/sec :-)

Das Ganze ist ein Missverständniss Deinerseits. HANA kennt keinen Trick, Daten schneller vom RAM auf die Platte zu schreiben.

Bisherige Datenbanken funktionieren so, dass eine Transaktion (wie read, write) direkt auf das Persistenzspeichermedium geht. Wenn Du etwa ein Datum liest, damit rechnest und dann fertig bist, wird wieder auf die Festplatte oder SSD geschrieben. Eine andere Transaktion auf das gleiche Attribut muss solange warten und greift danach zu, gleiches Spiel von vorne.

Inmemory-Datenbanken funktionieren so, dass alle Daten der Datenbank komplett ins RAM geladen werden. Danach wird nur noch dort gearbeitet. Für Abfragen heißt das: sie werden 100 bis 1000x mal schneller ausgeführt, weil die Daten nicht erst von der Platte gelesen werden müssen. Diesen Anwendungsfall hast Du gar nicht getestet, wenn Du Inserts zum Maßstab gemacht und gekuckt hast, wie schnell die auf der Platte landen.

Kommen wir zum Schreiben. Zehn aufeinanderfolgende Transaktionen auf das gleiche Feld (Attribut einer Zeile) funktionieren ebenfalls um Größenordnungen schneller als in normalen Datenbanken, denn die Datenbank arbeitet immer weiter im RAM und schreibt und liest nicht immer wieder. Allerdings sind die Ergebnisse dann auch noch nicht auf die Platte geschrieben. Das passiert nebenbei und ohne die Arbeit der DB zu stören. Und hat natürlich ein Backlog, denn das Schreiben auf die Platte ist nun mal durch die Geschwindigkeit der Platte begrenzt. Daran kann das inmemory-Konzept nichts ändern.

Fällt nun der Strom aus, ist die DB in einem konsistenten Zustand, jedoch sind eben viele Transaktionen noch nicht abgespeichert und müssen wiederholt werden.

Das ist nicht so schlimm, wie es sich anhört, da Massendatenverarbeitungsprogramme heutzutage restartfähig sind (das war eigentlich schon vor 20 Jahren nahezu Standard). Und eine normale Datenbank wäre nicht nur nicht weiter, sondern hätte in der gleichen Zeit sogar noch weniger Ergebnisse auf Platte geschafft, weil ja zwischendurch nicht nur geschrieben, sondern immer wieder von Platte gelesen werden muss.

Insgesamt gilt in etwa Folgendes: Für untertägiges, zeitlich verteiltes OLAP (reines Auswerten) ist so was wie HANA bei großen Datenmengen viel schneller (Faktor 100 bis 1000) und hat keinerlei Nachteile. Vor allem kann man sich Aggregationstabellen für Reports sparen, die sehr viele Joins benötigen. Für gemischtes Lesen und Schreiben (OLAP und OLTP) ist es ebenfalls viel schneller (je nach Mischung aber mehr oder weniger). Für reines OLTP ist es nur etwas und nicht mal immer schneller, wenn nur zählt, wie schnell die Daten auf der Platte persistiert sind (Faktor 1 bis 4), weil zwar die Lesezeit für Daten und ggf. den Index entfällt, aber das Schreiben genauso langsam ist wie bei normalen Datenbanken. Deshalb wurde HANA auch zuerst für SAP BW angeboten und nicht für z.B. FI. Etwas später kam dann auch BA damit auf den Markt, das ist zwar eine Auswertungsschicht, aber hier entstehen neue Kennzahlen bzw. eben neue Ergebnisdaten, die von bankfachlichem und juristischem Wert sind und daher natürlich auch persistiert werden müssen.

Ulriko

Das Posting wurde vom Benutzer editiert (14.11.2017 18:31).

Bewerten
- +
Anzeige