Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

← Datastore Commit Process - Developing Scalable Apps with Java

Get Embed Code
6 Languages

Showing Revision 5 created 05/25/2016 by Udacity Robot.

  1. We will now turn our attention to
  2. the Datastore Commit Process. This process describes
  3. to consistency rules for storing data. Datastore
  4. has two consistency models, Eventual Consistency and Strong
  5. Consistency. Let's look at these in more
  6. detail. In this use case diagram we have
  7. three things. Your Application, the datastore API
  8. that your application calls and the datastore backend,
  9. which performs work that your application is not involved
  10. in. When your application wants to store an entity,
  11. it performs a put operation towards the datastore API.
  12. The datastore backend then writes this entity to a
  13. log. When the write is completed, control is turned
  14. back to your application. At this point the Datastore
  15. backend has promised to write the entity to Datastore.
  16. Observe however that the entity has not been written yet.
  17. It has only been written to a log.
  18. The Datastore backend now goes through to work to
  19. make everything consistent. It does this by using the
  20. login information to update the entity storage and then
  21. it updates all the indexes. So observe that
  22. when control is returned to your application, datastore may
  23. not have done all the work required for the
  24. data to be updated. Is this good or bad?
  25. Well it's good, because this means that you have
  26. less latency in your application. But the question now
  27. becomes, what happens if a query is issued that
  28. would retrieve the data your application just requested to
  29. put into data store? Well, with eventual consistency the
  30. data store API will not wait for this to
  31. happen. So it only considers matching data that already
  32. exists. That is data, that was already in data store
  33. prior to your put call. And then it
  34. returns that result. That's why it's called eventual
  35. consistency. Queries will be eventually consistent with put
  36. operations performed to what's the data store API.