Hi Scott, Thanks for your input. The reason I'm splitting the accounts in multiple vertices is because my application is actually more complex than I'm portraying here. Each account has multiple profiles for very different aspects of my application, simply because it makes it easier to split the responsibilities instead of having a 'god' vertex which holds all the data. For instance, my users can manage relationships with a social profile, they can also participate in channels, so they have a channel profile where channels they own and moderate and connect to are linked, they can also participate in games, so they have a gaming profile, etc. The account vertex would be HUGE and would be linked by so many edges if I consolidated everything in one place. I figured a single edge traversal from the account to the appropriate profile should not add a ton of overhead in exchange for development simplicity.
For retrieving data, yes I do need a transaction because I cannot afford to read stale data. My application retrieves the 'state' for the user connecting via said transaction, and then registers for changes using a message queue system. As such, any changes to the state afterwards are no longer read from the database but through notifications from the message queue system instead. Can't have that if the initial state I receive is stale. As for querying the database in a loop, I don't do that unless there's a concurrent access issue that requires a retry. I send the transaction once to retrieve the initial state and everything from there onwards is handled through a messaging layer, not a loop that constantly reads from the database. I'm really looking forward to hear from Luca, Luigi or someone else because with this performance I absolutely cannot continue growing using OrientDB, and to be honest I really like the database from a developer's perspective. Cheers, Jean On Saturday, April 30, 2016 at 8:32:59 PM UTC+8, scott molinari wrote: > > Great explanation. > > I am not at all a Java programmer and I am also learning ODB and graph > databases, so I can only suggest what might be a problem or rather point to > what I think might be a problem. So, take what I say with a grain of salt. > > Is there a particular reason to split the accounts from the two profile > types? If the relationships are always direct, I'd not waste edges on > connecting them. I'd have the profiles as subdocuments of the account. That > will speed the retrieval of the profile data a lot. > > For retrieving data, do you really need a transaction? Transactions are > definitely more costly from a performance perspective. I mean, would it > matter if a person sees partially old data in your system? I would imagine > it isn't too critical. > > Also, from a data querying perspective, constantly hitting the database in > a loop is going to be slower than finding a proper query, which gets you > the data you need in one shot (in most cases). To be honest, I am not sure > that is actually happening, but from the code, that seems like what is > happening. Unfortunately, I can't help you on a better query. I am not that > good at the Java API. > > Hopefully Luca or Luigi can offer some better tips and sorry I can't offer > more of help. > > Scott > > > > > -- --- 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.
