06:10:02 GMT <dudeji> Hey guys , if i keep a big hashmap around 13000 keys and 2 values inside each key. what could be performance drawback ?
07:29:26 GMT <minus> hashes are optimized for 1024 entries by default, you can change that in the config
07:30:08 GMT <minus> if you always need those 2 values at once you could use a normal key instead and serialize them yourself, though not sure if that changes anything on performance
07:30:14 GMT <minus> just benchmark it :)
09:16:24 GMT <p1rate> anyone has worked with sharding/partioning?
09:16:45 GMT <p1rate> I'm creating a game which (according to client) will have ~5 million users in a month
09:17:00 GMT <p1rate> I'm thinking on the strategy on how to shard players
09:17:58 GMT <p1rate> my main issue that I'm not sure if I want to start with 20 (just a random number) instances and grow those when needed or if I should add more servers eventually
09:18:28 GMT <p1rate> like: put users 1 - 500.000 on server 1 and when we are nearing that number we spawn a second
09:19:12 GMT <p1rate> that option sounds dangerous but otherwise I have 20 servers which might be overkill if clients app is less used as their previous one
09:24:12 GMT <JuanDaugherty> 5 million something
09:41:42 GMT <p1rate> JuanDaugherty ?
09:42:53 GMT <JuanDaugherty> does the client expect 5 million distinct users in the first month?
09:43:18 GMT <JuanDaugherty> 5 million game plays?
09:43:28 GMT <JuanDaugherty> 5 million hits?
09:43:30 GMT <JuanDaugherty> etc.
09:43:34 GMT <p1rate> 5 million distinct users
09:43:58 GMT <p1rate> each user will have a bunch of keys to keep the game state
09:44:11 GMT <p1rate> p:<id>:<something>
09:44:30 GMT <p1rate> I was thinking to shard on the {p:<id>} part
09:45:03 GMT <p1rate> looking at stratiegies to be able to scale up or down with redis instances
09:45:29 GMT <p1rate> but only good option seems to be to start with a whole bunch of instances and vertically scale those when needed
09:45:39 GMT <p1rate> (in my case then)
09:45:50 GMT <p1rate> came here to check if there are better options out there :)
09:49:33 GMT <JuanDaugherty> if you are intentionally cloaked, may I ask why?
09:50:41 GMT <p1rate> what do you mean by that ?
09:53:01 GMT <JuanDaugherty> * p1rate (~p1rate@unaffiliated/p1rate) has joined #redis <- that's cloaking
09:53:29 GMT <JuanDaugherty> as opposed to e.g. ideea's entry 4 min ago
09:54:18 GMT <p1rate> I like to hide my ip, is that a bad thing ? :)
09:55:45 GMT <JuanDaugherty> i am just curious about why; on the whole it just makes me wonder why some people feel the need
09:59:02 GMT <p1rate> I do not see how that's relevant for my question tbh
10:00:48 GMT <p1rate> I guess I don't like the idea that people are trying to port scan me or something because I am publically exposed
10:01:11 GMT <p1rate> or maybe my irc client has vulnerabilities
10:01:20 GMT <p1rate> better safe than sorry
10:01:26 GMT <JuanDaugherty> i see. well if you google sharding you'll see an article on how craigslist does it
10:02:37 GMT <p1rate> yeah, I just found that
11:19:11 GMT <raz> anyone here affiliated with rediscloud and could comment on their pricing?
11:20:20 GMT <raz> my working theory is they don't trust their product and don't actually want it to be used at scale :/
16:24:57 GMT <redis218> Hello everybody! We're currently using Redis SCAN over 200,000 keys. How can we determine the best COUNT iteration number?
16:25:25 GMT <redis218> We tried with COUNT=10 but the execution is very slow :/
21:21:43 GMT <redis640> Hello
21:22:55 GMT <redis640> Space Pirats?
22:51:41 GMT <prsn> hi, i've been struggling with the following issue and could really use some help. i have loaded a lua script into redis which calls HGET <key> <hkey> and later calls HINCRBY <key> <amt>. If I manually delete <key> from redis-cli, the HGET /sometimes/ returns a previous value of <hkey>.
22:52:18 GMT <prsn> manual hgetall confirms that <key> was deleted
22:53:33 GMT <prsn> i modified the script to just return the result of the HGET if present, and sure enough, fairly frequently, it returns a value it had before being deleted