应用程序级别的分片
我正在设计一个多租户系统，并考虑在应用层而不是数据库级别按租户进行分片。
假设这样做的工作方式是，对于传入的请求，路由器进程有一个包含主要属性的租户全局集合，用于确定该请求的租户以及虚拟分片id。这个虚拟分片id进一步映射到一个实际的分片。
实际的分片既包含应用程序的代码，也包含该租户的全部数据。这些分片将是LNMP (Linux，Nginx，MySQL/MongoDB，PHP)服务器。
路由器进程应充当代理。它应该能够运行一些代码来根据存储在一些本地数据库或文件中的集合来确定传入请求的目标分片。为了能够更好地扩展，我正在考虑让分片本身也充当路由器，这样它们就可以运行一个反向代理，将请求转发到适当的分片。也许运行在shard上的nginx实例也可以充当反向代理。但是它将如何执行将请求与适当的分片相匹配所需的应用程序逻辑。
如果您对此路由器的实现有任何想法和建议，我将不胜感激。
谢谢
回答 2
Stack Overflow用户
发布于 2011-04-20 05:52:59
另一种选择是使用dbShards之类的产品。dbShards是唯一一个在应用程序级别进行分片的分片产品。这样，您可以使用任何RDMS (Postgres、MySQL等)。并且仍然能够切分您的数据库，而不必在两者之间放置某种代理。许多其他分片产品都依赖代理将事务指向正确的分片，但dbShards无需“询问”其他任何人就知道该去哪里。
很棒的产品。dbshards
Stack Overflow用户
发布于 2011-04-01 02:09:29
除非您希望租户生成大致相等的数据量，否则按租户进行分片将不会非常有效。
关于一般的应用程序级分片，让我分享一下我自己的经验：
我们的高容量SaaS产品的第1版在应用程序级别进行了分片。如果在应用程序级别对SQL类型的解决方案进行分片，您会发现随着增长而重新分片将是一个令人头疼的问题，或者您将不得不编写重要的工具来自动化该过程。
我们切换到了MongoDB (在考虑了包括Cassandra在内的多种选择之后)，这在很大程度上是因为它内置了对随着数据增长而重新分片/重新平衡的支持。
如果您的应用程序不需要MySQL的关系功能，我建议您将精力集中在MongoDB上(因为您已经将其确定为一种可能的数据平台)，如果您期望的不只是适度的数据增长。允许MongoDB处理数据分片。
https://stackoverflow.com/questions/5504290
复制相似问题
腾讯云开发者
