LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Alle Fragen rund um Basisthemen
9 Beiträge • Seite 1 von 1
9 Beiträge Seite 1 von 1

LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von a-dead-trousers (Top Expert / 4287 / 214 / 1142 ) »
Hallo @all

Im Zuge einer Entwicklung bin ich auf eine sehr interessante (zumindest für mich) Frage gestoßen:
Was ist eigentlich "besser"? Strings (CLOB) bzw. XStrings (BLOBs) unkomprimiert auf der Datenbank abzulegen und die eventuell notwendige Komprimierung dem DB-Optimizer zu überlassen oder die Daten auf dem Applikationsserver zu komprimieren und dannach erst auf der Datenbank abzulegen?

Vorteil der manuellen Komprimierung ist sicherlich der verringerte Datentransfer zwischen Applikationsserver und der Datenbank sowie der (initial) kleinere Speicherbedarf auf der Datenbank. Demgegenüber steht der höhere Programmieraufwand zum (de-)komprimieren und die zusätzliche Prozesszeit am Applikationsserver. Zudem könnte es ja sein, dass die Komprimierung auf der Datenbank sogar "effizienter" ist und unterm Strich ein besseres Ergebnis liefert.

Was gibt es sonst für Vor- und Nachteile die euch noch einfallen?
Gibt es Unterschiede zwischen Hana und anderen Datenbanken (z.B. Oracle)?
Gibt es dazu irgendwelche "Literatur" bzw. Best-Practice-Beispiele (vielleicht auch außerhalb von SAP/ABAP)?
Wie habt ihr das bei euren Projekten so gelöst?

lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von ewx (Top Expert / 4787 / 295 / 629 ) »
ich würde die Komprimierung immer der DB überlassen. Jeder zusätzliche Code birgt Fehlerpotential.
Zudem weißt du hinterher nicht, ob die Daten in einem Feld komprimiert sind oder nicht. Du siehst das erst, wenn du dir den Code der Applikation zum Zugriff auf die Daten anschaust. Das wäre bereits ein Risiko, dass ich nicht eingehen würde.

Wäre jedoch in der Tat interessant, wie die einzelnen Lösungen sich in puncto Performance und Speicherplatz unterscheiden würden. Jedoch gehe ich davon aus, dass die DB selbst das schon ganz gut und vor allen Dingen zuverlässig macht.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers


Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von black_adept (Top Expert / 3950 / 105 / 886 ) »
a-dead-trousers hat geschrieben:
24.08.2022 15:11
Vorteil der manuellen Komprimierung ist sicherlich der verringerte Datentransfer zwischen Applikationsserver und der Datenbank sowie der (initial) kleinere Speicherbedarf auf der Datenbank. Demgegenüber steht der höhere Programmieraufwand zum (de-)komprimieren und die zusätzliche Prozesszeit am Applikationsserver. Zudem könnte es ja sein, dass die Komprimierung auf der Datenbank sogar "effizienter" ist und unterm Strich ein besseres Ergebnis liefert.
Das entspricht ja in etwa dem Prinzip des Code Pushdown, das SAP bei HANA propagiert. Und dieses Code Pushdown kann ja m.E. nur dann besser sein wenn mindestens einer der folgenden Punkte erfüllt ist ( vielleicht gibt es ja auch mehr - aber die fallen mir ad hoc ein ), der am Ende eine Nettozeitersparnis bringt weil irgendein Bottleneck umgangen wird.
  • Es werden weniger Daten zwischen Applikationsserver und DB hin- und hergeschoben
  • Die DB ist in ihrer Effizienz besser als der Applikationsserver ( das wäre dein Fall, a-d-t, wo man schauen müsste ob die DB schneller/stärker komprimiert als die im Kernel implementierten CL_ABAP_GZIP Komprimierungsmethoden)
  • Die Applikationsserver sind ausgelastet während die DB vor sich hin idlet
Und ich habe zu diesen Fragen noch nirgends eine durch praktische Messungen in einem echten Kundenproduktivsystem untermauerte Aussage gefunden.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von Alpmann (ForumUser / 62 / 5 / 19 ) »
ewx hat geschrieben:
24.08.2022 15:31
ich würde die Komprimierung immer der DB überlassen. Jeder zusätzliche Code birgt Fehlerpotential.
Zudem weißt du hinterher nicht, ob die Daten in einem Feld komprimiert sind oder nicht. Du siehst das erst, wenn du dir den Code der Applikation zum Zugriff auf die Daten anschaust. Das wäre bereits ein Risiko, dass ich nicht eingehen würde.
ich sehe das genauso. Ich würde da nur etwas "ausprobieren", wenn ich weiß, dass es nur um einen konkreten Fall geht. Da sollte schon sicher sein, dass sich kein anderer Prozeß oder User an den Daten bedient.

Performance ist bei der Faktura wichtig :-)

Mit freundlichen Grüßen
Matthias Alpmann

Folgende Benutzer bedankten sich beim Autor Alpmann für den Beitrag:
a-dead-trousers


Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von a-dead-trousers (Top Expert / 4287 / 214 / 1142 ) »
Erstmal Danke an alle die sich bislang an dem Gedankenaustausch beteiligt haben.

Die beiden Varianten mit aussagekräftigen Performance- und Speichermessungen zu untermauern wäre sicher interessant, nur ich glaube halt nicht, dass sich das so ohne weiteres bewerkstelligen lässt. Man müsste dazu ja auch auf Netzwerkebene mitsniffen und der DB-Optimizer läuft meines Wissens auch etwas zeitversetzt. Außerdem weiß ich nicht mal ob man so detailierte Aussagen über die Speichergröße auf der Datenbank treffen kann, weil ja meistens blockweise geschrieben wird und da merkt man zwar wenn etwas "größer" aber nicht "kleiner" wird.

Soll jetzt nicht heißen, dass ich das Thema schon als "erledigt" ansehe. Gerne können (und sollen) sich auch noch andere zu Wort melden.

Die Frage nach betreffender "Fachliteratur" oder Best-Practice-Beispielen wurde ja zum Beispiel noch gar nicht erörtert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von black_adept (Top Expert / 3950 / 105 / 886 ) »
Ich habe mal ein kleines Testprogramm geschrieben um den Laufzeitunterschied zu messen. Und schon mal vorab die Info: Das Ganze ist bei mir abhängig von der zugrunde liegenden DB:

Testprogramm:

Code: Alles auswählen.

REPORT LINE-SIZE 1000.

CLASS lcl_check_zip_db DEFINITION FINAL.
  PUBLIC SECTION.
    METHODS:
      main IMPORTING iv_iterations TYPE i,
      create_data IMPORTING iv_lines       TYPE i
                  RETURNING VALUE(rv_data) TYPE string,
      save_data IMPORTING iv_zip                    TYPE abap_bool
                          iv_data_to_save           TYPE string
                RETURNING VALUE(rv_compressed_size) TYPE i.
ENDCLASS.

PARAMETERS: iterate TYPE i OBLIGATORY DEFAULT 4.

END-OF-SELECTION.
  NEW lcl_check_zip_db( )->main( iterate ).

CLASS lcl_check_zip_db IMPLEMENTATION.
  METHOD main.
    DATA: lv_lines                    TYPE i VALUE 1,
          lv_data                     TYPE string,
          lv_start                    TYPE i,
          lv_end                      TYPE i,
          lv_runtime_no_compression   TYPE i,
          lv_runtime_with_compression TYPE i,
          lv_compressed_size          TYPE i,
          lv_diff                     TYPE i,
          lv_ratio                    TYPE f.


    FORMAT COLOR 5 INTENSIFIED OFF.
    WRITE:/ 'DB-Type:', sy-dbsys INTENSIFIED ON.
    FORMAT COLOR OFF INTENSIFIED ON.

    DO iterate TIMES.
* Cleanup DB before each write statement.
      DELETE FROM zss_test1 WHERE compressed <> 'Z'. "
      COMMIT WORK.
      lv_lines = lv_lines * 2.
      WRITE:/ 'Lines:', lv_lines COLOR 3.
      lv_data = me->create_data( lv_lines ).
      WRITE: AT 20 'Datasize:', strlen( lv_data ) COLOR 3.
