CS848 Paper Review Form - Fall 2006

Paper Title: SVL: Storage Virtualization Engine Leveraging DBMS Technology

Author(s): Lin Qiao, Balakrishna R. Iyer, Divyakant Agrawal, Amr El Abbadi

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 design of a block virtualization engine based on a DBMS
by defining mapping between logical blocks and physical blocks related 
by table space maps. Storage compression and encryption is achieved via 
existing DBMS functionality. Several optimization strategies are introduced, 
including static SQL, block accumulation, table direct access (TDA) for fixed 
length blocks indexing, index direct access (IDA) for variable length blocks, 
communication buffer caching. IPC Shared memory is utilized whenever DBMS 
client and server reside on the same controller. 
The experiments done in the paper are broad enough and provide a good comparison
between the different options, like fixed length blocks and compressed blocks.
Impact of DBMS optimization, IO size and IO traces is discussed.

The paper does a good job in both presenting its novel approach in a clear and
concise way. The experiments are well designed, give good examples of the proposed
techniques and verify the actual claims of the paper.


8) List 1-3 strengths of the paper.  (1-2 sentences each,
identified as S1, S2, S3.)

S1. Proposes an efficient way to handle variable length blocks

S2. Block accumulation and SQL procedures for READ / WRITE IOs

S3. Good experimental setup - use of traces and testing both fixed/compresed blocks

    

9) List 1-3 weaknesses of the paper (1-2 sentences each,
identified as W1, W2, W3.)

W1. To achieve good performance the DBMS engine code needs to be updated
    (CONCAT/DECONCAT functions). 
    
W2. In the beginning, a decision has to be made about whether to use
    fix length blocks or compression and what DBMS page size to use.
    Those cannot be dynamically changed later on.

W3. Reordering of records and indexes (table/index reorg) may be necessary
    when using variable length blocks / compression / encryption and
    a lot of insert / deletes / updates.
    
10) Detailed comments for authors.

- How difficult was to implement the CONCAT/DECONCAT functions and
  how do you estimate this can be done in other DBMS systems?
  Is there a reason why they can't be implemented as functions, without
  touching DBMS engine code?

- Is CONCAT/DECONCAT feasible when not using shared memory?

- You mention that the greater portion of stored data is less often accessed
  (80/20 rule). Is it feasible to compress just part of the data according
  to some dynamic statistics?
  
- When data is compressed, can k (number of virtual blocks mapped to one record)
  become dynamic in trying to achieve page-size tuple length (record length)?
  
- A reorg-like functionality may be useful, when not using fixed length blocks.

- How can the new table compression feature in DB2 v9 be of help to SVL?

- Can logical blocks be more than 512 bytes long and how can this be utilized by SVL?