# Redesigning Storage Systems for Future Workloads Hardware and Performance Requirements

### Redesigning Storage Systems&#x20;

* New: applications, hardware, performance requirements&#x20;
* **Applications**&#x20;
  * Billions of impressions collected by most web services for analytics&#x20;
  * Past workloads: read mostly, rarely updated&#x20;
  * Future workloads: example of IoTs&#x20;
    * Mixed workload&#x20;
    * Read / write ratio&#x20;
    * Reads: read large volumes of sensor, data for control and analytics&#x20;
    * Writes: new sensor data, continuously recorded&#x20;
  * We produce huge amount of data: grow exponentially&#x20;
  * Need to figure out a way to serve data in persistent storage&#x20;
  * Nature of the data is quite diverse: unstructured data&#x20;
    * KVs: key to big, unstructured data&#x20;
    * API: put(), get(), and scan()&#x20;
    * Example: RocksDB, redis, cassandra&#x20;
* **Hardware**&#x20;
  * Landscape: RAM, HDD, Tape (archive)&#x20;
  * Now: NVM, SSD between layer of RAM and HDD; and Glass, DNA, ...
  * Focus: SSD&#x20;
    * New SSDs are much faster&#x20;
    * Random accesses almost as fast as sequential accesses&#x20;
* **Performance requirements**&#x20;
  * Throughput&#x20;
    * reads & writes / second
    * higher is better
    * should be steady&#x20;
  * Latency&#x20;
    * time it takes to read or write
    * lower is better
    * tail latency (e.g., 99th percentile)&#x20;
      * High tail latency in KVs --> unpredictable performance. Difficult to provide QoS guarantees&#x20;

#### Contributions&#x20;

* Applications: cluster metadata management. Mixed write-intensive workload.&#x20;
  * TRIAD \[ATC '17]: decrease maintenance I/O to increase client throughput.&#x20;
    * HyperLogLog-driven compaction
    * WAL repurposing
    * Hot/Cold key separation&#x20;
* Hardware: new servers with ample memory sizes (100s GB)
  * FloDB: Scale KVs with memory size&#x20;
    * New 2-level data structure&#x20;
    * Mostly O(1) insert&#x20;
    * Concurrent reads and updates&#x20;
* Performance requirements&#x20;
  * Need low, steady tail latency. No latency spikes.
  * SILK: KVs I/O scheduling&#x20;
    * Opportunistic I/O bandwidth allocation for KV maintenance ops&#x20;
    * Prioritize client work&#x20;
    * No tail latency spikes&#x20;
* KVell: fast KV for NVMe SSDs (SOSP 19')&#x20;
  * RocksDB: low, unstable throughput. CPU-bound on Fast SSDs.&#x20;
    * Can't saturate the I/O bandwidth that comes with the device&#x20;
  * Existing KVs internals&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sliu583.gitbook.io/blog/specific-work/seminar-and-talk/fall-21-reading-list/redesigning-storage-systems-for-future-workloads-hardware-and-performance-requirements.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
