{"id":"e89b15b8-05cb-4e0c-be39-e27fb2f7424f","arxiv_id":"2506.08923","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Mycelium embeds data transformations into LSM-tree compaction, reducing transformation write overhead from 35-60% to about 20% while speeding up column-reading queries by up to 4.25x.","lead":"This paper describes a version of the LSM-tree database engine that performs useful data transformations, such as splitting rows into columns, converting formats, and building indexes, in the background during normal compaction. The key results are a much lower write-cost penalty than doing those transformations separately, and up to 4.25x faster read queries for column accesses.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"TE-LSM transparency is unverified: no defined propagation path for later updates/deletes to keys already transformed into internal column families, and the write benchmark is insert-only.","rationale":"I read the paper as making two separable claims: (1) transformation-embedded compaction amortizes transformation I/O, giving ~20% write overhead versus 35-60% for external transformation; (2) this is achieved transparently, so the engine remains a drop-in RocksDB replacement. The first claim is supported only for inserts (Q1) and is somewhat confounded by the simultaneous switch to Tierveling—TE-LSM-Identity already shows -5.25% overhead—but the table still shows a large gap versus external baselines. The second claim is the load-bearing one because the abstract and introduction promise 'transparent' embedding. The paper's own text creates the gap: data is migrated out of the user-facing CF (Sec. 3.3), external writes to internal CFs are forbidden (Sec. 3.1), writes are described only as 'identical' to RocksDB (Sec. 3.2, Sec. 4.3), reads for split transformations reassemble from internal CFs (Sec. 4.4), and no update/delete propagation or version-merge rule is given anywhere, including Algorithms A1-A3. With no update/delete experiments, the correctness of the most basic storage-engine operation is unverified. This is precisely the reader's weakest assumption, so my pass does not move the verdict: the paper should remain conditional, with the condition being a demonstrated update/delete correctness test and, ideally, an update/delete read-latency measurement. I did not find a more damaging internal inconsistency; the cost model is rough but not self-contradictory on the example given, and the lack of released code is a reproducibility concern rather than a correctness flaw in the argument.","tokens_in":19201,"tokens_out":6142,"duration_ms":61368,"concrete_test":"Use the public API on a Mycelium-Splitting database: (1) insert key k with a full 32-column row and force a transformation-embedded compaction so k's columns are in internal destination CFs; (2) overwrite k with a row whose column values differ; (3) insert another key k2 and then delete k2; (4) issue the Q7 point read for k and the Q6 range scan over [k,k2]. Pass requires Q7 to return the new value exactly once, Q6 to contain no duplicated columns, and k2 to be absent after the delete and after subsequent compactions. A YCSB Workload A (50% updates, 50% reads) with per-key version checking is a stronger version of the same test. If stale versions or resurrected keys appear, the transparency assumption fails and the performance claims must be scoped to append-only workloads.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central premise is that Mycelium transparently embeds transformations (Abstract, Sec. 1). Transparency requires that the public API behave like RocksDB for reads, writes, updates, and deletes. The design moves data out of the user-facing source CF into internal destination CFs (Sec. 3.3) and, for split transformations, reassembles rows from those internal CFs at read time (Sec. 4.4). What is never specified is how a later write or delete to a key whose transformed copy is already in a destination CF propagates. Section 3.1 explicitly forbids external writes to destination CFs, and Section 4.3 only asserts that writes 'function the same way as in standard RocksDB'—which, if true, means the update lands only in the source CF. The read path for a full row has no described merge of source-CF latest versions with destination-CF transformed copies. Consequently a Q7 read after an overwrite could return the stale transformed row, and a deleted key could resurface from the destination CF. The evaluation uses only Q1 INSERT (Sec. 5.3.1) and never exercises updates or deletes. This is not a tuning issue: if the merge semantics are undefined, the system is not transparent and the headline performance claims are scoped to append-only workloads.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Transformation-Embedded LSM-trees (TE-LSM), a design that runs user-defined data transformations such as column splitting, format conversion, and secondary-index building during LSM-tree compaction, inside a RocksDB-based prototype called Mycelium. The claimed benefit is that the I/O cost of transformation is amortized by compaction I/O, reducing the write-throughput penalty of transformation to about 20% (versus 35-60% for transformations done outside compaction) while improving read latency by up to 425%. The paper includes a cost model and an experimental evaluation using YCSB workloads on 100GB of data.","tokens_in":19508,"tokens_out":9614,"duration_ms":100250,"significance":"The idea of embedding transformations into compaction is a useful generalization of prior work and may have practical value for mixed OLTP/OLAP workloads. The paper demonstrates substantial engineering: a working prototype, three transformation types, and a composition mechanism, with a large-scale evaluation. However, the headline quantitative claims are currently weakened by (i) the confounding of the write-overhead measurement with the Tierveling merge strategy and (ii) the absence of defined update/delete semantics for transformed data, without which the 'transparent' claim is not established. Both issues are addressable in a revision, and the qualitative direction of the results is likely to survive, so the paper has clear potential.","major_comments":[{"comment":"The write-throughput overhead figures are confounded by the Tierveling merge strategy. Table 2 reports Mycelium-Identity as -5.25% (i.e., 5.25% faster than RocksDB) even though it performs no transformation. The transformation-specific overhead should therefore be measured relative to Mycelium-Identity, not to the RocksDB baseline. Recomputing from the table, the single-transformation penalties become approximately 15-20% and Split-Converting becomes ~25%, rather than the 10.09-21.25% range stated. The paper should report the number of runs and error bars for these measurements, and either compare TE-LSM configurations against Mycelium-Identity or adjust the baseline to isolate the transformation cost from the Tierveling effect. Without this adjustment, the abstract's '20% write throughput overhead' claim is not established.","section":"§5.4.1, Table 2"},{"comment":"The 'transparent' embedding claim is unsupported for update and delete workloads. The design moves transformed data to internal destination column families (Sec. 3.3) and deletes the source files after transformation (Algorithm 3), while Sec. 3.1 forbids external writes to those destination column families. Sec. 4.3 states only that writes 'function the same way as in standard RocksDB,' which cannot be true for a key that already has a transformed copy in a destination column family: a later write, update, or delete in the user-facing source column family has no defined propagation path to that copy. Sec. 4.4 describes row reassembly from split column families but does not describe merging a newer source-column-family version with the transformed destination copy. The evaluation (Sec. 5.3.1) exercises only Q1 (INSERT) and never tests update or delete. As a result, the system may return stale or resurrected values for update/delete workloads, and the headline performance claims are currently scoped to append-only workloads. The authors must either implement and test update/delete propagation or explicitly restrict the paper's claims to append-only, insert-only usage.","section":"§3.1, §3.2, §4.3, §4.4, Algorithm 3"},{"comment":"The cost model is calibrated to the experimental results rather than used as an independent predictor. The write-throughput example picks n=2 extra writes during cross-column-family compaction and obtains the same ~20% overhead that appears in the abstract, while the point-query examples assume a 30% record-size reduction after format conversion, close to the measured 34.76% SST size reduction in Sec. 5.4.2. The values of n and the record-size reduction are not independently measured or justified. Since Sec. 3.6 claims the model can 'predict whether a given transformation is beneficial,' the paper should validate the model with measured parameters or explicitly describe it as an illustrative calculation rather than a predictive model.","section":"Appendix B"}],"minor_comments":[{"comment":"The test-data description refers to 'Baseline-1' through 'Baseline-4,' but Section 5.2.1 defines baselines as 'Baseline,' 'Baseline-Splitting,' 'Baseline-Converting,' and 'Baseline-Augmenting.' Please align the naming.","section":"§5.3.2"},{"comment":"The read-latency results report P50/P99 values but do not state how many measurement repetitions were performed or the run-to-run variance. Reporting confidence intervals or at least the number of batches would strengthen the claimed speedups, especially for Q2 and Q3.","section":"§5.4.2"},{"comment":"The claimed associativity and commutativity of transformers (Eqs. 1-2) appear inconsistent with the transformer-assignment rules in Sec. 4.2.5, which impose that gradual transformers are applied first and that at most one gradual transformer exists per logical column family. Please clarify whether the algebra describes logical equivalence of composed functions or the scheduling policy, and note that the evaluation only demonstrates one composition order.","section":"§3.5 and §4.2.5"},{"comment":"The column merge operator that reassembles full rows from split column families is described only in one sentence. A brief description of how the merge is performed and how it interacts with range scans would make the read path understandable without requiring the reader to infer the implementation.","section":"§4.4"},{"comment":"In Eq. (4), the text says the write bandwidth is 'determined by the minimum' of two terms, but the subsequent simplification to Eq. (5) silently assumes the write-disk bandwidth is the binding constraint. Please state that assumption explicitly and discuss the regime in which compute-bound transformation throughput would change the result.","section":"Appendix B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript would benefit from a broader discussion of update propagation in LSM variants and from reporting whether the benchmark code and data will be released. The 'hidden due to anonymity' line is understandable for a double-blind submission, but the journal should verify that the code will be available upon acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nRead this if you care about LSM design. Mycelium takes Saxena et al.'s idea of using compaction as a piggyback point for data transformation and generalizes it in a useful way: a composable transformer interface, cross-column-family compaction, and a hybrid tiering/leveling policy called Tierveling. The paper credits Saxena et al. explicitly, which is good. The prototype appears real, and the read-side improvements—e.g., 4.25x lower latency on range queries for converted data—are plausible and worth taking seriously.\n\nThe soft spots are in the evaluation, not the core idea. First, the write-overhead claim is confounded. Mycelium-Identity, which does no transformation, is 5.25% faster than the RocksDB baseline because Tierveling reduces write stalls. So the reported 10-21% \"transformation overhead\" is measured against a baseline that lacks that benefit. The right comparison is Mycelium-with-transformation against Mycelium-Identity, and that is not reported. The comparison against \"naive\" external transformation also needs care: the baselines are not shown to be tuned, so the 35-60% penalty may be partly an artifact.\n\nSecond, the transparency question raised in the stress-test is on target. Once data is moved into internal destination column families, the paper never defines how a later overwrite or delete propagates to the transformed copies. Writes are asserted to \"function the same way as in standard RocksDB,\" but no mechanism is given for updating or invalidating transformed records, and the read path for full rows has no described merge of source-latest versions with transformed copies. The evaluation is insert-only, so nothing exercises this. If the semantics are undefined, the system is not transparent, and the performance claims apply only to append-only workloads.\n\nThe Appendix B cost model is illustrative rather than predictive: n=2 is chosen and it produces the measured ~20% overhead, and the convert example assumes a 30% size reduction close to the measured 34.76%. That is a calibration concern, though minor relative to the semantics gap.\n\nI would send this to a serious referee. The idea is novel enough within the subfield, the prototype is substantial, and the update/delete question is exactly what a careful reviewer should force the authors to answer. But I would not accept it in current form. The authors need to (1) re-baseline write overhead against Mycelium-Identity, (2) specify and test update/delete propagation, and (3) release the code or at least a more detailed evaluation.\n\nFor your own reading: worth a group slot, but pair it with Saxena et al. so people can weigh the delta.","headline":"A useful generalization of compaction-embedded transformation, but the headline write-overhead claim is confounded and update/delete semantics are unspecified.","tokens_in":20003,"tokens_out":2749,"would_cite":true,"duration_ms":26416,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Data transformations embedded in LSM compaction can cost about 20% write overhead and speed reads by up to 425%.","keywords":["LSM-tree","compaction","data transformation","columnar storage","secondary index","write amplification","read optimization","RocksDB"],"falsifier":"Run a mixed workload that inserts keys, lets compaction transform them, then updates or deletes some of those keys, and issue point reads and range scans: if any read returns a stale or duplicate version, the engine is not transparent and the reported read improvements are not obtained on live data. Section 5.3.1 covers only Q1 (INSERT), so this experiment lies outside the paper's measurements.","tokens_in":19040,"feed_emoji":"⚙️","tokens_out":8685,"duration_ms":84872,"temperature":0.7,"pith_summary":"This paper tries to establish that the background compaction step of an LSM-tree can do more than merge sorted runs: it can reshape data for future reads at nearly the same I/O cost as compaction alone. The authors built Mycelium, a RocksDB-based prototype whose transformer interface splits rows into column groups, converts value formats, and builds secondary indexes while data is being compacted. On YCSB workloads, Mycelium reports a write-throughput overhead of about 20% for embedded transformations, compared with 35-60% when the same transformations are done outside compaction, and read-latency improvements up to 425% over the RocksDB baseline. If this holds, write-optimized storage could become read-optimized without a separate ETL pipeline, making real-time analytics on freshly ingested data more practical.","feed_headline":"Embedding transforms in LSM compaction cuts write overhead to ~20%","feed_subtitle":"Reads speed up to 425% because data is reshaped for queries during background compaction, not a separate ETL step.","key_machinery":"The load-bearing mechanism is transformation-embedded compaction: a compaction job in a source column family reads input SST files, applies a Transformer to each key-value pair in memory, and installs the outputs as new SST files in one or more internal destination column families that are hidden from user writes. The hybrid merge policy called Tierveling uses tiering for transformed compactions and leveling for identity compactions, so transformed data flows between column families while untransformed data keeps single-run levels. A Transformer interface with Prepare, Transform, and Retrieve methods makes split (row-to-column), convert (JSON-to-FlatBuffers), augment (secondary index), and composed transformations expressible as compaction-time functions.","core_discovery":"The paper's central claim is that data transformation can be made a byproduct of LSM compaction. Instead of writing compacted output back into the same column family, a compaction job applies a transformer to each key-value pair and installs the results into internal destination column families, so the reads and writes that compaction already performs are shared by the transformation. The reported result is a write-throughput penalty of 10.09% to 21.25% for single and combined transformations, versus 34.84% to 57.98% for naive external transformations, with read-latency gains of up to 425% and index-query gains of several hundred thousand times over full-table scans.","pith_inferences":["If update and delete transparency is verified, TE-LSM could become a general substrate for materialized views, schema normalization, and compression, not just the three transformations demonstrated.","The 425% read improvement applies to column-retrieving range queries; a workload dominated by full-row reads would likely shrink or reverse that gain because split rows must be reassembled.","A testable extension is to compare Mycelium against an engine that runs the same transformations during idle time, separating the benefit of amortizing I/O from the benefit of doing transformation work earlier.","The cost model's assumption that transformation is CPU-bound relative to compaction I/O could be probed by embedding a deliberately expensive transformer and measuring where the write overhead begins to exceed 20%."],"forward_implications":["A write-optimized store can progressively become read-optimized as data ages through compaction, without a separate extraction step and without delaying availability.","Transformations that shrink values or reduce per-query I/O transfer their benefit directly to read latency, with the largest gains on column-retrieving range queries and index queries.","Multiple transformations can share the same compaction I/O budget: the paper measures about 21% write overhead for split-plus-convert, versus 10-15% for a single transformation.","Applying even a no-op transformation under tierveling can slightly raise write throughput (about 5%) by moving data out of Level-0 faster and reducing write stalls, at the cost of potentially higher read costs.","Data transformations become composable, declarative operations on column families rather than externally scheduled jobs."],"supporting_citations":[{"why":"Defines the LSM-tree whose compaction Mycelium modifies and is the write-optimized baseline structure.","marker":"[23]"},{"why":"Pioneered piggybacking row-to-columnar transformation on compaction, which Mycelium generalizes to arbitrary transformations.","marker":"[34]"},{"why":"Frames the read-update-memory trade-offs that motivate amortizing transformation work into compaction.","marker":"[4]"},{"why":"Maps the leveling versus tiering compaction design space that Tierveling hybridizes.","marker":"[33]"},{"why":"Identifies write stalls as a key compaction cost, which Mycelium's tiering of transformed data is measured to reduce.","marker":"[35]"}],"fun_headline_variants":["Mycelium embeds data transforms into LSM compaction","Transforms ride compaction, cutting write overhead to ~20%","Compaction does double duty: transform while writing","Mycelium: LSM compaction that reshapes data on the fly","Data transforms piggyback on compaction, slashing write cost"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Mycelium's transparency rests on later updates and deletes to keys that have already been transformed still returning the correct current value, but the paper tests only inserts and does not specify how a post-compaction write or delete propagates to the transformed copies.","fun_headline_variants_meta":{"raw":{"variants":["Mycelium embeds data transforms into LSM compaction","Transforms ride compaction, cutting write overhead to ~20%","Compaction does double duty: transform while writing","Mycelium: LSM compaction that reshapes data on the fly","Data transforms piggyback on compaction, slashing write cost"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000396,"raw_usage":{"total_tokens":2065,"prompt_tokens":927,"completion_tokens":1138,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":543,"completion_tokens_details":{"reasoning_tokens":1054}},"tokens_in":543,"tokens_out":1138,"duration_ms":10208,"temperature":1.0,"reasoning_tokens":1054,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T04:58:45.602571+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a mixed workload that inserts keys, lets compaction transform them, then updates or deletes some of those keys, and issue point reads and range scans: if any read returns a stale or duplicate version, the engine is not transparent and the reported read improvements are not obtained on live data. Section 5.3.1 covers only Q1 (INSERT), so this experiment lies outside the paper's measurements.","supporting_citations":[{"cited_title":"The log-structured merge-tree (lsm-tree).Acta Informatica, 33:351–385, 1996","cited_arxiv_id":null,"evidence_quote":"Defines the LSM-tree whose compaction Mycelium modifies and is the write-optimized baseline structure."},{"cited_title":"Real-time lsm-trees for htap work- loads","cited_arxiv_id":null,"evidence_quote":"Pioneered piggybacking row-to-columnar transformation on compaction, which Mycelium generalizes to arbitrary transformations."},{"cited_title":"Designing access meth- ods: The rum conjecture","cited_arxiv_id":null,"evidence_quote":"Frames the read-update-memory trade-offs that motivate amortizing transformation work into compaction."},{"cited_title":"Constructing and Analyzing the LSM Compaction Design Space (Updated Version)","cited_arxiv_id":"2202.04522","evidence_quote":"Maps the leveling versus tiering compaction design space that Tierveling hybridizes."},{"cited_title":"blsm: a general purpose log structured merge tree","cited_arxiv_id":null,"evidence_quote":"Identifies write stalls as a key compaction cost, which Mycelium's tiering of transformed data is measured to reduce."}],"review_version":1}