Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis at Disqus

bretthoerner.com

Post reply on HN
Print view View original

41–42 of 42 posts

Re: Redis at Disqus

#41

Post by moeffju »

nikz wrote: post #21

When aggregating stats in this manner (by Day) how do people deal with Time Zones? For instance, if I have one user in, say, NZST, their "Tuesday, 22 February" is still "Monday, 21 February" in PST - and the real issue is that the buckets are off. So you can't just store in UTC and then move it by whatever timezone offset, as then you are grabbing different "buckets". I don't think that explanation is very clear (I h…

The simple solution is to store everything in UTC, but that means the smallest resolution you can store is 30 minutes (some time zones are :30 offset, and you ignore the Chatham islands that are :45 offset - http://en.wikipedia.org/wiki/Time_zones). It's really annoying and I have wished many times everyone would just use UTC.

Re: Redis at Disqus

#42

Post by sigil »

bretthoerner wrote: post #18
sigil wrote: post #17

Sharding: "We just take the modulo of the owning user's ID against the number of nodes we have to decide which node to read/write from/to." What's your procedure for adding new nodes to increase capacity? Would you have to take your redis cluster offline to redistribute data from all nodes over the new keyspace? I like the simplicity of your approach, but wonder if consistent hashing might be a bigger win in the long…

> What's your procedure for adding new nodes to increase capacity? Would you have to take your redis cluster offline to redistribute data from all nodes over the new keyspace? It's not easy, actually. The short answer is that we don't add capacity (because we've only needed to once, and we have tons of room to grow now). The long answer is that I have a switch I can flip that starts incrementing/adding data to a whol…

In a new post from antirez directly addressing your scenario, he suggests starting with a fixed but large number of shard instances on the same machine, then migrating the instances off to other machines using master / slave replication as needed.

http://antirez.com/post/redis-presharding.html

Post reply on HN