Pith. sign in

REVIEW 3 major objections 4 minor 50 references

FOCUS: Boosting Schema-aware Access for KV Stores via Hierarchical Data Management

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read FOCUS claims that mapping structured records to flat key-value pairs is the real bottleneck on non-volatile memory, and that hierarchical pairs with field-level access remove it.

desk verdict A genuinely new schema-aware KV engine with a solid design, but the evaluation omits the hybrid-mapping baseline that its own model identifies as the strongest flat competitor—so the headline performance gains are not yet proven. read the letter →

arxiv 2505.24221 v1 pith:RT53DPIA submitted 2025-05-30 cs.DB

Zhen Liu , Wenzhe Zhu , Yongkun Li , Yinlong Xu This is my paper
classification cs.DB
keywords hierarchicalKVmodelschema-awareaccessnon-volatilememorypersistentloglog-structuredstoreI/OamplificationsplittingNewSQLdatabases
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

NewSQL databases put table rows into key-value stores by either packing a whole row into one value or scattering each attribute into its own key-value pair. FOCUS argues that both mappings fight the nature of non-volatile memory: the first forces whole-row I/O for a single-attribute update, while the second splits a full-row read into many tiny I/Os. The paper's central claim is that a hierarchical KV model—one pair per row whose fields can be read and updated independently—removes both penalties, and that a log-structured engine can deliver this without sacrificing sequential writes. If the claim holds, applications on NVM-backed KV stores can serve partial SQL access several times faster while keeping the familiar KV interface.

What carries the argument

The load-bearing machinery is a two-layer persistent log (PLog): CLog appends complete KV pairs, and DLog appends delta updates for individual fields. A mechanism called swim (sequential write ahead of in-place merge) writes partial updates out of place, chains them to the prior version through an atomic compare-and-swap on the index, and asynchronously merges them into the complete record, using a cacheline-aware flush to batch tiny NVM writes. A restore point reconstructs the full row after about five chained delta updates, bounding the cost of reads. A schema-aware cache (SeaCache) absorbs the inevitable small reads on hot fields, is fused with the global index so misses pay no extra probe, and separates cache lifetime by schema so one cold schema cannot crowd out a hot one.

What would settle it

Run FOCUS against a hybrid mapping whose attribute groups are chosen by profiling the workload's true co-access pattern: if FOCUS does not beat that tuned static partition on a TPC-C-style mixed workload, the premise that no static grouping can match dynamic access is undercut. A second check is a uniform-access workload (Zipf 0): with no skew, SeaCache's hit ratio falls below the 0.5 admission threshold and cache management becomes overhead, so FOCUS's throughput should slide toward or below the baselines, quantifying how much of the reported 2.1–5.9x depends on skew rather than on the hierarchical layout itself.

Watch

Extended reading notes

Core claim

The paper claims that the performance ceiling for NVM-backed KV stores comes less from the storage engine than from the semantic mismatch between structured records and flat KV pairs. It analyzes the two mappings used by production NewSQL systems—consolidated mapping, which stores one KV pair per record, and scattered mapping, which stores one KV pair per attribute—and derives that each is ideal for exactly one access pattern: full access for consolidated, partial access for scattered. Because real workloads mix full and partial operations, no static partition of attributes into KV pairs can avoid either I/O amplification or I/O splitting. FOCUS's discovery is that decomposing a KV pair into independently addressable fields, aligned with the record's schema, lets one layout serve both patterns, and that the accompanying mechanisms for separating complete and delta writes, bounding update chains, and caching hot fields make the layout practical at NVM latencies.

Load-bearing premise

The design assumes that production workloads mix full and partial row access in a pattern that changes over time, and that traffic is skewed toward a few hot rows; if accesses are stable enough for a fixed attribute grouping to match them, or uniform enough that the cache rarely pays off, FOCUS's advantage over a well-tuned static design shrinks or disappears.

Editorial extensions

