Database Reference
In-Depth Information
as frequent inserts and updates. The latter has a lower compression rate
and lower query performance compared to the column-based engine. This
architecture allows mixed workloads to be supported in the same server, per-
forming complex analytical computations without the need of materializing
tables. Both relational engines support SQL and MDX. Calculations can be
performed in the database without moving the data into the application layer,
through an SQL script language that can be used to push down data-intensive
application logic into the database. Row or column storage can be selected at
the time a table is created but can be changed afterward. Both engines share
a common persistence layer (the nonvolatile data store in Fig. 13.4 ), where
page management and logging are supported like in traditional databases.
The data storage architecture is similar to the generic one depicted
in Fig. 13.4 , with an optimized column-store area and a nonoptimized buffer
area to allow insertions and updates. Insertions, deletions, and updates are
handled in HANA following the notion of lifetime management of a data
record. A level L1 delta storage , organized as a row-oriented storage area, is
used for individual updates. Bulk updates bypass level L1 and are managed
at a level L2 delta storage , organized in compressed columns, although it
is less optimized than the main storage area. Finally, the main store is the
highly compressed in-memory column storage explained above. Typically,
records are moved during their life cycle from level L1, to level L2, and to
the main store.
Regarding partitioning , data are divided into subsets and stored in a
cluster of servers, conforming a distributed database. This approach is called
scale-out. An individual database table can be placed on different servers
within a cluster or can be split into several partitions, either horizontally (a
group of rows per partition) or vertically (a group of columns per partition),
with each partition residing in a separate server within the cluster.
Atomicity, consistency, and isolation are ACID properties that are
not affected by in-memory storage. However, as explained above, durability
cannot be met by just storing data in main memory since this is volatile
storage. To make data persistent, it must reside on nonvolatile storage such
as hard drives or flash devices. HANA divides the main memory into pages.
When a transaction changes data, the affected pages are marked and written
to nonvolatile storage at regular intervals. In addition, a database log captures
all changes made by transactions. Each committed transaction generates a
log entry that is written to nonvolatile storage, ensuring that all transactions
are permanent. SAP HANA stores changed pages at savepoints ,whichare
asynchronously written to persistent storage at regular intervals (by default,
every 5min). A transaction does not commit before the corresponding log
entry is written to persistent storage, to meet the durability requirement
(in traditional database management, this is called write-ahead log). After
a power failure, the database can be restarted from the savepoints like a
disk-based database: the database logs are applied to restore the changes
Search WWH ::




Custom Search