Database Reference
In-Depth Information
One of the factors that will help to determine whether the scale-up or the scale-out option is more appropriate for
your environment is the transaction performance requirements. If a lower transaction latency is the goal, the scale-up
method may be the option to choose, as reading data from local memory is much faster than reading data from a
remote server across the network due to the fact that memory speed is much faster than networking speed, even for the
high-speed InfiniBand network. If increasing database transaction throughput is the goal, scale-out is the option to be
considered, as it can distribute transaction loads to multiple servers to achieve much higher transaction throughput.
Other factors to be considered include the costs of hardware and software licenses. While the scale-up method
may need a high-cost, high-end server to allow vertical scalability, the scale-out method will allow you to use low-cost
commodity servers clustered together. Another advantage of the scale-out method is that this solution also confers high
availability, which allows database transactions to be failed over to other low-cost servers in the cluster, while the scale-up
solution will need another high-cost server to provide a redundant configuration. However, the scale-out method usually
needs special licensed software such as Oracle RAC to cluster the applications on multiple nodes. While you may be able
to save some hardware costs with the scale-out model, you need to pay for the licencing cost of the cluster software.
The scale-out method takes much more complex technologies to implement. Some of the challenges are how to
keep multiple servers working together on a single database while maintaining data consistency among these nodes,
and how to synchronize operations on multiple nodes to achieve the best performance. Oracle RAC is designed to
tackle these technical challenges and make database servers work together as one single server to achieve maximum
scalability of the combined resources of the multiple servers. Oracle RAC's cache fusion technology manages cache
coherency across all nodes and provides a single consistent database system image for applications, no matter which
nodes of the RAC database the applications are connected to.
Oracle RAC
This section discusses Oracle RAC: its architecture, infrastructure requirements, and main components.
Database Clustering Architecture
To achieve horizontal scalability or scale-out of a database, multiple database servers are grouped together to form
a cluster infrastructure. These servers are linked by a private interconnect network and work together as a single
virtual server that is capable of handling large application workloads. This cluster can be easily expanded or shrunk by
adding or removing servers from the cluster to adapt to the dynamics of the workload. This architecture is not limited
by the maximum capacity of a single server, as the vertical scalability (scale-up) method is. There are two types of
clustering architecture:
•
Shared Nothing Architecture
•
Shared Everything Architecture
The shared nothing architecture is built on a group of independent servers with storage attached to each server.
Each server carries a portion of the database. The workloads are also divided by this group of servers so that each
server carries a predefined workload. Although this architecture can distribute the workloads among multiple servers,
the distribution of the workloads and data among the servers is predefined. Adding or removing a single server would
require a complete redesign and redeployment of the cluster.
For those applications where each node only needs to access a part of the database, with very careful partitioning
of the database and workloads, this shared nothing architecture may work. If the data partition is not completely in
sync with the application workload distribution on the server nodes, some nodes may need to access data stored in
other nodes. In this case, database performance will suffer. Shared nothing architecture also doesn't work well with
a large set of database applications such as OLTP (Online transaction processing), which need to access the entire
database; this architecture will require frequent data redistribution across the nodes and will not work well. Shared
nothing also doesn't provide high availability. Since each partition is dedicated to a piece of the data and workload
which is not duplicated by any other server, each server can be a single point of failure. In case of the failure of any
server, the data and workload cannot be failed over to other servers in the cluster.
