Pith. sign in

REVIEW 5 major objections 7 minor 38 references

Brame: Hierarchical Data Management Framework for Cloud-Edge-Device Collaboration

T0 review · 5 major / 7 minor · reviewed 2026-08-08 · deepseek-v4-flash

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

Pith's one-line read This paper proposes Brame, a three-tier cloud-edge-device storage framework that manages relational data in workload-aware Blocks instead of individual tuples, and claims cache hit rates 0.5X to 1.0X higher than locality-only baselines.

desk verdict Brame is a coherent block-based three-tier storage design whose core claim against tuple-level management is undermined by its own experiments; still worth a referee. read the letter →

arxiv 2502.08331 v1 pith:X275PLFJ submitted 2025-02-12 cs.DB

Xianglong Liu , Hongzhi Wang , Yingze Li , Minchong Li , Shenghe Zheng , Weihua Sun This is my paper · ORCID
classification cs.DB
keywords cloud-edge-devicecollaborationhierarchicalstoragedatamigrationblock-basedmanagementworkload-awareclusteringtemperaturemodelcachereplacementrelationaldatabase
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

Brame is a framework for storing and moving relational data across three tiers with very different capacities and latencies: cloud servers, edge servers, and terminal devices. Its central proposal is to stop managing data tuple by tuple and instead manage it in Blocks, which are sets of tuples deliberately grouped together because the same queries tend to request them. The paper argues that this coarser, workload-aware granularity keeps co-accessed tuples in one unit, so a fixed cache at the edge or on a device holds more of what queries actually need. On two real datasets, Brame reports tuple-level and block-level hit rates 0.5X to 1.0X higher than locality-only baselines, with block generation costs on the order of minutes. If the claim holds, it gives database systems a practical way to build cloud-edge-device hierarchies without paying per-tuple metadata and migration overhead.

What carries the argument

The load-bearing object is the Block, a bounded-size set of tuples grouped by similar query access patterns, together with the offline machinery that builds it: workload-aware tuple encoding, where each tuple's feature vector is the concatenation of query bitmaps; Hierarchical Balanced Clustering (HBC), which recursively splits large clusters into balanced child clusters; and a hierarchical clustering tree whose intermediate nodes carry Max-Min indexes for fast query routing. The online counterpart is a temperature model using exponential smoothing to score each Block's hotness and a 0-1 knapsack formulation that decides which Blocks fit in the edge cache, while terminal devices use conventional replacement policies such as LRU. This machinery makes the migration unit align with query access patterns, so moving one Block moves everything a query is likely to touch.

What would settle it

Build Blocks from one workload and evaluate on a disjoint workload with strongly different co-access patterns; if Brame's hit rates fall to the level of the locality-only baselines while a per-tuple scheduler keeps its hit rate, the workload-stationarity premise fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that the right unit for hierarchical data management in cloud-edge-device settings is a workload-defined Block rather than a tuple or a purely data-locality-defined page. Brame encodes each tuple as a bit vector over a representative query workload, clusters those vectors with a balanced hierarchical K-Means variant, and routes queries through a hierarchical clustering tree whose leaves are Blocks carrying Max-Min indexes. It then places Blocks by temperature, with hot Blocks near the edge or terminal and cold Blocks in the cloud. Experiments on cloud-edge data migration and cloud-edge-device cache replacement using the Power and DMV datasets report that Brame outperforms Key-Order, K-D Tree, and Hilbert Curve baselines by 0.5X to 1.0X in both tuple hit rate and block hit rate, while avoiding the per-tuple metadata reconstruction that tuple-level migration requires.

Load-bearing premise

The framework assumes the offline representative workload used to build Blocks remains a fair guide to future queries, and the paper tests only a slight skew in the generated workload, not substantial drift.

Editorial extensions

If this is right

  • Brame avoids per-tuple temperature maintenance and metadata rebuilding, so a cloud-edge-device system can migrate data frequently without reconstructing tuple-level indexes.
  • The same offline block generation output supports both periodic cloud-edge migration and real-time terminal cache replacement, so one construction pass pays for both scheduling modes.
  • Because Blocks carry Max-Min indexes, query routing can skip Blocks whose ranges fail the query predicates, reducing scanned pages and unnecessary requests to higher tiers.
  • The experiments on Power and DMV suggest that workload co-access, not just data locality, is the dominant factor in cache hit rates for single-table range queries.
  • If the representative workload is stable, Brame allows a smaller edge or terminal cache to satisfy a larger fraction of queries under the same byte budget.

