Databases Reference
In-Depth Information
If all three conditions are met, then the client can invoke the hashing function to
determine which node holds the required data. By directly accessing the node that holds
the data for the transaction and by carefully designing the system so that joins do not
generally result in data transfer, the shared-nothing architecture transforms the OLTP
database into almost literally a set of nearly independent databases each working on a
subset of the application space. There have been some high-profile industrial examples
exploiting shared nothing in this way. One of the most famous was the joint IBM-
Microsoft “Firestorm” benchmark published during the summer of 2000 (Table 6.3).
The Firestorm result was achieved and could only have been achieved using a shared-
nothing partitioned OLTP application. This benchmark exploited a shared-nothing archi-
tecture and a partitioned application to achieve huge scalability results, far exceeding any-
thing that had been achieved until then (Figure 6.5). The results achieved four times the
scale-out in number of servers and number of CPUs. The result, while impressive, was
only possible because the application was partitionable along the partitioning keys.
Figure 6.5
System topology example for partitioned OLTP result using shared-nothing architecture.
Very often this kind of application partitioning is not practical. OLTP applications
tend to have workloads that have short queries and frequent updates. It is often not
practical for the application code to determine which node of the cluster the data
