Pith. sign in

REVIEW 3 major objections 4 minor 40 references

Lorentz: Learned SKU Recommendation Using Profile Data

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

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

Pith's one-line read Lorentz claims that cloud capacity for new databases can be chosen near-optimally from customer profile tags alone, cutting wasted capacity by over 60% without extra throttling, by rightsizing existing workloads and continuously…

desk verdict Lorentz is a coherent cold-start SKU recommendation framework with a real problem and a sensible Stage 1, but the >60% slack reduction headline is supported only by a circular synthetic evaluation and contradicted by the paper's own real-data results. read the letter →

arxiv 2411.11325 v1 pith:AGBYLY2L submitted 2024-11-18 cs.DB

Nicholas Glaze , Tria McNeely , Yiwen Zhu , Matthew Gleeson , Helen Serr , Rajeev Bhopi , Subru Krishnan This is my paper · ORCID
classification cs.DB
keywords SKUrecommendationcloudprovisioningcapacityrightsizingcustomerprofiledatapersonalizationslackreductionthrottlingtargetencoding
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

Lorentz is a three-stage system for recommending the initial compute capacity, or SKU, of a cloud database before any workload has run on it. The paper's central claim is that customer profile tags—industry, segment, subscription, resource group—carry enough signal about future capacity needs to beat both user choices and static defaults: on Azure PostgreSQL DB, Lorentz cuts wasted capacity by more than 60% without increasing throttling. The system first rightsizes existing databases from their usage telemetry to create reliable training labels, then learns a mapping from profile features to rightsized capacity, and finally personalizes each recommendation by learning the customer's price-versus-performance preference from satisfaction signals. If the claim holds, new cloud resources can be provisioned near-optimally at creation time, saving cost and avoiding throttling without requiring workload traces.

What carries the argument

The load-bearing mechanism is the three-stage pipeline plus one identity: the personalized recommendation is a multiplicative shift in log-capacity space, $c^{**} = b^{\lambda} c^{*}$, so the learned parameter $\lambda$ is interpretable as 'how many powers of $b$ to raise or lower the Stage 2 prediction.' Stage 1's rightsizing optimizer selects the SKU whose slack is closest to a target $s^{*}$ subject to a throttling bound $\tau$, treating censored workloads specially by requiring at least $2K \times$ current capacity. Stage 2's hierarchical provisioner learns a feature hierarchy from profile data via an entropy-based method and recommends the $p$-th percentile of rightsized capacities from the coarsest bucket with enough samples; the target-encoding alternative replaces each categorical tag with the mean label of that tag's bucket and feeds the encodings to a gradient-boosted tree model. Stage 3's personalizer stores a $\lambda$-profile per customer, subscription, resource group, and server offering, and updates it by weighted message propagation with decay factors across stratifications, resource groups, and subscriptions.

What would settle it

Run Lorentz end-to-end on a fresh cloud service whose profile tags have been randomly permuted across customers, or on the real unmodified production workloads without the synthetic upscaling; if slack reduction against static defaults collapses toward zero, the claim that profile data alone carries the capacity signal is refuted. The paper already reports that on unmodified production data the provisioners only match default baselines, which is the same experiment at a smaller scale.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that SKU selection for newly created cloud resources can be treated as a supervised learning problem whose labels come from a rightsizing pass over existing users rather than from the users' own, often wrong, choices. Stage 1 computes a rightsized capacity for each existing database by minimizing slack subject to a zero-throttling constraint, using a censored-workload rule that scales throttled machines up by at least $2K$. Stage 2 offers two provisioners—a hierarchical bucket model that recommends the $p$-th percentile of rightsized capacities among similar customers, and a target-encoding model that feeds encoded profile tags into a tree-based regressor. Stage 3 adjusts the Stage 2 recommendation by a per-customer score $\lambda$ through $c^{**} = b^{\lambda} c^{*}$, learned by propagating sparse satisfaction signals across resource groups and subscriptions. The paper reports that the provisioners reduce mean slack by 66% (hierarchical) and 54% (target encoding) at comparable throttling on synthetically upscaled workloads, and that the personalizer converges in simulation to within half a capacity step of the true preference.

Load-bearing premise

