PORT (Performance-Optimal Read-Only Transaction)
PORT stands for Performance-Optimal Read-Only Transactions
If 14-SNOW Theorem asked:
How can we minimize the latency of a distributed read-only transaction?
PORT asks a broader question:
How close can a transactional read get to the overall performance of an ordinary, non-transactional read?
This includes both:
- latency: how long one transaction takes
- throughput: how many transactions the system can process per second
A performance-optimal read-only transaction must have the NOC Properties
However, the NOCS Theorem claims that NOC cannot be combined with strict serializability.
Why SNOW is not enough
SNOW defines latency-optimal properties of a read-only transaction. However, latency-optimal doesn’t necessarily mean throughput-optimal.
The SNOW Insight emphasizes the main optimzation principles as follows:
Move coordination overhead from reads to writes
This may ensure N + O properties, but the added work may cause more consumption of CPU time, network bandwidth, and memory, which leads to throughput reduction.
For example, a read might complete in one non-blocking round while writes send many additional background messages. The read has excellent latency, but the extra messages may reduce total system throughput.
Therefore, PORT studies all coordination work required to support transactional reads, not just messages visible on the read’s critical path.
Consequently, it intends to answer:
Can read-only transactions have the lowest latency, highest throughput, and strong consistency simultaneously?
NOC Properties: The Definition of Performance-Optimality
N: Non-blocking
Latency benefit
- The transaction does not spend time waiting
Throughput benefit
- Blocking can cause:
- thread suspension
- context switch
- CPU underutilization
- lock-management overhead
O: One-round communication
PORT’s definition of (O) is stronger and more throughput-aware than the simplified SNOW notion:
- exactly one parallel round of on-path messages
- no retries
- no additional off-path messages
C: Constant metadata
Transactional reads use metadata to identify mutually consistent versions across shards.
Examples include:
- timestamps;
- transaction IDs;
- dependency lists;
- participating-server lists;
- lists of concurrent transactions.
PORT requires the metadata processed for each read request to have constant size.
This consumes more:
- CPU time for serialization and comparison;
- network bandwidth;
- memory;
- cache capacity.
Performance-optimal definition
A read-only transaction is performance-optimal if it provides:
N + O + C
This is intended to make transactional reads perform as closely as possible to ordinary simple reads.
NOCS Theorem
NOCS Theorem: No read-only transaction algorithm can simultaneously be non-blocking, use only one round with no auxiliary messages, use constant metadata, and provide strict serializability.
This is the performance counterpart to the SNOW theorem.
Proof of NOCS Impossibility
Stable and unstable regions
System history is conceptually divided into two regions:
- Stable region: contains sufficiently old writes whose ordering is completely resolved.
- Unstable region: contains recent and concurrent operations whose relative ordering has not been fully established.
older history newest activity
─────────────────────┬───────────────────────>
stable region │ unstable region
order finalized │ conflicts unresolved
Strict Serializability forces reads toward the unstable region
If write (W) completes before read (R) starts, then:
W < R
Therefore, R must see W, even if W is very recent.
The read cannot always choose a convenient old stable snapshot, because that could omit a write that completed before the read began.
This forces strictly serializable reads to interact with the unstable region.
NOCS versus SNOW
The two theorems answer related but different questions.
| Theorem | Impossible combination | Main concern |
|---|---|---|
| SNOW | (S+N+O+W) | Lowest read latency with strong transactions |
| NOCS | (N+O+C+S) | Best overall read performance with strict serializability |
| The important difference is: |
- SNOW includes (W), conflicting multi-object write transactions.
- NOCS replaces (W) with (C), constant metadata.
Therefore NOCS establishes a stronger performance limitation:
Even if the database supports only simple writes—not distributed write transactions—strict serializability still cannot be combined with fully performance-optimal (NOC) reads.
It may be possible to have (N+O+S), but only by using metadata that grows with the system or workload.
NOCS is tight
Like SNOW, NOCS is tight: every combination of three properties is achievable.
The important new design target is:
N + O + C + strongest consistency possible below S
That target leads to PORT.
Design Space After PORT and SNOW
POS= process-ordered serializability;S= strict serializability;+W= support for conflicting transactional writes.