I saw an instance of your talk at another venue. At the time I was learning about bitmap indexes (because we needed OLAP capabilities on a another database engine that is not postgres). Your talk reminded me furiously of them, but in the end I was not able to further investigate the difference.
How does your technology differ from bitmap indexes? Have you solved the performance problem of updating random rows, for example?
Combining OLAP without OLTP (large aggregate queries + lots of real time updates) is the holy grail that Cassandra, for example, has addressed rather nicely.
Compressed bitmap indexes are awesome. Like most indexes, the updating random rows problem is best addressed using a log structured merge tree and amortizing your index updates. Just have an in-memory buffer of recently updated rows.
If you are doing mostly sums & counts type work and can deal with some level of inaccuracy, you can consider HyperLogLog...
Comments
I saw an instance of your talk at another venue. At the time I was learning about bitmap indexes (because we needed OLAP capabilities on a another database engine that is not postgres). Your talk reminded me furiously of them, but in the end I was not able to further investigate the difference.
How does your technology differ from bitmap indexes? Have you solved the performance problem of updating random rows, for example?
Combining OLAP without OLTP (large aggregate queries + lots of real time updates) is the holy grail that Cassandra, for example, has addressed rather nicely.
Compressed bitmap indexes are awesome. Like most indexes, the updating random rows problem is best addressed using a log structured merge tree and amortizing your index updates. Just have an in-memory buffer of recently updated rows.
If you are doing mostly sums & counts type work and can deal with some level of inaccuracy, you can consider HyperLogLog...
Our DeliRoll is used for analytics. It doesn't support random updates, it is append-only.
We use bitmap indexes in a number of places internally.