Curious about Time Series Use Case

[Eric24]

As I continue to learn ODB, I come across a lot of examples that make me think about alternative ways of doing the same thing and why the author of the example chose the approach they did. One that I saw early on an came back to recently was the Time Series Use Case in the docs (http://orientdb.com/docs/last/Time-series-use-case.html). I understand the purpose of this architecture, but I'm curious as to why the links between the various date parts was done using a LINKMAP instead of edges? To my way of thinking, using edges would be more "graph like", where as LINKMAP is more "document like". What are the pros/cons?
--Eric

[hartmut bischoff]

On Saturday, July 18, 2015 at 7:39:56 PM UTC+2, Eric24 wrote:

 

 why the links between the various date parts was done using a LINKMAP instead of edges? To my way of thinking, using edges would be more "graph like", where as LINKMAP is more "document like". What are the pros/cons?

For one its the simplicity of queriing, eg

 SELECT month[3].day[20].hour[10].logs FROM Year WHERE year = "2012"

[Eric24]

Yes, that makes sense (that's a very interesting query syntax; I understand what it does, but I'm not 100% clear on how it works). What would an "equivalent" query look like if this has been implemented using edges?

[alessand...@gmail.com]

Hi Eric,

the query would be something like :

SELECT expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour=10].out('haveLogs')) FROM Year WHERE year = "2012"

Regards,

Alessandro

[Eric Lenington]

@Alessandro: Ah, very nice! To me, this syntax actually makes more sense. :) But regardless, it also seems more flexible. For example, I think this should be possible, right?

SELECT expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour>=10 and hour<=20].out('haveLogs')) FROM Year WHERE year = "2012"

I plan to run some tests, but in the mean time, any thoughts on performance of this approach vs. the other?

--Eric

--

---
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/s7DO-_gygh0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alessand...@gmail.com]

Hi Eric,

the query SELECT expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour>=10 and hour<=20].out('haveLogs')) FROM Year WHERE year = "2012" 

should work.

Alessandro

[alessand...@gmail.com]

Hi,

I'm using version 2.0.12 and I have problem with > in the code [hour>=10 and hour<=20]

I solved the problem with the following query:

select expand(out('haveLog')) from (SELECT expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')) FROM Year WHERE year = "2012") where hour>=10 and hour<=20

Alessandro

[Eric24]

Interesting. I wonder if the "bracket" syntax is even supposed to work or if it only works with = ? Although that would seem pretty strange. I suppose putting all of it in the WHERE clause would work fine, too, and once the query is parsed, should produce an identical execution plan.
--Eric

[alessand...@gmail.com]

Hi,

at this link http://orientdb.com/orientdb-improved-sql-filtering/

I have founded Squared brackets [] allow to: 

- filtering by one index, example out()[0] 

- filtering by multiple indexes, example out()[0,2,4] 

- filtering by ranges, example out()[0-9] 

- filtering by equal conditions (only equals is supported), example out()[@class = ‘Person’] 

Regards,

Alessandro

[Eric24]

Aha! Interesting that the bracket syntax is 4X faster than using the WHERE clause. That's a bit surprising, as I would have thought that the query optimizer would have arrived at the same execution plan for either syntax, since they are functionally the same.

Anyone from Orient care to comment on: a) Why the speed difference? and b) Why the bracket syntax has the limitations it does, when it's possible to express those queries using the WHERE clause?

--Eric

[Luigi Dell'Aquila]

Hi Eric,

at this stage the query executor is not smart enough to understand that the two syntaxes have the same meaning, it just executes some of the elaboration steps (eg. square bracket filtering) the way they are declared.

There are very important plans about this in the roadmap. In 2.1 we rewrote the SQL parser (one of the reasons is to allow more flexible usage of conditions in square brackets) and in next release we will also rewrite the query executor.

We have many goals to do this:

1. better query language consistency and validation

2. support of more complex queries (eg. with complex conditions in square brackets, or with parameter passing also in subquery - already supported)

3. improved execution planning

4. easiness for future optimization

5. (spoiler) support for declarative querying (pattern matching)

Luigi

--

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

[Eric Lenington]

@Luigi: Excellent. Thanks for the quick and detailed response!

--Eric

--

---
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/s7DO-_gygh0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.