SAP brengt HANA-databasesoftware uit

SAP heeft zijn HANA-'appliance software' uitgebracht. Sommige SAP-klanten konden HANA al gebruiken, maar nu kan iedereen een server met de databasesoftware bestellen. De software is bedoeld voor grote hoeveelheden data.

Met ingang van deze week kan iedereen de HANA-software bestellen, zo heeft SAP bekendgemaakt. De databasesoftware is bedoeld voor het verwerken van grote hoeveelheden data en kan deze in het geheugen van servers houden, waardoor gegevens sneller kunnen worden opgevraagd dan wanneer harde schijven moeten worden geraadpleegd.

Het is niet bekend wat een HANA-installatie kost; het aanschaffen van dit soort pakketten gebeurt doorgaans op basis van een offerte. HANA ondersteunt zowel de sql- als de mdx-talen voor het doen van query's, maar de software is geoptimaliseerd voor Business Objects 4.0 van SAP. Die versie komt in juli uit.

HANA kan als pakket samen met een server worden geleverd; onder andere Dell, IBM, HP en Cisco bieden servers met HANA-software. In september wordt meer duidelijk over HANA AppCloud, waarbij SAP de HANA-software als dienst aanbiedt. HANA moet onder meer met Oracles Exadata-databasesoftware concurreren.

Reacties (42)

[NTH]

HANA is een in-memory based oplossing voor je Business Warehouse en is de database waarop het draait column based.
Dus alle data opaslaan in geheugen en alle dwarsdoorsnedes, opvragingen, etc real-time uitvoeren.

Op dit moment draai je grote rapportages in batches, volgens SAP zal het met HANA niet meer hoeven.

Hopelijk kan ik er binnenkort eens mee aan de slag of wat gebruikers ervaringen erover horen.

[matty___]

als het goed is komen de meeste rapportages toch al uit BW om dat het ECC gewoon niet meer te doen is.

[NTH]

Dat klopt. De informatie wordt dagelijks van ECC naar BW geladen bij de meeste productie systemen. Even een voorbeeldje bij één divisie van Philips was er een BW systeem van 9TB. In die orde van grote moet je denken.

[mvoosten]

Gaat hier neem ik aan niet om een transactioneel systeem zoals jullie voorbeelden maar om een datawarehouse platform. Andere doelgroep.

[matty___]

Allebei. De huidige versie is voor ECC bedoelt en eind van het jaar draait netweaver bw 7.3 volledig op hana en dat is dan het DWH van SAP.

[ToolkiT]

"HANA moet onder meer met Oracles Exadata-databasesoftware concurreren." doet me denken dat dit vooral een datawarehouse product is, of doelen ze daar alleen mee op de nieuwe versie/uitbereiding?

[Verwijderd]

SAP HANA (high performance analytic appliance) is inderdaad een appliance voor datawarehousing, net als Oracle Exadata en IBM Netezza. Ten opzichte van de andere 2 spelers zijn ze een beetje laat, maar voor veel SAP klanten die BO gebruiken kan dit extreem nuttig zijn.

[matty___]

Is het niet. check de sap presentaties. uiteindelijke gaat heel de stack ecc en netweaver op hana draaien.

De huidige versie is niet eens voor BW geschikt.

[PWA]

Lijkt er bijna op dat de toekomstige ECC's en BW versie's op reporting vlak meer overlap zullen gaan hebben.
Als HANA dus in memory is maakt het BW (bijna) overbodig, als je ECC en BO goed hebt draaien.

I.i.g. zal dit in de toekomst tot interresante vraagstukken m.b.t. reporting performance en calculaties in ECC/brondata gaan zorgen.

[matty___]

Dat werd duidelijk ontkracht door SAP.
In BW maak je nog steeds alle afleidingen die je niet zo maar in de reporting tools van BO kunt maken.

[maniak]

"De software is bedoeld voor grote hoeveelheden data."

Als je EVE-Online bekijkt die draait op MSSQL en die maken gebruik van staging memory <> storage.. wat maakt dit nou zo bijzonder?

[Bilel]

