‘SAP HANA. SAP HANA’ Database for Next-Generation Business Applications and Real-Time Analytics Explore and Analyze Vast Quantities of Data from Virtually Any Source at the Speed of Thought OT oy te oY be ss ? a rar rT) e ry a . a @ @ Or] 8 . co } rT) @ Ca 6 ro e a bd ryt a P ) @ po | C ° e|\? @ d rn r) e @ ® rr 6 @ ci} Ps e rr & e @ e 2 balls an Ls Ce ee ee eM oe or J ryTyTyTYTtTtYTte:.kt#f?.t*?Ld fd dudndy ME Ind ddd LT fad dl Oa cry) yd) yy) ey Po e wey 6 Cb66@6 cececceoee” P*) Cd eciee eraeroree ys o o 4 a) ie tee nt ers . © e« eh ae er alee “at al et Ps ae . te ee a Te Pt a PsP — L Aediediiediditiedadl‘SAP HANA* DATABASE FOR NEXT-GENERATION BUSINESS APPLICATIONS AND REALTIME ANALYTICS Table of Contents Onan 13 16 17 Revolutionize the Way You Run Your Business Current Generation of Enterprise Solutions ‘Technological Transition ‘SAP HANA Platform Overview “Taking a New Approach to Business Data Processing ‘Technology Foundation Execution Control Caleulation Models for SQLScript Table Functions Parallel Execution Columnar and Row-Based Data Storage Choosing Between Column and Row Store ‘Advantages of Columnar Tables ‘Temporal Tables ‘SAP HANA Benefits for Business Applications Paradigm Shift in Approach to Data Management Technologies Find Out MoreNEW DATABASE SOLUTIONS THAT REMOVE THE LIMITS OF TRADITIONAL DATABASE ARCHITECTURE. Revolutionize the Way You Run Your Business SAP has introduced a new class of solutions that powers the next generation of business applica- lions. The SAP HANA? database is an in-memory database that combines transactional data pro- cessing, analytical data processing, and applica- tion logic processing functionality in memory. SAP HANA removes the limits of traditional data- base architecture that have severely constrained how business applications can be developed to support real-time business. In recent years we have observed interrelated technological and social revolutions. Computer systems have a continuously increasing number of processing coves with large integrated caches, Main memary space has become practically unlimited with the ability to hold allthe business data of enterprises of every size. With the exoloding number of mobile devices, infor Imation for decision making needs tobe available in seconds. Changes to the business, risks, and opportunities need tobe tracked in eal time to keep the business competitive. SAP HANA ena today's demand fo ousiness applicat nor cost-effective. bles you to perform real-time OLAP analy: on an OLTP data st ons that previously were n Leaning on long-term business experience and visionary research, SAP nas created a new paradigm of bullcing business ‘applications that takes advantage of these advancements in technology. The paradigms realized in the SAP HANA plat form. SAP HANA enables you to perform real-time online apa cation processing (OLA) analysis on an online transaction processing (OLTP) data structure. Asa result, you can address today's dernand for real-time ousiness insights by creating business applications that previously were ne'ther feasible nor cost-effective, SAP HANA introduces a ciferent way of thinking from both the technical side of how to construct applications and the busi- ness side of how to exploit the new functionality. SAP offers an incremental road map that enables your organization to safely ‘explore the technology today, seize opportunities in side-by- side scenarios, and get prepared forthe increasing rate of doing business, ructure. As a result, you can address 7 real-time business insights by creating her feasible‘SEPARATION OF DATA MANAGEMENT SOLUTIONS INTO TRANSACTIONAL AND ANALYTICAL PROCESSING Current Generation of Enterprise Solutions ‘The architectures of currentgeneration business systems. reflect the technological conditions during the long evalution of business solutions: + Database layer: Database management systems were designed for optimizing performance on harcware with li ited main memory and with the slow disk /0 as the main bottleneck. The focus was on optimizing disk access, for ‘example, by minimizing the numberof disk pages to be read Into main memory when processing a query. + Business application layer: Business software was bult with ‘a sequential processing paradigm. Data tables for the cur rent scenario were fetched from the database, processed (on arow-by-row basis, anc pushed beck to the database. As discussed by Plattner and Zeiern their recent book on in-memory data management, technological database limita tions have forced a separation ofthe data management sol: tion into transactional and analytical processing: + Online transaction processing (OLTP) systerns are highly normalized to data entry volume and to speed up inser, Updates, and deletes. This nigh degree ct normalization is 3 Cisadvantage wren it comes to retrieving data, as mutiple tables may have tobe joined, which severely impacts Performance. ‘Online application processing (OLAP) systems were devel ‘oped to address the requirements of large enterprises to ‘analyze their data ina timely manner. These systems oxaloit specialized data structures des gned to optimize read perfor: mance and provide quick processing of complex analytical cata Data needs to be transterred out of an enterprise's transac: tional system into an analytical system andis then prepared ‘or predefined reports, Figure 1ilustratesa typical enterorise sovtware situation in current-generation solutions: Large organizations have mult ple enterprise resource planning (ERP) systems, each with its ‘own database for operational data, Analytical datas corsoli- dated in an enterprise data warehouse ina batch offline pro- ‘cess and consumed by business users via corporate business, intelligence (8) solutions. Lines of business that need custom reporting on more recent data (but not realtime) use addi- tional data marts and local Bl client. Figure 1: Typical Enterprise Software Situation toby SAP" ERP crswemnek sm “aescun at EE En igence (BD > Enterprise data warehouseNEED FOR NEW COMPUTING MODEL Technological Transition computer antec as hangs Tey smut me EC REE Crusererprvceststconmuncatonteveen rocor gure 2: Hardware Arete: cores via main memory or shared cache. Main memory's no| longer a limited resource. In2012 servers with more than 2 terabytes of RAM are avalable. a sesh ena ste aoe note eee eee eee ee ne stems there eee e eae ements ornate ica and oi rer Gee Pee) Avonlea ames ee eee en Cee one Erma ttc ee eee nee eee aera ore oe tenia Type of Memory Size Latency Tote cane Tessar ease 256K “aol Seach ae) ens 2-404 ees 20) venierey cbs pio oa "00-200 yes set ate ree cbs ptosis 00D ee Disk Upto petabytes: 1,000,000 cyctesSince traditional business solutions lean on OLTP databases, they co not use current hardware efficiently. Figure 3llustrates the architecture of the SAP* ERP application. Datais transmitted from the database tier to the application logic ter for processing. As ilustrated in Figure 2, the pertor mance bottlenecks between the main merrory and the CPU. Simple memory-resident caching with a traditional database system isnot the solution. The CPU spends half of the execu tion time in wasted stalls fortwo reasons: waiting for data being loaded from main memory nto the C?U cache, and the ‘act that sequential processing of the business application can not sroperty utilize the increasing number of processing cores. ‘Anew computing mocel, focused on exploiting the CPU cache and scale in parallel to mukicore processing, needs to be developed, Figure 3: Three-Tier Architecture of SAP* ERP? Presentation Pane Pear) ee BUSINESS LocIC Application server PersistenceOPTIMIZING APPLICATION AND CALCULATION PROCESSING DIRECTLY WITHIN MAIN MEMORY SAP HANA Platform Overview ‘TAKING A NEW APPROACH TO BUSINESS DATA PROCESSING. ‘The SAP HANA platform implements a new approach to bus ness data processing. In fact, it is much more tran the trad tional definition ofa database, And the in-memory attribute is ‘much more than a naive caching of disk data structures in the main memory Aconcestual view of SAP HANAisillstrated in Figure 4, While many of the concepts ciscussec below may be known in the incustry, the specific synergy of SAP HANA, which leverages SAP expertise in afferent domains, eveates anew class of solutions, Complete DBMS As Its Backbone SAPHANA. first and foremost, incorporates a full database ‘management system (DBMS) with a standard SQL interface, transactional isolation and recovery (ACIO (atomicity, ons Figure 4: Conceptual View of SAP HANA® Platform So Business function Wray ad tency, Isolation, durability] properties) and high availabilty ‘SAP HANA supports most entry-level SQL92. SAP applicat ons that use Open SQL can un on the SAP HANA platform without changes. SQLs the standard interface to SAP HANA. Adci- tional functionality, such as freestyle search. is implemented as SQL extensions. This approach simplifies the consumption of SAP HANA by applications. Analytical and Special interfaces In addition to SQL, SAP HANA suaports business intelligence clients directly using multidimensional expressions (MDX) for products such as Micrasoft Excel and business intelligence ‘consumer services (BICS), an internal interface for SAP BusinessObjects” solutions, For analytical planning, the user may iterate values on the aggregated analytical reports. With SAP HANA, a single value is transmitted for immediate recalculation by the in-memory planning engine, Parallel Data Flow Computing Model Tonatively take edvantege of massively parallel multicore pro- ccessors, SAP HANA manges the SQL processing instructions inta an optimized model that allows parallal execution and ‘sales incredibly well with the number af cores. The optimiza- tion includes partitioning the data in sections fr which the cal culations can be executed in parallel SAP HANA supports distribution across hosts. Large tables may be partitioned to be processed in parllel by multiple hosts. Figure 5 summarizes the results ofa scale test that was per {formed by an Intel team in collaboration with SAP. The test ‘demonstrates near-Inear scale. The processing time is 168 ‘seconds using 2 coves and improves to14 seconds using 22 cores. Hyperthreading adds an additional 20% improvement. Application Logic Extensions The parallel-data-tiow computing modelis extended with -application-specitic logic that is executed in processing nodes as part ofthe model, Support includes SQLScript asa func: tional lnguage and" as an mperativelanguage.® whic can call upon the prepackaged algorithms available in the predic tive analysis Ibrary of SAP HANA te perform advanced statist cal calculations. The application logic languages anc concepts are evolving as a result of collaboration with internal and exter nal SAP developer communities,Business Function Library and Predictive Analysis Library SAP leverages its deep agplication expertise to port speciic business epolication unct onalty as infrastructure within ‘SAP HANA to natively take advantage of in-memery compu ting technologies by oatimizing application and calculation processing directly within main memory. Examples include currency conversion, a fundamental fist step for a global eom= pany in which many reports, which otherwise may nave uted plain SQ\. utilize parallel processing well Another example is Converting business calendars: ferent countries use diferent civilian or business calendars and have cifferent definitions of = fiscal year, Multiple In-Memory Stores Optimized Per Task Native in-memory storage does not leverage the arocessing, power of modern C2Us well. The major optimization goalot SAPHANA\s to achieve high hit atiosin the different caching layers of the CPU. This is done by data comaression and by ‘adapting the data store for te task. For example, when the processing is cone row by row anc consurmes most of the fields vitin a row, 2 ew store in which each row is placed in mem- ory in sequence orovides the best performance. I calculations Figure 5: Example for Near-Linear Scale are executed on a single colum or several colurnns only, these {are scanned or aggregated into a column store in which each ccolurmnis stored in sequence as a (compressed) memory block, provicing mucm better results. An objects graph store ‘may benefit rom a structure in which each abject body is stored in sequence and the graph navigation is stored as another sequence to support unstructured and semistructured data storage. Appliance Packaging SAP HANA applies optimizations that take CPU utilzation to the extreme. Appliance packaging enables full control of the resources and ¢ certification process for hardware configura tions for best performance and reliability. For examale, SAP HANA includes automatic recovery from memory errors with ‘out system reboot. Systems with hign memory are statist cally more sensitive to such error, addition to a beneficial total cost of ownership of the appliance packing model, tis a funda ‘mental part of the SAP HANA design concept. Adsitionaly, SAP is actively invest gating virtual apaliances and cloud tem plates for SAP HANA to validate adsitionel performance use Joining TPC-H Data set (120 million records) in SAP HANA® on 4S Nehalem-EX (2.26 GHz) with 64 logical cores 1we2e Processing time (ilisecones) 10.000 20% improvement cue tomyperthreading with {A logical cores us 949]99 1 2 4 8 Number of threads 6 2 64ENGINEERED AND BUILT FOR OPTIMIZATION Technology Foundation EXECUTION CONTROL Execution controlisiltustrated in Figure 6. SQLSeript. MOX. and the planning engine interface can be seen as dormatn- specific programming languages or models that can be used to Interact with SAP HANA. The artifacts in the cifferent domain specific languages are translated by their specific compilers into a common representation caled a “calculation model." ‘calculation model sa directed acyclic graph with arrows representing data flows and nodes that represent operations, This approach and the exclusion of loops ard recursion enable ‘tomatic massive parallelism of the processing. ‘The easiest way to think of calculation models isto see thers a data flow graphs, where the modeler defines cata sources {as inputs an¢ciferent operations (join. aggregation, projec tion, and so on) an top of them for data manipulation. “The calculation engine automatically breaks up a model into ‘operations that cart be processed in parallel (model optimizer) These operations are passed to the database optimizer, which determines the best plan for accessing row or calurnn stores, leveraging cost-based optimizations and database statistics. Parallel process paths are illustrated in Figure 7, Figure 6: Processing Chain (Conceptual) Calculation engine cwecton plan ee Pryseal exceutonston Database executo RY RY Row MOKeo aleulaton engine a ne el vile oe ther compiler ay Seript execution rune ca agreed(CALCULATION MODELS FOR SQLSCRIPT TABLE FUNCTIONS, Coding Layers [As shown in Figure 8, the upper code layer within SAP HANAis| enabled through SQLScript, whichis the rich stored-procecure language of the SAP HANA database. SQlSerpt procedures ‘may contain SQL statements and can call ather procedures. It Isused to write procedural orchestration logic and to detine complex data flows. SQL Script is compiled first nto" (restricted subset of C++), which is then compiled into native code, SAPnas developed, dectly in C+=, @ business function lisrary (BFL) that includes ‘unctioralty for performing busi- ness processing at the database layer. BFL can be consumed by the layers above. SQLScript 'SQLScrist functions composed of SQL. queries and function calls can be represented as acyclic dataflow graphs. These functions, implemented in" language, are typically trans- formed into calculation models that contain oly one transfor: Imation node of type" script" In some cases a more complex ‘Braph may be created with SQL nodes for emisedded SQL {queries anc nodes for imperative code sequences. Each node has a set of inputs and outputs and an operation that transforms the inputs inte outputs. In action to ther pr ‘mary operation, each rode can also nave after condition for filtering the result set. The inputs anc the outouts of the opera tions are table-valued operands. Inputs can be connected to SAP HANA tables or to the outputs of nodes. Calculation models support a variety of node types: + Nodes for set operations such as projection, aggregation, join, union. minus, and intersection + SQL nodes that execute an SQL statement thats an attr: bute of the node + Scripting nodes for describing complex operations that can not be described with a grap of data transtormations. The function of such # node is described by a procedural script. To enable parallel execution, a calculation model may contain salt and join operations. A salit operation is used to partition input tables for subsequent processing steps based on part- tioning criteria. Operations between the spit anc join operation ‘may then be executed in parallel forthe different partitions. Figure 7: Parallel Process Paths rr eat Relational operation poe) Relational =o Parallet2 Paratel 3 Figure 8: Coding Layers in SAP HANA‘The compilers that create the calculation model try to trans: formas much ofthe input programas possible into a calcul tion model that consists only 0 set operation nades and SQL nodes. However this isnot possible in all cases. For example cops where an iteration depends on the results of previous iterations cannot be transforme¢ into dataflow graphs. In thse cases, the parts of the domain-specilic model that can not be transformed into dataflow transformations are trans- lated into scripting nodes with procedural code In.” language. Calculation models are more powertulthan traitional SQL, ‘queries or SQL views fortwo reasons: + These models offer the possibilty to detine specialized parameterized calculation schemas when tne actual query is Issued. Unlke an SQL view. a calculation model does not describe the actual query to be executed. Instead it describes the structure of the calculation, Additional nfor- ‘mations supplied when the calculation model s executed, Calculation engines use the actual parameters, attr bute lists, grouping attributes, and so on supplied with the invoce: ‘on to instantiate a query-spectic calculation model. This, “instantiated model” is optimized for the actual query and does not contain attributes, nodes, or data flows that are not needed for the specific invocation. + These models allow more flexible, serioted operations, via SQLScript or imperative scripts in" language. PARALLEL EXECUTION SAPA HANAis engineered for parallel execution that scales, ‘wellwith the number of available cores and across hosts when distrioution is used. Specifically, optimization for multicore platforms accounts forthe following two key considerations: + Datais partitioned wherever possible in sections that allow ‘calculations to be executed in parallel + Sequential processing is avoided, which includes finding akernatives to approaches such as thread locking, Parallel Aggregation Inthe shared-memory architecture withina node, SAP HANA, performs aggregation operations by soawning a nuriber of threads that act in parallel, cach of which has equal access to the data resident on the memory on that node. As lustrated at the top of Figure 9, each aggregation functions in loop-wise {fashion as follows: 1, Fetcha small partition of the input relation 2. Aggregate that partition 3, Raturn to step Iuntil te complete input relation is processed Each thread has a private hash table where l writes its aggre gation results. When the aggregal on threads are finished. the buttered hash tables are merged by merger threads using range partitioning, Each merger thread is responsible for acertain range! Figure 9: Use of Parallel Aggregation by SAP HANA® to Divide Work Among Threads® Aggregevon ‘thread 1 Cache-sizedhash tables “able bs es — Sor ea | wat tad a Sa nes ti Butter Merger thread Fat haan tabe Wg Merger thread 2 4 aiiA DIFFERENTIATING ATTRIBUTE OF SAP HANA Columnar and Row-Based Data Storage One of the differentiating attributes of SAP HANA is having both row-based and columr-oased stores within the samme engine Conceptually. a database table isa two-dimensional data structure with cells organized in rows and colurnns. Computer memory, however, is organized as a linear sequence. ing a table in linear memory, two options can & shown In Figure 10. Rw storage stores a sequence of re that contain the fields of one row inthe table, Ina column store, the entries ofa column are stored in contiguous memory locations, 5 stor= rds, (CHOOSING BETWEEN COLUMN AND ROW STORE \With SAP HANA you can specify whether a tables to be stored, by column or by row, Row stores eecommended it + The table has a small number of rows, such as configuration les. + The application needs to process only a single record at 3 time (many selects or uadates o single records). + The application typically needs to access the complete record + The columns contain mainly distinct values so the compres sion rate would below. + Aggregation and fast searching are not required, Row store's usec, for example, for SAP HANA database meta- data, for application serverinternaldata such 2s ABAP” server system tables, anc for con‘iguration data. In addition, applica tion developers may decide to put apolication tables in row store if the criteria given above are matched. Column store is recommended i tuted on a single column or a few col + Calculations are ex urns only + The table's searched based on the values of afew columns, + The table nas alarge number of columns. + The table nas alarge number of rows, anc columnar opera: ns are required (aggregate, scan, and so on). The majonity of columns contain oi (compared tothe number of rows), resulking n higher com pression rates, Figure 10: Row- and Column-Based Storage for a Table Table Country Product Sales, us ‘Aloha 3.000 us Beta 1250 e ‘Aloha 700 UK 450 Row store Column store Fowl County P Rowe. UK Product Alpha Beta Row3 wP Apna Alpha Alpha 700 Sales 3.000 Rowa) UK 1250) Alpha 700 450 450‘SAP HANA allows the joining of row-based tables with colum= rar tables, However, itis more efficient to join tables that are located in the same store, Therefore, master data thats fe ‘quently joined with transaction data is put in a column store ADVANTAGES OF COLUMNAR TABLES When the criterialisted above are fultled, columnar tables have several advantages. Higher performance for column operations. Operations on single columns, such as searching or aggregations. can be imolemented as loops over an array stored n contiguous ‘memory locations. Such an operation has high spatial locality and can efficiently be executed in the CPU cache. Higher data compression rates. Colurnnar data storage allons highly etficient compression. Especially ifthe colurnnis sorted, there will be anges of the same values in contiguous memory, so compression methods such asrur-length coding or cluster coging can be used, This s especially promising for SAP busi ress applications as they have many columns containing only a ‘ew distinct values compared to the number of rows. Examples are country codes or status codes as wells foreign keys. This high dogree of redundancy allows for effective compres: sion of column data, In row-based storage, successive memory locations contain data of cifferent colurins, so compression ‘methods such as rur-length coding cannot be used. In column stores a compression factor of 10 can be achieved compared to ‘traditional row-orientec datebese systems, Columnar data organization also allows highly etficient data compassion, This not only savas mernory but also increases speed for the following reasons: + Compressed data can be loaded into CPU cache more Quickly, As the limiting factor isthe data transport between memory an CPU cache, the performance gain wil exceed the adltional computing time needed for decompression. + With dictionary coding. the columns are stored as sequences, ot bit-coded integers. Checks for equalty canbe executed on the integers (or example, during scans or join operations). This is much faster than comparing string values. Compression can speed up operations such as scans and aggregations if tne operator is aware of the compression. Given a good compression rate, computing the sum of the values in column willbe much faster if the columns run- length coded and many additions ofthe sarve value can be replaced by a single mukipization. Elimination of additional indexes. Columnar storage elim nates the need for additional index structures in mary cases. Storing data in colurans works like having a bullin index for ‘each column the colurnn scanning speed of the in-memory column store and the compression mechanisms, especially dictionary compression. already allow read operations with very high performance. In many cases, additional index struc- tures will nat oe required. Eliminating adaitional indexes reduces complexity and eliminates effort for defining and maintaining metadata. Parallelization. Column-nasod storage also makesit easy to ‘execute operations in parallel using rultiple processor cores, Inacolumn store, data is already vertical partitioned, That ‘means operations on different colurnns can easily be pro- ‘cessed in parallel, If multiple columns need to be searched or ‘aggregated, eac' o* these operations can be assigned toa dit ferent processor core. In addition, operations on one column can be paralleized by partitioning the column into multiple sections that are processed by different processor cores. Fig- Lure I shows both options. Columns A and B are processed by different cores while column C was split into two partitions that are processed by two fferent cores. Higher performance for colurnn operations. With cokimnar {data organization, operations on single columns, such as ‘searching or aggregations, can be implemented as loops over ‘an array stored in contiguous memory locations. Such an oper- ation has high spatial localty anc can efficiently be executed in the CPU cache, ‘TEMPORAL TABLES ‘As mentioned above, SAP HANA supaorts temporal tables that allow queries against a historical state of the data, Write opera tions on temporal tables do not pinysically overwrite existing records. Instead, write operations always insert new versions of ‘the data record into the database. The different versions of a data record have timestamps indicating their vality. Applica tions can tell SAP HANA that subsequent queries are to be pro= ‘cessed against ahistorical view ofthe database.Figure 11: Example for Parallelization in a Column Store Processed by Processed by coune count counne icone ae me -_ ener % = ms soi 7 od #8 6 src = me see ma see ‘wa Eo sommes 08 wre sees ian re a8 we oe nt | ey a stots ssi cons | ieee geINCREASE READ PERFORMANCE BY ELIMINATING MATERIALIZED AGGREGATES SAP HANA Benefits for Business Applications Traditional business apolications use materialized aggregates to increase read performance, That means that the application ddovelopers define additional tables in which the application redundantly stores the results of aggregates, such as sums, comauted on other tables. The materialized aggregates are computed and stored either after each write operation on the aggregated data oral schestle times. Read operations reac the materializee-ageregates instead of computing them each time. \With scanning speed of several megabytes per millsecond, in-memory column stores make it possible to calculate ‘2ggrogates on large amounts of data on the fy wits high per formance. This is expected to eliminate the need for materia ized ageregates in many cases and thus eliminate un to 30% of the required tables. In financial applications, diferent kinds of totals and balances: are typically persisted as material zed aggregates for the citferent ledgers: general ledger. accounts payable, accounts receivable, cash ledger, material ledger, and so on, With an in- ‘memory column store, these materialized aggregates can be eliminated as al totals and balances can be computed on the fly with high performance from accounting document items organiza Eliminating materialized aggregates has several advantages: 1 to safely exp opportunities in side-by- for the increasing rate of doing business. Simplified data modet- With materialized aggregates. add ‘tonal tables are neaded, which make the data madel mare ‘complex. Inthe financials data model forthe SAP Business BByDesign” solution, for example, persisted totals and bal- ances are stored with a star schema, Specific business ‘objacts are introduced for totals and balances, each of which is persisted with one fact table and several dimension tables. With SAP HANA, allthese tables can be removed it totals and balances are computed on the fly. A simplified data model makes develooment more efficient, removes sources of pro- gramming errors, and increases maintainab lity Simplified aoplication logic: The application either needs to Update the ageregated value after an aggregated item was ‘adcec, deleted, or modified, or special aggregation runs need to be scheduled that update the aggregated values at certain time intervals, such as ance a day, By eliminating per- sisted aggrogates, th’ additional logic isno longer required Higher levelot concurrency: With materialized agaregates, a ‘write lock needs to be acquired after each write operation for Updating the aggregate. This mits concurrency anc may lead to pertarmanca issues, Without materialized aggre gates, only the cocument items are written. This can be done soncurrently without any locking, ‘Up-to-catedness" of aggregated values: With on-the-fly ‘aggregation, the aggregate values are always up-to-date, while materialized aggregates are sometimes updated only at scheduled times,DRAMATICALLY ACCELERATING SPEED OF BOTH DATA QUERYING AND BUSINESS PROCESSING Paradigm Shift in Approach to Data Management Technologies ‘SAP is leading a paradigm shift in the way we think about data ‘management technologies. Ths rethinking affects how we con struct business applications and our expectations in consum- ing therm. Businesses that adopt this new technology will have the potential for sharpening their cornpetitive edge by dramati- cally accelerating not anly data querying speed but also bus ness processing speed. SAP is working closely with customers, consultants, ané developers for both immediate business gain and a longer-term perspective and road map. As aline-of businesses driver ina lerge enterprise, you may ‘work in the short term with consultants to develop a business cease for real-time regorting on operat onal data. You may focus ‘on twa or thvee specific business scenarios and deploy SAP HANA in a side-by-side, nondisruptive manner. 4 team of your TT experts willgradally gain experience working with SAP HANA, learn to exploit its flexibilty, and further extend the util zation within your bus ness-user community Your organization wil become in-memory-corrputing 7eady and gain immediate business benefits at the same time, FIND OUT MORE Tolearn more about SAP HANA, visit ‘ADDITIONAL READING. “Keveger M.Grind © Trost Satine, S. Mule, and. Zee, Enterotise Osta Manager-er in Wied Wrdlaad Enuronments (rast Patina ter Sytem Engearing 2009) H Plattner. “A Common Database Approach for OLTP ard OLAP Us| ‘5: feMemary Geir Dataeae”(SIGMOD 03, lune 29-1uy 2.2008) Platine “Enterprise Appleatons ~ OLTP and OLA? = Share One DalanaseAcntectize”(ass0 Platine na le for IT Systems Enaineeig 2010) Plattner and A Zier, o-Memery Data Managemant An inetion Point Jor Enterprise Anglestons(Spenge verlag Ap 2011) “analyzing Business 35 I Happens: SAPIn Memory Apolince Software (SAP HANA runs onthe Inte Xeon® processor to generate suerion, fee uss eigerce (ref? A201) 1. Metien and, Lucas, rep forthe Quatum Leap in RealTime -Anaytes. How in memory ana s gong ta charge everything out yourentepise" (EMISAP. ue 2011) jencesaph and www sap.com/ ead sn. cr doo/natalorot/ocs/ bear FOOTNOTES Verlag. Apr 202. - . 2. tea. [3 Rostrictd susst ot C++ usd internally a SAP 44 Source: "Analyang Business as t Happens: SAP InMemory Applance speror. realtime business mlcigence”(nvellSA2 Aor 203). 3be a a a oe Pee oY rs . Oe a ee x D kk 6666666064 e a 7 | J 2 SEs EET UIE. re . c - oeeeeesese os Ye: > ie