1. Firewater The “split” personality of LucidDB A quick whirl through combining a purpose built BI database with scale “out” capabilities aka – LucidDB roadmap for “Bigger and Faster”

2. First and only 100% Open Source DB purpose built for doing Analytics Long Code History (10+ years)‏ Foundation backing Commercial Support through DynamoBI

3. Column Store  Vertical Partitioning (solves I/O problems)‏  Great for BI, awful for OLTP Bitmap IDXes, Hash Joins/Aggs Labels (read consistent reporting)‏ UDXs, plugin framework, extendable catalog

4. We're winning the “I/O war” Row Store  I/O Bound  CPU Cycles to Spare Column Store  I/O efficient  CPU bound THOU SHALT PARALLELIZE THY PROCESSING THY DATA SHALL BE PARTITIONED GETTING AHEAD OF THE I/O CURVE GIVES US A NEW WAR: CPU and Massively Parallel Processing

5. SERVER1 LUCIDDB SELECT SUM(SALES) FROM 100M_ROW_TBL GROUP BY YEAR, MONTH SERVER1 LUCIDDB SERVER2 LUCIDDB SERVER3 LUCIDDB SERVER0 FIREWATER SELECT SUM(SALES) FROM 100M_ROW_TBL GROUP BY YEAR, MONTH

6. 1 SERVER, SMP, 8 CPUs Available First “run” thrown out to tickle the cache SELECT T."Carrier" as "CARRIER", C, C2, C*1000/C2 as "C3" FROM (SELECT "Carrier", count("Carrier") AS C FROM OTP."ontime" WHERE "DepDelay">10 GROUP BY "Carrier") T JOIN (SELECT "Carrier", count("Carrier") AS C2 FROM OTP."ontime" GROUP BY "Carrier") T2 ON (T."Carrier" = T2."Carrier") ORDER BY 3 DESC;

7. DEMO

8. SMP MPP

9. What's Working Projection Pushdown Filter Pushdown ( where j > 3)‏ GROUP BY pushdown (all aggs)‏ GROUP BY + distinct count Combinations of these things

10. What's Not (aka Roadmap)‏ Hash and Replicated tables and * schema Joins Parallel Loading GOAL: Full support for Mondrian * queries MONDRIAN Page Views Cube LucidDB Firewater * queries