04:02:51 GMT <amosbird> hello
04:03:43 GMT <amosbird> if redis support value field filtering (via custom hooks), I think it's just a more generalized hbase
09:57:31 GMT <badboy_> amosbird: except hbase is a vastly different beast. namely a fuly distributed database intended for large datasets based on a distributed file system
09:57:37 GMT <badboy_> but sure, otherwise it's nearly a Redis in big…
13:10:08 GMT <amosbird> badboy_: yeah, but I still don't understand why they call hbase as a column store
13:10:25 GMT <amosbird> it's really just a kv store
13:11:55 GMT <badboy_> because of the way it stores its data
13:12:30 GMT <amosbird> it stores its data as key value AFAIK
13:14:29 GMT <badboy_> i never worked with it
16:42:26 GMT <fleetfox> Is there a way to have something like composite keys?
16:42:43 GMT <fleetfox> I have two dimensions and only on of each can exist at a time
16:43:49 GMT <minus> keys are pretty much arbitrary
16:46:45 GMT <fleetfox> Well, current plan is key:X:Y. But that involves scan on *:Y, X:* each time i want to upsert. I wonder if there is a better way
16:51:18 GMT <minus> create an index yourself (zset, set, list or hashmap) maybe
16:53:53 GMT <fleetfox> so i index by X,Y, then use ZRANGE to fetch one record
20:04:06 GMT <jjasinski> Hi all, I'm new-ish to redis configuration.  If I have "appendonly no" and "appendfsync everysec" set, can I still reboot the machine hosting redis, if I issue a safe reboot or safe restart of the process (i.e. sudo service redis restart)? Will redis save everything to disk before it restarts?
20:11:12 GMT <tgodar> Hi, working on a node.js/socket.io project... Trying to figure if redis might fit in... I'm needing to maintain a repository of objects in a current state (maybe redis) and I need to watch for changes to those objects and publish on change..  Wondering if I should add in something like rabbitMQ or if redis might also work as the queue
20:19:41 GMT <badboy_> jjasinski: with "appendonly no" you disabled AOF
20:19:57 GMT <badboy_> jjasinski: however, Redis has two mechanism of persistence. did you configure the save option?
20:20:09 GMT <badboy_> tgodar: it can act as such
20:20:28 GMT <badboy_> tgodar: you could listen for keyspace notifications or just always send a publish on changes as well
20:21:09 GMT <tgodar> badboy_: reading about the pub/sub to see if that might make sense
20:22:35 GMT <tgodar> badboy_: I'm not sure that makes the most sense though as technically the nodeJS server-side is  I'm 'subscribed' 'to all...
20:22:55 GMT <tgodar> keyspace notifications?  Could you elaborate hust a little on that?
20:23:20 GMT <badboy_> redis can use its own pubsub mechanism to publish whenever certain things happen: https://redis.io/topics/notifications
20:23:42 GMT <tgodar> Thanks, I'll read up
20:27:15 GMT <tgodar> badboy_: so I'm really just in the design phase now.. am I right in thinking that with this being built on the pub/sub layer... node.js would would be the one subscribing and events would be pushed there?
20:27:29 GMT <badboy_> yes
20:27:32 GMT <tgodar> Other stuff I was looking at with I think rabbit MQ was more of a cursor approach
20:27:34 GMT <tgodar> cool.
20:28:12 GMT <badboy_> if you only need to add stuff and on the other side a worker that pulls out stuff you might be better served by using a list
20:31:30 GMT <tgodar> badboy_: no, I think this is turning out to be a good use case... I'll have a collection of objects that are are populated in redis in their current states.  Web client connects, and over socket gets the current values, then on any change, we update the values in redis, which then also causes the new data to be sent over the socket to the web client.
20:32:15 GMT <badboy_> then pubsub sounds perfect
20:32:23 GMT <tgodar> fact it is 'fire and forget' is fine as on a reconnect the value in redis is the current state, we don't need to reiterate over past messages
20:32:58 GMT <tgodar> yeah, this looks good, like that the data store is also working as queue, simplifies it that much more
20:34:01 GMT <tgodar> ... and will scale more easily
20:46:15 GMT <jjasinski> badboy: sorry for the delay. Currently my save values are set to "save 900 1"  "save 300 10"  "save 60 10000"
20:46:57 GMT <jjasinski> So if my understanding is correct, these save to disk after a given amount of time or a given number of writes
20:47:50 GMT <jjasinski> However, I wondering if giving a SIG TERM (such as what I'd expect a service restart or reboot would do), if that would automatically fush to disk
20:50:15 GMT <badboy_> yes, a SIGTERM would trigger a dump as well
20:50:27 GMT <badboy_> depending on the size of your database however, it might take some time
20:50:32 GMT <jjasinski> Thank you - good to know
20:50:35 GMT <badboy_> and a reboot might kill it with SIGKILL before it finishes
20:50:50 GMT <jjasinski> I see, so maybe best to stop the service before rebooting