sunblaze-ucb / elastic-sensitivity-experiments

Elastic sensitivity experiments using TCP-H benchmark

Overview

This class calculates error of elastic sensitivity-based differential privacy for queries from the TCP-H benchmark.

Building & Running

sbt run

Generating benchmark data

The /data directory contains the generated SQL queries and results of each query executed on a populated database with scale factor 1.

If you want to regenerate the queries and database from scratch, see the instructions in data/README.txt. You will need to import the data into a relational database to execute the benchmark queries.

elastic-sensitivity-experiments's Issues

Query 16 question

Hi folks! Me again. =/

I don't understand how query 16 works for you, and I thought I would talk through the inconsistencies I see.

Query 16 involves a join with suppliers: it reports for each (brand, type, size) the number of distinct suppliers of such a part who have no customer complaints in their comments field. Complaints seems like sensitive information for the supplier, and if each of the counts of any parts they supply changed as a result, that could leak through. Suppliers supply exactly 80 parts each, because skew doesn't exist in TPCH it seems, which makes me think that with 0.1-DP you'll need error of magnitude at least 800.

Each part is only supplied by four suppliers (this is all at scale factor 1), and almost all (brand, type, size) triples are represented by just a few parts (2/3rds by just one) so this noise should be pretty significant, I would think. That is, 800 relative to 4.

According to your schema the supplier relation is not public, but also there is no max_freq for PS_SUPPKEY in the partsupp relation. This is where I was expecting to see 80. Is it possible that this bound is just missing, and that when absent the analysis is overly optimistic?

Possibly related: in Query 04 you indicate in the paper that there is no join, but there is a join on orderkey between lineitem and orders (count orders with late lineitems, by priority). Should this join be present too? It seems like the cardinality isn't high (in PINQ it would be a join with a distinct applied to the order keys in late lineitems; cardinality one), but something should be there, right?

Is there a cute way you are getting around exists and not in fragments for these two queries?