Paper check About

Bigtable: A Distributed Storage System for Structured Data

OSDI, 2006 · paper · Computer science

Describes Bigtable, a distributed storage system for structured data designed to scale to petabytes across thousands of servers. It presents the data model and implementation, and reports that it serves many Google products with varied demands.

Checked: PDF from usenix.org, fetched 4 Oct 2026. Page numbers are those of that PDF.

2 findings

Reference or label Reference [28] (Pike et al., Sawzall, Scientific Programming Journal 13, 4 (2005)) gives the pages as "227–298"; the article is reported to start on p. 277.
  • p. 14 Reference [28]
    227–298.
  • p. 14 Reference [28]
    Scientific Programming Journal 13, 4 (2005), 227–298.

Only the authors can say what is right here.

Judge's note: Rests on outside knowledge: that the Sawzall article in Scientific Programming 13(4) runs pp. 277–298. Crop C014-a confirms the printed range '227–298'. Taken at face value, that range is 72 pages, which is implausible for a journal article and fits a transposed digit. This cannot be verified from the files.

Second check: another model agreed

Report a problem with this finding
Wording "Random reads are slower than all other operations by an order of magnitude or more" is not supported by the one-server column of the Figure 6 table (random reads 1212; sequential reads 4425; sequential writes 8547; random writes 8850; random reads (mem) 10811; scans 15385).
  • p. 9 Section 7, Single tablet-server performance
    Random reads are slower than all other operations by an order of magnitude or more.
  • p. 9 Figure 6 table, column 1
    4425
  • p. 9 Figure 6 table, column for 1 tablet server
    sequential reads 4425

Only the authors can say what is right here.

Judge's note: Page 9, Figure 6 table, column '1', read from the image. The paragraph explicitly concerns the one-tablet-server case. Only scans are at least 10x faster than random reads. Sequential reads are only about 3.7x faster, and both kinds of write are about 7x faster. The text overstates the gap, so this is S3. The authors should reword it.

Second check: another model agreed

Report a problem with this finding
10 minor (typos and the like; most checked by the judge only)
Wording Section 3 calls "anchor:*.cnn.com" a "regular expression", but the pattern is written in glob notation; read as a regex it would not match the intended columns.
  • p. 3 Section 3, API
    match the regular expression anchor:*.cnn.com

Judge's note: Crop C001-a shows the text as quoted. Read as a regular expression, ':*' means zero or more colons and '.' matches any one character, so the pattern would not match e.g. 'anchor:www.cnn.com'. The intended meaning is clear, and the usage is informal notation rather than an error of substance, so this is an observation.

Second check: another model agreed

Report a problem with this finding
Wording "Aggregate throughput increases dramatically, by over a factor of a hundred" is stated generally, but for random reads the Figure 6 data give about 99x, which the paper itself later calls "only a factor of 100".
  • p. 9 Section 7, Scaling
    Aggregate throughput increases dramatically, by over a factor of a hundred
  • p. 10 Section 7, Scaling
    an increase in aggregate throughput by only a factor of 100 for a 500-fold increase
  • p. 9
    Aggregate throughput increases dramatically, by over a factor of a hundred, as we increase the number of tablet

Judge's note: Figure 6 table (page 9) and Scaling text (pages 9–10). Aggregate increase from 1 to 500 servers = per-server rate at 500 × 500 / rate at 1. Random reads give 99.4x. Every other benchmark exceeds 100x (random reads (mem) 289x, which matches 'almost a factor of 300'). The paper qualifies random reads itself, so this is a minor wording inconsistency.

Second check: another model agreed

Report a problem with this finding
Typo Section 5 misspells 'accommodate' as "acco-modate" (split across a line break), i.e. 'accomodate'.
  • p. 4 Section 5, first paragraph
    acco-modate changes in workloads
  • p. 4 Section 5, first paragraph
    to acco-modate changes in workloads

Judge's note: Page 4, top of the right column: "to acco- / modate changes in workloads". Joining the two halves of the line break gives 'accomodate', which is missing an 'm'.

Second check: none (judge only)

Report a problem with this finding
Typo Section 5.3 has a stray article: "a set of a redo points" should read 'a set of redo points'.
  • p. 6 Section 5.3
    and a set of a redo points
  • p. 6 Section 5.3 Tablet Serving
    a set of a redo points

Judge's note: Crop C004-a (page 6, left column) shows "and a set of a redo points, which are pointers into any commit logs".

Second check: none (judge only)

Report a problem with this finding
Typo Section 6: "caches SSTables blocks that were read from GFS" should read 'SSTable blocks'.
  • p. 7 Section 6, Caching for read performance
    caches SSTables blocks that were read from GFS

Judge's note: Crop C006-a (page 7, Caching for read performance) shows 'SSTables blocks'. Elsewhere the paper writes 'SSTable block' (e.g. '64 KB SSTable block' on page 9).

Second check: none (judge only)

Report a problem with this finding
Typo The plural subject in "the network paths traversed to reach the particular set of three GFS servers is suffering network congestion, or is heavily loaded" takes singular verbs.
  • p. 8 Section 6, Commit-log implementation
    servers is suffering network congestion, or is heavily loaded

Judge's note: Crop C007-a (page 8) shows the text. The subject 'network paths' is plural, so 'are suffering ... are heavily loaded' is expected. 'is heavily loaded' may be meant to refer to the server set, which leaves the clause ambiguous. Grammatical slip only.

Second check: none (judge only)

Report a problem with this finding
Typo Section 7: "strings under different row key were distinct" should read 'different row keys'.
  • p. 9 Section 7, benchmark description
    strings under different row key were distinct

Judge's note: Page 9, left column, shows 'under different row key were distinct'.

Second check: none (judge only)

Report a problem with this finding
Typo In Table 1, the bin "100 .. 499" is followed by "> 500", so a cluster of exactly 500 tablet servers falls in no bin.
  • p. 10 Table 1, last two rows
    > 500

Judge's note: Page 10, Table 1 image. The bins 0..19, 20..49, 50..99 and 100..499 are contiguous, and the last bin is printed '> 500'. The counts sum to the 388 clusters stated in Section 8, so the data are complete. Only the bin label has the gap; '≥ 500' was presumably intended.

Second check: none (judge only)

Report a problem with this finding
Typo Section 7: "as the number of tablet server in-creases by a factor of 500" should read 'tablet servers'.
  • p. 10 Section 7, Scaling
    as the number of tablet server in-creases by a factor of 500

Judge's note: Page 10, left column, shows 'the number of tablet server in- creases'.

Second check: none (judge only)

Report a problem with this finding
Typo Section 10 misspells 'partitioning' as "partioning" in "vertical and horizontal data partioning into flat files".
  • p. 13 Section 10, first paragraph
    vertical and horizontal data partioning into flat files
  • p. 13 Section 10 Related Work
    data partioning into flat files

Judge's note: Crop C013-a (page 13, left column) shows 'partioning'.

Second check: none (judge only)

Report a problem with this finding
Something wrong with this page, or a finding we missed?