* Ohne Komprimierung
      GET RUN TIME FIELD lv_start.
      me->save_data( iv_zip = abap_false iv_data_to_save = lv_data ).
      GET RUN TIME FIELD lv_end.
      lv_runtime_no_compression = lv_end - lv_start.
      WRITE: AT 45 'Runtime no compression in ABAP:', lv_runtime_no_compression COLOR 3.
* Mit Komprimierung
* Cleanup DB before each write statement.
      DELETE FROM zss_test1 WHERE compressed <> 'Z'. "
      COMMIT WORK.
      GET RUN TIME FIELD lv_start.
      lv_compressed_size = me->save_data( iv_zip = abap_true iv_data_to_save = lv_data ).
      GET RUN TIME FIELD lv_end.
      lv_runtime_with_compression = lv_end - lv_start.
      WRITE: AT 90 'Runtime with compression in ABAP:', lv_runtime_with_compression COLOR 3,
             AT 140 'With compressed size', lv_compressed_size COLOR 3.
      lv_diff = lv_runtime_with_compression - lv_runtime_no_compression.
      WRITE: AT 175 'Difference', lv_diff COLOR 7.
      lv_ratio = lv_runtime_with_compression / lv_runtime_no_compression.
      WRITE: AT 200 'Ratio', lv_ratio COLOR 7 EXPONENT 0 DECIMALS 2.

    ENDDO.
  ENDMETHOD.

  METHOD save_data.
    DATA: ls_data TYPE zss_test1,  " ZSS_TEST1 also name of database
          lv_x    TYPE xstring.
    IF iv_zip = abap_false.
      ls_data = VALUE #( compressed = ''
                         data_s     = iv_data_to_save
                       ).
      MODIFY zss_test1 FROM @ls_data.
      COMMIT WORK.
    ELSE.
* Zip first
      TRY.
          cl_abap_gzip=>compress_text( EXPORTING
                                         text_in                    = iv_data_to_save      " Input Text
                                      IMPORTING
                                        gzip_out                   = lv_x                  " Compressed output
                                        gzip_out_len               = rv_compressed_size    " Output Length
                                    ).
        CATCH cx_root.
          ASSERT 1 = 2.
      ENDTRY.
      ls_data = VALUE #( compressed = 'X'
                         data_x     = lv_x
                       ).
      MODIFY zss_test1 FROM @ls_data.
      COMMIT WORK.
    ENDIF.
  ENDMETHOD.

  METHOD create_data.
    SELECT *
      FROM dd03l
    INTO TABLE @DATA(lt_dd03l) UP TO  @iv_lines ROWS.
    WHILE lines( lt_dd03l ) < iv_lines.
      APPEND LINES OF lt_dd03l TO lt_dd03l.
    ENDWHILE.
    DELETE lt_dd03l FROM iv_lines + 1.

    CALL TRANSFORMATION id
      SOURCE data = lt_dd03l
      RESULT XML rv_data.
  ENDMETHOD.
ENDCLASS.
Definierte Tabelle ZSS_TEST1
LZO - DB.png
Laufzeit System 1:
LZO - MSSQL.png
Laufzeit System 2:
LZO - HDB.png
Fazit: Bei der von mir gewählten Datenmenge hängt die Laufzeit sowohl von der zugrunde liegenden DB als auch der Datenmenge ab.
  • kleine Datenmengen bis ~100K: Kein signifikanter Unterschied
  • Größere Datenmengen
    • MSSQL-DB: Komprimierung in ABAP ~ 25% bessere Laufzeit
    • HDB-DB(HANA): Komprimierung in ABAP ~ 50% schlechtere Laufzeit
Leider bin ich ein One Trick Pony und kenne mich zwar mit Laufzeiten aus aber nicht mit den Admintools um zu erkennen, wie viel Speicher am Ende der letzte Datensatz in der DB verbraucht.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
ewxa-dead-trousers

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von a-dead-trousers (Top Expert / 4287 / 214 / 1142 ) »
Vielen Dank.
Werd ich dann bei uns auch noch ausprobieren, wobei wir (nativ) aber nur HANA zu Verfügung haben. MSSQL könnten wir nur per Zweitverbindung anbinden.

