You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Michael Mior <mm...@uwaterloo.ca> on 2016/01/20 22:32:29 UTC
Introduction and question on lattices and adapters
Hello Calcite devs!
I'm a PhD student at the database group of the University of Waterloo in
Ontario, Canada. My work has focused on schema optimization for NoSQL
databases (specifically Cassandra for the time being). You can see a piece
of my recent work at the link below where I developed an automated tool to
design efficient schemas for Cassandra based on a description of
application workloads.
https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
I'm really interested on getting involved in Calcite and I have two main
questions
1) What is the status of lattices in Calcite? I read the documentation (
https://calcite.apache.org/docs/lattice.html) but it's unclear what's been
implemented or how it works. Specifically, the documentation seems to
suggest that Calcite will automatically select tiles to create. Are there
any examples of using lattices I can look at?
2) Is there any work being done on an adapter for Cassandra or HBase? This
is something I would be interested in contributing to. I know the Phoenix
folks are working on integrating with Calcite, but it looks like their
implementation is too Phoenix-specific to enable the use of vanilla HBase.
Thanks!
Cheers,
--
Michael Mior
mmior@uwaterloo.ca
http://michael.mior.ca/
Re: Introduction and question on lattices and adapters
Posted by Michael Mior <mm...@uwaterloo.ca>.
Rajat,
I'll take a look at Quark. (I'm assuming this is the project you're
referring to: https://github.com/qubole/quark). I'll drop you a line if I
have any questions. Thanks!
Cheers,
--
Michael Mior
mmior@uwaterloo.ca
2016-01-21 2:04 GMT-05:00 Rajat Venkatesh <rv...@qubole.com>:
> Hi Michael,
> I just sent an email talking about a project - Quark - we have a built on
> top of Calcite. We use lattices extensively. We define the tiles and do not
> depend on Calcite to select the tiles. Calcite optimizes queries correctly
> and chooses the right tiles etc. We've have a couple of issues but it
> shouldnt come in the way of starting to use it.
> 1. Lattices dont work if its used in a multi-threaded app. Calcite planner
> is not accessed concurrently but a different thread might own it and use
> it. For e.g. one thread opened the connection and another thread is
> creating and executing statements.
> 2. Each tile in a lattice gets parsed and setup for every single query. If
> you have 4-5 lattices with 6-7 dimensions, optimization becomes slow.
> We are still investigating if we are not using it correctly and if we are,
> how to solve. We will fire JIRAs once we have more concrete information.
>
>
>
> On Thu, Jan 21, 2016 at 7:50 AM hongbin ma <ma...@apache.org> wrote:
>
> > hi Michael,
> >
> > this is Hongbin Ma from Apache Kylin (http://kylin.apache.org/), like
> > James
> > mentioned, Kylin aimed to server OLAP queries by 1. pre-aggregating raw
> > records and save it into hbase 2. use Calcite to parse the query SQL and
> > translate it to HBase scans.
> >
> > AFAIK there're other projects doing the similar things except that they
> > store the pre-aggregated results in ElasticSearch. However it seems not
> > open sourced, and I believe it's not as mature and extendable as Kylin.
> > We're also very interested in trying out different storage engine rather
> > than HBase (like Cassandra). So if you're interested please throw a topic
> > in our dev list.
> >
> >
> > --
> > Regards,
> >
> > *Bin Mahone | 马洪宾*
> > Apache Kylin: http://kylin.io
> > Github: https://github.com/binmahone
> >
>
Re: Introduction and question on lattices and adapters
Posted by Rajat Venkatesh <rv...@qubole.com>.
Hi Michael,
I just sent an email talking about a project - Quark - we have a built on
top of Calcite. We use lattices extensively. We define the tiles and do not
depend on Calcite to select the tiles. Calcite optimizes queries correctly
and chooses the right tiles etc. We've have a couple of issues but it
shouldnt come in the way of starting to use it.
1. Lattices dont work if its used in a multi-threaded app. Calcite planner
is not accessed concurrently but a different thread might own it and use
it. For e.g. one thread opened the connection and another thread is
creating and executing statements.
2. Each tile in a lattice gets parsed and setup for every single query. If
you have 4-5 lattices with 6-7 dimensions, optimization becomes slow.
We are still investigating if we are not using it correctly and if we are,
how to solve. We will fire JIRAs once we have more concrete information.
On Thu, Jan 21, 2016 at 7:50 AM hongbin ma <ma...@apache.org> wrote:
> hi Michael,
>
> this is Hongbin Ma from Apache Kylin (http://kylin.apache.org/), like
> James
> mentioned, Kylin aimed to server OLAP queries by 1. pre-aggregating raw
> records and save it into hbase 2. use Calcite to parse the query SQL and
> translate it to HBase scans.
>
> AFAIK there're other projects doing the similar things except that they
> store the pre-aggregated results in ElasticSearch. However it seems not
> open sourced, and I believe it's not as mature and extendable as Kylin.
> We're also very interested in trying out different storage engine rather
> than HBase (like Cassandra). So if you're interested please throw a topic
> in our dev list.
>
>
> --
> Regards,
>
> *Bin Mahone | 马洪宾*
> Apache Kylin: http://kylin.io
> Github: https://github.com/binmahone
>
Re: Introduction and question on lattices and adapters
Posted by Michael Mior <mm...@uwaterloo.ca>.
Thanks for the reply Hongbin!
I'm going to be looking more into Kylin and I'll drop in on the Kylin
mailing list once I've had a chance to get a better feel for how this might
fit in with some of the other work I'm doing.
Cheers,
--
Michael Mior
mmior@uwaterloo.ca
2016-01-20 21:20 GMT-05:00 hongbin ma <ma...@apache.org>:
> hi Michael,
>
> this is Hongbin Ma from Apache Kylin (http://kylin.apache.org/), like
> James
> mentioned, Kylin aimed to server OLAP queries by 1. pre-aggregating raw
> records and save it into hbase 2. use Calcite to parse the query SQL and
> translate it to HBase scans.
>
> AFAIK there're other projects doing the similar things except that they
> store the pre-aggregated results in ElasticSearch. However it seems not
> open sourced, and I believe it's not as mature and extendable as Kylin.
> We're also very interested in trying out different storage engine rather
> than HBase (like Cassandra). So if you're interested please throw a topic
> in our dev list.
>
>
> --
> Regards,
>
> *Bin Mahone | 马洪宾*
> Apache Kylin: http://kylin.io
> Github: https://github.com/binmahone
>
Re: Introduction and question on lattices and adapters
Posted by hongbin ma <ma...@apache.org>.
hi Michael,
this is Hongbin Ma from Apache Kylin (http://kylin.apache.org/), like James
mentioned, Kylin aimed to server OLAP queries by 1. pre-aggregating raw
records and save it into hbase 2. use Calcite to parse the query SQL and
translate it to HBase scans.
AFAIK there're other projects doing the similar things except that they
store the pre-aggregated results in ElasticSearch. However it seems not
open sourced, and I believe it's not as mature and extendable as Kylin.
We're also very interested in trying out different storage engine rather
than HBase (like Cassandra). So if you're interested please throw a topic
in our dev list.
--
Regards,
*Bin Mahone | 马洪宾*
Apache Kylin: http://kylin.io
Github: https://github.com/binmahone
Re: Introduction and question on lattices and adapters
Posted by James Taylor <ja...@apache.org>.
On Thu, Jan 21, 2016 at 7:12 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>
> Is there anything on the radar for Phoenix to suggest materialized views or
> indexes to users based on queries? This is something I'd be particular
> interested in. Being able to leverage the cost-based optimizer from Calcite
> makes this task much more approachable.
>
Yes, we already use the Calcite optimizer to choose between using an index
versus the data table. We also use it to determine join ordering and
strategy. We don't yet use it to choose between a range scan and a skip
scan[1] - this would be a good, self contained contribution to get your
feet wet. Another derivative of this is to force a skip scan when the
leading column in the primary key isn't being filtered.
[1] https://phoenix.apache.org/skip_scan.html
>
>
> 2016-01-20 18:34 GMT-05:00 James Taylor <ja...@apache.org>:
>
> > Yes, this is a good fit for the current plans of Phoenix + Calcite. We
> > actually model secondary indexes as materialized views. We're interested
> in
> > being able to use materialized views in other situations too (i.e. to
> > service aggregate queries). Are you familiar with Apache Kylin? One idea
> we
> > had (since Kylin uses Calcite as well) is to see if it's possible for
> > Phoenix + Calcite + Kylin to inter-operate.
> >
> > Take a look at the presentations here for more documentation:
> > http://phoenix.apache.org/resources.html
> > Also, in general, our website is a good source for information:
> > http://phoenix.apache.org. Take a look at the pages under the Features
> > menu
> > for more detail.
> >
> > On Wed, Jan 20, 2016 at 2:23 PM, Michael Mior <mm...@uwaterloo.ca>
> wrote:
> >
> > > James,
> > >
> > > Thanks for the reply! I understand HBase has no query language per se,
> > but
> > > if I was trying to create the most basic possible adapter for HBase, it
> > > seems like the most straightforward approach would be to expose HBase
> > > tables and implement scans as a possible query plan operator. This
> would
> > > require the user to specify a schema, but of course this needs to
> happen
> > > with Phoenix anyway.
> > >
> > > That said, given that Phoenix does exist, the approach makes a lot of
> > sense
> > > and obviously adds additional features. In general, I'm interested in
> > > incorporating the use of materialized views when querying databases
> such
> > as
> > > Cassandra and HBase and exploring what needs to change from the
> > relational
> > > world. If there's a way that this fits into the current plans for
> > Phoenix +
> > > Calcite, I'd love to talk more.
> > >
> > > I'm still trying to wrap my head around both code bases. If there's any
> > > particular documentation you can point to that you think would be
> > helpful,
> > > do let me know!
> > >
> > > Cheers,
> > > --
> > > Michael Mior
> > > mmior@uwaterloo.ca
> > >
> > > 2016-01-20 16:37 GMT-05:00 James Taylor <ja...@apache.org>:
> > >
> > > > Hi Michael,
> > > > We'd love for you to get involved on the Phoenix on Calcite work. I'd
> > be
> > > > good to hear more on your thoughts about our implementation being
> "too
> > > > Phoenix-specific to enable the use of vanilla HBase". HBase has no
> > query
> > > > language. We're basically leverage Calcite to do query optimization
> (at
> > > the
> > > > relational algebra level) over HBase.
> > > > Thanks,
> > > > James
> > > >
> > > > On Wed, Jan 20, 2016 at 1:32 PM, Michael Mior <mm...@uwaterloo.ca>
> > > wrote:
> > > >
> > > > > Hello Calcite devs!
> > > > >
> > > > > I'm a PhD student at the database group of the University of
> Waterloo
> > > in
> > > > > Ontario, Canada. My work has focused on schema optimization for
> NoSQL
> > > > > databases (specifically Cassandra for the time being). You can see
> a
> > > > piece
> > > > > of my recent work at the link below where I developed an automated
> > tool
> > > > to
> > > > > design efficient schemas for Cassandra based on a description of
> > > > > application workloads.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
> > > > >
> > > > > I'm really interested on getting involved in Calcite and I have two
> > > main
> > > > > questions
> > > > >
> > > > > 1) What is the status of lattices in Calcite? I read the
> > documentation
> > > (
> > > > > https://calcite.apache.org/docs/lattice.html) but it's unclear
> > what's
> > > > been
> > > > > implemented or how it works. Specifically, the documentation seems
> to
> > > > > suggest that Calcite will automatically select tiles to create. Are
> > > there
> > > > > any examples of using lattices I can look at?
> > > > >
> > > > > 2) Is there any work being done on an adapter for Cassandra or
> HBase?
> > > > This
> > > > > is something I would be interested in contributing to. I know the
> > > Phoenix
> > > > > folks are working on integrating with Calcite, but it looks like
> > their
> > > > > implementation is too Phoenix-specific to enable the use of vanilla
> > > > HBase.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Cheers,
> > > > > --
> > > > > Michael Mior
> > > > > mmior@uwaterloo.ca
> > > > > http://michael.mior.ca/
> > > > >
> > > >
> > >
> >
>
Re: Introduction and question on lattices and adapters
Posted by Michael Mior <mm...@uwaterloo.ca>.
I've played around with Phoenix a fair bit but I'm eager to learn more so
perhaps I will dig into some of those presentations when I get the chance.
I'm not familiar with Kylin, so I'll dig into it and see if anything
interesting jumps out. I'd love to find a something that makes an
interesting project while being simultaneously beneficial for the community.
Is there anything on the radar for Phoenix to suggest materialized views or
indexes to users based on queries? This is something I'd be particular
interested in. Being able to leverage the cost-based optimizer from Calcite
makes this task much more approachable.
Cheers,
--
Michael Mior
mmior@uwaterloo.ca
2016-01-20 18:34 GMT-05:00 James Taylor <ja...@apache.org>:
> Yes, this is a good fit for the current plans of Phoenix + Calcite. We
> actually model secondary indexes as materialized views. We're interested in
> being able to use materialized views in other situations too (i.e. to
> service aggregate queries). Are you familiar with Apache Kylin? One idea we
> had (since Kylin uses Calcite as well) is to see if it's possible for
> Phoenix + Calcite + Kylin to inter-operate.
>
> Take a look at the presentations here for more documentation:
> http://phoenix.apache.org/resources.html
> Also, in general, our website is a good source for information:
> http://phoenix.apache.org. Take a look at the pages under the Features
> menu
> for more detail.
>
> On Wed, Jan 20, 2016 at 2:23 PM, Michael Mior <mm...@uwaterloo.ca> wrote:
>
> > James,
> >
> > Thanks for the reply! I understand HBase has no query language per se,
> but
> > if I was trying to create the most basic possible adapter for HBase, it
> > seems like the most straightforward approach would be to expose HBase
> > tables and implement scans as a possible query plan operator. This would
> > require the user to specify a schema, but of course this needs to happen
> > with Phoenix anyway.
> >
> > That said, given that Phoenix does exist, the approach makes a lot of
> sense
> > and obviously adds additional features. In general, I'm interested in
> > incorporating the use of materialized views when querying databases such
> as
> > Cassandra and HBase and exploring what needs to change from the
> relational
> > world. If there's a way that this fits into the current plans for
> Phoenix +
> > Calcite, I'd love to talk more.
> >
> > I'm still trying to wrap my head around both code bases. If there's any
> > particular documentation you can point to that you think would be
> helpful,
> > do let me know!
> >
> > Cheers,
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> >
> > 2016-01-20 16:37 GMT-05:00 James Taylor <ja...@apache.org>:
> >
> > > Hi Michael,
> > > We'd love for you to get involved on the Phoenix on Calcite work. I'd
> be
> > > good to hear more on your thoughts about our implementation being "too
> > > Phoenix-specific to enable the use of vanilla HBase". HBase has no
> query
> > > language. We're basically leverage Calcite to do query optimization (at
> > the
> > > relational algebra level) over HBase.
> > > Thanks,
> > > James
> > >
> > > On Wed, Jan 20, 2016 at 1:32 PM, Michael Mior <mm...@uwaterloo.ca>
> > wrote:
> > >
> > > > Hello Calcite devs!
> > > >
> > > > I'm a PhD student at the database group of the University of Waterloo
> > in
> > > > Ontario, Canada. My work has focused on schema optimization for NoSQL
> > > > databases (specifically Cassandra for the time being). You can see a
> > > piece
> > > > of my recent work at the link below where I developed an automated
> tool
> > > to
> > > > design efficient schemas for Cassandra based on a description of
> > > > application workloads.
> > > >
> > > >
> > > >
> > >
> >
> https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
> > > >
> > > > I'm really interested on getting involved in Calcite and I have two
> > main
> > > > questions
> > > >
> > > > 1) What is the status of lattices in Calcite? I read the
> documentation
> > (
> > > > https://calcite.apache.org/docs/lattice.html) but it's unclear
> what's
> > > been
> > > > implemented or how it works. Specifically, the documentation seems to
> > > > suggest that Calcite will automatically select tiles to create. Are
> > there
> > > > any examples of using lattices I can look at?
> > > >
> > > > 2) Is there any work being done on an adapter for Cassandra or HBase?
> > > This
> > > > is something I would be interested in contributing to. I know the
> > Phoenix
> > > > folks are working on integrating with Calcite, but it looks like
> their
> > > > implementation is too Phoenix-specific to enable the use of vanilla
> > > HBase.
> > > >
> > > > Thanks!
> > > >
> > > > Cheers,
> > > > --
> > > > Michael Mior
> > > > mmior@uwaterloo.ca
> > > > http://michael.mior.ca/
> > > >
> > >
> >
>
Re: Introduction and question on lattices and adapters
Posted by James Taylor <ja...@apache.org>.
Yes, this is a good fit for the current plans of Phoenix + Calcite. We
actually model secondary indexes as materialized views. We're interested in
being able to use materialized views in other situations too (i.e. to
service aggregate queries). Are you familiar with Apache Kylin? One idea we
had (since Kylin uses Calcite as well) is to see if it's possible for
Phoenix + Calcite + Kylin to inter-operate.
Take a look at the presentations here for more documentation:
http://phoenix.apache.org/resources.html
Also, in general, our website is a good source for information:
http://phoenix.apache.org. Take a look at the pages under the Features menu
for more detail.
On Wed, Jan 20, 2016 at 2:23 PM, Michael Mior <mm...@uwaterloo.ca> wrote:
> James,
>
> Thanks for the reply! I understand HBase has no query language per se, but
> if I was trying to create the most basic possible adapter for HBase, it
> seems like the most straightforward approach would be to expose HBase
> tables and implement scans as a possible query plan operator. This would
> require the user to specify a schema, but of course this needs to happen
> with Phoenix anyway.
>
> That said, given that Phoenix does exist, the approach makes a lot of sense
> and obviously adds additional features. In general, I'm interested in
> incorporating the use of materialized views when querying databases such as
> Cassandra and HBase and exploring what needs to change from the relational
> world. If there's a way that this fits into the current plans for Phoenix +
> Calcite, I'd love to talk more.
>
> I'm still trying to wrap my head around both code bases. If there's any
> particular documentation you can point to that you think would be helpful,
> do let me know!
>
> Cheers,
> --
> Michael Mior
> mmior@uwaterloo.ca
>
> 2016-01-20 16:37 GMT-05:00 James Taylor <ja...@apache.org>:
>
> > Hi Michael,
> > We'd love for you to get involved on the Phoenix on Calcite work. I'd be
> > good to hear more on your thoughts about our implementation being "too
> > Phoenix-specific to enable the use of vanilla HBase". HBase has no query
> > language. We're basically leverage Calcite to do query optimization (at
> the
> > relational algebra level) over HBase.
> > Thanks,
> > James
> >
> > On Wed, Jan 20, 2016 at 1:32 PM, Michael Mior <mm...@uwaterloo.ca>
> wrote:
> >
> > > Hello Calcite devs!
> > >
> > > I'm a PhD student at the database group of the University of Waterloo
> in
> > > Ontario, Canada. My work has focused on schema optimization for NoSQL
> > > databases (specifically Cassandra for the time being). You can see a
> > piece
> > > of my recent work at the link below where I developed an automated tool
> > to
> > > design efficient schemas for Cassandra based on a description of
> > > application workloads.
> > >
> > >
> > >
> >
> https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
> > >
> > > I'm really interested on getting involved in Calcite and I have two
> main
> > > questions
> > >
> > > 1) What is the status of lattices in Calcite? I read the documentation
> (
> > > https://calcite.apache.org/docs/lattice.html) but it's unclear what's
> > been
> > > implemented or how it works. Specifically, the documentation seems to
> > > suggest that Calcite will automatically select tiles to create. Are
> there
> > > any examples of using lattices I can look at?
> > >
> > > 2) Is there any work being done on an adapter for Cassandra or HBase?
> > This
> > > is something I would be interested in contributing to. I know the
> Phoenix
> > > folks are working on integrating with Calcite, but it looks like their
> > > implementation is too Phoenix-specific to enable the use of vanilla
> > HBase.
> > >
> > > Thanks!
> > >
> > > Cheers,
> > > --
> > > Michael Mior
> > > mmior@uwaterloo.ca
> > > http://michael.mior.ca/
> > >
> >
>
Re: Introduction and question on lattices and adapters
Posted by Michael Mior <mm...@uwaterloo.ca>.
James,
Thanks for the reply! I understand HBase has no query language per se, but
if I was trying to create the most basic possible adapter for HBase, it
seems like the most straightforward approach would be to expose HBase
tables and implement scans as a possible query plan operator. This would
require the user to specify a schema, but of course this needs to happen
with Phoenix anyway.
That said, given that Phoenix does exist, the approach makes a lot of sense
and obviously adds additional features. In general, I'm interested in
incorporating the use of materialized views when querying databases such as
Cassandra and HBase and exploring what needs to change from the relational
world. If there's a way that this fits into the current plans for Phoenix +
Calcite, I'd love to talk more.
I'm still trying to wrap my head around both code bases. If there's any
particular documentation you can point to that you think would be helpful,
do let me know!
Cheers,
--
Michael Mior
mmior@uwaterloo.ca
2016-01-20 16:37 GMT-05:00 James Taylor <ja...@apache.org>:
> Hi Michael,
> We'd love for you to get involved on the Phoenix on Calcite work. I'd be
> good to hear more on your thoughts about our implementation being "too
> Phoenix-specific to enable the use of vanilla HBase". HBase has no query
> language. We're basically leverage Calcite to do query optimization (at the
> relational algebra level) over HBase.
> Thanks,
> James
>
> On Wed, Jan 20, 2016 at 1:32 PM, Michael Mior <mm...@uwaterloo.ca> wrote:
>
> > Hello Calcite devs!
> >
> > I'm a PhD student at the database group of the University of Waterloo in
> > Ontario, Canada. My work has focused on schema optimization for NoSQL
> > databases (specifically Cassandra for the time being). You can see a
> piece
> > of my recent work at the link below where I developed an automated tool
> to
> > design efficient schemas for Cassandra based on a description of
> > application workloads.
> >
> >
> >
> https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
> >
> > I'm really interested on getting involved in Calcite and I have two main
> > questions
> >
> > 1) What is the status of lattices in Calcite? I read the documentation (
> > https://calcite.apache.org/docs/lattice.html) but it's unclear what's
> been
> > implemented or how it works. Specifically, the documentation seems to
> > suggest that Calcite will automatically select tiles to create. Are there
> > any examples of using lattices I can look at?
> >
> > 2) Is there any work being done on an adapter for Cassandra or HBase?
> This
> > is something I would be interested in contributing to. I know the Phoenix
> > folks are working on integrating with Calcite, but it looks like their
> > implementation is too Phoenix-specific to enable the use of vanilla
> HBase.
> >
> > Thanks!
> >
> > Cheers,
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> > http://michael.mior.ca/
> >
>
Re: Introduction and question on lattices and adapters
Posted by James Taylor <ja...@apache.org>.
Hi Michael,
We'd love for you to get involved on the Phoenix on Calcite work. I'd be
good to hear more on your thoughts about our implementation being "too
Phoenix-specific to enable the use of vanilla HBase". HBase has no query
language. We're basically leverage Calcite to do query optimization (at the
relational algebra level) over HBase.
Thanks,
James
On Wed, Jan 20, 2016 at 1:32 PM, Michael Mior <mm...@uwaterloo.ca> wrote:
> Hello Calcite devs!
>
> I'm a PhD student at the database group of the University of Waterloo in
> Ontario, Canada. My work has focused on schema optimization for NoSQL
> databases (specifically Cassandra for the time being). You can see a piece
> of my recent work at the link below where I developed an automated tool to
> design efficient schemas for Cassandra based on a description of
> application workloads.
>
>
> https://www.researchgate.net/publication/289372760_NoSE_Schema_Design_for_NoSQL_Applications
>
> I'm really interested on getting involved in Calcite and I have two main
> questions
>
> 1) What is the status of lattices in Calcite? I read the documentation (
> https://calcite.apache.org/docs/lattice.html) but it's unclear what's been
> implemented or how it works. Specifically, the documentation seems to
> suggest that Calcite will automatically select tiles to create. Are there
> any examples of using lattices I can look at?
>
> 2) Is there any work being done on an adapter for Cassandra or HBase? This
> is something I would be interested in contributing to. I know the Phoenix
> folks are working on integrating with Calcite, but it looks like their
> implementation is too Phoenix-specific to enable the use of vanilla HBase.
>
> Thanks!
>
> Cheers,
> --
> Michael Mior
> mmior@uwaterloo.ca
> http://michael.mior.ca/
>