6 ms·
And the best sharding? Doing multi-tenant. Sharding at table level is very complex and expensive. Fully give a single DB per tenant is very practical, and the
by mamcx 4y ago
And the best sharding? Doing multi-tenant.
Sharding at table level is very complex and expensive. Fully give a single DB per tenant is very practical, and the reasons to do sharding (like reporting) is where you do the other fancy things (like ship events in to kafka, etc, etc).
Also, most issues of scalability are dominated by a few tenants that consume most resources, and distribute the loads is more easy per-tenant.
- canadianhacker 4y agoI think we need intuitive tooling to let developers continue just thinking in multi-tenant terms, with single-tenant behind the scenes.
- deleted 4y ago[deleted]
- stn_za 4y agoIssue is when your primary tenant(s) are much larger than the other...eventually vertical scaling is difficult even for only 1 tenant, depending on it's size.
- bsaul 4y agoI've been doing that as much as possible. however you're still left with availability issues, such as replicating / failover management etc. Which really are orthogonal issues to tenancy. How do you manage that ?
- mamcx 4y agoYou need at least 1 backup and/or replica. Availability is kinda good: You could lose one/few tenants but that not take down all the rest (if they are isolated properly). Is MUCH worse if all the db made the fancy way get down, or worse, you get a cascade of latency and/or crashed by the interlinked nature of the "scalable architecture that is fact share-everything global singleton". And you can get a bit fancy (not done it myself, my customers tolerate a bit of downtime) of fork the tenant and upload it another node.
- cryptonym 4y agoI have been doing that in a previous project. One DB or one Schema per tenant can also simplify backup/restore, rollback, export, and data boundaries.