The entire headline reduction depends on customer profile tags (industry, segment, resource group) actually predicting how much compute a new database will need, and on the synthetic test in Section 5.2—which makes workloads larger exactly for customers with certain profile tags—being a realistic stand-in for real workload diversity.

Editorial extensions

If this is right

  • New database instances receive a recommended SKU at creation time, before any workload trace exists, which removes the default-minimum bias that leads many users to pick the smallest option.
  • Across the evaluated synthetic workload diversity, following the recommendation instead of user selections or defaults reduces wasted capacity by over 60% at the same throttling level.
  • The hierarchical provisioner retains near-full accuracy when trained on only 10% of the data, so the approach is deployable where labeled examples are scarce.
  • The personalization loop converges to within half a SKU step of true preference in simulation even with sparse and noisy feedback signals.
  • Because the system keeps the similar-customer buckets and the learned $\lambda$ profile, it can present the user with the matching customers and the current preference score as an explanation for each recommendation.

Reading between the lines

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

  • The gap between the synthetic results (66% slack reduction) and unmodified production results (matching defaults) suggests the realized benefit on a new service will be proportional to how much real profile-tag diversity exists; a service with uniform low-usage workloads cannot expect the headline gain.
  • Because $\lambda$ multiplies capacity in powers of two, the reported convergence error of 0.5 corresponds to recommending an adjacent SKU size; the personalizer's guarantees are therefore discrete-grid guarantees, not continuous capacity accuracy.
  • Randomizing or anonymizing profile tags would make a clean stress test: if slack reduction survives, the model is exploiting some other signal, and if it collapses, the tags are doing the work.
  • The same pipeline could be applied to any cloud resource with billing and profile tags, and adding trace data when it becomes available would tighten within-bucket SKU variability, bridging offline initial provisioning and later autoscaling.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 presents Lorentz, a three-stage system for recommending initial cloud compute SKUs without workload traces: (1) rightsizing existing workloads from utilization telemetry to produce training labels, (2) two profile-data-based provisioners (a hierarchical bucket model and a target-encoding tree model), and (3) an online personalizer that adjusts recommendations using customer satisfaction signals. The authors evaluate on production data from Azure PostgreSQL DB and on synthetic workloads, claiming that Lorentz reduces slack by over 60% without increasing throttling and that the personalizer converges to true customer preferences. The central claim is shown to rest on the synthetic upscaling experiment, while the unmodified production-data evaluation reports only a 33% maximum possible slack reduction and no improvement over default baselines.

Significance. If the headline result were valid, Lorentz would be a practically valuable contribution: it addresses a real provisioning problem, requires no workload traces, provides explainable recommendations, and includes a feedback loop for personalization. The production rightsizing analysis (Stage 1) and the synthetic personalization convergence study are useful engineering contributions, and the paper is generally well written. However, the central quantitative claim is not supported by the evidence presented. On unmodified production data the provisioners do not beat defaults, and the >60% figure comes from a synthetic experiment whose label-generation procedure injects the same profile features that the provisioners consume. Because the main claimed advantage over existing approaches depends exactly on profile data being informative of workload demand, and because that informativeness is not established, the contribution as stated is not credible.

major comments (3)
  1. [§5.2 (Synthetic workload upscaling; Provisioner evaluation)] The paper's headline result—'reducing slack by >60%' (Abstract and Section 7)—is obtained from the synthetic upscaling experiment, not from unmodified production data. In that experiment, each workload is multiplied by 2^{χ_w}, where χ_w is computed by assigning scale factors to the three profile features ResourceGroup, CloudCustomerGuid, and VerticalName; these are exactly the features used by the hierarchical and target-encoding provisioners. The evaluation thus demonstrates largely that the models can recover a dependency injected by the label-generation process. The paper itself acknowledges in the final paragraph of Section 5.2 that 'it's important that any VM profile data used as inputs is verified to be informative of their corresponding workloads,' but no such verification is provided. On the unmodified production test set, Section 5.2 reports that the provisioners 'achieve similar average slack to default-value baselines at most throttling ratios, with a maximum possible slack reduction of 33%.' Therefore the central quantitative claim is unsupported for real deployments.
  2. [Abstract; §7 (Conclusion)] The abstract and conclusion state that evaluation on production data demonstrates >60% slack reduction or elimination of >60% of wasted COGS. This is inconsistent with Section 5.2, which reports a maximum possible slack reduction of 33% on the real test set and cost reductions of 27% (hierarchical) and 8% (target encoding) relative to user selection. The >60% number appears only in the synthetic workload experiment. The claims in the abstract and conclusion must be corrected to attribute the result to synthetic data, or the synthetic experiment must be shown to be representative of production conditions; as written, the paper overstates what was measured.
  3. [§3.2, Eq. (9); Table 2] The rightsizing of censored workloads assumes that the desired capacity is at least 2^K times the currently selected capacity for every throttled workload, with K = 1 in the experiments. This is an assumption, not derived from data; the text says K can be calibrated using telemetry of formerly throttled servers whose capacities were scaled up, but no such calibration evidence is presented. If this assumption is inaccurate, the Stage 1 labels are systematically biased, and that bias propagates through Stage 2 and inflates apparent slack improvements. Please provide the calibration analysis or a sensitivity study over K.
