geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akihiro Kitada <akit...@pivotal.io>
Subject Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces
Date Tue, 21 Nov 2017 02:56:51 GMT
Hell folks,

This is a very interesting discussion to provide additional migration
options for users loving SQLFire/GemFire XD.

>1. Would you be interested to have the adapter as part of Geode's code
ecosystem?

If such a adapter is embedded in GemFire (commercial version of Apache
Geode) as a result, some existing SQLFire/GemFire XD users could be
interested in it.

Because of EOSL of SQLFire/GemFire XD products, current their one of
migration paths is SnappyData (like GemFire XD + Apache Spark and etc...)
but it's too much for non-Spark users (I.e., users only needing SQL
capability for OLTP empowered by in-memory data grid).

It seems that Apache Calcite is a simple and handy solution for such users.

In terms of SQL capability of SQLFire/GemFire XD products, they are based
on Apache Derby. I hope Apache Calcite (based on the modern implementation)
is faster than Apache Derby, in terms of query speed.

Thanks, regards.



-- 
Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
Support.Pivotal.io <http://support.pivotal.io/>  |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>


2017-11-21 5:56 GMT+09:00 Swapnil Bawaskar <sbawaskar@pivotal.io>:

> Hi Christian and Julian,
> This indeed sounds very promising.
> Looking at the formidable list of "Powered by Calcite
> <http://calcite.apache.org/docs/powered_by.html>" projects, I think we
> should explore embedding Calcite in Geode.
>
> On Thu, Nov 16, 2017 at 2:52 PM Julian Hyde <jhyde@apache.org> wrote:
>
> > I'm Julian Hyde, original developer of Calcite and a current PMC member.
> >
> > I'd love to see Calcite-Geode integration and so I'm delighted with
> > the work Christian has been doing. Whenever someone builds an adapter
> > for a particular data store X, the question comes up whether it should
> > live in X or become an adapter in Calcite. Generally I prefer the
> > former. I think Geode would benefit by having a built-in SQL interface
> > and ODBC/JDBC server, and Calcite embeds quite easily to make that
> > happen. (You just need a couple of jars from maven, and implement some
> > SPIs to provide metadata; no extra data on disk.)
> >
> > If you don't want that, I think our community would be happy to accept
> > Christian's code as a Geode adapter in Calcite. Geode would be able to
> > include that adapter later, albeit with a small added complication of
> > version differences.
> >
> > But if there are particular concerns, or reasons why you do not want
> > SQL support in Geode, now would be a good time to discuss.
> >
> > Julian
> >
> >
> > On Thu, Nov 16, 2017 at 12:22 PM, Christian Tzolov <ctzolov@pivotal.io>
> > wrote:
> > > Hi Jason
> > > ,
> > >
> > > Thanks for the comments!
> > >
> > > Regarding the talk, i'm not completely sure but i believe that as a
> part
> > of
> > > the S1P conference the sessions will be recorded.
> > >
> > >>>
> > > Also for question 1. Would you be interested to have the adapter as
> part
> > of
> > >
> > > Geode's code ecosystem?
> > >>
> > > Do you mean to create a module in Geode for this adapter?  Would it
> make
> > >
> > > sense to add a Geode module to Calcite?  Were you wanting a tighter
> > >
> > > integration (beyond an adapter) with Calcite within
> > >
> > > Geode?
> > >
> > > Currently the adapter is implemented as a pure Geode client using only
> > the
> > > public Geode API/OQL. There are no dependencies from Geode to the
> > adapter!
> > >
> > > 1. If the adapter became one of Calcite project adapter (
> > > https://calcite.apache.org/docs/adapter.html) it will benefit from
> being
> > > up to date with latest Calcite developments. But IMO this might not the
> > > most important driving force for evolving the adapter.
> > > 2. If it became an "extension" project/module under Geode's project
> > > umbrella it will stay closer to it potential users and will evolve with
> > > their needs. Hopefully it may attract more contributors if found
> useful.
> > >
> > > Personally I would be interested to explore further the approach and
> > figure
> > > out what are its strengths and weaknesses.
> > >
> > > - Cheers,
> > > Christian
> > >
> > >
> > > On 13 November 2017 at 19:46, Jason Huynh <jhuynh@pivotal.io> wrote:
> > >
> > >> Hi Christian,
> > >>
> > >> I don't know much about Calcite and haven't had a chance to try out
> your
> > >> adapter yet but it sounds like a neat idea.  Will your talk be
> recorded
> > and
> > >> available after the Summit?
> > >>
> > >> Also for question 1. Would you be interested to have the adapter as
> > part of
> > >> Geode's code ecosystem?
> > >> Do you mean to create a module in Geode for this adapter?  Would it
> make
> > >> sense to add a Geode module to Calcite?  Were you wanting a tighter
> > >> integration (beyond an adapter) with Calcite within Geode?
> > >>
> > >> -Jason
> > >>
> > >> On Fri, Nov 10, 2017 at 3:49 AM Christian Tzolov <ctzolov@pivotal.io>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > I've been working lately on Apache Calcite SQL/JDBC adapter for
> Apache
> > >> > Geode [1].
> > >> >
> > >> > Adapter's current implementation act as a plain Geode client (using
> > the
> > >> > public API/OQL interfaces) trying to push down to Geode OQL as many
> > >> > relational expressions as it can. Relational expressions not
> > supported by
> > >> > OQL are executed by the adapter itself.
> > >> >
> > >> > While this approach has its advantages and disadvantages, which I
> will
> > >> try
> > >> > to address at my Geode Summit talk [2] I would like to ask two
> > question:
> > >> >
> > >> > 1. Would you be interested to have the adapter as part of Geode's
> code
> > >> > ecosystem?
> > >> >
> > >> > 2. I am aware (an experienced it myself) the SQLFire story. But
> given
> > >> that
> > >> > OQL features are expanding (aggregations are are already supported)
> > and
> > >> > that tools like Calcite offer proper logical/physical (cost based)
> > planer
> > >> > and SQL extensions such as SQL streaming, would it be useful to
> > discuss
> > >> > what novel approaches for using SQL/JDBC with Geode are possible?
> > >> >
> > >> > (Julian Hyde - founder of Calcite - is in cc)
> > >> >
> > >> > Cheers,
> > >> > Christian
> > >> >
> > >> > [1] https://github.com/tzolov/calcite/tree/geode-1.3
> > >> > [2]
> > >> >
> > >> > https://springoneplatform.io/sessions/enable-sql-jdbc-
> > >> access-to-apache-geode-gemfire-using-apache-calcite
> > >> >
> > >> >
> > >> > --
> > >> > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle
> > >> Software
> > >> > Engineer | Pivotal <http://pivotal.io/> | ctzolov@pivotal.io
|
> > >> +31610285517 <+31%206%2010285517>
> > >> > <+31%206%2010285517>
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle
> > Software
> > > Engineer | Pivotal <http://pivotal.io/> | ctzolov@pivotal.io |
> > +31610285517 <+31%206%2010285517>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message