Lightweight Edges vs Other Edges

[Riccardo Tasso]

Hi,

   since in the new Orient 2.0 there will be Lightweight Edges (LE) disabled by default I would like to ask which are the benefits and cost of one approach instead of the other.

Of course I see that LE can't have other properties than label. LE will require less space, since no records are created on the database.

Are there other benefits in terms of cost of inserting/updating/deleting a new edge?

Which performance differences can I expect in a traversal with or without LE?

I'd like to see this kind of discussion inside documentation, which I guess will be updated soon (since it states LE are the default): http://www.orientechnologies.com/docs/last/orientdb.wiki/Tutorial-Working-with-graphs.html

Cheers,

  Riccardo

P.S. I have my orient t-shirt right now, thank you guys!

[Luca Garulli]

Hi Riccardo,

We removed Lightweight edges by default because it's harder working with them, specially from SQL. So we preferred simplicity than speed by default, but they can always be enabled.

Do you like the new OrientDB T-Shirt? :-)

Lvc@

--

---
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 orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sajal Gupta]

Hi Luca,

   Is it possible to enable lightweight edges in 2.0RC1 or this is feature removed completely?

I tried alter database custom useLightweightEdges=true and also checked OStorageEntryConfiguration and I could see the value set to true, however when I call addEdge its creating the edges in a document (not lightweight). I feel there are certain use cases where lightweight edges are preferred approach from performance and space point of view (modelling simple one-2-many relations like Customer -> orders without any edge specific properties). I really like this flexibility and hope this feature is not removed.

 

Thanks

Sajal.

[Luigi Dell'Aquila]

Hi Sajal,

lightweight edges are still available and the "alter database" command is the right way to enable them, so if you are not able to create one maybe there is an error in your code or an issue in the release.

Could you provide a snippet of code (or better, a test case) to replicate the problem?

Thanks

Luigi

--

[Sajal Gupta]

Hi,

I did some further tests, I tried the below code snippet (in remote mode) after executing alter database custom useLightweightEdges=true from console.The higlighted line seem to be cause, which is why its ending up creating the non lightweight edges.

If I set graph.setUseLightweightEdges(true)  explicitly before creating the edges,then it works and i get the lightweigh edges. So I am using this workaround for the timebeing.

 

OrientGraphFactory factory = new OrientGraphFactory("remote:localhost/test1","admin","admin");  
factory.setUseLightweightEdges(true);
OrientGraphNoTx graph = factory.getNoTx();

final List<OStorageEntryConfiguration> custom = (List<OStorageEntryConfiguration>) graph.getRawGraph().get(ATTRIBUTES.CUSTOM);
for (OStorageEntryConfiguration c : custom) {
if (c.name.equals("useLightweightEdges"))
 System.out.println("StorageEntryConfig IsLightweightEdge:" + Boolean.parseBoolean(c.value)); //prints true which is fine.
}      
System.out.println("Graph IsLightweightEdge:" + graph.isUseLightweightEdges()); //This prints false which seem to be the issue

 

Thanks

Sajal.

 

 

 

 

On Thursday, 18 December 2014 14:16:07 UTC+5:30, Riccardo Tasso wrote:

[Keith Freeman]

So you saying that the "alter database" command isn't working right, but if you use "factory.setLightweightEdges(true)" it does work, right?  That really sounds like a bug, can you create an issue for it?  I know for my project we really rely on the old behavior for lightweight edges, so this could be a really big deal for us.

[Sky Viker-Rumsey]

LWE work for me on something such as  Genre categories for a film.

However, when I want to update the film, which it's easiest for me to remove all edges first as there could be additions or subtractions to the genre / actors etc, I am struggling to write a SQL query that should simply do something like

delete edge is_genre from #13:53 

(assuming vertex Film is cluster 13, and has out edge 'is_genre' to Genre)

this gives the error:

java.lang.ClassCastException: com.orientechnologies.common.collection.OMultiCollectionIterator cannot be cast to com.tinkerpop.blueprints.impls.orient.OrientEdge [ONetworkProtocolHttpDb]

(Orient 2.0-M3)

I would hope something like that would delete the in and outs

However, not using LWE, I can do something like

delete edge is_genre where out=#13:53

which I can only assume assumes you saying that the SQL is tricky to write for LWE's.

How much practically does LWE's save in both memory and query path costs? I won't be working on massive amounts of data, can probably assume around 150k films, each with several genre categories, say 2.5, so for estimations, around 375k edges (there's only 20 genres though so each genre will be have 1000s edges)

I hope to be running some complex queries utilising the genre links, hence assumed LWE would be best option (I also have no need to label the edges), but if you feel non-LWE will not impact performance noticeably then I will turn them off

Cheers

Sky