CS848 Paper Review Form - Fall 2006 Paper Title: Relaxed Currency and Consistency: How to Say "Good Enough" in SQL Author(s): H. Guo, P.-A. Larson, R. Ramakrishnan, J. Goldstein 1) Is the paper technically correct? [x] Yes [ ] Mostly (minor flaws, but mostly solid) [ ] No 2) Originality [ ] Very good (very novel, trailblazing work) [x] Good [ ] Marginal (very incremental) [ ] Poor (little or nothing that is new) 3) Technical Depth [ ] Very good (comparable to best conference papers) [x] Good (comparable to typical conference papers) [ ] Marginal depth [ ] Little or no depth 4) Impact/Significance [ ] Very significant [x] Significant [ ] Marginal significance. [ ] Little or no significance. 5) Presentation [x] Very well written [ ] Generally well written [ ] Readable [ ] Needs considerable work [ ] Unacceptably bad 6) Overall Rating [ ] Strong accept (very high quality) [x] Accept (high quality - would argue for acceptance) [ ] Weak Accept (marginal, willing to accept but wouldn't argue for it) [ ] Weak Reject (marginal, probably reject) [ ] Reject (would argue for rejection) 7) Summary of the paper's main contribution and rationale for your recommendation. (1-2 paragraphs) This paper proposes a way to offload the work of guaranteeing currency and consistency (C&C) constraints of cached data to the DBMS. To ensure consistency, the concept of consistency class is introduced, where data of same class belongs to the same snapshot. To provide these requirements in queries, a new SQL clause is introduced. The paper accounts for code modifications to a cost-based optimizer as well. Consistency constraints are enforced at compile time, while currency constraints at run time by checking currency of local replicas. For this useful and innovative approach, I recommend an "Accept" rating. 8) List 1-3 strengths of the paper. (1-2 sentences each, identified as S1, S2, S3.) - Offloads responsibility of C&C to DBMS and thus greatly simplifies replica and application management. - Offers a cost-based approach optimization, i.e. not all reads need to be done at replica site. - Provides option to provide consistency in time ordering of queries. Two queries that are time ordered can read consistent data, rather than data with different level of staleness. 9) List 1-3 weaknesses of the paper (1-2 sentences each, identified as W1, W2, W3.) - Do not implement and analyze the grouping columns. - Need to test a larger load to see if overhead is really not that large - Use DBMS specific features, like SwitchUnion and could improve on the optimizer 10) Detailed comments for authors. Q1 - How can caching be better utilized in this new model? Which ones would be most cost/time effective and thus implemented first? Q2 - How did you estimate the "ideal" overhead of the workloads you ran? How about a more realistic scenario, including different TPCC/TPCH benchmarks. Q3 - Can eager and lazy replication be mixed here in this model: Since staleness of certain data sources (tables) is allowed, some of them can be eagerly replicated. i.e. table A is always eagerly replicated on particular nodes and thus it can be used there. How much modifications to your model are necessary for that?