Ein Punkt ist mir aber aufgefallen:
Die Zeiten von MSSQL sind in deinem Beispiel generell etwas langsamer. Kann das vielleicht an der Hardware oder am Netzwerk liegen? Wie "vergleichbar" sind deine beiden Testsystem in diesen Punkten?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von black_adept (Top Expert / 3950 / 105 / 886 ) »
Moin a-d-t,
a-dead-trousers hat geschrieben:
26.08.2022 10:30
Die Zeiten von MSSQL sind in deinem Beispiel generell etwas langsamer. Kann das vielleicht an der Hardware oder am Netzwerk liegen? Wie "vergleichbar" sind deine beiden Testsystem in diesen Punkten?
So den großen Unterschied sehe ich eigentlich nicht. Sind halt verschiedene Systeme. Beachte auch, dass die zu übertragende Datenmenge im MSSQL-System etwas größer ist als im HDB-System.
Aber ansonsten: Gleiches Netzwerk, unterschiedliche Netzwerksegmente der Systeme und vor allem andere Hardware und andere Kernel ( S/4 vs ECC mit recht hohem Patchstand ). Somit schließt sich ein Vergleich System<-->System eigentlich aus und mich haben am Ende nur die relativen Laufzeiten auf dem selben System interessiert.
Hat jmd. zufällig noch ein Minisap/Netweaver DevEvaluationsystem rumfliegen. Das arbeitet doch mit der ADABAS-DB ( oder wie immer der SAP-Nachfolger jetzt gleich heißt. SAPDB? ). Das wäre interessant weil viel, viel kleiner dimensioniert, da auf heimischen Rechner in VM ausgeführt mit anderer DB, so dass hier ein ganz anderes Bottleneck ausschlaggebend sein könnte.

Mein Fazit ist jedenfalls: Wenn es nur auf Laufzeit ankommt, vorher ausprobieren, was das jeweils zugrunde liegende System präferiert.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: LOB-Feld komprimiert ablegen oder DB erledigen lassen?

Beitrag von a-dead-trousers (Top Expert / 4287 / 214 / 1142 ) »
Huch, die Zeiten von unserem System sind ja gruselig: 3,6-fache Laufzeit.
HDB.png
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Seite 1 von 1

Vergleichbare Themen

1
Antw.
1849
Views
Beleg ablegen über NAST '2-ablegen' auf Fileebene möglich
von Mike10081973 » 28.08.2017 17:10 • Verfasst in Sales and Distribution
4
Antw.
1748
Views
URL`s im BDS ablegen
von Neroringer » 27.06.2006 13:17 • Verfasst in ABAP Objects®
3
Antw.
3784
Views
PDF auf Applikationsserver ablegen
von basstos » 23.07.2008 15:04 • Verfasst in ABAP® Core
5
Antw.
1949
Views
Excel auf Server ablegen
von Thomas17 » 05.12.2012 11:37 • Verfasst in ABAP® Core
4
Antw.
7321
Views
Dienste zum Objekt: PDF Ablegen
von Jumper » 20.07.2012 11:12 • Verfasst in ABAP® Core

Aktuelle Forenbeiträge

Artikel automatisch in va01
vor 2 Tagen von wreichelt 2 / 53
langtexte beim Fertigungsauftrag
vor 2 Tagen von ByteMeBaby 7 / 6423
Updates der Daten, Fehlermeldung
vor 3 Tagen von Egzon gelöst 1 / 73

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Artikel automatisch in va01
vor 2 Tagen von wreichelt 2 / 53
langtexte beim Fertigungsauftrag
vor 2 Tagen von ByteMeBaby 7 / 6423
Updates der Daten, Fehlermeldung
vor 3 Tagen von Egzon gelöst 1 / 73

Unbeantwortete Forenbeiträge

Updates der Daten, Fehlermeldung
vor 3 Tagen von Egzon 1 / 73
Zwischensumme Adobe Forms
letzen Monat von Lucyalison 1 / 290