Databases Reference
In-Depth Information
ASIA
Tokyo
EUROPE
ARCTIC
OCEAN
A
B
C
D
E
F
GREENLAND
(DEN.)
U.K.
Paris
A
B
C
D
E
F
AFRICA
CANADA
A
B
C
A
B
C
NORTH AMERICA
D
E
F
PACIFIC
OCEAN
ATLANTIC
OCEAN
D
E
F
New York
UNITED STATES
Memphis
Los Angeles
A
B
C
MEXICO
D
E
F
Caribbean
Sea
SOUTH AMERICA
F I G U R E 12.7
Distributed database with maximum data
replication
replicated tables? Figure 12.7 shows the maximum approach of replicating every
table at every site. It's great for availability and for joins, but it's the absolute worst
arrangement for concurrency control. Every change to every table has to be reflected
at every site. It's also a security nightmare and, by the way, it takes up a lot of disk
space.
The concept in Figure 12.8 is to have a copy of the entire database at
headquarters in New York and to replicate each table exactly once at one of the
other sites. Again, this improves availability, at least to the extent that each table
is now at two sites. Because each table is at only two sites, the security and
concurrency exposures are limited. Any join that has to be executed can be handled
at New York. So, this arrangement sounds pretty good, but it is limiting. What if a
particular table is used heavily at both Tokyo and Los Angeles? We would like to
place copies of it at both of those sites, but we can't because the premise is to have
one copy in New York and only one other copy elsewhere. Also, New York would
tend to become a bottleneck, with all of the joins and many of the other accesses
being sent there. Still, the design of Figure 12.8 appears to be an improvement over
the design of Figure 12.7. Can we do better still?
The principle behind making this concept work is flexibility in placing
replicated tables where they will do the most good. We want to:
Place copies of tables at the sites that use them most heavily in order to minimize
telecommunications costs.
■
Search WWH ::
Custom Search