根据自定义安装，我们尝试数据库失败。有康复计划吗？

Question

到目前为止，有一个web应用程序已经处于生产模式3年左右了。从历史上看，由于不同的原因，决定使用每个客户的数据库安装。

现在我们遇到了一个事实，即现在的部署非常缓慢。

我们是否应该考虑将所有数据库移回单个数据库，以降低环境复杂性？或者这是不是太冒险了？

我现在看到的问题是，很难将这些数据库与保存引用完整性合并在一起(不同数据库表的主键无法明显区分)。

数据库不是很大，所以我们不会因为拥有多个数据库而减少负载。

Answer 1

你的问题很宽泛。

a)确保当合并1000个数据库时，即使每个数据库都很小，合并后的数据库也不会受到连接语句之类的性能下降的影响。至于你的引用完整性。我假设它是基于auto_increment的。您可以通过更改模式并替换UUID或类似的唯一非顺序值来替换这些关系。或者甚至是除了您的自动增量PK之外的代理密钥对。

b)执行基准测试，以确保您的应用程序在性能限制范围内响应

c)这样做有没有直接的投资回报？迁移的长期成本收益与费用相比是什么？降低的复杂性是否值得增加(如果有的话)的成本？

d)这对您的备份和灾难恢复计划有何影响？这会让它们变得更便宜吗？慢点？更贵？

抽象和管理工具方法：

如果是我，根据情况，我会保持每个客户端分片带来的可扩展性，并创建一组管理工具来抽象地创建一个虚拟数据库。使用这些工具，您可以在不损失技术灵活性的情况下获得简化的管理。我怀疑您想要简化管理所有这些数据库的成本(基于您的部署声明)。为您的场创建“控制面板”是简化复杂系统的好方法(特别是当部署可能使用不同的架构版本时)。

Answer 2

对于迁移的数据...客户1数据库UUID可以以10000000开头，客户2数据库UUID可以以20000000开头。客户三个数据库UUID可以以30000000开头.....

在我看来，当您为客户托管数据库时，处理多个客户的单个数据库总体上是一个更好的想法。当然，您需要添加一个" customers“表来记录客户，并在表中的所有顶级数据上添加一个"customer_id”列，并在所有SQL中包括检查，以确保客户的视图仅限于他们自己的数据。

我用额外的列建立了一个新的数据库，然后用一个或三个虚拟客户测试它一段时间，以确保所有的bug都被清除。然后，我会一个接一个地迁移所有客户，检查数据是否符合要求。