Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Spanner: Google’s Globally -Distributed Database

No description
by

Mehak Mehta

on 2 October 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Spanner: Google’s Globally -Distributed Database

Spanner: Google’s Globally-Distributed Database
A Critical Review

Being Critical
Uses two phase commit in Paxos groups which can be time consuming in movement of directory operation.
Design depends upon the application programmers to deal with performance bottlenecks
High amount of redundancy in data since the value is stored as key-value pair but not as tables

TrueTime API Evaluation
Lockfree reads can be implemented without TrueTime using data version
Being Critical
Mechanism is tightly coupled with hardware clocks (GPS and atomic). So very less chances of adaption outside Google or by any open source community.
Latency of Spanner is quiet less than other NoSQL solutions like BigTable i.e. for 50 participant servers the latency of Spanner is approx 43ms as compared to approx 5-7ms mainly due to semi reational structure and TrueTime overhead.
Conclusion
Design of Spanner shows that some clear choices have been made in terms of trade offs like NoSQL Vs NewSQL, message over head vs consistency, latency vs syncronization etc.
Primary purpose of the system was to cater to Google's database needs of today which clearly does not align to open source community.
TrueTime API is the first practically tested synchronization strategy of any system at a global scale.
There is a long way to go to synchronize servers in a global distributed system.
How good is TrueTime
Introduction
A new entrant in NewSQL class of databases
Motivated by the need to replace Bigtable and its successor Megastore systems, in order to port them onto new system like Spanner
Does not use GFS instead uses sharding of the key space over Paxos cohorts
Spanner is highly valiant effort to bring synchronization or consistency (external/internal) to a global distributed database systems
TrueTime brings in a lot of overhead to the the system. The latency goes quite high (>150 ms) due to expensive write operations and time keeping operations
Snapshot read can get a consistent cut read of all the variables requested at that given time. It requires capturing and recording causality relationships across many different versions of the variables involved

Counter Approach:
Could explore the possibility of using logical causality relations
Bigtabe Latency
Spanner Latency
Full transcript