Skip to content

Commit 6a1831e

Browse files
mwhittakermwhittaker
committed
Cleaned up a couple more summaries.
1 parent 2421e33 commit 6a1831e

9 files changed

+80
-80
lines changed

‎TODO.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -5,10 +5,10 @@
55
- [x] `lauer1979duality.md`
66
- [x] `lampson1980experience.md`
77
- [x] `chamberlin1981history.md`
8-
- [ ] `mckusick1984fast.md`
9-
- [ ] `saltzer1984end.md`
10-
- [ ] `agrawal1987concurrency.md`
11-
- [ ] `stonebraker1987design.md`
8+
- [x] `mckusick1984fast.md`
9+
- [x] `saltzer1984end.md`
10+
- [x] `agrawal1987concurrency.md`
11+
- [x] `stonebraker1987design.md`
1212
- [ ] `herlihy1990linearizability.md`
1313
- [ ] `stonebraker1991postgres.md`
1414
- [ ] `golub1992microkernel.md`

‎html/agrawal1987concurrency.html

Lines changed: 17 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -8,26 +8,29 @@
88

99
<body>
1010
<div id="container">
11-
<h2 id="concurrency-control-performance-modeling-alternatives-and-implications-1987"><a href="https://scholar.google.com/scholar?cluster=9784855600346107276&amp;hl=en&amp;as_sdt=0,5">Concurrency Control Performance Modeling: Alternatives and Implications (1987)</a></h2>
12-
<p><strong>Overview.</strong> There are three types of concurrency control algorithms: locking algorithms, timestamp based algorithms, optimistic algorithms. There have been a large number of performance analyses aimed at deciding which type of concurrency algorithm is best, however despite the abundance of analyses, there is no definitive winner. Different analyses have contradictory results, largely because there is no standard performance model or set of assumptions. This paper presents a complete database model for evaluating the performance of concurrency control algorithms and discusses how varying assumptions affect the performance of various algorithms.</p>
13-
<p><strong>Performance Model.</strong> This paper analyzes three specific concurrency control mechanisms,</p>
11+
<h1 id="concurrency-control-performance-modeling-alternatives-and-implications-1987"><a href="https://scholar.google.com/scholar?cluster=9784855600346107276&amp;hl=en&amp;as_sdt=0,5">Concurrency Control Performance Modeling: Alternatives and Implications (1987)</a></h1>
12+
<h2 id="overview">Overview</h2>
13+
<p>There are three types of concurrency control algorithms: locking algorithms, timestamp based algorithms, optimistic algorithms. There have been a large number of performance analyses aimed at deciding which type of concurrency algorithm is best, however despite the abundance of analyses, there is no definitive winner. Different analyses have contradictory results, largely because there is no standard performance model or set of assumptions. This paper presents a complete database model for evaluating the performance of concurrency control algorithms and discusses how varying assumptions affect the performance of various algorithms.</p>
14+
<h2 id="performance-model">Performance Model</h2>
15+
<p>This paper analyzes three specific concurrency control mechanisms,</p>
1416
<ul>
15-
<li><em>Blocking.</em> Transactions acquire locks before they access a data item. Whenever a transaction acquires a lock, deadlock detection is run. If a deadlock is detected, the youngest transaction is aborted.</li>
16-
<li><em>Immediate-restart.</em> Again, transactions acquire locks, but instead of blocking if a lock cannot be immediately acquired, the transaction is instead aborted and restarted with delay. This delay is adjusted dynamically to be roughly equal to the average transaction duration.</li>
17-
<li><em>Optimistic.</em> Transactions do not acquire locks. A transaction is aborted when it goes to commit if it read any objects that had been written and committed since the transaction began.</li>
17+
<li><strong>Blocking.</strong> Transactions acquire locks before they access a data item. Whenever a transaction acquires a lock, deadlock detection is run. If a deadlock is detected, the youngest transaction is aborted.</li>
18+
<li><strong>Immediate-restart.</strong> Again, transactions acquire locks, but instead of blocking if a lock cannot be immediately acquired, the transaction is instead aborted and restarted with delay. This delay is adjusted dynamically to be roughly equal to the average transaction duration.</li>
19+
<li><strong>Optimistic.</strong> Transactions do not acquire locks. A transaction is aborted when it goes to commit if it read any objects that had been written and committed since the transaction began.</li>
1820
</ul>
1921
<p>using a closed queueing model of a single-site database. Essentially, transactions come in, sit in some queues, and are controlled by a concurrency control algorithm. The model has a number of parameters, some of which are held constant for all the experiments and some of which are varied from experiment to experiment. Some of the parameters had to be tuned to get interesting result. For example, it was found that with a large database and few conflicts, all concurrency control algorithms performed roughly the same and scaled with the degree of parallelism.</p>
20-
<p><strong>Resource-Related Assumptions.</strong> Some analyses assume infinite resources. How do these assumptions affect concurrency control performance?</p>
22+
<h2 id="resource-related-assumptions">Resource-Related Assumptions</h2>
23+
<p>Some analyses assume infinite resources. How do these assumptions affect concurrency control performance?</p>
2124
<ul>
22-
<li><em>Experiment 1: Infinite Resources.</em> Given infinite resources, higher degrees of parallelism lead to higher likelihoods of transaction conflict which in turn leads to higher likelihoods of transaction abort and restart. The blocking algorithm thrashes because of these increased conflicts. The immediate-restart algorithm plateaus because the dynamic delay effectively limits the amount of parallelism. The optimistic algorithm does well because aborted transactions are immediately replaced with other transactions.</li>
23-
<li><em>Experiment 2: Limited Resources.</em> With a limited number of resources, all three algorithms thrash, but blocking performs best.</li>
24-
<li><em>Experiment 3: Multiple Resources.</em> The blocking algorithm performs best up to about 25 resource units (i.e. 25 CPUs and 50 disks); after that, the optimistic algorithm performs best.</li>
25-
<li><em>Experiment 4: Interactive Workloads.</em> When transactions spend more time “thinking”, the system begins to behave more like it has infinite resources and the optimistic algorithm performs best.</li>
25+
<li><strong>Experiment 1: Infinite Resources.</strong> Given infinite resources, higher degrees of parallelism lead to higher likelihoods of transaction conflict which in turn leads to higher likelihoods of transaction abort and restart. The blocking algorithm thrashes because of these increased conflicts. The immediate-restart algorithm plateaus because the dynamic delay effectively limits the amount of parallelism. The optimistic algorithm does well because aborted transactions are immediately replaced with other transactions.</li>
26+
<li><strong>Experiment 2: Limited Resources.</strong> With a limited number of resources, all three algorithms thrash, but blocking performs best.</li>
27+
<li><strong>Experiment 3: Multiple Resources.</strong> The blocking algorithm performs best up to about 25 resource units (i.e. 25 CPUs and 50 disks); after that, the optimistic algorithm performs best.</li>
28+
<li><strong>Experiment 4: Interactive Workloads.</strong> When transactions spend more time “thinking”, the system begins to behave more like it has infinite resources and the optimistic algorithm performs best.</li>
2629
</ul>
27-
<p><strong>Transaction Behavior Assumptions.</strong></p>
30+
<h2 id="transaction-behavior-assumptions">Transaction Behavior Assumptions</h2>
2831
<ul>
29-
<li><em>Experiment 6: Modeling Restarts.</em> Some analyses model a transaction restart as the spawning of a completely new transaction. These fake restarts lead to higher throughput because they avoid repeated transaction conflict.</li>
30-
<li><em>Experiment 7: Write-Lock Acquisition.</em> Some analyses have transactions acquire read-locks and then upgrade them to write-locks. Others have transactions immediately acquire write-locks if the object will ever be written to. Upgrading locks can lead to deadlock if two transactions concurrently write to the same object. The effect of lock upgrading varies with the amount of available resources.</li>
32+
<li><strong>Experiment 6: Modeling Restarts.</strong> Some analyses model a transaction restart as the spawning of a completely new transaction. These fake restarts lead to higher throughput because they avoid repeated transaction conflict.</li>
33+
<li><strong>Experiment 7: Write-Lock Acquisition.</strong> Some analyses have transactions acquire read-locks and then upgrade them to write-locks. Others have transactions immediately acquire write-locks if the object will ever be written to. Upgrading locks can lead to deadlock if two transactions concurrently write to the same object. The effect of lock upgrading varies with the amount of available resources.</li>
3134
</ul>
3235
<script type="text/x-mathjax-config">
3336
MathJax.Hub.Config({

‎html/mckusick1984fast.html

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -8,20 +8,20 @@
88

99
<body>
1010
<div id="container">
11-
<h2 id="a-fast-file-system-for-unix-1984"><a href="TODO">A Fast File System for UNIX (1984)</a></h2>
12-
<p><strong>Summary.</strong> The <em>Fast Filesystem</em> (FFS) improved the read and write throughput of the original Unix file system by 10x by</p>
11+
<h1 id="a-fast-file-system-for-unix-1984"><a href="https://scholar.google.com/scholar?cluster=1900924654174602790">A Fast File System for UNIX (1984)</a></h1>
12+
<p>The <strong>Fast Filesystem</strong> (FFS) improved the read and write throughput of the original Unix file system by 10x by</p>
1313
<ol style="list-style-type: decimal">
1414
<li>increasing the block size,</li>
1515
<li>dividing blocks into fragments, and</li>
1616
<li>performing smarter allocation.</li>
1717
</ol>
18-
<p>The original Unix file system, dubbed “the old file system”, divided disk drives into partitions and loaded a file system on to each partition. The filesystem included a superblock containing metadata, a linked list of free data blocks known as the <em>free list</em>, and an <em>inode</em> for every file. Notably, the file system was composed of <strong>512 byte</strong> blocks; no more than 512 bytes could be transfered from the disk at once. Moreover, the file system had poor data locality. Files were often sprayed across the disk requiring lots of random disk accesses.</p>
19-
<p>The “new file system” improved performance by increasing the block size to any power of two at least as big as <strong>4096 bytes</strong>. In order to handle small files efficiently and avoid high internal fragmentation and wasted space, blocks were further divided into <em>fragments</em> at least as large as the disk sector size.</p>
18+
<p>The original Unix file system, dubbed “the old file system”, divided disk drives into partitions and loaded a file system on to each partition. The filesystem included a superblock containing metadata, a linked list of free data blocks known as the <strong>free list</strong>, and an <strong>inode</strong> for every file. Notably, the file system was composed of <strong>512 byte</strong> blocks; no more than 512 bytes could be transfered from the disk at once. Moreover, the file system had poor data locality. Files were often sprayed across the disk requiring lots of random disk accesses.</p>
19+
<p>The “new file system” improved performance by increasing the block size to any power of two at least as big as <strong>4096 bytes</strong>. In order to handle small files efficiently and avoid high internal fragmentation and wasted space, blocks were further divided into <strong>fragments</strong> at least as large as the disk sector size.</p>
2020
<pre><code> +------------+------------+------------+------------+
2121
block | fragment 1 | fragment 2 | fragment 3 | fragment 4 |
2222
+------------+------------+------------+------------+</code></pre>
2323
<p>Files would occupy as many complete blocks as possible before populating at most one fragmented block.</p>
24-
<p>Data was also divided into <em>cylinder groups</em> where each cylinder group included a copy of the superblock, a list of inodes, a bitmap of available blocks (as opposed to a free list), some usage statistics, and finally data blocks. The file system took advantage of hardware specific information to place data at rotational offsets specific to the hardware so that files could be read with as little delay as possible. Care was also taken to allocate files contiguously, similar files in the same cylinder group, and all the inodes in a directory together. Moreover, if the amount of available space gets too low, then it becomes more and more difficult to allocate blocks efficiently. For example, it becomes hard to allocate the files of a block contiguously. Thus, the system always tries to keep ~10% of the disk free.</p>
24+
<p>Data was also divided into <strong>cylinder groups</strong> where each cylinder group included a copy of the superblock, a list of inodes, a bitmap of available blocks (as opposed to a free list), some usage statistics, and finally data blocks. The file system took advantage of hardware specific information to place data at rotational offsets specific to the hardware so that files could be read with as little delay as possible. Care was also taken to allocate files contiguously, similar files in the same cylinder group, and all the inodes in a directory together. Moreover, if the amount of available space gets too low, then it becomes more and more difficult to allocate blocks efficiently. For example, it becomes hard to allocate the files of a block contiguously. Thus, the system always tries to keep ~10% of the disk free.</p>
2525
<p>Allocation is also improved in the FFS. A top level global policy uses file system wide information to decide where to put new files. Then, a local policy places the blocks. Care must be taken to colocate blocks that are accessed together, but crowding a single cyclinder group can exhaust its resources.</p>
2626
<p>In addition to performance improvements, FFS also introduced</p>
2727
<ol style="list-style-type: decimal">

‎html/saltzer1984end.html

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,8 @@
88

99
<body>
1010
<div id="container">
11-
<h2 id="end-to-end-arguments-in-system-design-1984"><a href="TODO">End-to-End Arguments in System Design (1984)</a></h2>
12-
<p><strong>Summary.</strong> This paper presents the <em>end-to-end argument</em>:</p>
11+
<h1 id="end-to-end-arguments-in-system-design-1984"><a href="https://scholar.google.com/scholar?cluster=9463646641349983499">End-to-End Arguments in System Design (1984)</a></h1>
12+
<p>This paper presents the <strong>end-to-end argument</strong>:</p>
1313
<blockquote>
1414
<p>The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)</p>
1515
</blockquote>

‎html/stonebraker1987design.html

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -8,34 +8,34 @@
88

99
<body>
1010
<div id="container">
11-
<h2 id="the-design-of-the-postgres-storage-system-1987"><a href="TODO">The Design of the POSTGRES Storage System (1987)</a></h2>
12-
<p><strong>Summary.</strong> POSTGRES, the ancestor of PostgreSQL, employed a storage system with three interesting characteristics:</p>
11+
<h1 id="the-design-of-the-postgres-storage-system-1987"><a href="https://scholar.google.com/scholar?cluster=6675294870941893293">The Design of the POSTGRES Storage System (1987)</a></h1>
12+
<p>POSTGRES, the ancestor of PostgreSQL, employed a storage system with three interesting characteristics:</p>
1313
<ol style="list-style-type: decimal">
1414
<li>No write-ahead logging (WAL) was used. In fact, there was no recovery code at all.</li>
1515
<li>The entire database history was recorded and archived. Updates were converted to updates, and data could be queried arbitrarily far in the past.</li>
1616
<li>The system was designed as a collection of asynchronous processes, rather than a monolithic piece of code.</li>
1717
</ol>
18-
<p>Transactions were sequentially assigned 40-bit transaction identifiers (XID) starting from 0. Each operation in a transaction was sequentially assigned a command identifiers (CID). Together the XID and CID formed a 48 bit interaction identifier (IID). Each IID was also assigned a two-bit transaction status and all IIDs were stored in a transaction log with a most recent <em>tail</em> of uncommitted transactions and a <em>body</em> of completed transactions.</p>
18+
<p>Transactions were sequentially assigned 40-bit transaction identifiers (XID) starting from 0. Each operation in a transaction was sequentially assigned a command identifiers (CID). Together the XID and CID formed a 48 bit interaction identifier (IID). Each IID was also assigned a two-bit transaction status and all IIDs were stored in a transaction log with a most recent <strong>tail</strong> of uncommitted transactions and a <strong>body</strong> of completed transactions.</p>
1919
<p>Every tuple in a relation was annotated with</p>
2020
<ul>
2121
<li>a record id,</li>
2222
<li>a min XID, CID, and timestamp,</li>
2323
<li>a max XID, CID and timestamp, and</li>
2424
<li>a forward pointer.</li>
2525
</ul>
26-
<p>The min values were associated with the transaction that created the record, and the max values were associated with the transaction that updated the record. When a record was updated, a new tuple was allocated with the same record id but updated min values, max values, and forward pointers. The new tuples were stored as diffs; the original tuple was the <em>anchor point</em>; and the forward pointers chained together the anchor point with its diffs.</p>
26+
<p>The min values were associated with the transaction that created the record, and the max values were associated with the transaction that updated the record. When a record was updated, a new tuple was allocated with the same record id but updated min values, max values, and forward pointers. The new tuples were stored as diffs; the original tuple was the <strong>anchor point</strong>; and the forward pointers chained together the anchor point with its diffs.</p>
2727
<p>Data could be queried at a particular timestamp or in a range of timestamps. Moreover, the min and max values of the records could be extracted allowing for queries like this:</p>
2828
<pre><code>SELECT Employee.min_timestamp, Eployee.max_timestamp, Employee.id
2929
FROM Employee[1 day ago, now]
3030
WHERE Employee.Salary &gt; 10,000</code></pre>
3131
<p>The timestamp of a transaction was not assigned when the transaction began. Instead, the timestamps were maintained in a TIME relation, and the timestamps in the records were left empty and asynchronously filled in. Upon creation, relations could be annotated as</p>
3232
<ul>
33-
<li><em>no archive</em> in which case timestamps were never filled in,</li>
34-
<li><em>light archive</em> in which timestamps were read from a TIME relation, or</li>
35-
<li><em>heavy archive</em> in which timestamps were lazily copied from the TIME relation into the records.</li>
33+
<li><strong>no archive</strong> in which case timestamps were never filled in,</li>
34+
<li><strong>light archive</strong> in which timestamps were read from a TIME relation, or</li>
35+
<li><strong>heavy archive</strong> in which timestamps were lazily copied from the TIME relation into the records.</li>
3636
</ul>
3737
<p>POSTGRES allowed for any number of indexes. The type of index (e.g. B-tree) and the operations that the index efficiently supported were explicitly set by the user.</p>
38-
<p>A <em>vacuum cleaner</em> process would, by instruction of the user, vacuum records stored on disk to an archival storage (e.g. WORM device). The archived data was allowed to have a different set of indexes. The vacuum cleaning proceeded in three steps:</p>
38+
<p>A <strong>vacuum cleaner</strong> process would, by instruction of the user, vacuum records stored on disk to an archival storage (e.g. WORM device). The archived data was allowed to have a different set of indexes. The vacuum cleaning proceeded in three steps:</p>
3939
<ol style="list-style-type: decimal">
4040
<li>Data was archived and archive indexes were formed.</li>
4141
<li>Anchor points were updated in the database.</li>

0 commit comments

Comments
 (0)