Reading between the lines

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

  • A natural extension the paper leaves implicit is incremental re-clustering or block splitting when the incoming workload drifts, since the offline Blocks are built once and only 'slight skew' is tested.
  • The reported hit-rate gains should translate into fewer network round trips between end devices and the cloud, but the paper measures hit rates and construction time, not end-to-end latency or bandwidth consumption.
  • The observed inverted-U relationship between Block size and hit rate suggests that an adaptive Block-size controller driven by observed query distributions could push Brame beyond fixed-size settings.
  • Because the paper tests only single-table range queries, extending to multi-table joins or write-heavy workloads would require revisiting how the workload-aware feature vectors are defined.
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

5 major / 7 minor

Summary. The paper proposes Brame, a hierarchical data management framework for cloud-edge-device (CEDC) environments. Brame's central idea is to replace tuple-level management with block-level management: an offline component generates workload-aware Blocks by clustering tuples that are co-accessed by representative queries, using a hierarchical balanced clustering method (HBC) over a table partitioned into pages; an online component schedules Blocks across cloud, edge, and end tiers using a temperature model and a 0-1 knapsack formulation for cloud-edge migration, and a cache replacement strategy for end-device caching. The paper reports experiments on two real datasets (Power and DMV) for two downstream tasks (cloud-edge migration and cloud-edge-device cache replacement), comparing Brame against Key-order, K-D Tree, and Hilbert-curve block-generation baselines. The claimed contribution is that workload-aware block generation yields higher tuple-level and block-level hit rates while reducing metadata management overhead compared with tuple-grained management.

Significance. If the central claim were established, Brame would address a real and under-studied problem in hierarchical storage for CEDC: the overhead of tuple-level temperature tracking and metadata reconstruction during migration. The paper has several strengths: the offline/online decomposition is clean; the complexity statements for the clustering and migration algorithms are explicit; the evaluation covers two datasets and two downstream tasks; and the ablation on block size and cache replacement strategy, plus the soft/hard filtering comparison, give some insight into the design space. However, the significance is conditional because the experimental validation does not currently isolate the contribution of block generation from the temperature model, does not include the tuple-level baseline in the main comparisons, and does not measure the metadata cost half of the central claim. These gaps are fixable but require additional experiments and reporting.

major comments (5)
  1. [Section VI-B, Section VI-C, Table II, Figures 5-8] The central claim that block-level management outperforms tuple-level management is not supported by the reported experiments. The only experiment that includes a Tuple baseline is Table II, on Power, for cloud-edge migration, and there Brame-H (hard filtering) is below Tuple at every cache budget (e.g., THR 0.179 vs 0.184 at 4% and 0.789 vs 0.814 at 32%); only Brame-S (soft filtering) exceeds Tuple. The main comparisons in Figures 5-8 omit the Tuple baseline entirely, so the Section VI-C statement that Brame 'consistently outperforms the three baseline methods' compares only Key-order, K-D Tree, and Curve. Furthermore, Section VI-B explicitly attributes the remaining advantage over Tuple to 'the design of the temperature model,' not to workload-aware block construction. No tuple-level result is reported for DMV, and no experiment isolates the contribution of Blocks themselves. To support the paper's central claim, the authors need to compare Brame with a tuple-level management scheme under the same temperature model and the same filtering strategy, on both datasets and both tasks, with repeated runs and variance reporting.
  2. [Section VI-A] The workload generation procedure creates both training and testing workloads from the same representative workload, with only 'a slight skew' between them. This makes the evaluation of workload-aware block generation partially circular: the Blocks are built from a workload that is nearly identical to the test workload, so the test does not measure robustness to workload drift. The paper should evaluate with test workloads that are more substantially perturbed, or with a held-out workload drawn from a different distribution, and report hit rates as a function of drift magnitude. Without such an experiment, the claimed advantage of workload-aware Blocks over data-aware layouts may be an artifact of the training/test overlap.
  3. [Section VI-C] None of the figures report error bars, confidence intervals, or repeated runs; each curve appears to come from a single execution. This is a load-bearing issue because the reported margins are often modest (e.g., 10%-30% on DMV, and '0.5X to 1.0X' on Power in Section VI-C), and it is impossible to assess whether the differences are stable across workload seeds, query arrival curves, or dataset subsamples. The authors should run multiple trials with different random seeds in workload generation and report means with standard deviations or confidence bands.
  4. [Section VI-A and Section VI-D] Several free parameters are set without sensitivity analysis or justification: block size (2048 for Power, 8192 for DMV), the temperature decay coefficient gamma = 0.6, the balance coefficient phi in Eq. (1), the page frequency threshold and cold-zone size threshold in Section IV-C, and the dynamically adjusted cluster count k in Algorithm 1. The ablation in Section VI-D covers only block size and cache replacement strategy. Since the central evidence is experimental, the authors should either provide a sensitivity study for gamma, phi, and the filtering thresholds, or give a principled argument for the chosen values. Otherwise it is unclear whether the reported improvements depend on carefully tuned parameters.
  5. [Abstract, Section I, Section VI] The paper repeatedly claims that block-level management reduces metadata management cost (e.g., 'lower metadata management cost' in the abstract and the discussion of C2 and C4 in Section I), but the experiments never measure metadata size, metadata update cost, or query-routing overhead. The metrics in Section VI-A are only tuple-level hit rate, block-level hit rate, and partition construction time. The authors should add direct measurements of metadata footprint and update cost, or at least report the number of tree nodes and the cost of placement updates, to substantiate the second half of the central claim.
