1) Is the problem real?
For secondary attributes query, the previous solution of using in-memory index has the problem of high memory footprints. The solution for this problem is to compress data, or only cache hot data. However, for either case, it introduces latency on either decompress data or disk I/O
2) What is the solution’s main idea (nugget)?
Query on compressed data. The main idea is twofold.
1 store an entropy-compressed representation of the input data, which enable random access.
2 enable query directly on the compressed data.
3) Why is solution different from previous work?
For secondary attributes query, there are basically two categories of works.
1) the previous arts use column oriented stores. the data scan introduce high latency and low network throughput.
2) the second one is to build index. However, the index memory footprint is too large. When using compression on the footprint, the corresponding response time has higher latency since they need to first decompress the index before query. When only cache hot data, the latency is introduced by the disk IO.
Succinct directly query on compressed data.
4) Does the paper (or do you) identify any fundamental/hard trade-offs?
The first time of pre-processing data (i.e. compress function) is an overhead. In addition, Succinct currently cannot support for data updates.
5) Do you think the paper will be influential in 10 years? Why or why not?
Maybe. To me, I think it is a more compacted and sorted data representation type. Data compression is always a topic in system. Since it currently has many shortcomings (e.g. cannot support updates, etc), I think it will have several follow up works to fix it.
No comments:
Post a Comment