Version 3 proposal: Store optional member data in a single hash

[czarneckid]

This has the benefit of not using a separate hash for every single
member's data. As is updated in the documentation, you can store
more data for a given member by, for example, encoding a Hash
in JSON. Not only will this save on Hash-splosion if using member
data in a leaderboard, it also means that when deleting a
leaderboard, we can also delete ALL of the member data at once. In
version 2.x, if using member data, you would have to go through and
delete the member data hashes individually. Yikes!

[hypomodern]

Have we benchmarked the two approaches?

[czarneckid]

Benchmarked which approaches?

[hypomodern]

You are proposing to change the present implementation. Is your proposed change slower or faster or "doesn't matter" than the original? It seems to me this is one area where performance might matter, since you'll often be retrieving or updating a bunch of member data in one unit of work.

[czarneckid]

It will be faster since we are only ever retrieving one piece of data O(1) in this implementation from a Redis hash as opposed to retrieving all of the items from a hash O(n) in the previous implementation. Also, retrieving member data when pulling leader data is still optional in the call.

[czarneckid]

This code has been integrated into the version 3 branch.