What are the challenges?

Before TAO, cache-aside pattern is used

The social graph is stored in MySQL and cached in Memcached

Three existing problems:

  1. Updating the side list of the social graph in Memcached is inefficient. Instead of adding an edge to the end of the list, you update the entire list.
  2. The logic for clients to manage the cache is complex
  3. It is difficult to maintain consistency between database reads and writes

To solve these problems, we have three goals:

  • Graph storage that is efficient in the face of large-scale data
  • Optimize read operations (read/write ratio is 500:1)
    • Reduces the read operation duration
    • Improved availability of read operations (final consistency)
  • Complete write operations in a timely manner (write before read)

The data model

  • Objects with unique IDS (for example, users, addresses, comments)
  • Association between two ids (e.g., tagged, liked, published)
  • Both data models have key-value data and time-dependent data

Solution: TAO

  1. Speed up read operations and efficiently process large-scale reads

    • Cache graphs specifically
    • Add a layer of caching between the stateless server layer and the database layer (see Business split)
    • Split the data center (see Split by data)

  2. Complete the write operation in time

    • Write-through cache
    • Use the follower/leader cache to solve the scare problem
    • Asynchronous replication

  3. Improve the availability of read operations

    • If a reading error occurs, read from somewhere else readable

TAO architecture

  • MySQL Database → Durability
  • Leader cache → Coordinate writes for each object
  • Follower cache → used for reading rather than writing. Move all write operations to the leader cache.

Fault tolerance of read operations

This article was originally published by Silicon Valley’s IO