reference a special entity called root entity in its root table An entity group

Reference a special entity called root entity in its

This preview shows page 281 - 284 out of 403 pages.

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
Image of page 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
Image of page 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.
Image of page 283
Image of page 284

You've reached the end of your free preview.

Want to read all 403 pages?

  • Fall '17
  • Murat Orhun

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture