团队，
我们正在构建一个Web项目（例如IT票务系统）。而且，我们预计一旦发布产品，就会有一些大客户。应该有三种方法来提高票证：1）通过Web应用程序（表格），2）通过电子邮件或3）通过致电代理人。根据我们的研究，有99％的门票是通过电子邮件发送的，这意味着我们将存储很多长消息等。
该项目的范围确定为使我们具有两个接口：代理（IT人员处理查询）和客户（寻求帮助的人）。
这里的问题是，考虑到预期的数据和存储增长，您会建议我们做什么：
请随时添加第三个选项。
答案 0 :(得分：0)
我不太确定我是否正确理解了所有内容，但根据我的理解，我可以指出以下关键点 您的系统要求：
您的2条建议：
我不建议随着数据库的增长而出现许多其他问题。 例如，您将被迫添加索引以加快对数据库的查询，这将有助于 一开始，但后来这会吸引您，特别是如果您必须添加大量非集群 索引。您可以通过使用只读副本使它更好一点，但是即使这样做，您有时也会 有问题。该问题仍将保留在您的1个主数据库中，该数据库将不断增长。
报价：
单独的应用程序分为两部分，一个用于IT代理，另一个用于 客户。想法是将应用程序分为两部分：一个集中式 接口和后端（用于IT代理）和另一个（用于客户端）。对于 每个客户我们都会创建一个单独的数据库以及一个副本 PHP项目（代码同步很容易实现自动化）。多客户 实例可以托管在一台或多台服务器上。他们将 通过API进行通信。例如：IT代理打开仪表板，然后 显示未清票列表。如果该代理正在处理 10个大客户后端需要通过API和10个实例联系 索取未付票。我们只能确保一定数量的 查询将被显示...
您可以按照说明将其拆分为2个独立的应用程序：
集中式界面+后端，将调用1个或多个数据库
客户端应用程序+后端（整体或多个服务），将调用与集中式接口相同的数据库 但仅适用于当前客户
据我了解，您的问题不是扩展Web服务器（您的后端），而是扩展数据库？如果您的问题也是扩展后端 那么您可以考虑将其扩展到多个实例，或者将您的域拆分为微服务，然后在 每个服务的微服务级别。
我的建议：
1。扩展后端： 您可以将所有内容保留在一项服务中（整体方法）并进行部署 在多台服务器上，并一起扩展整个服务。这没有错。 像一切一样，它取决于您的业务/域要求以及最适合您的方法。 尽管如今使用微服务非常流行，但它们并不是解决问题的最佳解决方案 每个问题。我曾经使用过两种类型的架构，并且在 不同的情况。 您甚至可以在它们之间使用中间层解决方案来承担具有 高扩展需求并将其提取为单独的服务（例如创建Tickets子系统服务） 而需求低的其余应用程序将是一项大服务。
2。扩展数据库： 考虑到以上几点，我建议您使用数据分片或数据分区。 您可以阅读有关数据分片here的信息。 通常，这是一种逻辑上和物理上将数据从一个数据库拆分为多个数据库的方法 在某些分区或分片键上。 这意味着您可以将域中的一个特定概念用作分片键，以基于该分片来拆分数据。 在您的情况下，这可以是CustomerId。仅当业务操作包含更多内容时，才可以这样做 那么对于您的公司而言，不是一个客户。表示您的所有操作是否都在一个客户内完成。 唯一的例外是一起阅读/查看更多客户。很好，因为它不需要任何 跨国行为。 这实际上取决于您的业务场景和逻辑。 如果基于分片客户ID将数据库拆分为多个数据库还不够，则可以采用分片键 在客户范围内更具体。同样，这取决于您的域是否允许这样做。 例如，在这种情况下，客户A可能具有客户A-欧洲分片的概念 CustomerA-USA分片，CustomerA-Africa等。 这将代表逻辑碎片。物理碎片将是物理数据库。
重要的一点是，您一开始就选择了逻辑分片，这样您就可以轻松地 以后在需要基于该分键的数据时，将数据迁移到其他物理数据库。
除此之外，您还可以包括一些重型表的“历史化”，以分隔最新的 历史数据中的数据。您可以在此处了解更多信息。