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.
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 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.
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. :)
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.