Hi Doyung and Jo,
    Actually, I have no concern about supporting more storages rather than
HBase. Refactoring existing design to support more engines will make
project more suitable for different usage.

    But the question here is the community does not know why, until you
guys started to discuss in mailing list and reply above. Please keep moving
on  and bring more discussion in mailing list.

    Thanks.
Luke



Best Regards!
---------------------

Luke Han

On Fri, Apr 1, 2016 at 1:52 PM, Hyunsung Jo <hyunsung...@gmail.com> wrote:

> Doyoung,
>
> Thank you for sharing the document!
>
>
> Luke and Alexander,
>
> Do you have any concerns regarding supporting multiple storage engines?
>
> As far as I understand, although S2Graph began exclusively on top of HBase,
> it always had other storage engines in mind.
> Perhaps this is somewhat unclear in the proposal, but I see hits of the
> plan for additional storages in statements such as -
> S2Graph <https://wiki.apache.org/incubator/S2Graph> provides a scalable
> distributed graph database engine over *a key/value store such as HBase*.
> This is also why some of the earliest JIRA tickets (S2GRAPH-1, 51) cover
> this topic. (Now that I think of it, we should have had this discussion
> prior to opening the tickets, but better late than never!)
> Thanks to the recent refactoring (S2GRAPH-17) as Doyoung mentioned, I think
> the latest storage-related code is abstract + general enough to try out
> integrations with storages other than HBase.
>
> Thanks,
> Jo
>
> On Fri, Mar 25, 2016 at 11:06 PM DO YUNG YOON <sho...@gmail.com> wrote:
>
> > Hi Luke and Alexander.
> >
> > Thanks for asking question and here is reason I did list storage engine.
> >
> > S2Graph has been used HBase as primary storage engine. I think there is
> no
> > reason we need to change this.
> >
> > However, I also think there is no reason we should only support HBase.
> >
> > We realized that lots of codes can be independent to storage backend, so
> we
> > abstract away storage dependent codes at S2GRAPH-17. after this
> > refactoring, it becomes easy for others who want to use different storage
> > other than HBase to connect to their choice for storage.
> >
> > Personally I think it would be better to give user more options.
> >
> > For example, http://thinkaurelius.github.io/titan/ support various
> > storages(Cassandra, HBase, BerkeleyDB, but seems primary is Casssandra)
> and
> > I think S2Graph can also support these options, but primary is HBase.
> >
> > What others think about this?
> >
> > Also regarding Query Graphical User Interface, I have no idea what other
> > existing project can be used. If it is possible to re-use existing
> > projects, then I prefer to use them.
> >
> > Please guide me what are these existing projects(I would love to try
> > Zeppelin though).
> >
> > Thanks.
> > Doyung Yoon
> >
> > On Thu, Mar 24, 2016 at 8:54 AM Luke Han <luke...@gmail.com> wrote:
> >
> > > Hi
> > >     For Storage Engines, are we trying to extend to others rather than
> > > HBase?
> > >
> > > Thanks.
> > > Luke
> > >
> > >
> > > Best Regards!
> > > ---------------------
> > >
> > > Luke Han
> > >
> > > On Wed, Mar 23, 2016 at 10:31 PM, Kim, Min-Seok <mskim....@gmail.com>
> > > wrote:
> > >
> > > > updated and added
> > > >
> > > >
> > > >    -
> > > >
> > > >    Batch Jobs(S2Lambda)
> > > >    -
> > > >
> > > >       Kafka to HDFS (WAL)
> > > >       -
> > > >
> > > >       Streaming Cooccurrence across labels(user-user/item-item
> > > similarity)
> > > >       -
> > > >
> > > >       OLAP operations on (WAL or KAFKA)
> > > >       -
> > > >
> > > >    A/B Testing capabilities
> > > >    - Multi-armed Bandit to select the best query
> > > >
> > > >
> > > > I think A/B and MAB can be component themselves, they could be merged
> > > into
> > > > other components.
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2016년 3월 22일 (화) 오전 7:57, DO YUNG YOON <sho...@gmail.com>님이 작성:
> > > >
> > > > > Hi folks.
> > > > >
> > > > > I just want to open up discussion on our project roadmap.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1QSEf628QHrLmky16cJN_wIv0H_cfi1E9NGLqKMpdsNE/edit?usp=sharing
> > > > >
> > > > >
> > > > > Things I wrote on link is completely draft(I just list up all I can
> > > think
> > > > > of now), please feel free to change as it is necessary.
> > > > > Some of them might easy and some of them would take time, so I also
> > > want
> > > > to
> > > > > ask what others think about first release.
> > > > > Personally, I think It would be great if we can list up our load
> map,
> > > > then
> > > > > decide priority, and talks about our first release.
> > > > > Also, I think once we decide road map, then this road map can be
> used
> > > as
> > > > > component at JIRA. currently there is no component so it is hard to
> > > guess
> > > > > what each issue is about.
> > > > >
> > > > > Looking forward to hear what others think.
> > > > >
> > > >
> > >
> >
>

Reply via email to