If this is right

  • Field-level reads and updates eliminate the I/O amplification and I/O splitting penalties the paper measures at 1.7–3.6x and 3.3–4.8x for the flat mappings, respectively.
  • The CLog/DLog split keeps writes sequential while swim and the restore point bound read cost, so mixed read–update workloads (YCSB A and F) see the largest gains, 2.2x and 2.6x over the best flat-mapping baseline.
  • Schema-separated cache admission and eviction prevent cache congestion, so skewed access patterns (Zipf 0.99) keep hitting memory; the paper reports 49.6% and 49.1% throughput gains from the eviction policy alone when the hot spot moves.
  • Because the default field set is empty, existing full-access KV callers work unchanged, giving backward compatibility with the plain KV interface.
  • The advantage persists at large value sizes: with 16 KB values, FOCUS still reports 7.1x over the baselines, indicating the benefit is not limited to small records.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The hierarchical model can be read as a dynamic generalization of today's hybrid column-family mappings: FOCUS removes the requirement that the user choose the attribute grouping at schema-creation time, so a workload profiler could tune grouping, caching, and merge policy online—something the paper does not claim.
  • The same field-level addressing would plausibly benefit non-SQL workloads such as document or graph stores that currently rewrite whole values to change one attribute; the paper evaluates only the SQL adapter path.
  • A testable extension is the CLog/DLog split on SSD-backed stores, where byte-addressable field reads are unavailable; the same layout could degenerate into scattered small reads on block devices, so the design's benefit may be specific to NVM.
  • The 0.5 hit-ratio admission threshold is calibrated against the access cost of the Optane testbed; on faster or slower media the crossover between cached and uncached reads moves, so the threshold likely needs to become media-dependent to preserve the gain.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper argues that NewSQL databases integrating NVM-backed KV stores suffer from I/O amplification and I/O splitting because they use flat data mapping, in which structured records are either consolidated into one KV pair or scattered across many. FOCUS is a from-scratch log-structured KV store that introduces a hierarchical KV model: each record maps to a KV pair whose fields can be accessed independently, with schema metadata managed in a schema-friendly layout, full updates and delta updates separated into CLog and DLog, an asynchronous sequential-write-ahead-of-in-place-merge (swim) mechanism, and a schema-aware cache (SeaCache) integrated with the index. The evaluation uses YCSB workloads and custom microbenchmarks, reporting 2.1-5.9x throughput improvements over Pmem-RocksDB and ListDB under consolidated and scattered mappings.

Significance. If the performance claims are supported, FOCUS would be a meaningful demonstration that exposing schema information to a KV storage engine can reduce NVM I/O amplification and splitting, and the design contains several credible components: a clean hierarchical KV API, a two-layer persistent log separating full and delta updates, a cacheline-aware asynchronous merge, and a schema-aware admission/eviction cache. The paper also includes component ablations and parameter-sensitivity studies. The main weakness is that the evaluation does not test the central claim against the full space of flat data mappings, and several parameters appear to be tuned on the evaluation workloads themselves. The paper does not provide a reproducibility artifact or error bars, so the magnitude of the reported gains is not yet firmly established.

major comments (3)
  1. [§VI-B and §III-A] The central claim that FOCUS eliminates the I/O amplification and I/O splitting incurred by flat data mapping is not tested against hybrid mapping, which §III-A explicitly includes in flat data mapping and describes as spanning the spectrum between consolidated and scattered mappings. The baselines in §VI-A are only Pmem-RocksDB and ListDB under consolidated and scattered mappings, and the YCSB workloads in Table II use fixed operation ratios rather than the volatile, dynamic co-access patterns that §III-B uses to motivate hierarchical management. A tuned hybrid mapping could approximate the static workload mix and may close much of the reported 2.1-5.9x gap. Please add a hybrid-mapping baseline, or use workloads with shifting co-access patterns, or explicitly re-scope the claim to comparisons against the consolidated and scattered extremes.
  2. [§VI-A and §VI-D] Several cache parameters appear to be selected using the same workloads that are later reported as the main results, creating a risk of overfitting. Section VI-A sets the hit threshold to 0.5 and sets the RW eviction parameter according to runtime statistics, while §VI-D justifies hit threshold = 0.5 from the YCSB-C sensitivity curve in Figure 16(a) and derives an optimal RW table from similar experiments in Figure 16(b). Please report repeated runs with variance, select parameters on held-out workloads or with a validation split, and show how sensitive the headline YCSB throughput numbers in Figure 9 are to the chosen hit threshold and RW values.
  3. [§VI-C, Figure 12(b)] The cacheline-aware merge evaluation contains an internal inconsistency. The text states that at an update ratio of 1/8 the impact of cacheline-aware merge is minimal because partial updates touch only one field, but then states that at an update ratio of 1/8 the merge improves performance by 13.6x compared to non-optimized updates. Figure 12(b) also labels the y-axis as throughput in MB/s while the text reports a 13.6x ratio. Please correct the contradiction, clarify which update ratio the 13.6x figure refers to, and add error bars; as written, this breakdown does not support the claimed benefit.
minor comments (4)
  1. [§VI-A] The text says "We evalute three state-of-the-art key-value stores" but only Pmem-RocksDB and ListDB are listed; §VI-B then repeatedly refers to "the best of six baselines," although the described configuration yields four baselines (Pmem-RocksDB and ListDB, each with consolidated and scattered mappings). Please correct the counts.
  2. [§V-C] The eviction lifetime formula "Lifetime_i = 2−N × H_i × (1−RO_i) × RW_i" is ambiguous: clarify whether 2−N is an exponent, define the units of N, and state the range of RW_i.
  3. [Figures 10 and 11] The normalized throughput and latency figures are difficult to interpret because most absolute values are omitted and the legends/axis labels are unclear, especially in Figure 10(b). Please provide a table of absolute numbers or annotate each bar clearly.
  4. [Throughout] There are numerous typos and grammatical errors, including "mechenaism," "circuvmenting," "apple-to-apple," and "We evalute." A careful proofreading pass is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: FOCUS's throughput claims are direct empirical measurements against independent baselines; no derivation reduces to its inputs.

full rationale

We found no significant circularity. FOCUS's central claim—that hierarchical data management and schema-aware access improve throughput by 2.1–5.9x over Pmem-RocksDB and ListDB under YCSB SQL workloads (Abstract, §VI-B)—is an empirical benchmark result, not a derivation. The system was implemented from scratch (§VI-A) and evaluated against external, independent baselines using two standard flat mappings; the claimed speedups are measured, not implied by construction. The §III-B motivation labels the 'ideal' latency as 'the latency of the other mapping,' but this is a comparison between the two flat-mapping extremes for a given access pattern (consolidated vs. scattered), not an equation that makes the later throughput results true by definition. The cache parameters (hit_threshold = 0.5 and RW) are tuned using the same experimental workloads in §VI-A and §VI-D; this is a legitimate generality and overfitting concern for the evaluation, but it is not the paper presenting a fitted parameter as an independent prediction, and it does not define the main result. The only self-citations ([33] for Zipf skew and [38] for NVM cache-miss overhead) are incidental and not load-bearing; no uniqueness theorem is imported, and no known result is renamed as a first-principles derivation. The absence of a hybrid-mapping baseline weakens the breadth of the flat-mapping comparison, but that is a benchmarking limitation, not a circularity. The paper is therefore self-contained against external benchmarks, and no circular step can be exhibited with a specific reduction.

Assumptions & free parameters 6 free parameters · 6 assumptions · 0 invented entities

The central claim depends on hardware behavior and workload assumptions, and the system has several tunable parameters that are fitted in the paper's experiments. No new natural entities are posited; the design components are implemented and benchmarked, so the invented-entities list is empty.

free parameters (6)
  • hit_threshold = 0.5
    SeaCache admission threshold; set after sensitivity analysis in §VI-D where performance with and without SeaCache intersect at hit ratio 0.5.
  • RW retention window table = schema-dependent optimal config
    Eviction lifetime parameter table tuned against hit ratio in §VI-D and continuously updated at runtime to maximize performance.
  • restore_point_threshold = 5
    Number of consecutive partial updates before a full rewrite is forced; set by hand in §V-B to balance read and write performance.
  • cache eviction target = 80%
    Eviction halts when page usage falls below 80%; default setting in §V-C.
  • cache_size = 500 MB
    DRAM cache size matched to Pmem-RocksDB and ListDB recommended configuration in §VI-A.
  • zipf_skew = 0.99
    Skew parameter for microbenchmark workloads to stress SeaCache; taken from prior work [33] and used in §VI-A.
assumptions (6)
  • domain assumption Non-volatile memory requires cache-line flushes for persistence; sequential writes outperform random writes; byte-addressability enables fine-grained access.
    Core hardware premise of the paper, cited from [20,26,28,44] and not re-validated in this work.
  • domain assumption Production NewSQL workloads mix full and partial accesses in a dynamic pattern that no static attribute partition can match.
    Motivation for hierarchical data management in §III-B; asserted from prior workload studies [10,12], not measured here.
  • domain assumption Consolidated, scattered, and hybrid mappings cover all possible static partitions of attributes; optimal static partition requires perfect knowledge of co-access patterns.
    Modeling assumption in §III-A; the impossibility argument relies on this definition of the mapping space.
  • domain assumption CAS on the index pointer, combined with append-only writes, provides consistent concurrent updates without locks.
    Correctness assumption in §V-B for the update protocol; no formal proof or crash test is provided.
  • domain assumption Cache-line aligned flushes and clflush/mfence are sufficient for crash consistency of the log and merge operations.
    Persistence guarantees rely on hardware semantics; the paper does not test power-fail recovery.
  • domain assumption The two-layer log (CLog/DLog) with asynchronous merge will not produce unbounded read amplification because restore points cap chain length.
    Design assumption in §V-B; threshold 5 is a free parameter, and worst-case behavior is not analyzed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FOCUS: Boosting Schema-aware Access for KV Stores via Hierarchical Data Management." pith.science (2026). https://pith.science/paper/RT53DPIA

