Request Flows in SILT
Explore the detailed request handling in SILT's key-value store design. Understand how PUT and DELETE requests are processed through write-friendly, intermediary, and memory-efficient stores, and how GET requests retrieve the latest values by querying stores in sequence. This lesson clarifies the role of partial-key cuckoo hashing, log maintenance, and merging strategies to optimize resource use, latency, and scalability in distributed storage systems.
We'll cover the following...
In this lesson, we will look at how our consolidated store serves the requests. Every request will have a key associated with it. For example, PUT(key, value), DELETE(key), and GET(key).
PUT and DELETE requests
Our write-friendly store receives all new PUT and DELETE requests. Every request triggers two tasks—one in memory and the other in storage.
In storage, the write-friendly store has sequentially maintained a log to which it appends our request. The write-friendly store saves the offset—its position in the log—for all incoming requests.
In memory, the write-friendly store starts looking for a candidate bucket using partial-key cuckoo hashing on the key for the request, and as soon as it finds a candidate bucket, it stores the offset in that bucket.
Both PUT and DELETE requests remain stored in this state until a new request:
Exhausts the number of allowed displacements for partial-key cuckoo hashing to find a candidate ...