[
https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-16284:
-------------------------------------
Description:
Let's read, understand and discuss the following spanner specific docs
[https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf]
[https://blog.the-pans.com/notes-on-the-spanner/]
[https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf]
Let's read, understand and discuss the following spanner specific docs
[https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf]
[https://blog.the-pans.com/notes-on-the-spanner/]
[https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf]
h2. Research results
Spanner is Google’s scalable, multi-version, globally-distributed, and
synchronously-replicated database. From the transaction's point of view Spanner
is a system that guarantees external consistency and provides lock-free
read-only and pessimistic read-write transactions. It worth mentioning that
Spanner widely uses TrueTime with corresponding commit Wait logic. Bellow
there’s a detail explanation of how read-write and read-only transactions are
work in Spanner.
h4. Read-Write Transactions
For transactions that involve multiple Paxos groups, Spanner uses the two-phase
commit protocol with long-held locks to guarantee that read-write transactions
provide external consistency.
The client buffers the write operations that occur in a transaction until it is
ready to commit. At commit time, it chooses a leader of one of the Paxos groups
to act as the transaction coordinator and sends a prepare message with the
buffered writes and the identity of the coordinator to the leaders of the other
participant groups. Each participant leader then acquires writes locks and
performs the specified operations before responding to the coordinator with the
status of its mini-transaction.
The client also issues reads within read-write transactions to the leader
replica of the relevant group, which acquires read locks and reads the most
recent data. One of the other limitations of two-phase commit highlighted in
the previous lecture is its proneness to deadlocks. Spanner uses the wound-wait
locking rule to avoid deadlocks when reading data.
!Spanner (2).png|width=666,height=611!
h4. Read-Only Transactions
Spanner makes two optimizations to achieve greater performance in read-only
transactions:
# It does not hold locks or use the two-phase commit protocol to serve
requests.
# It allows reads from replicas.
In order to guarantee external consistency through snapshot isolation Spanner
keeps multiple versions of an object—each version labelled with a timestamp
representing what transaction produced it. Snapshot isolation enforces that a
read-only transaction will only see the versions of a record that have a
timestamp less than its assigned transaction timestamp i.e. a snapshot of what
the record was before the transaction started. To prevent reading stale data
from non-majority replicas, each replica maintains a _safe time_ property,
which is the maximum timestamp at which it is up to date. Paxos leaders send
writes to followers in timestamp order and the safe time represents the most
recent timestamp a replica has seen.
!Spanner (4).png|width=676,height=520!
was:
Let's read, understand and discuss the following spanner specific docs
https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
https://blog.the-pans.com/notes-on-the-spanner/
[https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf]
> In-depth CC related spanner research
> ------------------------------------
>
> Key: IGNITE-16284
> URL: https://issues.apache.org/jira/browse/IGNITE-16284
> Project: Ignite
> Issue Type: Task
> Reporter: Alexander Lapin
> Assignee: Alexander Lapin
> Priority: Major
> Labels: ignite-3
> Attachments: Spanner (2).png, Spanner (4).png
>
>
> Let's read, understand and discuss the following spanner specific docs
> [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf]
> [https://blog.the-pans.com/notes-on-the-spanner/]
> [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf]
> Let's read, understand and discuss the following spanner specific docs
> [https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf]
> [https://blog.the-pans.com/notes-on-the-spanner/]
> [https://www.microsoft.com/en-us/research/wp-content/uploads/2013/09/DC-col51-Sep13-1.pdf]
> h2. Research results
> Spanner is Google’s scalable, multi-version, globally-distributed, and
> synchronously-replicated database. From the transaction's point of view
> Spanner is a system that guarantees external consistency and provides
> lock-free read-only and pessimistic read-write transactions. It worth
> mentioning that Spanner widely uses TrueTime with corresponding commit Wait
> logic. Bellow there’s a detail explanation of how read-write and read-only
> transactions are work in Spanner.
> h4. Read-Write Transactions
> For transactions that involve multiple Paxos groups, Spanner uses the
> two-phase commit protocol with long-held locks to guarantee that read-write
> transactions provide external consistency.
> The client buffers the write operations that occur in a transaction until it
> is ready to commit. At commit time, it chooses a leader of one of the Paxos
> groups to act as the transaction coordinator and sends a prepare message with
> the buffered writes and the identity of the coordinator to the leaders of the
> other participant groups. Each participant leader then acquires writes locks
> and performs the specified operations before responding to the coordinator
> with the status of its mini-transaction.
> The client also issues reads within read-write transactions to the leader
> replica of the relevant group, which acquires read locks and reads the most
> recent data. One of the other limitations of two-phase commit highlighted in
> the previous lecture is its proneness to deadlocks. Spanner uses the
> wound-wait locking rule to avoid deadlocks when reading data.
>
> !Spanner (2).png|width=666,height=611!
> h4. Read-Only Transactions
> Spanner makes two optimizations to achieve greater performance in read-only
> transactions:
> # It does not hold locks or use the two-phase commit protocol to serve
> requests.
> # It allows reads from replicas.
> In order to guarantee external consistency through snapshot isolation Spanner
> keeps multiple versions of an object—each version labelled with a timestamp
> representing what transaction produced it. Snapshot isolation enforces that a
> read-only transaction will only see the versions of a record that have a
> timestamp less than its assigned transaction timestamp i.e. a snapshot of
> what the record was before the transaction started. To prevent reading stale
> data from non-majority replicas, each replica maintains a _safe time_
> property, which is the maximum timestamp at which it is up to date. Paxos
> leaders send writes to followers in timestamp order and the safe time
> represents the most recent timestamp a replica has seen.
>
> !Spanner (4).png|width=676,height=520!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
