Hi Joel, I've had the exact same problem and created a GitHub issue for OrientDB earlier today. You can see it here: https://github.com/orientechnologies/orientdb/issues/4056
I will add your situation as additional material on the issue ticket. This proves that there is an issue with performance in the specific scenarios where we are counting via edges. PS: I am not affiliated with Orient Technologies -- just a user who's run into the same problem Best regards, Jean On Thursday, April 30, 2015 at 12:58:20 PM UTC+8, Joel Spriggs wrote: > > I'm using OrientDB 2.0.8. Here's the scenario I'm curious about. I have > a Person class, and about this person we store some demographic > information: date of birth, sex, etc. We only have a small set of some of > the options for some demographic fields. So along with our Person object > we have a lookupGender object, they are linked via a link property and we > link them so we can still have a table/object that lists all the possible > genders (male, female, unknown, not asked, etc). > > Now, this is great from our ui standpoint, we can easily add more genders > if needed without needing to refactor data, and by using the link, when we > want to query it, we can just say select gender.displayGender from Person > to see what the actual text is instead of just the ids and this is all > incredibly fast. > > What if I want to see my person distribution by gender though? If I run > > select gender, count(gender) from Person group by gender > > or > > select gender.displayGender, count(gender.displayGender) from Person group > by gender.displayGender > > these statements both run, but the time increases as my database size > increases. That's expected, 15 records will always be faster than 2.1 > million. But if I apply any kind of non-unique index to the gender link > property on my Person, it has no effect on the time it takes to run that > aggregate distribution query to see how many of each gender are represented > in my set of Persons. With about 2.1 million records on my dev machine it > is about 20 seconds. > > So, with that kind of set up in mind, I'm wondering does indexing work or > do anything on link properties? Am I looking at this from he wrong angle > to perform fast aggregate reporting functions? > > We did look into it using nested objects as properties on Person as well, > and there were pretty clear answers that indexing those were not supported, > which is fine, having the links and lookup tables helps with being able to > populate forms for us anyway. But I'm still thinking I'm missing something > on my indexing strategy, and it's probably something someone else has seen > before too. > > I did try searching for some answers to this, but didn't really come up > with anything similar either here, google or stack overflow. > -- --- 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.
