When the character Maverick from the movie Top
Gun exclaimed, “I feel the need, the need for speed”, you’d be forgiven for
mistaking it for a sound bite from a CIO discussing their transactional
databases. Whether it’s a financial organization predicting share prices, a
bank knowing whether it can approve a loan or a marketing organisation reaching
consumers with a compelling promotional offer, the need to access, store,
process and analyze data as quickly as possible is an imperative for any
business looking to gain a competitive edge. Hence when in 2011, SAP announced
their new in-memory platform HANA for enterprise applications everyone took
note as they coined the advantage of real-time analytics. SAP HANA promised to
not just make databases dramatically faster like traditional business warehouse
accelerator systems but instead speed up the front end, enabling companies to
run arbitrary, complex queries on billions of records in a matter of seconds as
opposed to hours. The vendors of old legacy traditional databases were facing a
major challenge, most notably the king of them all…Oracle.
The
Birth and Emergence of Big Data
Back in the days of mainframe, you’d find the
application and transactional data of reporting databases physically stored in
the same system. This was due to applications, operating systems and databases
being designed to maximize their hardware resources, which consequently meant
you couldn’t process transactions and reports simultaneously. The
bottleneck here was cost, in that if you wanted to scale you needed another
mainframe.
After the advent of client servers where
applications could run on a centralized database server via multiple and cost
effective servers, scalability was achieved by simply adding additional
application servers. Regardless, of this a new bottleneck was quickly
established with systems relying on a single database server and requests from
ever increasing application servers that ended up causing I/O stagnation. This
problem became exasperated with OLTP (online transaction processing), where
report creation required the system to concurrently read multiple tables in the
database. Added to this servers and processors kept getting faster while disks
(despite the emergence of SSD) were quickly becoming the bottleneck to
automated processes that were producing large amounts of data that concurrently
resulted in more report requests.
The net effect was a downward spiral where the
increase of users requiring an increase of reports from the databases meant an
increase in huge amounts of data being requested from disks that simply weren’t
up to the job. When you then factored in the data proliferation of external
users caused by the Internet and pressure inducing laws such as Sarbanes-Oxley,
the demand to analyze even more data even quicker has reached fever point. With
data and user volumes increasing by a factor of thousands compared to the I/O
capability of databases, the transaction-based industry faced a challenge that
required a dramatic shift and change. Cue the 2011 emergence of SAP’s
HANA.
Real-Time
In Memory Platform Presents a Groundbreaking Approach
One of the major advantages of SAP HANA’s ability
to run in real time is that it offers a non-requirement for data redundancy as
it’s built to run as a single database. With clusters of affordable and
scalable servers, transactional and analytical data are run on the same
database, hence eliminating different types of databases for different
application needs. Oracle on the other hand has built an empire on exactly the
opposite.
Oracle has thrived on a model where generally companies start with a simple database that’s utilized for checking sales orders and ensuring product delivery to customers but as the business grows they need more databases with different and more demanding functions. Functions such as managing customer relationships, complex reporting and analysis drives a need for new databases that are separate from the actual business requiring data to be moved from one system to another. Eventually you have a sprawl of databases as existing ones are unable to handle the workloads making it almost impossible to track data movements yet alone attain real time updates. So while the Oracle marketing machine is also pitching the benefits of in-memory via its Exalytics appliance and in-memory database, TimesTen, Oracle are certainly in no rush to break this traditional model of database sprawl and the money-spinning licenses that come with it.
Looking closely at the Oracle Exalytics /
TimesTen package, despite the hype, it merely is just an add-on product meaning
that an end user will still need a license for the transactional database,
another license for the data warehouse database and yet another license for
TimesTen for Oracle Exalytics.
Moreover, the Oracle bolt-on approach serves to
sell more of their hardware commodity and in some ways perversely justify their
acquisition of SUN Microsystems, all at the expense of the customer. Due to the
Exalytics approach continuing the traditional requirement for transactional
data to be duplicated from the application to the warehouse and once again to
Exalytics, the end user not only ends up with three copies of the data, they
also have to have three levels of storage and servers. In contrast SAP HANA is
designed to be a single database that runs both transactional applications and
Business Warehouse deployments. Not only does SAP HANA’s one copy of data
replace the two or three required for Oracle it also eliminates the need for
materialized views, redundant aggregates and indexes leaving a significantly
reduced data footprint.
Comparing
HANA to Oracle’s TimesTen and Exalytics
As expected Oracle have already initiated their
FUD team with bogus claims and untruths against HANA as well as even pushing
their TimesTen as a like for like comparison. Where this is hugely flawed is
that they fail to acknowledge or admit that SAP HANA is a completely
groundbreaking design as opposed to a bolt-on approach. With SAP HANA
data is completely managed and accessed in RAM consequently doing away with the
requirement of MOLAP, multiple indexes and other tuning features that Oracle
pride themselves on.
Furthermore, despite the Oracle FUD, SAP HANA
does indeed handle both unstructured and structured data, as well as utilise
parallel queries for scaling out across server nodes. In this instance Oracle
are trying hard to create the most confusion and subsequently detract the
market from realizing that the TimesTen with Exalytics package still can’t
scale out beyond the 1TB RAM limit unlike SAP HANA where each container can
store up to 500TB of data all executable at high speed.
With an aggressive TCO and ROI model compared to
a traditional Oracle deployment, SAP HANA also proves a lot more cost
effective. With pricing based on an incremental of 64GB RAM and the total
amount of data held in memory, licenses are fully inclusive of production and
test/development requirements as well as the necessary tools.
SAP HANA’s embracing of VMware
Furthermore with Oracle’s belligerent stance
towards VMware and the cost savings it brings to end users, SAP on the other
hand has embraced it. The recent announcement that SAP HANA is supporting
VMware vSphere will provide them a vast competitive advantage, as it will
enable customers to provision instances of SAP HANA in minutes as VM templates,
as well as gain benefits such as Dynamic Resource Scheduling and vSphere
vMotion. By virtualizing SAP HANA with VMware, end users can quickly have several
smaller HANA instances all sharing a single physical server leading to better
utilization of existing resources. With the promise of certified preconfigured
and optimised converged infrastructures such as the Vblock around the corner,
SAP HANA appliances could be shipped with vSphere 5 and SAP HANA pre-installed
within days, enabling rapid deployment for businesses.
With business and transactions being done in real
time, SAP HANA ensures that the data and the analytics that come with them are
also in real time. The process of manually polling data from multiple systems
and sorting them through are inadequate in a time when businesses are facing
unpredictable economic conditions and volatile demand and complex supply
chains. The need is for real time metrics that are aligned to supply and demand
where a retailers' shelves can accurately and immediately be stocked
eliminating unnecessary inventory costs, lost sales opportunities and failed
product launches. Being able to instantly analyze data at any level of
granularity enables a business to quickly respond to these market insights and
take decisive actions such as transferring inventory between distribution
centers based on expected sales or altering the prices of promotions based on
customer demand. Instead of waiting for processes that take hours, days or even
weeks, SAP HANA’s real time capabilities enable businesses to react in real
time to incidents.
Ultimately SAP HANA is a revolutionary step
forward that will empower organizations to focus more on the business and less
on the infrastructure that supports them. With the promise of new applications
being built by SAP to support real time decision making as well as being able to
run existing applications, SAP HANA presents the opportunity to not only
transform a business but also the underlying technology that supports it.
