jamie-vesoft

Autoclosing is a good take.

Thanks for your feedback and sorry for the user experience. Is there an element that you feel specifically hard to read? For example, code snippet?

Are you reading on mobile? As to "the share hover", do you mean the popup?

Graph databases are efficient in exploring multi-hop relationships which are common in many business scenarios. So basically if your application needs to query n-hop relationships all the time, then graph database is a better choice. Some main use cases include real-time recommendation (product/content/shop), risk management like fraud detection in the financial services industry, knowledge graph and machine learning, etc.

Good point. Software systems mature with on-going testing. Nebula Graph has implemented Jepsen tests for quite some time already. See https://nebula-graph.io/en/posts/detect-data-consistency-iss...

Thanks for sharing! Yes you are right, the architecture articles are trying to help users understand how Nebula Graph stores and processes data.

Great digging! Thanks so much for paying attention to the benchmark report data. We apologize that you have to wait for so long!

Yes we have been working on the benchmark data for quite some time because we have been working with our clients to verify our capability. For example, one of our clients has inserted 300b records to 6 servers within 20 hours, then we are confident to say that Nebula Graph can manage 690k inserts/sec/server.

We will keep working and provide a trustworthy benchmark report for you as soon as we can.

Thanks again!

Thanks so much for your suggestion regarding the website!I am thinking about the same thing as well. Will keep improving the site along the way. Really appreciate it.

As to the data for throughput, there are some PoC projects going on and according to data from production, for inserting, one of our clients has inserted 300b records to 6 servers within 20 hours, that is 690k inserts/sec/server.

We want the benchmark data to be verified by decent clients in their production environment. And will reveal more data in the future.

Thanks again!

Thanks for your advice! Appreciate that. I'll try my best.

Nice to know the site. I found Hootsuite is also a nice place to manage a Twitter handle.

Totally agree that the nice thing is everything stays in one place. I use it for Stack Overflow as well. :) And will definitely add Reddit to my list.

Yes,I read about that part as well. :) Thanks for for advice.

Good to know. Cypher is quite popular indeed.

You meant the pictures right? Sorry for the bad experience. Will definitely improve our color palette for future posts.

Interesting story with Neo4j and RedisGraph. Thanks for your suggestion. We are going to support OpenCypher. We will also take a look at AQL and include it in our next version. :)

Hey Thanks for pointing it out. We'll add that soon.

Seems not able to use these colors in this editor?

Thanks so much for trying Nebula! We really appreciate it.

Sorry about the where clause issue. Do you mind bringing an issue in this regard on our GitHub repo? So that we can assign it to relevant staff.

As to the query language, thanks for your suggestion and nGQL will surely be aligned with the GQL standard. We are keeping a close eye on it. :)

We are planning to support OpenCypher in the first half of 2020 and TinkerPop would be the next.

Thanks again! Here's our slack group btw and you may raise any question there: https://join.slack.com/t/nebulagraph/shared_invite/enQtNjIzM...

Thanks for asking! Sorry I missed this question earlier.

Nebula doesn't store data multiple times for index.

And here's how the indexing works in Nebula Graph:

You are allowed to create multiple indexes for one tag or edge type in Nebula Graph. For example, if a vertex has 5 properties attached to it, then you can create one index for each if it's necessary for you. Both indexes and the raw data are stored in the same partition with their own data structure for quick query statement scanning. Whenever there are "where" clause/syntax in the queries, the index optimizer decides which index file should be traversed.

Yes, Nebula Graph supports multiple backend storages by design. So theoretically you are able to use whatever storage you want for whichever graph space in Nebula Graph.

You may take a look at this article about the design of our storage engine: https://github.com/vesoft-inc/nebula/blob/master/docs/manual...

In 2020 we will be working on more plugins. You may stay tuned if that interests you. :)

LOL Not bad that my comment made you laugh. I'll be honest that it's the latter reason because I am new to the community. :) Glad to meet you here.

Thanks for the explanation. I thought that was the reason you changed the title. Makes sense to me. :)

Jepsen is the actual benchmark for a distributed system. And it deserves the popularity.

Very insightful answer! Thanks for sharing your opinions here. Nebula Graph is good at OLTP use cases where high QPS and low latency are required.

Much appreciated! We will definitely check these out and re-consider our license.

Much appreciated! You may find us on Twitter to follow the most recent updates.:) Also, welcome to be a contributor!

Thanks for the questions! Good ones indeed.

1)nGQL will be compatible with the international standard GQL.

2) Currently no

3) So far the following SDKs are available:

   Python https://github.com/vesoft-inc/nebula-python 

   Java https://github.com/vesoft-inc/nebula-java

   Go https://github.com/vesoft-inc/nebula-go

5) Yes we'll follow the Open Core business model like you said. All the features that are open source today will remain open source. :)

Please let me know if you have any further questions.

Really appreciate the feedback and discussion! We will seriously consider the license issue.

Please DO let us know if you have any better license options than Common Clause that can help provide an open-source project for the community while stop cloud vendors from monetizing without contributing back?

Thanks again!

Thanks for your feedback!

While our original intention is to provide a real open-source graph database project for the community, we also want to prevent cloud vendors from monetizing the project without contributing back to the community. Exactly like what's explained in this TechCrunch article: https://techcrunch.com/2018/09/07/commons-clause-stops-open-...

That being said, Common Clause seems to be the only license that can be used. Quote the article: "Academics, hobbyists or developers wishing to use a popular open-source project to power a component of their application can still do so. "

However, we will seriously consider the license issue. Please do let us know if you know any better licenses that can be used.

Much appreciated!

Ah I see. Thanks for the explanation! Could you please change the URL back to the GitHub URL? Also the title? Much appreciated!

Hey, thanks for letting me know. May I ask why?