基于云的计费软件的数据库结构，规划问题[关闭]

Question

我们正在构建基于云的计费软件。该软件是基于网络的，应该像桌面软件（至少）一样运行。我们将同时有 5000 多个用户计费。目前，我们只有 250 个用户。我们现在需要扩展。我们使用 Angular 作为前端，Python 用于后端，React Native 用于移动应用程序。 PostgreSQL DB 用于数据库。在我们扩大规模之前，我几乎没有任何疑问。

1. 使用 PostgreSQL for DB 将来会出现任何问题吗？

2. 我们使用 UUID 代替整数的主键（为了方便数据迁移，但它使用更多空间）。以后会不会有什么问题？

3. 对于这种缩放，我们是否必须考虑任何数据库方法？ （现在，为所有用户使用一个数据库）

4. 我们正计划使用一台具有巨大规格的服务器（适用于所有用户）。这样会好还是我们必须计划其他事情？

5. 我们的这个场景需要使用单独的应用服务器和数据库服务器吗？

Answer 1

我会尽力回答问题。随意判断。

因此，您正在构建基于云的计费软件。现在您有 250 多个用户，预计未来至少有 5000 个用户。

现在回答您提出的问题：

1. 使用 PostgreSQL for DB 将来会出现任何问题吗？

ans: PostgreSQL 非常适合生产。这是安全的方式。以后应该不会出现任何问题，但很大程度上取决于数据库设计。

1. 我们使用 UUID 代替整数的主键（为了方便数据迁移，但它使用更多空间）。这是否会在未来带来任何问题？

ans： 使用 UUID 有其优点和缺点。如果您认为扩展是一个问题，那么您应该考虑更新您的收入模式。

1. 对于这种缩放，我们是否必须考虑任何数据库方法？ （现在，为所有用户使用一个数据库）

ans： 生产应用程序的单个数据库在初始阶段是好的。在扩展时，尤其是在 5000 个并发用户的情况下，最好考虑迁移到微服务。

4. 我们计划使用一台具有巨大规格的服务器（适用于所有用户）。这样会好还是我们必须为其他事情做计划？

ans： 就像我说的，5k 并发用户将需要一个强大的服务器（虽然高度依赖于操作，我假设中等繁重的计算和东西）因此，推荐规划微服务架构。通过这种方式，您可以扩展大量使用的服务并缩小其他服务。但请记住，微服务听起来很棒，但在实践中，设置起来很痛苦。如果你有一个强大的后端团队，你可以继续这个想法，否则就不要这样做。

6. 我们的这个场景需要使用单独的应用服务器和数据库服务器吗？

ans： 简短的回答是肯定的。长答案：当你有这么多用户时，你为什么要给你的服务器机器施加压力。