我正在设计一个多租户系统,我正在考虑在应用层而不是数据库中由租户进行分片.
假设,这应该起作用的方式是,对于传入请求,路由器进程具有包含主要属性的全局租户集合,以确定此请求的租户以及虚拟分片ID.此虚拟分片ID还将映射到实际分片.
实际的分片包含应用程序的代码以及此租户的整个数据.这些分片将是LNMP(Linux,Nginx,MySQL/MongoDB,PHP)服务器.
路由器进程应该充当代理.它应该能够运行一些代码,以根据存储在某些本地数据库或文件中的集合来确定传入请求的目标分片.为了能够更好地扩展这一点,我正在考虑使分片本身也充当路由器,以便它们可以运行反向代理,将请求转发到适当的分片.也许在shard上运行的nginx实例也可以充当反向代理.但是它将如何执行将请求与适当的分片匹配所需的应用程序逻辑.
我将非常感谢这个路由器实现的任何想法和建议.
谢谢
除非您希望租户生成大致相等的数据量,否则租户分片的效率不会很高。
对于一般的应用级分片,我分享一下我自己的经验:
我们的大容量 SaaS 产品的版本 1 在应用程序级别进行了分片。您会发现,如果您在应用程序级别对 SQL 类型解决方案进行分片,那么随着您的成长,重新分片将是一个令人头疼的问题,或者您将不得不编写重要的工具来自动化该过程。
我们转向 MongoDB(在考虑了包括 Cassandra 在内的多种替代方案之后),很大程度上是因为随着数据增长,它内置了对重新分片/重新平衡的支持。
如果您的应用程序不需要 MySQL 的关系功能,并且您预计数据增长将超过适度的数据增长,那么我建议您将精力集中在 MongoDB 上(因为您已经将其确定为可能的数据平台)。让 MongoDB 处理数据分片。
| 归档时间: |
|
| 查看次数: |
2336 次 |
| 最近记录: |