Shared publicly  - 
 
Here are my slides from NYC GTUG meeting last night. It's similar to the talk I'll be giving in Mexico City, though I might spend more time going into detail then.

Lots of thanks to +Bob Hancock for playing along when I asked an audience member for a reason why I would be giving them money (example of eventual vs. strong consistency).

Yes, I know I've totally hand-waved over the Paxos stuff, and there are some inaccuracies in the graphics I need to fix, but the message is more or less the same.

Now it's time to hide before +Alex Feinberg chides me for spreading lies.
6
1
Brandon Donnelson's profile photoSergio Félix's profile photoIkai Lan's profile photoKazunori Sato's profile photo
10 comments
 
Thanks for the WebFilings mention! +1
 
Dude, thanks for building something worth mentioning
 
It was an excellent presentation. Not only was it lively and informative, but it generated a great deal of discussion among the members both during and after the meeting. Come back anytime!
 
Today someone called me a radical developer for suggesting a non relational database: "in this company we use real tools" sigh
 
I missed a really important point in these slides that I'll add before Mexico City about journaling and what it is. Basically, when you do a write to high replication datastore, the write "succeeds" and the API call returns once your write has been inserted into the journals of a majority of data centers/datastore instances. A journal is like a todo list of writes you need to do. It's similar to MySQL's binary log, though that's not how replication works in HRD. For instance, suppose you are updating an entity. That update goes into a journal and not directly into the datastore. When the datastore gets around to applying the journal - that is, doing the actual entity update as well as any secondary entities that need updating (indexes, composite indexes), this is when the "version" of the data is updated.

In slide 30/34, when I say "catch up the datastore", what this means is "block until the local datastore instance has applied all writes up to the newest version we expect to have". The reason this isn't slower is because if a catch up operation is required, we also send RPCs to remote datastore instances and return to the user the first data that's returned to us.
Add a comment...