Now I'm trying to think of a solution to filter by country code or some other player attribute. In addition, I also want to dynamically create timeslices so I can show leaderboard rankings that occurred between time A and time B.
If I were to implement the filter or timeslices into my B+Tree, I'd have to basically scan from the first record down to the last by checking against player attributes and/or the timestamp of when ranking was inserted.
The goal is to have 1 leaderboard index per stat, rather than X leaderboard per stat.
Is it feasible, or should I just create a new leaderboard index for every combination of attribute / timeslice?
The issue with storing BTree to disk are the many operations for balancing on insert and deletion. I want a structure that is very simple to write to disk that doesn't require "balancing".
I tried making a HashTree for unique indexing which basically creates a new hashmap on each collisions, which would simplify appending the new hashmap into a file on disk. The issue was the hash function was difficult to craft that avoided going too far in depth through consecutive collisions.
I'm thinking there must be an alternative structure, but my limited understanding and research has yet to reveal anything better than BTree, LSM tree or Skiplists.
I know redis can do this using zset and zrevrange using a new key for each stat/timeframe, but it doesn't easily allow referencing the player's full metadata like name, country, and other default stats like wins/loss/score. I would have to store those separately and retrieve them each time I pull the top X players in the leaderboard.
If I pull top 100 players in a leaderboard, that is 100 player metadata retrievals using some identifier like player id, and it doesn't scale well.
I'm looking for something that will allow me to pull the top 100 player id/score AND the player metadata in one step, without having to store the metadata within the leaderboard itself.
Any ideas?