We are storing local sessions for each project, as well as for central auth, together in a single instance of Kask that we refer to as sessionstore. Each of these session types are distinct, and should be stored in their own namespace. Namespacing does occur, but it is managed at the application level by encoding names into formatted keys. For example:
If this namespacing were happening at the storage layer, then the database would be able to provide a breakdown by operation type (read, write, and delete), rates, throughput, and storage utilization, on a per namespace basis.
Additionally, an argument could be made for using a separate storage namespace for each wiki group (i.e. group0, group1, group2, etc), or even on a per-wiki basis (i.e. enwiki, dewiki, commons, etc). Both of these are in fact examples of namespaces, whether modeled in storage or not.
/sessions/mwsession/{session_id} ...or
/sessions/group0/{session_id} ...or
/sessions/enwiki/{session_id}
/sessions/centralauth/{session_id}Observability concerns aside though, there are also advantages to being able to operate each namespace independently. For example: Each has its own workload and might benefit —operationally— from being separated (i.e. compaction, compression, caching, etc). We would also have the ability to truncate an individual namespace —without impacting the others— say if storage were corrupted during a partial rollout.
See also:
{T390514}