graph database recomputing parent nodes when children change

<p>I&#39;m searching for advice if a graph database may help solve my solution and which options would be overall the best choices. Would dgraph be a good choice for solving this problem?</p> <p>I want to make a graph s.t. projects -&gt; orders -&gt; items, where each node has statistics where each field is aggregated from the children&#39;s&#39; fields. Ideally, when nodes are updated, inserted, or deleted the relevant values would be recomputed. I need the ability define how the nodes are aggregated with a function and not a basic query aggregation.</p> <hr/>**评论：**<br/><br/>thornag: <pre><p>I’ve done something similar but slightly different setup.</p> <p>I have dgraph being built from event stream. Some changes to child nodes can bubble up and change parent nodes.</p> <p>To make that happen I have a consumer that builds the graph in memory (only the relevant bits to that mutation), consumes change events and follows up the tree via normal object reference.</p> <p>Where a change in parent is caused it will produce a new event in the queue and it will cause a chain reaction.</p> <p>That way the original dgraph isn’t really responsible for knowing how to mutate data up the chain, it only listens to events and makes updates.</p> <p>That solution decouples the specific business requirement from the way we are projecting data in dgraph, a typical event sourced + micro architecture.</p> <p>Edit:</p> <p>The in memory graph is about 250k nodes, no problems with memory or performance so far.</p></pre>JavaJuke: <pre><p>Thanks, this makes a lot of sense. Do you have any experience with cayley? I&#39;m responsible for building this component of our application but we&#39;re currently using postgresql for the application and oracle for our manufacturing/plant db. I&#39;ve heard that dgraph is significantly faster and it seems to have better documentation; however, my boss is a little leery of using another database so I need to know if I should push for using dgraph over cayley. </p></pre>thornag: <pre><p>I don&#39;t. Even that dgraph deployment is new to us. The new 0.9 version released recently had some BC breaking changes (removed upserts) which caused us massive pain. </p> <p>We are cool with that tho, I mentioned the micro architecture - because dgraph servers only one function we are happy to put an egg into this basket, there&#39;s many other baskets with only few eggs in them too.</p> <p>If I had to base it all on dgraph I would probably think twice, but mostly how to avoid that central dependency ;)</p></pre>JavaJuke: <pre><p>Good to know, thanks thornag!</p></pre>