DEPENDENCY_LIST_USAGE_COUNTER redis hash may be storing too much data
While looking at the biggest keys in the gitlab.com persistent (SharedState) redis instance, the DEPENDENCY_LIST_USAGE_COUNTER key was a standout. It is a hash with the field identifier being a project id, and the value of each field a count of usage of dependency list for that project. On gitlab.com it currently contains about 105000 fields (gradually increasing) and is just shy of 5MB in size.
The only uses of this data store I was able to find were a calculation of the total count across all projects on a gitlab instance, reported in usage pings (which, incidentally, we don't do from gitlab.com).
If there are no plans to ever use the per-project information directly, then we should only be storing a total count across all projects (a single integer key). If we need per-project information, there may be other ways to collect and store this in more effective places (e.g. Sisense/periscope).
NB: The actual data size (5MB) isn't hugely problematic, although it is still quite large and noticeable. If it keeps growing forever as more projects use this functionality, it could become a problem in future.