Ik zie het verband niet tussen EVE-online en het bedrijfsleven? EVE-online hoeft geen grote hoeveelheden data te versturen en op te slaan in vergelijking met het bedrijfsleven.

[arjankoole]

Ik zie het verband niet tussen EVE-online en het bedrijfsleven? EVE-online hoeft geen grote hoeveelheden data te versturen en op te slaan in vergelijking met het bedrijfsleven.

uh, dat moeten ze dus wel. Er is een complete economie binnen het spel, en alle data van ieder zonnestelsel (system) in elke regio van hun universum staat er in. Om nog maar te zwijgen over alle ruimtestations en planetaire basissen, alsmede alle objecten die karakters van spelers bezitten. ( van mij alleen - en ik ben maar klein grut - is dat al tientallen ruimteschepen en honderduizenden items, van dogtags tot artillery)

Er zijn letterlijk duizenden bedrijven actief binnen het spel, zowel player owned als non-player owned, die allemaal transacties uitvoeren, belasting heffen over inkomsten, repairbills, bounties, bonussen, etc, etc, etc.

Hoeveel data denk je dat dat is?

[Reactie gewijzigd door arjankoole op 30 juli 2024 14:02]

[Het.Draakje]

Naam zonnestelsel, locatie, gegevens +/- 10K data. 10K van dergelijke stelsels en andere objecten. Deze data verandert (als het goed is niet), dus geen enkel nut om ze te analyseren (waar je Business Objects voornamelijk voor gebruikt). Waard om te analyseren: de gegevens van gebruiker: ruimteschip type, locatie etc. wellicht 10K per gebruiker. 6 miljoen gebruikers ongeveer 10 TB.

Vergelijk dat eens met (bijvoorbeeld) de OV chipknip. 4/5 dagen per week, minimaal 1K (kaartnummer, opstaphalte, tijd, uitstaphalte, tijd). Verhoog dat met eventueel overstappen en de terugreis. 10K per week (minus vakanties) 300K per jaar. 7 jaar opslag en 6 miljoen gebruikers. Totaal ongeveer 1.800 TB. Iets andere grootte van database (Ik vergat het het te vermenigvuldigen met het aantal jaren opslag) . Kom dus op een verhouding 1 op 1.000.

[Reactie gewijzigd door Het.Draakje op 30 juli 2024 14:02]

[MaZeS]

Sorry hoor, maar je schatting van de data voor een ov chipkaart is vrij lomp.Niemand slaat alle data op bij ieder ritje, maar gebruikt foreign keys om te koppelen tussen verschillende tabellen.
kaartnummer? zal waarschijnlijk in een kaarten tabel staan met een id van max 4 bytes
op/uitstaphaltes? zal waarschijnlijk in een opstaphalte tabel staan met een id van max 4 bytes.

Wat is er dan nog nodig om één enkele rit te registreren? kaartid, starttijd, eindtijd, en de in- en uitstaphalte id's = 5x4 bytes = 20 bytes
In een week: 200 bytes
Per jaar: 6kb

Totaal na 7 jaar: 6000 bytes * 6000000 * 7 = 252000000000 bytes = "maar" 234 GB voor de ritten

[airell]

Ik neem aan dat het OV-chipkaart model gebaseerd is op het Transmodel: the CEN European Reference Data Model for Public Transport Information;

Transmodel, hoofdstuk 3.9:
The fare collection data model aims at a most generic description of the data objects and elements needed to support functions like definition of the fare structure and its parameters, operating sales, validating the consumption and charging customers.

Wiki:
http://en.wikipedia.org/wiki/Transmodel

Transmodel datamodel:
http://www.transmodel.org/en/cadre1.html

Do the math...

[Mellow Jack]

is 4 byte niet een beetje weinig voor 16 mio gebruikers? Als je kijkt naar bijv de korting kaarten dan worden deze apart geregistreerd Edit: sorry 4.2 miljard mogelijkheden is wel voldoende voor ons kikkerlandje

Verder klopt het zo wel aardig alleen mis je de datums... Ik vermoed dat deze als date time worden opgeslagen in de database of zullen ze in losse kolommen staan en gelinkt worden naar een andere tabel?

