10:33:42 GMT <Pred_> hey guys
10:57:49 GMT <Pred_> hello guys
15:05:52 GMT <gajus> How to delete all keys from a database when FLUSHALL FLUSHDB are renamed?
19:43:37 GMT <ember3> hi, I need to stream a few billion upserts from a few thousand workers into redis. ideally via an additive bulk operation: <key> [additive list]
19:43:59 GMT <ember3> is there a way to do this without doing a GET on all the objects that need to be upserted?
19:44:14 GMT <ember3> i.e., having redis handle the additive operation
19:44:21 GMT <minus> what kind of data?
19:44:33 GMT <ember3> small ascii strings
19:44:35 GMT <minus> redis has hashes, so if you just need to update one field in a hash that works
19:44:40 GMT <ember3> <20 bytes
19:44:51 GMT <minus> if you just override stuff SET works just fine
19:45:12 GMT <minus> if you need to lookup-modify-save it's gonne be more difficult
19:46:18 GMT <ember3> well, I basically want to have{ key1: [listobj1, listobj2]} and do a SET on {key1: [listobj3]} without knowing whether key1 exists, and while preserving the current contents
19:46:57 GMT <minus> make key1 a list/set and push/add to it
19:49:45 GMT <ember3> could be I'm missing something, but seems like a SET blows away the current contents
19:50:15 GMT <minus> SADD is for adding to sets
19:50:26 GMT <minus> SET writes a plain key
19:50:43 GMT <minus> https://redis.io/commands/#set
19:51:05 GMT <minus> use lists if order matters
19:53:45 GMT <ember3> just realized why I didn't see that in the docs, thanks :)
19:54:48 GMT <ember3> and there's no performance issues with having a few billion sets?
19:55:11 GMT <minus> as long as you don't iterate over the keyspace ;)
19:55:18 GMT <minus> and your RAM is large enough
19:55:52 GMT <ember3> yeah, it'll be sized appropriately for the dataset
19:56:20 GMT <ember3> but the 4bn limit is kind of irritating
19:56:30 GMT <minus> there's a limit?
19:56:45 GMT <minus> you probably should use cluster at that size anyway
19:56:51 GMT <minus> that should work around the limit
19:57:35 GMT <ember3> yes, limited to 2^32 keys for some reason
19:58:05 GMT <minus> well, that's not terribly surprising
19:58:30 GMT <ember3> guess they assume you should be sharding at that point
19:58:48 GMT <ember3> but sometimes you just need a massive bloom filter
19:59:40 GMT <minus> mh?
20:00:33 GMT <minus> i don't see how that is related to one massive bloom filter
20:01:32 GMT <ember3> say you want to check if keys a,b,c,d,e exist without 5 calls to the a,b,c,d,e shards