[
https://issues.apache.org/jira/browse/IGNITE-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16284:
-----------------------------------------
Epic Link: IGNITE-15081
> 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)