minor comments (4)
  1. [§2.2; §1] The statement that users select the ideal capacity only 43% of the time is defined relative to Lorentz's own rightsized capacities ('relative to Lorentz's rightsized capacities (see Section 3.2)'), not against an independent ground truth. The abstract and introduction phrase this as an objective fact about user behavior; the paper should make the relativity explicit in those places.
  2. [§5.2, Figure 10] The Pareto comparison to user selections is implemented through default-value baselines, justified by the observation that 89% of users choose the default or the next larger vCore value. This is a reasonable approximation, but the slack-reduction percentages in the text are relative to these default baselines rather than to the actual user-selected SKU distribution on the upscaled test set; the comparison should be stated more precisely.
  3. [§5.3.1] There are several typos in this subsection: 'geenrated' should be 'generated', 'labled' should be 'labeled', and in the caption of Figure 7 'defied decay rate' should be 'defined decay rate'.
  4. [§5.1, Figure 9] The Stage 1 evaluation uses absolute slack (slack ratio multiplied by capacity), while the rightsizing optimizer in Eq. (7) operates on slack ratios. The text notes this is deliberate for business cost alignment, but the discrepancy between the optimized objective and the reported metric should be discussed explicitly, since the 34% slack reduction may partly reflect the weighting rather than the rightsizing criterion.

Circularity Check

2 steps flagged · score 6.0 of 10

Headline >60% slack-reduction claim is carried by a synthetic test set whose upscaling injects the very profile features the provisioners consume; on unmodified production data the paper reports only baseline-comparable performance with a 33% upper bound.

  1. self definitional [Section 5.2, 'Synthetic workload upscaling' and 'Provisioner evaluation']
    "To upscale the Azure PostgreSQL DB workloads, we first compute the hierarchy present in their profile features using Step 1 of the hierarchical provisioner, from most to least granular. We then upscale workloads with the following steps: (1) Select three features throughout the hierarchy, and assign them global scale factors–ResourceGroup: 1, CloudCustomerGuid: 1, VerticalName: 3; ... (4) Upscale each workload as 2𝜒𝑤·𝑤[𝑛]; (5) Recompute the rightsized capacities."

    The rightsized labels in the synthetic test set are defined by multiplying each real workload by 2^chi_w, and chi_w is a function of exactly the same three profile features (ResourceGroup, CloudCustomerGuid, VerticalName) that the hierarchical and target-encoding provisioners are trained on. Evaluating the provisioners on these upscaled workloads therefore demonstrates only that the models can recover a feature-label dependency that the data-generation step itself inserted. The reported headline reductions, 66% mean slack for the hierarchical provisioner and 54% for the target encoder, are measured on this synthetic set.

  2. self definitional [Section 2.2, Dataset Summary; referenced in Abstract and Section 1]
    "Users select the ideal resource capacity only 43% of the time: 19% over-provision and 38% of the time under-provision, relative to Lorentz’s rightsized capacities (see Section 3.2)."

    The 43% 'correctly chosen' statistic, used in the abstract and introduction to motivate Lorentz, is defined relative to Lorentz's own Stage 1 rightsizing labels. Those labels are produced by the paper's optimizer (Equations 7-9) under its chosen slack target s* = 0.5 and zero-throttling constraint, so the statistic measures agreement with Lorentz's own criterion rather than with an independent ground truth. This is a self-referential framing statistic: it does not by itself invalidate the system, but it makes the motivation depend on Lorentz's own definition of 'right-sized.'

full rationale

The load-bearing quantitative claim, over 60% slack reduction, is not established independently of the paper's own label-construction procedure. On the unmodified production test set, Section 5.2 states that the provisioners 'achieve similar average slack to default-value baselines at most throttling ratios, with a maximum possible slack reduction of 33%.' The >60% figure comes exclusively from the 'Synthetic workload upscaling' procedure, which multiplies each workload by 2^chi_w and assigns chi_w from the same profile features (ResourceGroup, CloudCustomerGuid, VerticalName) that the provisioners are trained on. This makes the synthetic evaluation a recovery of an injected feature-label dependency rather than evidence that real profile data predicts real capacity demand. Because the abstract and conclusion present the >60% number as a production-data result, the headline claim inherits the circularity. The Stage 3 personalization simulation is also internally generated: ground-truth lambdas are assumed, signals are generated by comparing current recommendations to the resulting optimal capacities, and the updater is tested against those same lambdas; this is a legitimate convergence test but does not validate the signal-generation assumptions. The paper is transparent about the synthetic step and even warns that profile data 'must be verified to be informative of their corresponding workloads,' but that verification is not supplied. No load-bearing self-citation chain was found; Doppler and related work are used for contrast, and HALO is external.

Assumptions & free parameters 8 free parameters · 5 assumptions · 0 invented entities

The central result rests on several hand-set parameters in the rightsizing optimizer (s*, tau, eta, K), on the untested premise that profile tags predict workload demand, and on a synthetic evaluation that constructs labels from profile features. No independent external benchmark is provided; the only external check, the real Azure test set, does not show the headline improvement.

free parameters (8)
  • rightsizing slack target s*_CPU = 0.5
    Table 2 sets the Stage 1 optimizer's target slack to 50% CPU utilization. This single number defines 'right-sized' for every existing database and therefore controls all training labels for Stage 2.
  • throttling limit tau = 0
    Table 2 sets the maximum allowed throttling probability to 0 in Equation (7), so any throttling event marks a database as underprovisioned. Combined with eta=0.95, it shapes the labels.
  • utilization threshold eta_r = 0.95
    Table 2 sets the ratio above which a resource is considered throttled. Lower values would generate more underprovisioned labels.
  • throttled rightsizing multiplier K = 1
    Equation (8) assumes censored (throttled) workloads should be rightsized to at least 2^K times current capacity. No calibration is shown; this heuristic affects labels for the 38% of workloads classified as underprovisioned.
  • hierarchy threshold gamma = 0.6
    Table 2; empirically selected to include only strong hierarchies. It determines which feature pairs are used in building the bucket hierarchy.
  • bucket percentile p = 50
    Table 2; hierarchical provisioner returns the 50th percentile of capacities in the matched bucket. Changing p changes all recommendations.
  • learning rate and decay for personalizer = 0.3 and 0.25
    Table 2; the message propagation update in Algorithm 1 uses these; the paper does not test sensitivity on production signals.
  • synthetic upscaling scale factors = ResourceGroup=1, CloudCustomerGuid=1, VerticalName=3
    Section 5.2; hand-chosen factors applied to real workloads to create a more diverse test set. These factors inject a feature-label correlation that later inflates the provisioners' apparent accuracy.
