-
Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 18:55
Bitte korrigiert mich, aber das kann doch gar nicht funktionieren:
1. Wenn vermehrt im Arbeitsspeicher gearbeitet wird, dann kommen doch erhebliche Mehrkosten in Form von Arbeitsspeicher auf die SAP-Kundschaft zu.
2 Arbeitsspeicher ist ein Flüchtiger Speicher, als braucht es den Festplattenspeicher genauso. Ich kann mir nicht vorstellen, dass auf Festplatten verzichtet werden kann, wie es der Artikel suggeriert.
3. Kann ich die Annahme von Golem nicht ganz Nachvollziehen, dass es sich hier beinahe um ein R4 handelt. Da heisst es, dass SAP an vielen Stellen Optimierungen gemacht hat und Code ersetzt hat. Ganz ehrlich: Wer den Wechsel auf R2 und R3 erlebt hat, der weiss, dass n bisschen Optimieren und alten Code ersetzen noch lange keinen Release-Namen rechtfertigt. Geschweige denn, war die Code-Ersetzungs-Aktion sowieso schon längst überflällig.
Aber vielleicht täusche ich mich ja auch, denn dieser Golem-Artikel hat sehr wenig Fleisch am Knochen.
1 mal bearbeitet, zuletzt am 10.01.13 18:58 durch Testdada. -
Re: Irgendwie geht das nicht auf...
Autor: Der schwarze Ritter 10.01.13 - 19:06
Außerdem... kostenlose Erweiterung!? Dass ich nicht lache, die werden doppelt und dreifach bezahlt, auch wenn es gar keine Erweiterungen gibt.
-
Re: Irgendwie geht das nicht auf...
Autor: neocron 10.01.13 - 19:10
Testdada schrieb:
--------------------------------------------------------------------------------
> Bitte korrigiert mich, aber das kann doch gar nicht funktionieren:
>
> 1. Wenn vermehrt im Arbeitsspeicher gearbeitet wird, dann kommen doch
> erhebliche Mehrkosten in Form von Arbeitsspeicher auf die SAP-Kundschaft
> zu.
Arbeitsspeicher ist nicht mehr so teuer wie vor einigen jahren noch... des weiteren Nutzt diese Technologie ja optimierungsverfahren .... die meiste zeit liegt die DB zu 80 oder 90% unangetastet brach ... durch entsprechende Algorithmen kannst du dies effizienter gestalten und genau die 20% im Arbeitsspeicher halten, die du auch brauchst ... und zwar so, dass du auch zukuenftige ladevorgaenge bereits "voraussagen kannst"
>
> 2 Arbeitsspeicher ist ein Flüchtiger Speicher, als braucht es den
> Festplattenspeicher genauso. Ich kann mir nicht vorstellen, dass auf
> Festplatten verzichtet werden kann, wie es der Artikel suggeriert.
Nein, der artikel suggeriert nur, dass du fuer den Betrieb keine Festplatten benoetigst also fuer Datenbankoperationen ... natuerlich brauchst du festplatten noch um die Daten auch irgend wo abzulegen, logs zu schreiben, relogs, etc! Backups muss es ja trotzdem noch geben!
> 3. Kann ich die Annahme von Golem nicht ganz Nachvollziehen, dass es sich
> hier beinahe um ein R4 handelt. Da heisst es, dass SAP an vielen Stellen
> Optimierungen gemacht hat und Code ersetzt hat. Ganz ehrlich: Wer den
> Wechsel auf R2 und R3 erlebt hat, der weiss, dass n bisschen Optimieren und
> alten Code ersetzen noch lange keinen Release-Namen rechtfertigt.
> Geschweige denn, war die Code-Ersetzungs-Aktion sowieso schon längst
> überflällig.
>
> Aber vielleicht täusche ich mich ja auch, denn dieser Golem-Artikel hat
> sehr wenig Fleisch am Knochen. -
Re: Irgendwie geht das nicht auf...
Autor: ji (Golem.de) 10.01.13 - 19:23
neocron schrieb:
--------------------------------------------------------------------------------
> Testdada schrieb:
> ---------------------------------------------------------------------------
> > Bitte korrigiert mich, aber das kann doch gar nicht funktionieren:
> >
> > 1. Wenn vermehrt im Arbeitsspeicher gearbeitet wird, dann kommen doch
> > erhebliche Mehrkosten in Form von Arbeitsspeicher auf die SAP-Kundschaft
> > zu.
> Arbeitsspeicher ist nicht mehr so teuer wie vor einigen jahren noch... des
> weiteren Nutzt diese Technologie ja optimierungsverfahren .... die meiste
> zeit liegt die DB zu 80 oder 90% unangetastet brach ... durch entsprechende
> Algorithmen kannst du dies effizienter gestalten und genau die 20% im
> Arbeitsspeicher halten, die du auch brauchst ... und zwar so, dass du auch
> zukuenftige ladevorgaenge bereits "voraussagen kannst"
Zudem nutzt HANA ein spaltenorientiertes Design und Kompression. Dadurch soll sich der Speicherbedarf im realen Einsatz um rund 80 Prozent reduzieren lassen, so SAP. Das haben auch die Pilotkunden bestätigt.
Jens Ihlenfeld
(Golem.de) -
Re: Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 19:28
>Arbeitsspeicher ist nicht mehr so teuer wie vor einigen jahren noch... des weiteren
>Nutzt diese Technologie ja optimierungsverfahren .... die meiste zeit liegt die DB zu 80
>oder 90% unangetastet brach ... durch entsprechende Algorithmen kannst du dies
>effizienter gestalten und genau die 20% im Arbeitsspeicher halten, die du auch
>brauchst ... und zwar so, dass du auch zukuenftige ladevorgaenge bereits
>"voraussagen kannst"
Ja, Speicher ist nicht mehr so teuer, eigentlich. Aber bei derartigen Serveranlagen ist es wesentlich komplizierter und auch teuere. Und ja, solche Optimierungsverfahren, wo die Arbeitsaufteilung zwischen Arbeitsspeicher und Harddisk optimiert ist, ist keineswegs bahnbrechend, sondern vielmehr schon Jahrelange praxis. Und Speichervoraussagen gibt auch schon länger.
>Nein, der artikel suggeriert nur, dass du fuer den Betrieb keine Festplatten
>benoetigst also fuer Datenbankoperationen ...
Das stimmt schlichtweg nicht.
>Dabei soll die Umstellung einiges vereinfachen, denn durch den Verzicht auf
>Festplatten sei es nicht länger nötig, mit aggregierten Daten zu arbeiten
Soviel dazu.
>natuerlich brauchst du festplatten noch um die Daten auch irgend wo abzulegen,
>logs zu schreiben, relogs, etc!
Ist ja kein Unterschied, zu allen heute gängigen Datenbanken.
Irgendwie habe ich das Gefühl, Hana ist MaxDB 2.0. Aber wie gesagt, vielleicht kenne ich die wirklichen Fakten noch nicht, ich bin offen. -
Re: Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 19:29
Vielen Dank, mit diesen Zusätzlichen Infos macht das ganze schon wesentlich mehr Sinn. Vielleicht wär das noch was, zum den Artikel zu ergänzen.
-
Re: Irgendwie geht das nicht auf...
Autor: developer 10.01.13 - 19:43
Testdada schrieb:
--------------------------------------------------------------------------------
> Irgendwie habe ich das Gefühl, Hana ist MaxDB 2.0. Aber wie gesagt,
> vielleicht kenne ich die wirklichen Fakten noch nicht, ich bin offen.
Na ja, wie solltest du wenn du dich damit anscheinend nocht nicht beschäftigt hast.
Einfach mal bei der Quelle reinschaun http://scn.sap.com/community/hana-in-memory mit dem nötigen technischen know how wirst du ja in der Lage sein zu beurteilen ob das Sinn ergibt oder nicht.
Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5 -
Re: Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 19:53
Danke für den Link, werde mich mal schlau machen. Nichtsdestotrotz steht im Golem-Artikel überhaupt nichts darüber, WIESO dieses Hana so speziell ist.
So wie hier da steht, macht es kaum Sinn. -
Re: Irgendwie geht das nicht auf...
Autor: JosefMinde 10.01.13 - 19:55
Testdada schrieb:
--------------------------------------------------------------------------------
> >natuerlich brauchst du festplatten noch um die Daten auch irgend wo
> abzulegen,
> >logs zu schreiben, relogs, etc!
> Ist ja kein Unterschied, zu allen heute gängigen Datenbanken.
>
> Irgendwie habe ich das Gefühl, Hana ist MaxDB 2.0. Aber wie gesagt,
> vielleicht kenne ich die wirklichen Fakten noch nicht, ich bin offen.
Ich habe HANA ausprobiert und die Geschwindigkeit von HANA rockt.
Bei traditionellen Datenbanken muss man erst aufwendig die Hardware und die Softwareeinstellungen tunen, bevor sie richtig schnell werden. Bei HANA ist die Performance von den Anbietern schon von Haus aus sehr gut optimiert. Zugegeben: SAP übertreibt masslos, wenn im Marketing von hunderttausendfacher Beschleunigung durch HANA und x-facher Kompression der Daten spricht. Das mag zwar möglich sein, aber nur, wenn schlechte Datenbankanwendungen auf traditionellen Datenbanken durch gute Anwendungen auf HANA umgestellt werden. Bei kundenspezifischen Datenbankanwendungen mit vergleichbar teurer Hardware und vergleichbarem Optimierungsaufwand konnte ich aber in der Praxis immerhin eine Beschleunigung um den Faktor 45 feststellen! Der entscheidende Kostenfaktor für die Kunden ist dabei derzeit ganz klar die SAP-HANA-Lizenz, nicht die Hardware d.h. eine um den Faktor 45 schnellere Hardware wäre deutlich teurer, als eine HANA-zertifizierte Hardware. -
Re: Irgendwie geht das nicht auf...
Autor: developer 10.01.13 - 20:01
Testdada schrieb:
--------------------------------------------------------------------------------
> Danke für den Link, werde mich mal schlau machen. Nichtsdestotrotz steht im
> Golem-Artikel überhaupt nichts darüber, WIESO dieses Hana so speziell ist.
>
> So wie hier da steht, macht es kaum Sinn.
Na ja, Golem hat einfach darüber berichtet und hat das Feedback der Kunden noch dazu einfliesen lassen.
Das ist schon ok, dass die da jetzt nicht noch ne Hana Einführung dazu gepackt haben, die Informationen dazu sind ja auch so verfügbar.
Hana kombiniert so wie ich das verstanden hab einfach eine Reihe von sinnvollen für sich betrachtet nicht zwangsweise neue Techniken zu einem wohl recht effizienten Konzept zum verwalten von komprimierten Daten im Speicher.
Nach dem was man so hört scheint das sogar in der Praxis gut zu funktionieren. Ansonsten hätte das die Konkurenz vermutlich auch schon genüsslich zerlegt.
Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5 -
Re: Irgendwie geht das nicht auf...
Autor: developer 10.01.13 - 20:06
JosefMinde schrieb:
--------------------------------------------------------------------------------
> Zugegeben: SAP übertreibt masslos, wenn im Marketing von
> hunderttausendfacher Beschleunigung durch HANA und x-facher Kompression der
> Daten spricht. Das mag zwar möglich sein, aber nur, wenn schlechte
> Datenbankanwendungen auf traditionellen Datenbanken durch gute Anwendungen
> auf HANA umgestellt werden.
Hm ja, vermutlich gab es da mal diesen einen Fall oder so hrhr.
> Bei kundenspezifischen Datenbankanwendungen mit
> vergleichbar teurer Hardware und vergleichbarem Optimierungsaufwand konnte
> ich aber in der Praxis immerhin eine Beschleunigung um den Faktor 45
> feststellen! Der entscheidende Kostenfaktor für die Kunden ist dabei
> derzeit ganz klar die SAP-HANA-Lizenz, nicht die Hardware d.h. eine um den
> Faktor 45 schnellere Hardware wäre deutlich teurer, als eine
> HANA-zertifizierte Hardware.
Na ja, das würde ja nicht einfach um den Faktor 45 skalieren auf dem Niveau. Vermutlich müsste man da noch weitaus mehr Geld investieren für den Faktor 45.
Aber wenn plötzlich die Wartezeiten reduziert werden und ein paar 1000 Mitarbeiter am Tag ein paar Minuten weniger warten müssen, dann hast du selbst die Hardware irgendwann wieder drin.
Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5 -
Re: Irgendwie geht das nicht auf...
Autor: neocron 10.01.13 - 20:15
Testdada schrieb:
--------------------------------------------------------------------------------
> >Arbeitsspeicher ist nicht mehr so teuer wie vor einigen jahren noch... des
> weiteren
> >Nutzt diese Technologie ja optimierungsverfahren .... die meiste zeit
> liegt die DB zu 80
> >oder 90% unangetastet brach ... durch entsprechende Algorithmen kannst du
> dies
> >effizienter gestalten und genau die 20% im Arbeitsspeicher halten, die du
> auch
> >brauchst ... und zwar so, dass du auch zukuenftige ladevorgaenge bereits
> >"voraussagen kannst"
>
> Ja, Speicher ist nicht mehr so teuer, eigentlich. Aber bei derartigen
> Serveranlagen ist es wesentlich komplizierter und auch teuere. Und ja,
> solche Optimierungsverfahren, wo die Arbeitsaufteilung zwischen
> Arbeitsspeicher und Harddisk optimiert ist, ist keineswegs bahnbrechend,
> sondern vielmehr schon Jahrelange praxis. Und Speichervoraussagen gibt auch
> schon länger.
>
> >Nein, der artikel suggeriert nur, dass du fuer den Betrieb keine
> Festplatten
> >benoetigst also fuer Datenbankoperationen ...
> Das stimmt schlichtweg nicht.
> >Dabei soll die Umstellung einiges vereinfachen, denn durch den Verzicht
> auf
> >Festplatten sei es nicht länger nötig, mit aggregierten Daten zu arbeiten
> Soviel dazu.
richtig, da geht es um den verzichte der Festplatten, die fuer aggregierte Daten noetig waren vorher ...
die fallen allerdings weg. Das ist richtig. Wird ja im artikel auch erklaert!
Wozu aggregierte daten halten, wenn du sie blitzschnell im RAM aggregieren kannst!?
>
> >natuerlich brauchst du festplatten noch um die Daten auch irgend wo
> abzulegen,
> >logs zu schreiben, relogs, etc!
> Ist ja kein Unterschied, zu allen heute gängigen Datenbanken.
sagt ja auch niemand!
aber du brauchst weniger plattenplatz (siehe oben ... verzicht auf das speichern von aggregierten daten)
>
> Irgendwie habe ich das Gefühl, Hana ist MaxDB 2.0. Aber wie gesagt,
> vielleicht kenne ich die wirklichen Fakten noch nicht, ich bin offen. -
Re: Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 20:21
So anhand der SAP-Beschreibung habe ich es jetzt auch verstanden :-)
>Das ist schon ok, dass die da jetzt nicht noch ne Hana Einführung dazu gepackt haben,
>die Informationen dazu sind ja auch so verfügbar.
Ich kann ja verstehen, dass man keine Hochtechnische Erklärung bringt, aber es sollte mindestens so geschrieben sein, dass der Artikel in sich sinnvoll ist.
>...Indem Daten im Speicher statt auf der Festplatte gehalten werden...
>...denn durch den Verzicht auf Festplatten ...
>...Die Einführung der SAP Business Suite on HANA soll für Kunden nicht mit
>zusätzlichen Kosten verbunden sein...
Das sind alles so Aussagen, die alleinstehend völlig surreal sind und einfach keinen Sinn geben. Deshalb sollte man schon wenigstens n kleinen Einblick in die Technik geben.
Ich versuchs mal zusammenzufassen:
Zuerst hat man Index- und Indizes-Bäume aus dem Arbeitsspeicher geschmissen. Danach war genug Platz für die vollständige Datenbank in komprimierter Form. Damit sollte jetzt jeder Datenbankzugriff so schnell sein, wie früher der Zugriff auf reine Schlüsselfelder. -
Re: Irgendwie geht das nicht auf...
Autor: Testdada 10.01.13 - 20:34
>richtig, da geht es um den verzichte der Festplatten, die fuer aggregierte Daten noetig >waren vorher ...
Ich behaupte jetzt einfach mal, dass das Falsch ist.
Aggregierte Daten benötigt man meines Wissens beim Datawarehousing, weil die normalen Primary-Key Zugriffen für solche Auswertungen normalerweise nicht taugen. Deshalb kopiert man sich die Daten auf einen Datawarehouseserver und konvertiert die DB-Struktur derart, dass die Keys- und Indizes für die Spezialauswertung optimal arbeiten.
Nun fällt dieser Schritt komplett weg, weil Zugriffe Nicht-Indizierte-Felder ebenso schnell funktionieren, wie wenn diese im Key wären.
Dementsprechend fallen damit nicht bloss ein bisschen HD-Speicher weg, sondern ein ganzer Server. -
Re: Irgendwie geht das nicht auf...
Autor: developer 10.01.13 - 22:14
Testdada schrieb:
--------------------------------------------------------------------------------
> >richtig, da geht es um den verzichte der Festplatten, die fuer aggregierte
> Daten noetig >waren vorher ...
>
> Ich behaupte jetzt einfach mal, dass das Falsch ist.
>
> Aggregierte Daten benötigt man meines Wissens beim Datawarehousing, weil
> die normalen Primary-Key Zugriffen für solche Auswertungen normalerweise
> nicht taugen. Deshalb kopiert man sich die Daten auf einen
> Datawarehouseserver und konvertiert die DB-Struktur derart, dass die Keys-
> und Indizes für die Spezialauswertung optimal arbeiten.
>
> Nun fällt dieser Schritt komplett weg, weil Zugriffe
> Nicht-Indizierte-Felder ebenso schnell funktionieren, wie wenn diese im Key
> wären.
> Dementsprechend fallen damit nicht bloss ein bisschen HD-Speicher weg,
> sondern ein ganzer Server.
So hab ich das auch verstanden.
Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5 -
Re: Irgendwie geht das nicht auf...
Autor: chewy 10.01.13 - 22:19
- mir sind 2 Kunden bekannt die die Laufzeit ihrer SQL Abfragen/DB lastigen Batch jobs von ~1 1/2 Tagen auf <2s untern HANA drücken konnten.
- die Column-Store Kompressionsrate berägt durchschnittlich Faktor 4-5
- die hohe Geschwindigkeit wird darurch erreicht das heutzutage selbst sehr gut getunte (DB & Applikationsseitig) Standard DB Systeme ca 50-60% ihrer Sevicezeit mit (lesen) der Daten von Disk/Storagesubsystemene verbringen, und die CPU(s) mehr oder weniger 'idlen'. Das ist der Main-Bottleneck. HANA ist designet im ALLE vornandenen CPU cores möglichst immer voll auszusten (sprich Daten zu prozesssieren). Der gegenwärtige Bottleneck bei HANA liegt hingegen auf der Datenübertragungsseite zwischen a) CPU Cache und Cores b) CPU Cache und lokalem Main Memory c) Intra Memory Datentransfer sprich Intel Quick-Path Durchsatz (6.4 GB/s) beim Zugriff auf Daten die nicht am lokalen Memory controller hängen .. -
Re: Irgendwie geht das nicht auf...
Autor: JosefMinde 11.01.13 - 07:54
developer schrieb:
--------------------------------------------------------------------------------
> Na ja, das würde ja nicht einfach um den Faktor 45 skalieren auf dem
> Niveau. Vermutlich müsste man da noch weitaus mehr Geld investieren für den
> Faktor 45.
Das dachte ich auch! Ich bin aber eines Besseren belehrt worden, als ich es ausprobiert und selbst gemessen habe. Im Projektalltag ist es denke ich ein grosser Vorteil von HANA, dass Hard- und Software schon werksseitig so gut auf Performance optimiert sind, dass mit geringem Aufwand seitens des Anwendungsentwicklers oder Kunden schnell laufende Anwendungen erstellt werden können. -
Hurra! (Wir machen das mit den Fähnchen ...)
Autor: Anonymer Nutzer 11.01.13 - 10:12
> Testdada schrieb:
> ich aber in der Praxis immerhin eine Beschleunigung um den Faktor 45
> feststellen!
Jahrelang waren SAP-Systeme nur betreibbar, wenn man regelmäßig Hardware nachsteckte. Nix mit Moore's Law und Verbesserung der Performance. SAP-Systeme wurden mit jedem Patch und Release nur eines: ressourcenhungriger - und zwar überdurchschnittlich. (Kein Wunder bei der unterliegenden Steinzeitarchitektur, die die ganzen mittlerweile angeflanschten Klingeln und Balkone gar nicht mehr tragen kann.)
Jetzt kommt mal ein messbarer Performance-Gewinn und die Leute brechen gleich in Jubel aus. Faktor 45 von was? Wenn ich eine Schildkröte um den Faktor 45 beschleunige, habe ich immer noch keinen Düsenjäger.
Der Einäugige mag zwar König unter den Blinden sein - aber hier wird einem Hungrigen ein Würstchen verkauft und er glaubt, das Schlemmerparadies gefunden zu haben.
Leute, bleibt bitte realistisch. -
Re: Hurra! (Wir machen das mit den Fähnchen ...)
Autor: Testdada 11.01.13 - 10:38
Hast du überhaupt den leisesten schimmer, was die technische Grundlage dieses Hana ist?
Wenn du das wüsstest, dann wüsstest du auch, dass theoretisch sogar wesentlich mehr als Faktor 45 möglich sein könnte. Aber schon Faktor 2 wäre ein Meilenstein in Bereich der Datenbanken.
Und ich weiss nicht mit welchem Datenaufkommen du zu tun hast, aber die Datenbankserver skalieren grade bei grossem Datenaufkommen sehr gut. Ich hatte schon bei vielen Firmen das vergnügen zu Arbeiten, aber nirgends ist mit jemals zu Ohren gekommen, dass man regelmässig Hardware nachgerüstet hätte, so wie du es beschrieben hast.
Die Appl-Server skalieren weniger gut, aber noch immer gleichmässig zu den Anzahl Benutzern. -
Re: Hurra! (Wir machen das mit den Fähnchen ...)
Autor: neocron 11.01.13 - 10:39
mumbojumbo schrieb:
--------------------------------------------------------------------------------
> Der Einäugige mag zwar König unter den Blinden sein - aber hier wird einem
> Hungrigen ein Würstchen verkauft und er glaubt, das Schlemmerparadies
> gefunden zu haben.
das hat er auch, wenn es weit und breit sonst nichtmal ein wuerstchen gibt!



