Re:When "clever" goes wrong: how Etsy overcame poor architec...
by joevandyk on Monday October 03, 2011 @11:31AM
(#3066641)
Isn't updating a counter in SQL just: update counters set amount = amount + 1 where id = something?
[ Parent
| on HN ]
Re:When "clever" goes wrong: how Etsy overcame poor architec...
by clojurerocks on Monday October 03, 2011 @11:42AM
(#3066686)
In a basic application yes this is true. But if you have a large cluster and data is spread out it becomes more difficult not to mention time consuming to run that query. With redis and other nosql solutions they are designed with this in mind so they are much faster and easier.
Re:When "clever" goes wrong: how Etsy overcame poor architec...
by dramaticus3 on Monday October 03, 2011 @01:18PM
(#3067171)
You didn't check for overflow.
Re:When "clever" goes wrong: how Etsy overcame poor architec...
by ars on Monday October 03, 2011 @03:24PM
(#3067610)
Don't check for overflow. Simply use a data type so large that it would take centuries to overflow.
If you were doing a million increments per second it would take almost 600,000 years to overflow a 64 bit int.
Re:When "clever" goes wrong: how Etsy overcame poor architec...
by dramaticus3 on Wednesday October 05, 2011 @04:36AM
(#3074801)
Check your assumptions. The field could be updated at any time to any value by another connection.
And who's to say we started at zero.