Sounds as a great plan to me as well, thank you for sharing details, please keep it up and keep the mailing list posted!
As for "Query Graphical User Interface" I would suggest trying Zeppelin out and just providing a an interpreter implementation [1] for the query language you choose as it's very simple and nice GUI comes for free. 1. http://zeppelin.incubator.apache .org/docs/0.6.0-incubating-SNAPSHOT/development/writingzeppelininterpreter .html -- Alex On Tue, Apr 5, 2016 at 11:30 PM, Luke Han <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] > > > > > > 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 <[email protected]>님이 작성: > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > >
