views:

19

answers:

1

I'm working on a Grails web app that would be similar in access patterns to StackOverflow or MyLifeIsAverage - users can vote on entries, and their votes are used to sort a list of entries based on the number of votes. Votes can be placed while the sorted select queries are being performed.

Since the selects would lock a large portion of the table, it seems that normal transaction locking would cause updates to take forever (given enough traffic). Has anyone worked on an app with a data access pattern such as this, and if so, did you find a way to allow these updates and selects to happen more or less concurrently? Does anyone know how sites like SO approach this?

My thought was to make the sorted selects dirty reads, since it is acceptable if they're not completely up to date all of the time. This is my only idea for possibly improving performance of these selects and updates, but I thought someone might know a better way.

+1  A: 

Don't infer too much about your database - database's are extremely complicated animals and will almost always NOT work the way you would think. An MVCC database, which is any modern database (i.e. not myisam tables), will perform a table scan without locking heavily. The whole concept of MVCC is that writes don't block reads and visa versa. But no table scan will be performed here. To efficiently answer the query there is probably an index on votes. That index will be used to 1) limit the number of rows retrieved from the table 2) retrieve them in sorted order (i.e. without performing a sort.)

Eloff
Ah good point, the calculation could be stored in a field and indexed. I just wonder how it would perform if you're updating an indexed field every time someone votes... I should probably just try it and stress test to see.
Kaleb Brasee
Yes, ask a performance question, make profiling work for yourself. If for some reason it is too slow you could batch votes for a couple minutes (chances are you're caching the query for about that long anyway) and then apply them together in one transaction. Because it wouldn't be critical if some votes were lost in a system failure. But that's only if it's measured to be a problem, and there's no simpler solution (there always is - you just have to think of it.)
Eloff