RAC – simple, cheap, effective, application transparent way to assemble rock solid highly available and scalable database environment out of cheap boxes (read bricks).
FAB principles quoted from page 1 (bold marks are mine):
A Federated Array of Bricks (FAB) is a logical
disk system that provides the reliability and performance
of enterprise-class disk arrays, at a fraction of the
cost and with better scalability.
A Federated Array of Bricks (FAB) is a low-cost alternative
to disk arrays, and is designed to be scalable from
very small to very large systems. FAB achieves this by
composing together storage bricks, where each brick is
a small rack-mounted storage appliance built from commodity
components including disks, a CPU, NVRAM, and
network cards. FAB systems cost much less than disk arrays
to manufacture and develop, due to the economies
of scale inherent in volume production, and because FAB
can replace entire array product lines (amortizing development
costs). Because of these factors, we anticipate that
a FAB system can be built for far less than the equivalent
high-end system. FAB provides comparable reliability,
achieved through replication: we store the same disk
block on multiple bricks, and we create redundant paths
between all components of the system. FAB performance
scales by completely distributing all functionality (no centralized
bottlenecks) across the set of available bricks.
I’m afraid the real life sounds more like:
- RAC — if application is able to partition workload well than it will “go RAC” well or with a bit of efforts can be distributed well without RAC.
- FAB — if application (database) can partition storage well than it would be able to “go FAB” nicely as well as without it.
Cost saving analogy – compare cost of a brick house vs. price of bricks. It turned out that monolith or prebuilt houses are much cheaper when technology reached certain level.
Dear Reader, what is your perspective?