到目前为止，有一个 Web 应用程序处于生产模式 3 年左右。从历史上看，由于不同的原因，决定使用按客户安装的数据库。
现在我们遇到了这样一个事实，即现在的部署非常缓慢。
我们是否应该考虑将所有数据库移回单个数据库以降低环境复杂性？还是这个想法太冒险了？
我现在看到的问题是，很难将这些数据库与保存引用完整性进行合并（不同数据库表的主键不能明显区分）。
数据库并没有那么大，因此拥有多个数据库并没有太多减少负载的好处。
问问题
77 次
2 回答
1
对于迁移的数据...客户一库UUID可以10000000开头，客户二库UUID可以20000000开头，客户三库UUID可以30000000开头.....
在我看来，当您为客户托管数据库时，处理多个客户的单个数据库总体上是一个更好的主意。当然，您需要添加一个“customers”表来记录客户，并在表内的所有顶级数据上添加一个“customer_id”列，并在所有 SQL 中包含检查以确保客户的视图仅限于他们的自己的数据。
我会用额外的列建立一个新数据库，然后用一个或三个虚拟客户对其进行测试，以确保消除所有错误。然后我会逐一迁移所有客户，检查数据是否合适。
于 2010-06-01T16:42:40.447 回答
1
你的问题很广泛。
a) 确保合并的数据库不会因 JOIN 语句之类的事情而遭受性能下降的影响，例如，当合并 1000 个数据库时，即使每个数据库都很小。至于您的参照完整性……我认为这是auto_increment基于……您可以通过更改架构并替换 UUID 或类似的唯一非顺序值来替换这些关系。甚至是除了您的自动增量 PK 之外的代理密钥对。
b)进行基准测试以确保您的应用程序将在性能限制内响应
c) 这样做是否有直接的投资回报率？与迁移费用相比，长期成本收益是多少？降低的复杂性是否值得增加（如果有的话）成本？
d) 这对您的备份和灾难恢复计划有何影响？这会让它们更便宜吗？慢点？更贵？
抽象和管理工具方法：
如果是我，根据情况，我会保留每个客户端分片带来的可扩展性，并创建一组管理工具来抽象地创建一个虚拟数据库。使用这些工具，您可以获得简化的管理，而不会失去技术灵活性。我怀疑您想简化管理所有这些数据库的成本（基于您的部署声明）。为您的服务器场创建一个“控制面板”可能是简化复杂系统的好方法（尤其是当部署可能使用不同的架构版本时）。
于 2010-06-01T16:42:47.777 回答