Apples to oranges for sure. But how many milliseconds would you expect SQL translation to take? Any idea?
We also did 1 more experiment on getting a slew of data from the cubes. This one ran for 10-20 seconds. ES was faster in this case as well - by a few secs for best case..and 2 to 3x faster than kylin's worst case. Our cubing engine is in infancy. We just created a simple table scan for ES in Apache calcite. We are yet to get into deeper work. Actually we are exploring to see how to make use of avatica. Is there any good documentation in that? How was the jdbc server created for kylin? Best, Sarnath On Nov 15, 2015 9:17 PM, "Ted Dunning" <[email protected]> wrote: > On Sun, Nov 15, 2015 at 8:47 PM, Sarnath <[email protected]> wrote: > > > For the experiment below, ES was almost 5x to 8x faster than > > kylin. (60ms vs 240ms/450ms)... But then we use ES search REST interface > > directly and compare that with kylin's REST interface. So I am not sure > > about the SQL translation...overheads in kylin. > > > > The SQL planner can add significant overhead so such a comparison is pretty > apples to oranges. Also, Kylin is premised on cubes not fitting in memory > while ES is pretty optimistically assuming they will fit in memory. > > How do you handle queries that do indirect references to cubes (say by > asking for a rollup by region when you only cubed by city)? > > And do you automatically decide which cubes to use? >
