When is database replication most appropriate (consider network constraints, heterogeneity, and tolerance for staleness)?
-
AWhen transmission speeds and capacity in a network prohibit frequent refreshing of large tables.
-
BWhen using many nodes with different operating systems and DBMSs and database designs.
-
CThe application's data can be somewhat out-of-date.
-
DAll of the above.
Answer
Correct Answer: All of the above.
Explanation
Introduction / Context:Replication copies data across sites to improve availability, performance, and local autonomy. Deciding when to replicate requires weighing network bandwidth, heterogeneity, and read/write patterns—including tolerance for slightly stale data.
Given Data / Assumptions:
- Large tables are costly to refresh frequently across slow networks.
- Sites may be heterogeneous, complicating tightly coupled distributed transactions.
- Use cases may allow eventual consistency where slight staleness is acceptable.
Concept / Approach:Replication is well-suited when bandwidth is limited (reduce round-trips), environments are heterogeneous (decouple updates), and the application can accept eventual consistency rather than strict real-time synchronization.
Step-by-Step Solution:
Evaluate each condition independently as a reason to replicate.Recognize that each favors local reads and asynchronous propagation.Select the option that consolidates all valid reasons.Verification / Alternative check:CAP-inspired designs and classic replication literature cite bandwidth constraints and staleness tolerance as drivers for replication strategies.
Why Other Options Are Wrong:
- Each single reason is valid but incomplete; D captures the full set.
Common Pitfalls:Assuming replication always guarantees strict consistency; asynchronous models trade freshness for availability/performance.
Final Answer:All of the above.