Zum Hauptinhalt springen

Performante Lookups in BW-Transformationen - Die richtige Tabellenart wählen

Dies ist vielleicht die grundlegendste aller ABAP-Fragen, und zwar nicht nur, wenn man sich mit performanten Lookups auseinandersetzt. Sobald man etwas in ABAP macht, wird man auf diese Frage stoßen.

Die am häufigsten verwendete interne Tabellenart ist die Standardtabelle. Dies ist zum Teil historisch bedingt, da Hash- und sortierte Tabellen erst seit dem Release 4.0 verfügbar sind. Des Weiteren sind die Standardtabellen schnell zu befüllen, da jeder neue Datensatz ohne weiteres am Ende der Tabelle hinzugefügt werden kann (siehe APPEND). Bei sortierten oder Hash-Tabellen muss dagegen erst einmal der richtige Ort gefunden (siehe INSERT) bzw. der Hash-Schlüssel generiert werden. Zum Schreiben ist die Standardtabelle somit zu bevorzugen.

Für Lesezugriffe sind Standardtabellen allerdings ein Performancekiller. Denn diese werden im Gegensatz zu den anderen Tabellen linear durchsucht. Wird also eine Standardtabelle mit 50.000 Datensätzen durchsucht, beginnt die Suche immer beim allerersten Datensatz. Im ungünstigsten Fall, wenn der gesuchte Datensatz an der letzten Stelle steht, müssen alle vorhergehenden 49.999 Datensätze auch gelesen werden.

Wie sich das bei Lookups auswirkt, wird anhand des nachstehenden Beispiels verdeutlicht:

 

lookup-selektion-relevanter-datensaetze

 

Nehmen wir an, wir haben eine interne Tabelle X mit 50.000 Datensätzen, bei der jeder Datensatz mit Informationen einer Datenbanktabelle Y ergänzt werden muss. Im besten Fall haben wir nur die relevanten Datensätze aus Datenbanktabelle Y in einer internen Tabelle Z geladen. Diese enthält somit für jeden unserer X-Datensätze genau einen entsprechenden Datensatz (auch 50.000).

Die Art der Tabelle X ist zweitrangig, da wir dadurch LOOPEN müssen und dabei jeden einzelnen Datensatz auslesen. Wenn Z aber eine Standardtabelle ist, werden wir für unser LOOKUP insgesamt 1.250.025.000 (50.000!) Lesezugriffe haben. Bei SAP BW on HANA verarbeitet man oft sogar Datenpakete mit 200.000 oder mehr Datensätzen. In unserem Beispiel würden wir bei der Anwendung einer Standardtabelle für Z dann bei 20.000.100.000 Lesezugriffen pro Datenpaket landen.

Selbstverständlich können auch die Standardtabellen aufsteigend sortiert und dann mit BINERY SEARCH durchsucht werden. Warum dann aber nicht gleich eine sortierte oder Hash-Tabelle nehmen? Eine Daumenregel ist, dass bei ca. 10.000 Datensätzen beide Tabellenarten ungefähr gleich schnell sind. Bei deutlich größeren Tabellen ist die Hash-Tabelle nicht zu schlagen, da die Zugriffszeit, unabhängig von der Größe, nahezu konstant ist. Bei weniger als 10.000 Datensätzen gibt es in der Regel keine Performanceprobleme. 

Hash-Tabellen haben aber den "Nachteil", dass sie nur eindeutige Datensätze enthalten sollen. Wenn es also nicht möglich ist, eindeutige Tabellenschlüssel zu erzeugen, zum Beispiel durch die Aggregation der selektierten Daten, sollte man mit sortierten Tabellen arbeiten.

 

Zusammengefasst heißt das:

  • Braucht man eine interne Tabelle zum Schreiben, sollte man eine Standardtabelle nehmen.
  • Muss man eine große interne Tabelle durchsuchen, sollte man eine Hash-Tabelle verwenden.
  • Muss man eine große interne Tabelle mit nicht eindeutigen Datensätzen durchsuchen, sollte man eine sortierte Tabelle nutzen.