[Reactie gewijzigd door Mellow Jack op 30 juli 2024 14:02]

[MaZeS]

keuze genoeg.... Ik bedoelde inderdaad een datetime voor de de start/-eindtijd, maar deze zijn toch al wel snel 8 bytes.
Het totaal aantal bytes moet dus nog even vermenigvuldigd worden met 7/5 = 328GB

Je hebt natuurlijk ook nog wel een redelijk grote tabel met kaarten nodig, maar van de ritten zul je de meeste data houden..

[Reactie gewijzigd door MaZeS op 30 juli 2024 14:02]

[arjankoole]

Ah, jij werkt voor MCOM, dat je die details over de ov-chipkaart zo goed weet?

Deze data verandert (als het goed is niet)

Jawel, de samenstelling van asteroidfields is niet altijd hetzelfde volgens mij, en bovendien is die data aanpasbaar omdat de spelers daar resources uithalen. Die resources (en dat geld ook voor ijsvelden en gaswolken) moet je ook weer bijhouden. En dan hebben we 't nog niet eens over zaken als wormholes, waarbij de spelers invloed uitoefenen op de status van het wormhole en of die wel/niet voor kan komen in een stelsel.

De data van EVE is, als je er goed over nadenkt, enorm

[Reactie gewijzigd door arjankoole op 30 juli 2024 14:02]

[airell]

10 TB is nog steeds veel, 1.800 TB is gewoon 'nog' veel meer.

[matty___]

sorry maar dit is beetje hopeloze discussie.

SAP met EVE vergelijken. appels en peren vergelijken

[arjankoole]

sorry maar dit is beetje hopeloze discussie.

SAP met EVE vergelijken. appels en peren vergelijken

Een data object is een data object. Het maakt echt geen zier uit of dat om een product in een SAP database gaat, of een product in EVE wat te koop staat. EVE is een enorm complex geheel, net zoals veel SAP implementaties dat zijn. Dat er direct en indirect meer geld omgaat binnen SAP systemen, daar zal je mij niet over horen discussieren, dat moge duidelijk zijn.

Natuurlijk zijn er talloze verschillen, maar puur abstract is er weinig verschil. Zo simpel kun je 't prima bekijken. Of vind jij iets in SAP per definitie meer dan iets in een andere database?

[matty___]

Bij SAP gaat het om echt geld en sneller beslissingen in het bedrijfsleven leveren meer waard op dan in een spel.

Draait EVE op 1 server / database? of hebben ze elk zonnestelsel een eigen server gegeven?

[martijnve]

De hele eve-online database draait op één server ja. (eentje met 512GB RAM)

Plus de economie in eve-online is inmiddels groter dan die van de rest van ijsland (waar ccp vandaan komt)

http://www.eveonline.com/devblog.asp?a=blog&bid=885

[Reactie gewijzigd door martijnve op 30 juli 2024 14:02]

[daft_dutch]