assumptions (5)
  • domain assumption Customer profile data (industry, segment, resource group) is predictive of compute capacity requirements.
    Section 5.2 assumes this when generating synthetic workloads by scaling real usage according to profile features; the production evaluation does not validate it, and real-data results show no improvement over defaults.
  • domain assumption Rightsized capacities from Stage 1 are the correct ground-truth labels for training recommenders.
    Section 3.2; this equates 'rightsized' with the outcome of the slack/throttling optimizer, a modeling choice not independently justified.
  • ad hoc to paper For censored workloads, the true desired capacity is at least 2^K times the currently selected capacity.
    Equation (8) uses K=1 to rightsize throttled workloads; the paper mentions calibrating K from scaled-up servers but provides no calibration data.
  • domain assumption Keyword matching in CRI tickets reliably classifies customer sentiment as price-sensitive, performance-sensitive, or neutral.
    Section 3.4.2; the keyword lists in Table 1 are manually crafted, and the distribution (5 price-sensitive, ~2000 performance-sensitive out of 4400) is treated as ground truth.
  • ad hoc to paper Message propagation with multiplicative decays across resource groups, subscriptions, and stratifications captures real customer preferences.
    Section 3.4.3 and Algorithm 1; convergence is demonstrated only in simulation with known lambda values; the decay parameters are not calibrated to production feedback.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Lorentz: Learned SKU Recommendation Using Profile Data." pith.science (2026). https://pith.science/paper/AGBYLY2L

@misc{pith2026241111325,
  author       = {Pith},
  title        = {Pith review of: Lorentz: Learned SKU Recommendation Using Profile Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AGBYLY2L}},
  note         = {Machine review of arXiv:2411.11325}
}
read the original abstract

Cloud operators have expanded their service offerings, known as Stock Keeping Units (SKUs), to accommodate diverse demands, resulting in increased complexity for customers to select appropriate configurations. In a studied system, only 43% of the resource capacity was correctly chosen. Automated solutions addressing this issue often require enriched data, such as workload traces, which are unavailable for new services. However, telemetry from existing users and customer satisfaction feedback provide valuable insights for understanding customer needs and improving provisioning recommendations. This paper introduces Lorentz, an intelligent SKU recommender for provisioning compute resources without relying on workload traces. Lorentz uses customer profile data to forecast resource capacities for new users by profiling existing ones. It also incorporates a continuous feedback loop to refine recommendations based on customer performance versus cost preferences inferred from satisfaction signals. Validated with production data from Azure PostgreSQL DB, Lorentz achieves over 60% slack reduction without increasing throttling compared to user selections and existing defaults. Evaluations with synthetic data demonstrate Lorentz's ability to iteratively learn user preferences with high accuracy.

Figures

Figures reproduced from arXiv: 2411.11325 by the authors.

