whisper

whisper copied to clipboard

The entire storage premise is flawed: http://redis.io/commands/keys

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets.

The storage and retrieval methods need to be completely rewritten.

Suggestion on this one: Use a list or a set for each room. You don't actually need to grab each message by unique ID, since this is just for history, so you can get away with just getting the entire contents of the list or set. Lists also have the advantage that you get get, for example, the last N messages rather than all of them. I'd suggest also storing the messages as JSON blobs instead of hashes, as it would be far less calls into redis.

Would have to do some sort of manual message expiration/filtering, but that might not be so bad.

Expiry aside, yeah throwing JSON into lists would help a lot.

I'd still need to come up with a solution to the many lookups required every time a location changes. Currently writes are fast but reads have a ridiculous amount of overhead. Perhaps writing messages to every applicable geohash room is the answer (though there could be several per message), while using an EVAL, would be pretty good tradeoff.

This may help: https://matt.sh/redis-geo

Upcoming version of Redis adds several Geo Hash related commands:

GEOADD
GEODIST
GEOHASH
GEOPOS
GEORADIUS
GEORADIUSBYMEMBER