We noticed immediate performance increases in the Buffer Cache Hit Ratio, which is a counter indicating how often the server goes to the buffer (fast) instead of disks (not as fast). The old TQ database was at 97% while the New TQ database is at 99.7%. (We don't need no stinkin disks!)

Als of een SAP Database ooit in de buurt komt van zo veel "Buffer Cache Hit Ratio" Ik zie het al voor me. EVE-Online business static management: Eigenlijk weet u het al.

[c64flash]

Ja natuurlijk komt een SAP systeem daarbij in de buurt. Hoe kom je erbij dat dat niet zo zou zijn. De rule of thumb van SAP is dat het altijd boven 95% moet zijn in een SAP systeem, ook gedurende zware load. Maar een beetje normaal systeem heeft een ratio van boven de 99%.

[arjankoole]

Bij SAP gaat het om echt geld en sneller beslissingen in het bedrijfsleven leveren meer waard op dan in een spel.

Dat is het verschil ja. De eind waarde. Maar de data hoeft helemaal niet zo verschillend te zijn. Bovendien zal EVE voor maker CCP best belangerijk zijn als inkomsten bron. (maar daar gaat uiteraard heel wat minder geld in om dan - noem eens wat - een bank, EVE spelers betalen ongeveer 10 euro per maand geloof ik)

Draait EVE op 1 server / database? of hebben ze elk zonnestelsel een eigen server gegeven?

Sommige regio's draaien samen op 1 server, er zijn echter ook regio's (zoals Jita) die hun eigen dedicated hardware hebben gekregen, en zelfs die dedicated hardware kan 't niet aan. (als je in Jita problemen veroorzaakt, kun je zelfs gebanned worden heb ik begrepen)

Ik ken de verdere infra van EVE niet zo heel goed, ik heb een leuk beeld gekregen, maar logischerwijs vertellen ze bij CCP niet alles

[Mellow Jack]

Zit het verschil hem niet in de rapportages ed? Uit ervaring weet ik dat queries onwijs lang kunnen duren wanneer je uitgebreide selectie criterea aangehouden worden. Hiermee doel ik op bijv een query die een verkoop overzicht maakt voor 1 specifieke verkoop organisatie (voor de leken een bedrijf in je groep bedrijven ), een selectie van de klanten (dus niet allemaal), daar weer bepaalde artikel groepen en dat allemaal over een periode in het verleden. Dit soort queries duren in onze R3 om en nabij 15 minuten en hier zie ik games zoals EVE niet mee werken (iig niet realtime) waardoor het voor EVE minder voordeel bied dan bij SAP aangezien de minuten dat de mensen zitten te wachten gewoon verloren geld is. Je systeem zal dan al door miljoenen entries moeten zoeken en daar de benodigde records uit trekken (incl al de data die gelinkt is via bijv joins) en dan praat ik in mijn geval over een middelgroot bedrijf en niet over een bank die nog eens 100x groter is dan ons bedrijf

[Reactie gewijzigd door Mellow Jack op 30 juli 2024 14:02]

[humbug]

Natuurlijk heeft dit systeem voordelen boven een standaard database. Echter online games hebben wel degelijk ook te maken met grote databases en (nog meer dan bedrijfsdatabases) miljoenen gebruikers. Sterker nog er zitten verschillende game gerelateerde bedrijven bij de grootste klanten van database leveranciers als oracle ibm en microsoft.

Ook zijn raporten vaak niet tot op de minuut relevant (zeker niet als je er een kwartier op kan wachten ) Het is niet ongebruikelijk die rapporten s nachts voor te bereiden zodat ze overdag geen 15 minuten hoeven te kosten.

EVE online is dus geen slecht voorbeeld van een alternatieve oplossing voor dit probleem.

[Mellow Jack]

Ik praat niet over de hoeveelheid aan data of gebruikers maar de soort queries die gedraaid worden. Zoals ik al vermelde is het voor een bedrijf van levensbelang dat de juist mensen de juiste data op het juiste moment krijgen. Als mijn directeur vraagt om een rapportage dan wilt hij een actuele rapportage waar de laatste deals zijn opgenomen zodat hij een goed overzicht heeft over de organisatie. Ten eerste kan ik niet aankomen met het excuus dat ik het gisteren heb gedraaid en de gegevens vanavond pas kan updaten en ten tweede hebben wij geen nacht Als ik naar huis ga zijn mijn Amerikaanse collega's pas 4 uurtjes aan het werk en mijn Chinese collega's liggen dan al diep te slapen

Daarom moet je wel bewust zijn dat game databases een ander soort eisen pakket hebben en ze delen de regio's vaak in tijdzones in waardoor de game databases in de nacht kunnen indexeren en gegevens kunnen klaarzetten zonder dat iemand hier last van ondervind (gezien de load gewoon veel minder is)

Dit staat dus eigenlijk compleet los van het feit dat EVE een imposante verzameling databases zal hebben

Edit: Hier wil ik trouwens nog aan toevoegen dat in het geval van SAP een vertraging wat veroorzaakt wordt door 1 gebruiker effect heeft op de gehele organisatie. Draai maar bijv een heffing overzicht van een bepaald jaar en print vlak daarna eventjes al je facturen uit. Je zal zien dat je nog langer moet wachten op die facturen want ze kunnen pas afgehandeld worden wanneer het door mij genoemde heffing overzicht is afgerond (gezien ze exact dezelfde tabellen gebruiken)

[Reactie gewijzigd door Mellow Jack op 30 juli 2024 14:02]

[Verwijderd]

Aangezien EVE een spel is dat op z'n minst deels bestaat uit het emuleren van een complete economie (dus meerdere bedrijven) en ik er van uit ga dat de spelers daarin ook up-to-date rapportering over hun investeringen willen, zou het wel eens kunnen zijn dat e.e.a. meer op jouw werk lijkt dan het op het eerste zicht lijkt?

[roy-t]

EVE Online is groot, uiteindelijk gaat het om 60.000 (concurrent) gebruikers met data, bij een grote internationale bank heb je het toch al snel over 10x zoveel gebruikers met mogelijk veel meer data (elke transactie sinds opening van de rekening, metadata, beurskoerzen, paketten, etc..). Dus 'grote hoeveelheden data' is een relatief begrip.

[Kaastosti]

De demonstraties die ermee gegeven zijn waren indrukwekkend... inderdaad op een tabel met miljarden records binnen twee seconden je query uit kunnen voeren. Wat ik echter niet weet is hoe men omgaat met een crashend systeem... je geheugen is dan namelijk wel weg. Hoe werkt het met je transactionele data? Of met upgraden?

[matty___]

SSD Raid waar het geheugen in wordt weggeschreven.
bij het booten na een crash wordt de data van de ssd raid set weer in het geheugen geladen.

volgens de sap rep dan eh

[Verwijderd]

De demonstraties die ermee gegeven zijn waren indrukwekkend... inderdaad op een tabel met miljarden records binnen twee seconden je query uit kunnen voeren.

Ter referentie: Google doet queries over miljarden (misschien zelfs biljoenen?) records in 0,05 seconden...

(Google heeft echter een hoop voordelen, zoals dat queries geen rekening moeten houden met updates die ondertussen gebeuren, etc.)

[Verwijderd]

HANA is door SAP voornamelijk gepositioneerd op systemen die behoorlijke RAS funktionaliteit hebben(mission critical hardware-->UNIX). Afgelopen week was ik bij een lezing over HANA, daar werd aangegeven dat op dit moment HANA alleen geschikt is voor gegevens die je MAG kwijt raken, het zal voorlopig dus nog naast een andere DB draaien (DB2/Oracle). het is wel de bedoeling van SAP dat HANA zo'n ontwikkeling zal doormaken dat het de complete database layer in memeory zal doen, en dus een externe DataBase partij buitenspel komt te staan bij SAP omgevingen.

[matty___]

Denk bv aan een datawarehouse van 40TB waar queries niet meer 10 min lopen maar 5 sec.

[Blokker_1999]

Dan mogen ze het hier snel invoeren, SAP werkt hier ongelooflijk traag met momenten.

[Rembert]

Even gegoogled: het blijkt dat er wat geruchten zijn SAP B1 vanaf versie 9.0 HANA zal ondersteunen en dat dit al draait in een lab omgeving. Echt interessant wordt het als als B1 in een hosted omgeving wordt gedraaid met HANA Appcloud.

[c64flash]

HANA is inderdaad in eerste instantie bedoeld om delen van databases of gehele databases in memory te zetten (ook niet-SAP middels SBOP Data Services) en daar dan middels SBOP BI queries/rapportages op los te laten. Het is dus (nog) geen vervanger voor de traditionele database omdat het (nog) niet bedoeld is voor database wijzigingen.

[Blazing-Studios]

wel een beetje lastig om EVE met SAP te vergelijken aangezien EVE op een van de (als het niet DE) krachtigste supercomputers ter wereld draait.
Ik neem aan dat SAP op "normalere" serverhardware draait of heb ik mij daarin vergist?

[c64flash]

Supercomputer ??? Hahahaha, het is een gewoon windows systeem met wat extra memory en SSD disks. Niet te vergelijken met enterprise servers waar SAP systemen veelal op draaien.