minor comments (7)
  1. [Section III] The sentence 'We will introduce BS and HSS in Section IV and Section V, respectively' should read 'BG and HSS,' since the block generation module is abbreviated BG throughout the paper.
  2. [Algorithm 2] Line 2 of Algorithm 2 has a syntax error: the call `queryRoute (W, P ages, routeT ree;` is missing a closing parenthesis and should be `queryRoute(W, P ages, routeT ree);`.
  3. [Table III] The caption 'BLOCK GENERATION TIME CONSUME' should be 'BLOCK GENERATION TIME CONSUMPTION.'
  4. [Figure 7] The caption 'Exeprimental Results' contains a typo and should read 'Experimental Results.'
  5. [Section IV-B] The text says a bitmap representation is 'donated as bitmap(q, D)'; this should be 'denoted as bitmap(q, D).'
  6. [Section V-C] The statement 'Given 2n + 1 positive integers S, s1, s2, . . . , sn and c1, c2, . . . , cm' uses inconsistent index counts; m should be n (or the notation should be aligned) for the knapsack formulation to be well-defined.
  7. [Section VI-B] The phrase 'Our further analysis of Blocksize' should be 'Our further analysis of Block size' for consistency with the rest of the paper.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the workload-aware block-generation claim is supported by direct experiments rather than by a derivation that reduces to its inputs, with only minor evaluation caveats.

full rationale

Brame's central claim is that workload-aware Blocks, built by HIKM/HBC clustering of tuple feature vectors derived from representative workload W, improve query hit rates over data-aware block ordering. This is an empirical systems claim, not a first-principles derivation: the paper does not define block quality in terms of the headline metrics or fit a parameter that is then reported as a prediction. The block-construction objective (group tuples with similar row vectors in X=[bitmap(q1,D)||...]) is different from the measured THR/BHR on generated test workloads. The only self-citation, TS-Cabinet [5], appears in related work and is explicitly contrasted with Brame ('On the contrary, Brame uses Blocks as the fundamental unit'), so it is not load-bearing. The evaluation uses test workloads generated from the same representative queries as the training workload, with only 'slight skew' (Section VI-A), which is a generalizability limitation, but the test set is not identical to W and the hit-rate comparisons against Key-order, K-D Tree, and Curve are not forced by construction. Section VI-B also admits that part of the margin over the Tuple baseline is attributable to the temperature model rather than block generation, but that is an experimental-validity and attribution confound, not circular reasoning. Therefore the correct circularity score is 0.

Assumptions & free parameters 7 free parameters · 4 assumptions · 1 invented entities

The framework depends on a small set of tunable parameters, none of which are derived from theory: block size, temperature decay, balance coefficient, filter thresholds, and cache policy. The central assumptions are workload stationarity and a narrow single-table read-only scope. The only invented concept is the Block itself, which is a design choice rather than an empirically validated discovery.

