On Wed, Jun 15, 2011 at 2:31 AM, Patrik Sundberg <[email protected]>wrote:
> On 14 Jun 2011, at 22:51, Michael Hunger > <[email protected]> wrote: > > > Patrick, > > > > David Montag created a versioned graph approach on github: > https://github.com/dmontag/neo4j-versioning > > > > Perhaps you can take some inspiration from that. > > I'll take a look, thanks. > I had a look at this. It's a really cool idea. It's in principal a very good solution to what I'd like to accomplish, even more ambitious even. And for part of my graph it's ideal in practical terms as well - the parts that don't change so often and where number of relationships wont mushroom. However, I have a nagging suspicion that it may not be practical in the Book, Elements, Effects use case - may get too many relationships. If I have versioned relationships that keeps growing from Books to Elements then over time a Book will get a lot of direct relationships it's involved in. Let's say I have ~500 elements/book (at any point in time), and they'll change every day (not quite true but lets assume so for now), then a book will add on 125,000 relationships/year (assuming 250 business days). Over a few years you'll start having half a million direct relationships of a single Book. That's probably not an ideal deisgn, correct? What I was thinking is that I could have an ElementSet reference node layer sitting between a Book and Elements. An ElementSet has a timestamp property for when the snapshot was made or the relationship from Book to ElementSet has a valid range on it. Then an ElementSet node in turn has Elements. So in a year you'd add ~250 Book to ElementSet relationships, and each ElementSet would have ~500 relationships to it's Elements. I can still get the state of the book quite easily via a simple 2 level traversal. Another thought I'd be happy to get some input on: My Elements are essentially consisting of an Entity and a Quantity. The Effects as well. If we assume we'll have millions of Effects and 100s of thousands of Elements then I'm thinking that it's not a good idea to have actual relationships pointing to the Entity nodes from the Element and Effect nodes, correct? The Entity nodes would get millions of direct relationships. I could instead put in the identifier or the Entity in the Element and the Effect as properties and use index based queries for that step. Patrik > Am 14.06.2011 um 21:14 schrieb Patrik Sundberg: > >> I should probably put in some estimates of the sort of orders of magnitude >> of data involved: >> Books are in the 100s >> Effects are in the 10,000s / day >> Elements are in the 100s / Book >> >> On Tue, Jun 14, 2011 at 8:07 PM, Patrik Sundberg >> <[email protected]>wrote: >> >>> Hi, >>> >>> Design question: >>> I have a Book. A book has Elements. To change what Elements are in a Book >>> there are Effects. An Effect adds or deletes an element from a Book (and has >>> other info). Everyday I archive the state of a Book so that I can easily get >>> the state of the Book (it's Elements) at a historical point in time. The >>> number of elements and which elements are in a Book vary from day to day >>> depending on the Effects taking place in the time period. >>> >>> So it's a bit like "Book contents archive of day X + 1 = Book contents >>> archive of day X + the Effects between X and X + 1" >>> >>> There's no need to represent the daily archives in any way, it's the >>> functionality of having historical snapshots that matter to me, so that one >>> can easily get the state of a Book at any point in time by finding the >>> closest archive point before the time and applying the Effects from that >>> archive timestamp and the point of interest. >>> >>> Ideally want to keep a long time history of Book state and Effects. >>> >>> Any ideas for an effecient of organizing this in a graph friendly way? >>> >>> Thanks, >>> Patrik >>> >>> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