Figure 1
Figure 1. Users improperly provision many resources on Azure PostgreSQL DB (flexible server). [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Rightsizing focuses the capacity distribution to prevent over- and under-provisioning. [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Inputs and outputs of each stage of the Lorentz capacity recommendation framework [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: CPU slack and throttling for under-provisioned (left), over-provisioned (center), and well-provisioned [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Example of the learned hierarchy and buckets. Transformations. For regression methods, the exponential scale of many compute resources (e.g., vCores ∈ {1, 2, 4, 8, 16, ...}) can lead to undesirable statistical properties, including heteroskedastic noise [36], which in …
Figure 7
Figure 7. Figure 7: Example of updating 𝜆 with exaggerated numbers: signal 𝛾 = 1, learning rate 𝑙𝑟 = 2, and decays 𝜌𝑅 = 1/2, 𝜌𝑆 = 1/2, and 𝜌𝐶 = 1/4. preferences in addition to RG-specific preferences. However, as signals become more common, it may be preferable to set 𝜌𝑆 = 0 to prevent sh…
Figure 8
Figure 8. Figure 8: Lorentz leverages an offline pipeline for frequent retraining and prediction pre-computation. • Publish Data (C): We use a cloud-based ETL service to copy the new predictions to an online prediction store which provides low-latency lookup with built-in authentication a…
Figure 9
Figure 9. Figure 9: Capacity rightsizing reduces slack and throttling over user selections [PITH_FULL_IMAGE:figures/full_fig_p018_9.png]
Figure 10
Figure 10. Figure 10: Lorentz provisioners improve the slack/throttling Pareto frontier over baselines. [PITH_FULL_IMAGE:figures/full_fig_p019_10.png]
Figure 11
Figure 11. Figure 11: Lorentz provisioners improve slack while keeping average throttling<10% over baseline. [PITH_FULL_IMAGE:figures/full_fig_p019_11.png]
Figure 12
Figure 12. Figure 12: The hierarchical provisioner is robust to data quantity. [PITH_FULL_IMAGE:figures/full_fig_p019_12.png]
Figure 13
Figure 13. Figure 13: Lorentz’s Stage 3 converges rapidly in all simulations. [PITH_FULL_IMAGE:figures/full_fig_p022_13.png]
Figure 14
Figure 14. Figure 14: Stage 3 converges rapidly when customer signals are accurate. [PITH_FULL_IMAGE:figures/full_fig_p023_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 38 canonical work pages

  1. [1]

    2024.AmazonWebService

    Amazon.com, Inc. 2024.AmazonWebService. Retrieved Jan 4, 2024 from https://aws.amazon.com/

    work page 2024

  2. [2]

    Joyce Cahoon, Wenjing Wang, Yiwen Zhu, Katherine Lin, Sean Liu, Raymond Truong, Neetu Singh, Chengcheng Wan, Alexandra Ciortea, Sreraman Narasimhan, and Subru Krishnan. 2022. Doppler: Automated SKU Recommendation in Migrating SQL Workloads to the Cloud.Proc.VLDBEndow.15, 12 (aug 2022), 3509–3521. https://doi.org/10.14778/ 3554821.3554840

    arXiv 2022

  3. [3]

    Rodrigo N Calheiros, Enayat Masoumi, Rajiv Ranjan, and Rajkumar Buyya. 2014. Workload prediction using ARIMA model and its impact on cloud applications’ QoS.IEEE transactionson cloudcomputing 3, 4 (2014), 449–458

    work page 2014

  4. [4]

    Surajit Chaudhuri and Vivek Narasayya. 2007. Self-Tuning Database Systems: A Decade of Progress. InVLDB ’07. 3–14

    work page 2007

  5. [5]

    Eli Cortez, Anand Bonde, Alexandre Muzio, Mark Russinovich, Marcus Fontoura, and Ricardo Bianchini. 2017. Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms. In Proceedingsof the 26th Symposiumon Operating SystemsPrinciples. 153–167. Proc. ACM Manag. Data, Vol. 2, No. 3 (SIGMOD), Article 149....

    work page 2017

  6. [6]

    MLOS: An infrastructure for automated software performance engineering

    Carlo Curino, Neha Godwal, Brian Kroth, Sergiy Kuryata, Greg Lapinski, Siqi Liu, Slava Oks, Olga Poppe, Adam Smiechowski, Ed Thayer, et al.2020. MLOS: An infrastructure for automated software performance engineering. In DEEM. 1–5

    work page 2020

  7. [7]

    Robert Dale. 2021. GPT-3: What’s it good for?NaturalLanguageEngineering 27, 1 (2021), 113–118

    work page 2021

  8. [8]

    Sudipto Das, Feng Li, Vivek R Narasayya, and Arnd Christian König. 2016. Automated demand-driven resource scalinginrelationaldatabase-as-a-service.In Proceedingsofthe2016InternationalConferenceonManagementofData. 1923–1934

    work page 2016

Show all 40 references
  1. [9]

    Christina Delimitrou and Christos Kozyrakis. 2014. Quasar: Resource-efficient and qos-aware cluster management. ACMSIGPLAN Notices 49, 4 (2014), 127–144

    2014

  2. [10]

    Avrilia Floratou, Ashvin Agrawal, Bill Graham, Sriram Rao, and Karthik Ramasamy. 2017. Dhalion: self-regulating stream processing in heron.Proceedings ofthe VLDB Endowment 10, 12 (2017), 1825–1836

    2017

  3. [11]

    Zhenhuan Gong, Xiaohui Gu, and John Wilkes. 2010. Press: Predictive elastic resource scaling for cloud systems. In 2010 International Conferenceon Networkand Service Management. Ieee, 9–16

    2010

  4. [12]

    Vladimir Gorodetsky, Vladimir Samoylov, and Olga Tushkanova. 2014. Agent-based customer profile learning in 3G rec- ommendingsystems.In Proceedingsof9-thInternationalWorkshoponAgentandDataMiningInteraction(ADMI-2014) Associated withInternational Conferenceon AutonomousAgentsan...

    2014

  5. [13]

    Léo Grinsztajn, Edouard Oyallon, and Gaël Varoquaux. 2022. Why do tree-based models still outperform deep learning on typical tabular data?Advancesin NeuralInformationProcessing Systems 35 (2022), 507–520

    2022

  6. [14]

    Michael Hammer and Arvola Chan. 1976. Index Selection in a Self-Adaptive Data Base Management System. In SIGMOD. 1–8

    1976

  7. [15]

    Sadeka Islam, Jacky Keung, Kevin Lee, and Anna Liu. 2012. Empirical prediction models for adaptive resource provisioning in the cloud.FutureGeneration Computer Systems 28, 1 (2012), 155–162

    2012

  8. [16]

    Jaeyong Kang and Kwang Mong Sim. 2010. Cloudle: a multi-criteria cloud service search engine. In2010 IEEE Asia-PacificServices Computing Conference. IEEE, 339–346

    2010

  9. [17]

    Lightgbm: A highly efficient gradient boosting decision tree

    GuolinKe,QiMeng,ThomasFinley,TaifengWang,WeiChen,WeidongMa,QiweiYe,andTie-YanLiu.2017. Lightgbm: A highly efficient gradient boosting decision tree. InAdvancesinneural informationprocessing systems. 3146–3154

    2017

  10. [18]

    Arijit Khan, Xifeng Yan, Shu Tao, and Nikos Anerousis. 2012. Workload characterization and prediction in the cloud: A multiple time series approach. In2012 IEEE NetworkOperations andManagementSymposium. IEEE, 1287–1294

    2012

  11. [19]

    Aliki Kopaneli, George Kousiouris, Gorka Echevarria Velez, Athanasia Evangelinou, and Theodora Varvarigou. 2015. A model driven approach for supporting the Cloud target selection process.Procedia Computer Science 68 (2015), 89–102

    2015

  12. [20]

    Matthew J Kushin and Kelin Kitchener. 2009. Getting political on social network sites: Exploring online political discourse on Facebook.FirstMonday (2009)

    2009

  13. [21]

    PythonimplementationofHALO

    Lotcher.Bowaer.2024. PythonimplementationofHALO. RetrievedJan4,2024fromhttps://github.com/lotcher/HALO

    2024

  14. [22]

    2006.Oracle Database 10g Release 2: The Self-Managing Database

    Oracle. 2006.Oracle Database 10g Release 2: The Self-Managing Database. Technical Report. Oracle

    2006

  15. [23]

    Oracle. 2021. Oracle Database. https://www.oracle.com/database/. Accessed: 2021-11-03

    2021

  16. [24]

    Pradeep Padala, Kai-Yuan Hou, Kang G Shin, Xiaoyun Zhu, Mustafa Uysal, Zhikui Wang, Sharad Singhal, and Arif Merchant. 2009. Automated control of multiple virtualized resources. InProceedings of the 4th ACM European conferenceon Computer systems. 13–26

    2009

  17. [25]

    Sasa Petrovic, Miles Osborne, and Victor Lavrenko. 2011. Rt to win! predicting message propagation in twitter. In Proceedings ofthe international AAAI conferenceonwebandsocial media, Vol. 5. 586–589

    2011

  18. [26]

    Olga Poppe, Tayo Amuneke, Dalitso Banda, Aritra De, Ari Green, Manon Knoertzer, Ehi Nosakhare, Karthik Rajendran, Deepak Shankargouda, Meina Wang, et al. 2020. Seagull: An infrastructure for load prediction and optimized resource allocation. arXiv preprint arXiv:2009.12922 (2020)

    2020 arXiv

  19. [27]

    Olga Poppe, Qun Guo, Willis Lang, Pankaj Arora, Morgan Oslake, Shize Xu, and Ajay Kalhan. 2022. Moneyball: proactive auto-scaling in Microsoft Azure SQL database serverless.ProceedingsoftheVLDBEndowment15, 6 (2022), 1279–1287

    2022

  20. [28]

    Nilabja Roy, Abhishek Dubey, and Aniruddha Gokhale. 2011. Efficient autoscaling in the cloud using predictive models for workload forecasting. In2011IEEE 4thInternational Conferenceon Cloud Computing. IEEE, 500–507

    2011

  21. [29]

    Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, Przemyslaw Zych, Przemyslaw Broniek, Jarek Kusmierek, Pawel Nowak, Beata Strack, Piotr Witusowski, Steven Hand, et al. 2020. Autopilot: workload autoscaling at Google. In Proceedings ofthe FifteenthEuropean Conferenceon Compu...

    2020

  22. [30]

    Andrey Sadovykh, Christian Hein, Brice Morin, Parastoo Mohagheghi, and Arne J Berre. 2011. REMICS-REuse and Migration of legacy applications to Interoperable Cloud Services. InEuropean Conferenceon a Service-Based Internet. Springer, 315–316

    2011

  23. [31]

    2023.CRM101:WhatisCRM? Retrieved Dec 24, 2023 from https://www.salesforce.com/crm/what- is-crm/ Proc

    Salesforce, Inc. 2023.CRM101:WhatisCRM? Retrieved Dec 24, 2023 from https://www.salesforce.com/crm/what- is-crm/ Proc. ACM Manag. Data, Vol. 2, No. 3 (SIGMOD), Article 149. Publication date: June 2024. Lorentz: Learned SKU Recommendation Using Profile Data (DMDS) 149:25

    2023

  24. [32]

    Mohanbir Sawhney, Birju Shah, Ryan Yu, Evgeny Rubtsov, and Pallavi Goodman. 2019. Uber: Applying Machine Learning to Improve the Customer Pickup Experience.KelloggSchoolof ManagementCases (2019), 1–21

    2019

  25. [33]

    Scikit-learn. 2023. GradientBoostingRegression. Retrieved Oct 4, 2023 from https://scikit-learn.org/stable/auto_ examples/ensemble/plot_gradient_boosting_regression.html

    2023

  26. [34]

    Scikit-learn. 2023. RandomForestRegressor. Retrieved Oct 4, 2023 from https://scikit-learn.org/stable/modules/ generated/sklearn.ensemble.RandomForestRegressor.html

    2023

  27. [35]

    Rebecca Taft, Nosayba El-Sayed, Marco Serafini, Yu Lu, Ashraf Aboulnaga, Michael Stonebraker, Ricardo Mayerhofer, and Francisco Andrade. 2018. P-store: An elastic database system with predictive provisioning. InProceedingsofthe 2018 International Conferenceon Managementof Data...

    2018

  28. [36]

    2023.AmazonWebService

    Wikipedia. 2023.AmazonWebService. Retrieved Oct 4, 2023 from https://en.wikipedia.org/wiki/Homoscedasticity_ and_heteroscedasticity

    2023

  29. [37]

    Xu Zhang, Chao Du, Yifan Li, Yong Xu, Hongyu Zhang, Si Qin, Ze Li, Qingwei Lin, Yingnong Dang, Andrew Zhou, et al. 2021. Halo: Hierarchy-aware fault localization for cloud systems. InProceedings of the 27th ACM SIGKDD Conferenceon KnowledgeDiscovery&DataMining. 3948–3958

    2021

  30. [38]

    KEA:TuninganExabyte-ScaleDataInfrastructure.In Proceedings of the 2021 International ConferenceonManagementofData

    Yiwen Zhu, Subru Krishnan, Konstantinos Karanasos, Isha Tarte, Conor Power, Abhishek Modi, Manoj Kumar, Deli Zhang,KartheekMuthyala,NickJurgens,etal .2021. KEA:TuninganExabyte-ScaleDataInfrastructure.In Proceedings of the 2021 International ConferenceonManagementofData. 2667–2680

    2021

  31. [39]

    Yiwen Zhu, Yuanyuan Tian, Joyce Cahoon, Subru Krishnan, Ankita Agarwal, Rana Alotaibi, Jesús Camacho-Rodriguez, Bibin Chundatt, Andrew Chung, Niharika Dutta, Andrew Fogarty, Anja Gruenheid, Brandon Haynes, Matteo Interlandi, Minu Iyer, Nick Jurgens, Sumeet Khushalani, Brian Kr...

    2023

  32. [40]

    Paolo Zicari, Gianluigi Folino, Massimo Guarascio, and Luigi Pontieri. 2021. Discovering accurate deep learning based predictive models for automatic customer support ticket classification. InProceedingsofthe36thAnnualACM SymposiumonAppliedComputing(VirtualEvent,RepublicofKore...

    2021

Pith tools

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