Reference a special entity called root entity in its

reference a special entity, called root entity in its root table. An entity group consists of the
primary entity and all entities that reference it.
The system makes extensive use of Bigtable . Entities from different Megastore tables
can be mapped to the same Bigtable row without collisions; this is possible because the
Bigtable column name is a concatenation of the Megastore table name and the name of a
281

disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
disk
Datacenters
Strict consistency
(ACID semantics)
enforced within an
entity group.
Loose consistency
among entity
groups.
Entity groups
Figure 96: Megastore organization. The data is partitioned into entity groups ; full ACID
semantics within each partition and limited consistency guarantees across partitions are
supported. A partition is replicated across datacenters in different geographic areas.
property. A Bigtable row for the root entity stores the transaction and all metadata for the
entity group. As we have seen in Section 8.8 multiple versions of the data with different
timestamps can be stored in a cell. Megastore takes advantage of this feature to implement
multiversion concurrency control (MVCC); when a mutation of a transaction occurs, this
mutation is recorded along with its timestamp, rather than marking the old data as obsolete
and adding the new version. This strategy has several advantages: read and write operations
can proceed concurrently, a read always returns the last fully updated version.
A write transaction involves the following steps: (1) Get the timestamp and the log
position of the last commited transaction; (2) Gather the write operations in a log entry;
(3) Use the consensus algorithm to append the log entry and then commit; (4) update the
Bigtable entries; and (5) Cleanup.
282

8.10 History notes
A 1989 survey of distributed file systems can be found in [315]. NFS Versions 2, 3 and 4
are defined in RFCs 1094, 1813, and 3010, respectively. NFS Version 3 added a number of
features including: support for 64-bit file sizes and offsets, support for asynchronous writes
on the server, additional file attributes in many replies, and a READDIRPLUS operation.
These extensions allowed the new version to handle files larger than 2 (GB), to improve
performance, and to get file handles and attributes along with file names when scanning a
directory. NFS Version 4 borrowed a few features from the Andrew file system. WebNFS is
an extension of NFS Version 2 and 3; it enables operations through firewalls and is easier
integrated into Web browsers.
AFS was developed at CMU in collaboration with IBM [249]; AFS was further developed
as an open-source system by IBM under the name OpenAFS in 2000. Sprite [165] was
developed at U. C. Berkeley in the mid 1980s. Locus [363] was initially developed at UCLA
in the early 1980s and its development was continued by Locus Computing Corporation.