free parameters (7)
  • Block size = 2048 (Power), 8192 (DMV)
    Chosen per dataset; ablation in Section VI-D shows hit rates peak near these values, so reported results reflect tuned parameters.
  • Temperature decay coefficient gamma = 0.6
    Set in Section VI-A without sensitivity analysis; used in exponential smoothing (Eq. 2) to compute Block temperature that feeds the knapsack placement.
  • Balance coefficient phi = not reported
    Trade-off parameter in balanced K-Means objective (Eq. 1); value omitted, so clustering behavior cannot be reproduced.
  • Page frequency threshold = not reported
    Determines hard filtering of cold pages in Section IV-C; threshold value not disclosed.
  • Cold zone size threshold = not reported
    Used in soft filtering to merge small cold zones into hot zones (Section IV-C); value not disclosed.
  • Dynamic cluster count k = not specified
    HIKM/HBC adjusts k per cluster based on size and characteristics (Section IV-B); the adjustment rule is not given.
  • Cache replacement strategy = LRU (main), ARC best
    End-device eviction policy is a free design choice; results vary by strategy (Section VI-D), so reported gains depend on this choice.
assumptions (4)
  • domain assumption Representative workload W is stable enough that blocks built offline from W remain useful online.
    Invoked in Section II and IV-B; test workloads in VI-A are generated with only slight skew from W, so the evaluation does not test strong drift.
  • domain assumption The system only handles single-table read-only range-select queries without replicas.
    Stated in Section II Scope; joins, writes, order-by, and replication are excluded, limiting the central claim to this narrow setting.
  • standard math Balanced K-Means from Liu et al. [14] and K-D Tree/Max-Min indexing correctly support clustering and query routing.
    Brame relies on cited algorithms for cluster balance and for guaranteeing no matching tuple is missed (Section IV-B, V-B); the paper adds no formal correctness proof.
  • domain assumption Exponential smoothing temperature model is an appropriate predictor of future Block access.
    Equation (2) models temperature as gamma-weighted history plus recent hits; the paper acknowledges temperature model design is deferred to future work (Section VI-B).
invented entities (1)
  • Block
    purpose: Coarse-grained unit of storage, migration, and query routing, grouping tuples with similar query access patterns.
    Introduced in Section I and III as a design abstraction; no independent validation outside the paper's own experiments, and no formal argument that block-level grouping preserves query completeness beyond Max-Min indexes.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Brame: Hierarchical Data Management Framework for Cloud-Edge-Device Collaboration." pith.science (2026). https://pith.science/paper/X275PLFJ

@misc{pith2026250208331,
  author       = {Pith},
  title        = {Pith review of: Brame: Hierarchical Data Management Framework for Cloud-Edge-Device Collaboration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X275PLFJ}},
  note         = {Machine review of arXiv:2502.08331}
}
abstract

In the realm of big data, cloud-edge-device collaboration is prevalent in industrial scenarios. However, a systematic exploration of the theory and methodologies related to data management in this field is lacking. This paper delves into the sub-problem of data storage and scheduling within cloud-edge-device collaborative environments. Following extensive research and analysis of the characteristics and requirements of data management in cloud-edge collaboration, it is evident that existing studies on hierarchical data management primarily focus on the migration of hot and cold data. Additionally, these studies encounter challenges such as elevated operational and maintenance costs, difficulties in locating data within tiered storage, and intricate metadata management attributable to excessively fine-grained management granularity. These challenges impede the fulfillment of the storage needs in cloud-edge-device collaboration. To overcome these challenges, we propose a \underline{B}lock-based hie\underline{R}archical d\underline{A}ta \underline{M}anagement fram\underline{E}work, \textbf{Brame}, which advocates for a workload-aware three-tier storage architecture and suggests a shift from using tuples to employing $Blocks$ as the fundamental unit for data management. \textbf{Brame} owns an offline block generation method designed to facilitate efficient block generation and expeditious query routing. Extensive experiments substantiate the superior performance of \textbf{Brame}.

Figures

Figures reproduced from arXiv: 2502.08331 by the authors.