@misc{pith2026250524221,
  author       = {Pith},
  title        = {Pith review of: FOCUS: Boosting Schema-aware Access for KV Stores via Hierarchical Data Management},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RT53DPIA}},
  note         = {Machine review of arXiv:2505.24221}
}
read the original abstract

Persistent key-value (KV) stores are critical infrastructure for data-intensive applications. Leveraging high-performance Non-Volatile Memory (NVM) to enhance KV stores has gained traction. However, previous work has primarily focused on optimizing KV stores themselves, without adequately addressing their integration into applications. Consequently, existing applications, represented by NewSQL databases, still resort to a flat mapping approach, which simply maps structured records into flat KV pairs to use KV stores. Such semantic mismatch may cause significant I/O amplification and I/O splitting under production workloads, harming the performance. To this end, we propose FOCUS, a log-structured KV store optimized for fine-grained hierarchical data organization and schema-aware access. FOCUS introduces a hierarchical KV model to provide native support for upper-layer structured data. We implemented FOCUS from scratch. Experiments show that FOCUS can increase throughput by 2.1-5.9x compared to mainstream NVM-backed KV stores under YCSB SQL workloads.

Figures

Figures reproduced from arXiv: 2505.24221 by the authors.

Figure 1
Figure 1. Flat data mapping strategies. the primary key is StuID, which is encoded into the key, thus do not need to be stored in the value. • Consolidated mapping: It encapsulates all attributes of a record into one KV pair, with the key encoded as ”ta￾ble id/primary key” (see [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Inefficiency of flat data mapping. we omit the primary key here. but requiring the user to fully understand the attribute co￾access pattern and decide the partitioning scheme accordingly. Theoretically, for an attribute set, the above mapping strate￾gies cover all possible partitions. Therefore, provided the attribute co-access pattern is identified and fixed, i.e., for any pair of attributes, whether they would be … view at source ↗
Figure 4
Figure 4. Hierarchical data management and data mapping. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (11 more)
Figure 5
Figure 5. Figure 5: FOCUS architecture. IV. OVERVIEW To solve the challenges listed above, we design the FOCUS, a log-structured KV store optimized for fine-grained hierar￾chical data organization coupled with schema-aware access. FOCUS functions as the stand-alone KV storage engine, offe…
Figure 6
Figure 6. Figure 6: Partial access optimized data layout. CLog Chunk 0 … 2 Append New Data 1 Find Chain Pointer by Read Index Example Operation: Update (Field1, Field2) Example Operation: Read a Full Row Non -volatile Memory (NVM) DRAM 1 Update Index 3 Find Chain Pointer by Read Index 3 C…
Figure 7
Figure 7. Figure 7: This diagram shows the workflow of partial reads and writes in [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: The data structure of SeaCache. be unacceptable in the context of NVM [38]. For the cache structure, SeaCache uses page lists to store multiple rows. The allocation and reclamation of the cache space are performed at the granularity of memory pages for low metadata ove…
Figure 9
Figure 9. Figure 9: YCSB performance. 0 2 4 Insert Read-F Scan-F Normalized Thpt Pmem-RocksDB (Sct) ListDB (Sct) Pmem-RocksDB (Con) ListDB (Con) FOCUS 118.8KOPS 183.6KOPS 6.0KOPS 0 2 4 Insert Read-F Scan-F Normalized Thpt 118.8KOPS 183.6KOPS 6.0KOPS (a) Full access performance 0 4 8 Inser…
Figure 10
Figure 10. Figure 10: Performance with full access. 0 2 4 Insert Read-F Scan-F Normalized Thpt Pmem-RocksDB (Sct) ListDB (Sct) Pmem-RocksDB (Con) ListDB (Con) FOCUS 118.8KOPS 183.6KOPS 6.0KOPS 0 2 4 6 8 Update Read-P Scan-P Normalized Thpt 102.1KOPS 135.2KOPS 1.7KOPS (a) Partial access per…
Figure 11
Figure 11. Figure 11: Performance with partial access. access distribution to squeeze the performance of SeaCache. We set the Zipf as 0.99 [33]. Baselines. We evalute three state-of-the-art key-value stores that are heavily optimized persistent memory: Pmem￾RocksDB [24], and ListDB [31]. A…
Figure 12
Figure 12. Figure 12: Performance analysis of update mechanism. [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]
Figure 13
Figure 13. Figure 13: Effectiveness analysis of SeaCache. improvement is primarily due to the joint optimization of delta update and swim merge designs, which are tailored for both read and partial update operations in FOCUS. Given that workloads A and F entail simultaneous reads and parti…
Figure 14
Figure 14. Figure 14: Effectiveness analysis of eviction policy. [PITH_FULL_IMAGE:figures/full_fig_p011_14.png]
Figure 15
Figure 15. Figure 15: Impact of multiple threads and value size. [PITH_FULL_IMAGE:figures/full_fig_p011_15.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

50 extracted references · 47 canonical work pages

  1. [1]

    File systems unfit as distributed storage backends: lessons from 10 years of ceph evolution,

    A. Aghayev, S. Weil, M. Kuchnik, M. Nelson, G. R. Ganger, and G. Amvrosiadis, “File systems unfit as distributed storage backends: lessons from 10 years of ceph evolution,” inProc. of ACM SOSP. ACM, Oct. 2019, pp. 353–369

    work page 2019

  2. [2]

    Resistive random access memory (reram) based on metal oxides,

    H. Akinaga and H. Shima, “Resistive random access memory (reram) based on metal oxides,”Proceedings of the IEEE, vol. 98, no. 12, pp. 2237–2251, Dec. 2010

    work page 2010

  3. [3]

    Dynamodb homepage,

    Amazon, “Dynamodb homepage,” https://aws.amazon. com/dynamodb/, 2012

    work page 2012

  4. [4]

    Oracle homepage,

    O. and/or its affiliates., “Oracle homepage,” https://www. oracle.com/database/, 1993

    work page 1993

  5. [5]

    Viper: an efficient hybrid pmem-dram key-value store,

    L. Benson, H. Makait, and T. Rabl, “Viper: an efficient hybrid pmem-dram key-value store,”Proc. of VLDB Endow., vol. 14, no. 9, pp. 1544–1556, May 2021

    work page 2021

  6. [6]

    Bonsaikv: Towards fast, scalable, and persistent key-value stores with tiered, heterogeneous memory system,

    M. Cai, J. Shen, Y . Yuan, Z. Qu, and B. Ye, “Bonsaikv: Towards fast, scalable, and persistent key-value stores with tiered, heterogeneous memory system,”Proc. VLDB Endow., vol. 17, no. 4, p. 726–739, mar 2024

    work page 2024

  7. [7]

    POLARDB Meets Computational Stor- age: Efficiently Support Analytical Workloads in Cloud- Native Relational Database,

    C. Cao, Y . Liu, Z. Cheng, N. Zheng, W. Li, W. Wu, L. Ouyang, P. Wang, Y . Wang, R. Kuan, Z. Liu, F. Zhu, and T. Zhang, “POLARDB Meets Computational Stor- age: Efficiently Support Analytical Workloads in Cloud- Native Relational Database,” inProc. of USENIX FAST, 2020

    work page 2020

  8. [8]

    Polardb-x: An elastic distributed re- lational database for cloud-native applications,

    W. Cao, F. Li, G. Huang, J. Lou, J. Zhao, D. He, M. Sun, Y . Zhang, S. Wang, X. Wu, H. Liao, Z. Chen, X. Fang, M. Chen, C. Liang, Y . Luo, H. Wang, S. Wang, Z. Ma, X. Yang, X. Peng, Y . Ruan, Y . Wang, J. Zhou, J. Wang, Q. Hu, and J. Kang, “Polardb-x: An elastic distributed re- lational database for cloud-native applications,” inProc. of IEEE ICDE. IEEE, ...

    work page 2022

Show all 50 references
  1. [9]

    Flatstore: An efficient log-structured key-value storage engine for persistent memory,

    Y . Chen, Y . Lu, F. Yang, Q. Wang, Y . Wang, and J. Shu, “Flatstore: An efficient log-structured key-value storage engine for persistent memory,” inProc. of ACM ASPLOS. ACM, Mar. 2020, pp. 1077–1091

    2020

  2. [10]

    Benchmarking Cloud Serving Systems with YCSB,

    B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, “Benchmarking Cloud Serving Systems with YCSB,” inProc. of ACM SoCC. ACM, Jun. 2010, p. 143–154

    2010

  3. [11]

    Spanner: Google’s globally dis- tributed database,

    J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschildet al., “Spanner: Google’s globally dis- tributed database,”Proc. of ACM TOCS, vol. 31, no. 3, pp. 1–22, Aug. 2013

    2013

  4. [12]

    TPC-C standard specification revision 5.11,

    T. P. P. Council., “TPC-C standard specification revision 5.11,” https://www.tpc.org/tpcc/, 2010

    2010

  5. [13]

    Hardware-supported remote persistence for distributed persistent memory,

    Z. Duan, H. Lu, H. Liu, X. Liao, H. Jin, Y . Zhang, and S. Wu, “Hardware-supported remote persistence for distributed persistent memory,” inProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’21. New York, NY ,...

    2021

  6. [14]

    Data tiering in heterogeneous memory systems,

    S. R. Dulloor, A. Roy, Z. Zhao, N. Sundaram, N. Satish, R. Sankaran, J. Jackson, and K. Schwan, “Data tiering in heterogeneous memory systems,” inProceedings of the Eleventh European Conference on Computer Systems, ser. EuroSys ’16. New York, NY , USA: Association for Computin...

    2016

  7. [15]

    RocksDB homepage,

    Facebook, “RocksDB homepage,” http://rocksdb.org/, 2013

    2013

  8. [16]

    Myrocks homepage,

    Facebook, “Myrocks homepage,” https://myrocks.io/, 2016

    2016

  9. [17]

    Hbase homepage,

    A. S. Foundation., “Hbase homepage,” https://hbase. apache.org/, 2008

    2008

  10. [18]

    Nram: a disruptive carbon-nanotube resistance-change memory,

    D. C. Gilmer, T. Rueckes, and L. Cleveland, “Nram: a disruptive carbon-nanotube resistance-change memory,” Nanotechnology, vol. 29, no. 13, p. 134003, Apr. 2018

    2018

  11. [19]

    Bigtable homepage,

    Google, “Bigtable homepage,” https://cloud.google.com/ bigtable/, 2015

    2015

  12. [20]

    Data structure primitives on persistent memory: an evaluation,

    P. G ¨otze, A. K. Tharanatha, and K.-U. Sattler, “Data structure primitives on persistent memory: an evaluation,” ser. DaMoN ’20. New York, NY , USA: Association for Computing Machinery, 2020. [Online]. Available: https://doi.org/10.1145/3399666.3399900

    2020

  13. [21]

    Plat- form storage performance with 3d xpoint technology,

    F. T. Hady, A. Foong, B. Veal, and D. Williams, “Plat- form storage performance with 3d xpoint technology,” Proceedings of the IEEE, vol. 105, no. 9, pp. 1822–1833, Aug. 2017

    2017

  14. [22]

    Anal- ysis of HDFS under HBase: A Facebook Messages Case Study,

    T. Harter, D. Borthakur, S. Dong, A. S. Aiyer, L. Tang, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “Anal- ysis of HDFS under HBase: A Facebook Messages Case Study,” inProc. of USENIX FAST. USENIX Association, Feb. 2014, pp. 199–212

    2014

  15. [23]

    Tidb: a raft-based htap database,

    D. Huang, Q. Liu, Q. Cui, Z. Fang, X. Ma, F. Xu, L. Shen, L. Tang, Y . Zhou, M. Huanget al., “Tidb: a raft-based htap database,”Proc. of VLDB Endow., vol. 13, no. 12, pp. 3072–3084, Aug. 2020

    2020

  16. [24]

    A version of RocksDB that uses persistent mem- ory,

    Intel., “A version of RocksDB that uses persistent mem- ory,” https://github.com/pmem/Pmem-RocksDB, 2018

    2018

  17. [25]

    Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing,

    X. Jiang, Y . Hu, Y . Xiang, G. Jiang, X. Jin, C. Xia, W. Jiang, J. Yu, H. Wang, Y . Jiang, J. Ma, L. Su, and K. Zeng, “Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing,”Proc. of VLDB Endow., vol. 13, no. 12, pp. 3272–3284, 2020

    2020

  18. [26]

    Basic performance measurements of the intel optane dc persistent memory module,

    I. Joseph, Y . Jian, Z. Lu, K. Juno, L. Xiao, M. Amirsaman, J. S. Yun, W. Zixuan, X. Yi, R. D. Subramanya, Z. Jishen, and S. Steven, “Basic performance measurements of the intel optane dc persistent memory module,” 2019. [Online]. Available: https://arxiv.org/abs/1903.05714

    2019 arXiv

  19. [27]

    SLM-DB: Single-Level Key-Value store with persistent memory,

    O. Kaiyrakhmet, S. Lee, B. Nam, S. H. Noh, and Y .- r. Choi, “SLM-DB: Single-Level Key-Value store with persistent memory,” inProc. of USENIX FAST. USENIX Association, Feb. 2019, pp. 191–205

    2019

  20. [28]

    Redesigning lsms for non- volatile memory with novelsm,

    S. Kannan, N. Bhat, A. Gavrilovska, A. Arpaci-Dusseau, and R. Arpaci-Dusseau, “Redesigning lsms for non- volatile memory with novelsm,” inProc. of USENIX ATC. USENIX Association, Jul. 2018, pp. 993–1005

    2018

  21. [29]

    Overview and future challenge of ferroelectric random access mem- ory technologies,

    Y . Kato, Y . Kaneko, H. Tanaka, K. Kaibara, S. Koyama, K. Isogai, T. Yamada, and Y . Shimada, “Overview and future challenge of ferroelectric random access mem- ory technologies,”Japanese Journal of Applied Physics, vol. 46, no. 4S, p. 2157, Apr. 2007

    2007

  22. [30]

    Reliability investigations for manufacturable high density pram,

    K. Kim and S. J. Ahn, “Reliability investigations for manufacturable high density pram,” inProc. of IEEE IRPS. IEEE, Apr. 2005, pp. 157–162

    2005

  23. [31]

    ListDB: Union of Write-Ahead logs and persistent SkipLists for incremental checkpointing on persistent memory,

    W. Kim, C. Park, D. Kim, H. Park, Y . ri Choi, A. Suss- man, and B. Nam, “ListDB: Union of Write-Ahead logs and persistent SkipLists for incremental checkpointing on persistent memory,” inProc. of USENIX OSDI. USENIX Association, Jul. 2022, pp. 161–177

    2022

  24. [32]

    GraphChi: Large-Scale Graph Computation on Just a PC,

    A. Kyrola, G. Blelloch, and C. Guestrin, “GraphChi: Large-Scale Graph Computation on Just a PC,” inProc. of USENIX OSDI. USENIX Association, Oct. 2012, pp. 31–46

    2012

  25. [33]

    Elasticbf: Elas- tic Bloom Filter with Hotness Awareness for Boosting Read Performance in Large Key-Value Stores,

    Y . Li, C. Tian, F. Guo, C. Li, and Y . Xu, “Elasticbf: Elas- tic Bloom Filter with Hotness Awareness for Boosting Read Performance in Large Key-Value Stores,” inProc. of USENIX ATC. USENIX Association, Feb. 2019, pp. 739–752

    2019

  26. [34]

    Cache craftiness for fast multicore key-value storage,

    Y . Mao, E. Kohler, and R. T. Morris, “Cache craftiness for fast multicore key-value storage,” in Proceedings of the 7th ACM European Conference on Computer Systems, ser. EuroSys ’12. New York, NY , USA: Association for Computing Machinery, 2012, p. 183–196. [Online]. Availabl...

    2012

  27. [35]

    Fast and flexible persistence: the magic potion for fault-tolerance, scalability and per- formance in online data stores,

    P. Mehra and S. Fineberg, “Fast and flexible persistence: the magic potion for fault-tolerance, scalability and per- formance in online data stores,” inProc. of IEEE IPDPS. IEEE, Apr. 2004, p. 206

    2004

  28. [36]

    The log-structured merge-tree (lsm-tree),

    P. O’Neil, E. Cheng, D. Gawlick, and E. O’Neil, “The log-structured merge-tree (lsm-tree),”Acta Informatica, vol. 33, pp. 351–385, 1996

    1996

  29. [37]

    Fast Scans on Key-Value Stores,

    M. Pilman, K. Bocksrocker, L. Braun, R. Marroquin, and D. Kossmann, “Fast Scans on Key-Value Stores,”Proc. of VLDB Endow., vol. 10, no. 11, pp. 1526–1537, 2017

    2017

  30. [38]

    Frozenhot cache: Rethinking cache management for modern hardware,

    Z. Qiu, J. Yang, J. Zhang, C. Li, X. Ma, Q. Chen, M. Yang, and Y . Xu, “Frozenhot cache: Rethinking cache management for modern hardware,” inProc. of ACM EuroSys. ACM Association, Jul. 2023, p. 557–573

    2023

  31. [39]

    Phase-change random access memory: A scalable technology,

    S. Raoux, G. W. Burr, M. J. Breitwisch, C. T. Rettner, Y .-C. Chen, R. M. Shelby, M. Salinga, D. Krebs, S.- H. Chen, H.-L. Lunget al., “Phase-change random access memory: A scalable technology,”IBM Journal of Research and Development, vol. 52, no. 4.5, pp. 465– 479, Jul. 2008

    2008

  32. [40]

    Scylladb homepage,

    ScyllaDB, “Scylladb homepage,” https://www.scylladb. com/, 2015

    2015

  33. [41]

    Cockroachdb: The resilient geo-distributed sql database,

    R. Taft, I. Sharif, A. Matei, N. VanBenschoten, J. Lewis, T. Grieger, K. Niemi, A. Woods, A. Birzin, R. Poss et al., “Cockroachdb: The resilient geo-distributed sql database,” inProc. of ACM SIGMOD. ACM, Jun. 2020, pp. 1493–1509

    2020

  34. [42]

    Spin-torque diode effect in magnetic tunnel junctions,

    A. Tulapurkar, Y . Suzuki, A. Fukushima, H. Kubota, H. Maehara, K. Tsunekawa, D. Djayaprawira, N. Watan- abe, and S. Yuasa, “Spin-torque diode effect in magnetic tunnel junctions,”Nature, vol. 438, no. 7066, pp. 339– 342, Nov. 2005

    2005

  35. [43]

    A wait-free queue as fast as fetch-and-add,

    C. Yang and J. Mellor-Crummey, “A wait-free queue as fast as fetch-and-add,” inProc. of ACM PPoPP. ACM, Feb. 2016, pp. 1–13

    2016

  36. [44]

    An empirical guide to the behavior and use of scalable persistent memory,

    J. Yang, J. Kim, M. Hoseinzadeh, J. Izraelevitz, and S. Swanson, “An empirical guide to the behavior and use of scalable persistent memory,” inProc. of USENIX FAST. USENIX Association, Feb. 2020, pp. 169–182

    2020

  37. [45]

    Segcache: a memory- efficient and scalable in-memory key-value cache for small objects,

    J. Yang, Y . Yue, and R. Vinayak, “Segcache: a memory- efficient and scalable in-memory key-value cache for small objects,” inProc. of USENIX NSDI. USENIX Association, Apr. 2021, pp. 503–518

    2021

  38. [46]

    Oceanbase: a 707 million tpmc distributed relational database system,

    Z. Yang, C. Yang, F. Han, M. Zhuang, B. Yang, Z. Yang, X. Cheng, Y . Zhao, W. Shi, H. Xiet al., “Oceanbase: a 707 million tpmc distributed relational database system,” Proc. of VLDB Endow., vol. 15, no. 12, pp. 3385–3397, 2022

    2022

  39. [47]

    Matrixkv: Reducing write stalls and write amplification in lsm-tree based kv stores with matrix container in nvm,

    T. Yao, Y . Zhang, J. Wan, Q. Cui, L. Tang, H. Jiang, C. Xie, and X. He, “Matrixkv: Reducing write stalls and write amplification in lsm-tree based kv stores with matrix container in nvm,” inProc. of USENIX ATC. USENIX Association, Jul. 2020, pp. 17–31

    2020

  40. [48]

    Yugabytedb homepage,

    I. Yugabyte, “Yugabytedb homepage,” https://www. yugabyte.com/, 2017

    2017

  41. [49]

    Chameleondb: a key-value store for optane persistent memory,

    W. Zhang, X. Zhao, S. Jiang, and H. Jiang, “Chameleondb: a key-value store for optane persistent memory,” inProc. of ACM EuroSys. ACM, Jul. 2021, pp. 194–209

    2021

  42. [50]

    FlashGraph: Processing Billion-Node Graphs on an Array of Commodity SSDs,

    D. Zheng, D. Mhembere, R. Burns, J. V ogelstein, C. E. Priebe, and A. S. Szalay, “FlashGraph: Processing Billion-Node Graphs on an Array of Commodity SSDs,” inProc. of USENIX FAST. USENIX Association, Feb. 2015, pp. 45–58

    2015

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.