在应用程序级别进行分片

Question

我正在设计一个多租户系统，我正在考虑在应用层而不是数据库中由租户进行分片。

假设，这应该起作用的方式是，对于传入请求，路由器进程具有包含主要属性的全局租户集合，以确定此请求的租户以及虚拟分片ID。此虚拟分片ID还将映射到实际分片。

实际的分片包含应用程序代码以及此租户的整个数据。这些分片将是LNMP（Linux，Nginx，MySQL / MongoDB，PHP）服务器。

路由器进程应该充当代理。它应该能够运行一些代码，以根据存储在某些本地数据库或文件中的集合来确定传入请求的目标分片。为了能够更好地扩展这一点，我正在考虑使分片本身也充当路由器，以便它们可以运行反向代理，将请求转发到适当的分片。也许在shard上运行的nginx实例也可以充当反向代理。但是它将如何执行将请求与适当的分片匹配所需的应用程序逻辑。

我将非常感谢有关此路由器实施的任何想法和建议。

由于

Answer 1

另一种选择是使用dbShards等产品。 dbShards是唯一在应用程序级别进行分片的分片产品。通过这种方式，您可以使用任何RDMS（Postgres，MySQL等），并且仍然可以对数据库进行分片，而无需在其间放置某种代理。许多其他分片产品依赖代理将事务指向正确的分片，但dbShards知道去哪里而不必“询问”其他任何人。

很棒的产品。 dbshards

Answer 2

除非您希望租户产生大致相等的数据量，否则租户分片效率不会很高。

关于应用程序级别分片，让我分享一下自己的经验：

我们的高容量SaaS产品版本1在应用程序级别进行了分类。你会发现，如果你在应用程序级别对SQL类型的解决方案进行分片，那么随着你的成长而重新分配将是一件非常令人头痛的问题，或者你必须编写重要的工具来自动化这个过程。

我们切换到MongoDB（在考虑了多种替代方案，包括Cassandra之后），因为随着数据的增长，所有内置支持重新分片/重新平衡。

如果您的应用程序不需要MySQL的关系功能，我建议您将精力集中在MongoDB上（因为您已经确定这是一个可能的数据平台），如果您期望的是数据增长率不高。允许MongoDB处理数据分片。