Hi, Does this mean you are not using graph and edges to connect between these? And if so then why not?
Regards, -Stefan On Wednesday, 20 May 2015 00:33:35 UTC, Andrey Verbin wrote: > > Hi, > > I document here my findings about pagination over relations. There are > four 1-N relation types: LINKMAP, LINKSET, LINKLIST and LINKBAG. They seems > to be stored as a list of rids right inside vertex/document (which is > cool). LINKMAP, LINKSET, LINKLIST > are loaded all at once when you ask for corresponding document/vertex > fields - this makes them unusable to store large number of entries. BTW in > my testing I found that 10000 links to empty documents takes only 170KB. > LINKBAG on the other side can be partially loaded and potentially contain > infinite number of entries. > > Unfortunately all these goodies completely useless when you want to > display paginated list. MAP, SET and LIST cannot be used since you will > have to load entire collection, sort it and only then display some small > portion of it. LINKBAG does not maintain order so it is also useless. The > only method which I can think of is to use “relational” way of doing things. > 1. Add “foreign key” aka "one directional link" from child to parent. > CREATE LINK parent FROM Child.parentId TO Parent.rid > 2. Create SB-Tree index on “child” vertex/document which will store > entries in correct order. Something like this: CREATE INDEX xyz ON Child > (ParentId, SortKey) NOT UNIQUE > Since this is SB-Tree index hopefully index data will be sorted by > “ParentId" and then “SortKey" which is exactly the order we need to display > in a web page. > 3. Select child entries from index which match your parent and > ordering/sorting criteria. SELECT FROM INDEX:xyz WHERE ParentId = ? and > SortKey > ? LIMIT PAGE_SIZE > > > On 19 мая 2015 г., at 19:03, Stefán <[email protected] <javascript:>> > wrote: > > Hi, > > You can, if all the information exist on the edge, create that index on > out, date_created (the composition you propose will not give all the speed > you could get). > > I though you were talking about the date_created belonging to the vertex > (rather than the edge) but I understand now that you are talking about the > date that the relationship was created. > > Regards, > -Stefán > > > On Tuesday, 19 May 2015 15:19:52 UTC, Andrey Verbin wrote: >> >> Hi Stefan, >> >> I was thinking that one way I can do it is to create sorted index on >> (user_id, follower_id, date_created) and then select PAGE_SIZE entries form >> it. Rest is easy - fetch selected entries and pass them to web page for >> rendering. I’m still not sure if this is practical so any advice from >> community will be helpful. >> >> Thanks, >> Andrey >> >> On 19 мая 2015 г., at 17:02, [email protected] wrote: >> >> Hi, >> >> As far as I know there is no way to do that without: >> - Scanning all the "incoming classes" edges >> - Fetch the edges + vertexes >> - Keep them all in memory while they are being sorted >> - Return the top n edges/vertexes >> >> This happens behind the scenes and is not problematic on the query side >> but it is on the performance side. >> >> This is one of the issues we have come across when working with dense >> graphs and the changes, needed to fix this, are on the backlog. >> >> I would love fore someone to tell me that I'm terribly wrong here. >> >> Regards, >> -Stefan >> >> >> On Monday, 18 May 2015 14:58:17 UTC, Andrey Verbin wrote: >>> >>> Hi there! >>> >>> Let say I'm building something like Twitter. There is a User with 20000 >>> followers modeled as a relationships between User and Follow classes. Every >>> user reference N Follow instances which in turn has a link to follower user >>> and also creation date. I want to display paginated list of followers but >>> not sure how to do it with OrientDB. What would be the best way to display >>> paginated list of such followers sorted by creation date? >>> >>> Thanks >>> >> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "OrientDB" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
