element-hq / element-hq/synapse
Separate datastore for devices?
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
This issue has been migrated from [#12906](https://github.com/matrix-org/synapse/issues/12906).
---
**Description:**
We are currently experimenting with different ways to scale out the synapse database in particular where it would be possible to divide tables amongst separate database instances, much like the state tables/datastore class.
Based on my analysis it should be possible to extract the following device/e2e related stores into a separate datastore instance:
+ `Device*Store` (`stores/main/devices.py`)
+ `DeviceInbox*Store` (`stores/main/deviceinbox.py`)
+ `EndToEndKey*Store` (`stores/main/end_to_end_keys.py`)
+ `ClientIp*Store` (`stores/main/client_ips.py`)
I picked these because they're fairly small overall/low inter-dependency and represent a high percentage of database IO on our instance (currently single database all tables).
Note: the one interdependency this misses is the [`populate_monthly_active_users` call in `client_ips.py`](https://github.com/matrix-org/synapse/blob/28989cb301fecf5a669a634c09bc2b73f97fec5d/synapse/storage/databases/main/client_ips.py#L598) which could become `self.hs.get_datastores().device.populate_monthly_active_users(user_id)`.
Is there any appetite for this? We can commit engineering time to implement this if so. Also keen to discuss any other groups of stores that may be suitable candidates.
Contributor guide
Research direction
Start by reading stores/main/devices.py, deviceinbox.py, end_to_end_keys.py, and client_ips.py, then inspect the populate_monthly_active_users call in client_ips.py. The issue proposes separating these stores but does not define an agreed design or acceptance criteria, so confirm the intended datastore boundaries and migration plan before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, databases, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100