Databases Reference
In-Depth Information
rule of course, more is better for most resources, but cost climbs rapidly for some
resources. And while CPUs are relatively inexpensive, large NUMA systems with com-
plex bus architectures to efficiently support clusters of CPUs are dramatically more
expensive than the simple sum of the cost of the CPUs they include might suggest. Sev-
eral factors play into this problem:
1.
The relative speed of disk access versus RAM.
2.
The relative cost of CPU versus disk.
3.
The relative cost of RAM versus disk.
4.
The topology choice (e.g., shared nothing or shared everything).
5.
The database access skew (how much of your data is really active).
There are no absolute rules that define what is right. However, there are some “best
practices.” What follows are some guidelines, which may not hold true in future gener-
ations of components.
Very generally, best CPU and I/O balancing appears to occur when CPU-to-data
(GB) ratios are around 1:100, RAM-to-disk ratios are around 1:25, and CPU-to-disk
ratios are 1:6. These are very approximate ratios that can vary quite widely based on
component speeds. Because CPU speeds, memory speed, and disk capacity change sig-
nificantly every year, these ratios can vary easily by a factor of 2 or 3. Even so, these
ratios should serve as a somewhat useful guideline for the approximate range of relative
capacity of components to compile when constructing a database server. These ratios
have held their ground across many application types, including business intelligence
systems (OLAP, DSS) and transaction processing systems (OLTP). See Table 13.3.
Table 13.3
Typical Resource Ratios
These ratios are likely reasonable for the next few years. Note that these ratios are
based on the volume of active data. Many databases include a considerable amount of
inactive data (rarely accessed). When considering the storage requirements for your
server, you should calculate the total storage requirements for the system, and then