Figure 1
Figure 1. Tuple-level vs Block-level. framework to cater to the diverse requirements of hierarchical data storage in the context of CEDC. To enable effective CEDC, we attempt to solve the above two issues by slightly increasing data management granularity and introducing a three-tier data management architecture. For the former, we suggest using data blocks (Blocks) as the basic units for data management, where each Block is … view at source ↗
Figure 2
Figure 2. An Overview of Brame. way. The latter performs online block scheduling. Brame’s architecture is depicted in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Workload-aware vs Data-aware Approaches. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (7 more)
Figure 3
Figure 3. Figure 3: The Workflow of Brame’s Offline Block Generation Technology. subordinate data tuples, including Max-Min index. Leaf nodes record metadata pertaining to the corresponding Block and its placement location. Consequently, when a query is received, it determines the Blocks …
Figure 5
Figure 5. Figure 5: Experimental Results of Cloud-Edge Data Scheduling, on Power [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Experimental Results of Cloud-Edge Data Scheduling, on DMV [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Exeprimental Results of Cloud-Edge-Device Cache Replacement, [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 9
Figure 9. Figure 9: Sensitivity Study on Block size in Cloud-Edge Data Scheduling (a) Tuple Hit Ratio (b) Block Hit Ratio [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: Sensitivity Study on Block size in Cloud-Edge-Device Cache Replacement Comparison of Page Filtering Strategy: In this part, we evaluate the impact of page filtering strategies proposed in Section IV-C on Brame’s performance. Table IV and Table V respectively show the …
Figure 11
Figure 11. Figure 11: Experimental Results of Using Different Cache Replace Strategy [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 36 canonical work pages

  1. [1]

    Cloud-edge-end collaboration in air–ground integrated power iot: A semidistributed learning approach,

    H. Liao, Z. Jia, Z. Zhou, Y . Wang, H. Zhang, and S. Mumtaz, “Cloud-edge-end collaboration in air–ground integrated power iot: A semidistributed learning approach,” IEEE Transactions on Industrial Informatics, vol. 18, pp. 8047–8057, 2022

    work page 2022

  2. [2]

    Blockchain and federated deep reinforce- ment learning based secure cloud-edge-end collaboration in power iot,

    S. Zhang, Z. Wang, Z. Zhou, Y . Wang, H. Zhang, G. Zhang, H. Ding, S. Mumtaz, and M. Guizani, “Blockchain and federated deep reinforce- ment learning based secure cloud-edge-end collaboration in power iot,” IEEE Wireless Communications, vol. 29, pp. 84–91, 2022

    work page 2022

  3. [3]

    Msiap: A dynamic searchable encryption for privacy-protection on smart grid with cloud-edge-end,

    K. Fan, Q. Chen, R. Su, K. Zhang, H.-Y . Wang, H. Li, and Y . Yang, “Msiap: A dynamic searchable encryption for privacy-protection on smart grid with cloud-edge-end,” IEEE Transactions on Cloud Com- puting, vol. 11, pp. 1170–1181, 2023

    work page 2023

  4. [4]

    Application- driven data management framework for wind farms by cloud-edge- end collaboration,

    Y . Li, X. L. Shen, Y . Wang, Y . Zhang, and W. Yang, “Application- driven data management framework for wind farms by cloud-edge- end collaboration,” 2022 IEEE 6th Conference on Energy Internet and Energy System Integration (EI2) , pp. 1689–1695, 2022

    work page 2022

  5. [5]

    TS-Cabinet: Hierarchical Storage for Cloud-Edge-End Time-series Database

    S. Cui, H. Wang, X. Liu, Z. Tian, and X. Ding, “Ts-cabinet: Hi- erarchical storage for cloud-edge-end time-series database,” ArXiv, vol. abs/2302.12976, 2023

    work page Pith review arXiv 2023

  6. [6]

    An effective model for edge- side collaborative storage in data-intensive edge computing,

    Y . Li, J. Luo, J. Jin, R. Xiong, and F. Dong, “An effective model for edge- side collaborative storage in data-intensive edge computing,” 2018 IEEE 22nd International Conference on Computer Supported Cooperative Work in Design ((CSCWD)) , pp. 92–97, 2018

    work page 2018

  7. [7]

    Secure data sharing and search for cloud- edge-collaborative storage,

    Y . Tao, P. Xu, and H. Jin, “Secure data sharing and search for cloud- edge-collaborative storage,” IEEE Access , vol. 8, pp. 15963–15972, 2020

    work page 2020

  8. [8]

    A time-driven data placement strategy for a scientific workflow combining edge computing and cloud computing,

    B. Lin, F. Zhu, J. Zhang, J. Chen, X. Chen, N. N. Xiong, and J. L. Mauri, “A time-driven data placement strategy for a scientific workflow combining edge computing and cloud computing,” IEEE Transactions on Industrial Informatics , vol. 15, pp. 4254–4265, 2019

    work page 2019

Show all 38 references
  1. [9]

    Identifying hot and cold data in main-memory databases,

    J. J. Levandoski, P.- ˚A. Larson, and R. Stoica, “Identifying hot and cold data in main-memory databases,” 2013 IEEE 29th International Conference on Data Engineering (ICDE) , pp. 26–37, 2013

    2013

  2. [10]

    Gorilla: A fast, scalable, in-memory time series database,

    T. Pelkonen, S. Franklin, P. Cavallaro, Q. Huang, J. Meza, J. Teller, and K. Veeraraghavan, “Gorilla: A fast, scalable, in-memory time series database,” Proc. VLDB Endow., vol. 8, pp. 1816–1827, 2015

    2015

  3. [11]

    Life cycle of transactional data in in-memory databases,

    A. Pathak, A. Gurajada, and P. Khadilkar, “Life cycle of transactional data in in-memory databases,” 2018 IEEE 34th International Conference on Data Engineering Workshops (ICDEW) , pp. 122–133, 2018

    2018

  4. [12]

    Efficient identification of hot data for flash memory storage systems,

    J.-W. Hsieh, T.-W. Kuo, and L.-P. Chang, “Efficient identification of hot data for flash memory storage systems,” ACM Trans. Storage , vol. 2, pp. 22–40, 2006

    2006

  5. [13]

    Hot data identification for flash-based storage systems using multiple bloom filters,

    D. Park and D. H.-C. Du, “Hot data identification for flash-based storage systems using multiple bloom filters,” 2011 IEEE 27th Symposium on Mass Storage Systems and Technologies (MSST) , pp. 1–11, 2011

    2011

  6. [14]

    Fast clustering with flexible balance constraints,

    H. Liu, Z. Huang, Q. Chen, M. Li, Y . R. Fu, and L. Zhang, “Fast clustering with flexible balance constraints,” 2018 IEEE International Conference on Big Data (Big Data) , pp. 743–750, 2018

    2018

  7. [15]

    An algorithm for finding best matches in logarithmic expected time,

    J. H. Friedman, J. L. Bentley, and R. A. Finkel, “An algorithm for finding best matches in logarithmic expected time,” ACM Trans. Math. Softw. , vol. 3, pp. 209–226, 1976

    1976

  8. [16]

    Design and analysis of approximation algorithms,

    D. Z. Du, K.-I. Ko, and X. Hu, “Design and analysis of approximation algorithms,” in Springer Science Business Media , 2011

    2011

  9. [17]

    A density-based algo- rithm for discovering clusters in large spatial databases with noise,

    M. Ester, H.-P. Kriegel, J. Sander, and X. Xu, “A density-based algo- rithm for discovering clusters in large spatial databases with noise,” in Knowledge Discovery and Data Mining , 1996

    1996

  10. [18]

    Hierarchical grouping to optimize an objective function,

    J. H. Ward, “Hierarchical grouping to optimize an objective function,” Journal of the American Statistical Association , vol. 58, pp. 236–244, 1963

    1963

  11. [19]

    Data clustering: a review,

    A. K. Jain, M. N. Murty, and P. J. Flynn, “Data clustering: a review,” ACM Comput. Surv., vol. 31, pp. 264–323, 1999

    1999

  12. [20]

    Spann: Highly-efficient billion-scale approximate nearest neighbor search,

    Q. Chen, B. Zhao, H. Wang, M. Li, C. Liu, Z. Li, M. Yang, and J. Wang, “Spann: Highly-efficient billion-scale approximate nearest neighbor search,” ArXiv, vol. abs/2111.08566, 2021

    2021 arXiv

  13. [21]

    Qd-tree: Learning data layouts for big data analytics,

    Z. Yang, B. Chandramouli, C. Wang, J. Gehrke, Y . Li, U. F. Minhas, P.-˚A. Larson, D. Kossmann, and R. Acharya, “Qd-tree: Learning data layouts for big data analytics,” Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data , 2020

    2020

  14. [22]

    Dritter band: Analysis · grundlagen der mathematik · physik verschiedenes: Nebst einer lebensgeschichte,

    D. V . Hilbert, “Dritter band: Analysis · grundlagen der mathematik · physik verschiedenes: Nebst einer lebensgeschichte,” in Springer-Verlag, 1935

    1935

  15. [23]

    Clock-pro: An effective improvement of the clock replacement,

    S. Jiang, F. Chen, and X. Zhang, “Clock-pro: An effective improvement of the clock replacement,” in USENIX Annual Technical Conference, General Track, 2005

    2005

  16. [24]

    M-clock: migration-optimized page replacement algorithm for hybrid dram and pcm memory archi- tecture,

    M. Lee, D. Kang, J. Kim, and Y . I. Eom, “M-clock: migration-optimized page replacement algorithm for hybrid dram and pcm memory archi- tecture,” Proceedings of the 30th Annual ACM Symposium on Applied Computing, 2015

    2015

  17. [25]

    Individual household electric power cinsumption data set,

    “Individual household electric power cinsumption data set,” 2021

    2021

  18. [26]

    Vehicle, snowmobile, and boat registrations,

    “Vehicle, snowmobile, and boat registrations,” 2019

    2019

  19. [27]

    Are we ready for learned cardinality estimation?,

    X. Wang, C. Qu, W. Wu, J. Wang, and Q. Zhou, “Are we ready for learned cardinality estimation?,” Proc. VLDB Endow., vol. 14, pp. 1640– 1654, 2020

    2020

  20. [28]

    An adaptive striping architecture for flash memory storage systems of embedded systems,

    L.-P. Chang and T.-W. Kuo, “An adaptive striping architecture for flash memory storage systems of embedded systems,” Proceedings. Eighth IEEE Real-Time and Embedded Technology and Applications Symposium, pp. 187–196, 2002

    2002

  21. [29]

    The lru-k page replacement algorithm for database disk buffering,

    E. J. O’Neil, P. E. O’Neil, and G. Weikum, “The lru-k page replacement algorithm for database disk buffering,” ACM SIGMOD Record, vol. 22, pp. 297 – 306, 1993

    1993

  22. [30]

    Megiddo and D

    N. Megiddo and D. S. Modha, “Proceedings of fast ’03: 2nd usenix conference on file and storage technologies 2nd usenix conference on file and storage technologies arc: a self-tuning, low overhead replacement cache,”

  23. [31]

    Dulo: an effective buffer cache management scheme to exploit both temporal and spatial locality,

    S. Jiang, X. Ding, F. Chen, E. Tan, and X. Zhang, “Dulo: an effective buffer cache management scheme to exploit both temporal and spatial locality,” in USENIX Conference on File and Storage Technologies , 2005

    2005

  24. [32]

    Amc: an adaptive multi-level cache algorithm in hybrid storage systems,

    Y . Cheng, W. Chen, Z. Wang, X. Yu, and Y . Xiang, “Amc: an adaptive multi-level cache algorithm in hybrid storage systems,”Concurrency and Computation: Practice and Experience , vol. 27, pp. 4230 – 4246, 2015

    2015

  25. [33]

    Exploitation of different types of locality for web caches,

    G. Karakostas and D. N. Serpanos, “Exploitation of different types of locality for web caches,” Proceedings ISCC 2002 Seventh International Symposium on Computers and Communications , pp. 207–212, 2002

    2002

  26. [34]

    An adaptive dynamic replacement approach for a multicast based popularity aware prefix cache memory system,

    P. Jayarekha and T. R. G. Nair, “An adaptive dynamic replacement approach for a multicast based popularity aware prefix cache memory system,” ArXiv, vol. abs/1001.4135, 2010

    2010 arXiv

  27. [35]

    Driving cache replacement with ml-based lecar,

    G. Vietri, L. V . Rodriguez, W. A. Martinez, S. Lyons, J. Liu, R. Ran- gaswami, M. Zhao, and G. Narasimhan, “Driving cache replacement with ml-based lecar,” in USENIX Workshop on Hot Topics in Storage and File Systems , 2018

    2018

  28. [36]

    Learning relaxed belady for content distribution network caching,

    Z. Song, D. S. Berger, K. Li, and W. Lloyd, “Learning relaxed belady for content distribution network caching,” in Symposium on Networked Systems Design and Implementation , 2020

    2020

  29. [37]

    A learned cache eviction framework with minimal overhead,

    D. Yang, D. S. Berger, K. Li, and W. Lloyd, “A learned cache eviction framework with minimal overhead,” ArXiv, vol. abs/2301.11886, 2023

    2023 arXiv

  30. [38]

    Research on recognition mechanism of hot and cold data based on data temperature,

    X. Yulin, “Research on recognition mechanism of hot and cold data based on data temperature,” 3 2019

    2019

Pith tools

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