值得一提的是,我已经处理了一些更大的系统,并且有一个自定义的内部应用程序可以汇总来自服务器的查询,以用于公司的一般应用程序。
例如select * from t1 被转换为:
select * from db1.t1
union
select * from db2.t2
等等
主要问题是,如果您遇到跨服务器连接,在大型百万行以上的系统上,它会严重影响网络并且需要很长时间来处理查询。
假设您正在进行网络分析,需要对表进行连接以确定用户属性的“链接”。
您最终可能会遇到一些奇怪的查询,例如(请原谅语法):
select db1.user1.boss, db1.user1.name, db2.user.name db2.user.boss from db1 inner join on db1.user.name = db2.user.name
(例如,找一个人的老板,以及他们的老板,或朋友的朋友等)
当您想要获得良好的数据来执行链接类型的查询时,这可能是一个巨大的 PITA,但是对于简单的统计数据,如总和、平均值等......最适合这些人的是每晚查询汇总统计数据进入每个服务器上的表(例如 nightlystats)..
例如select countif(user.datecreated>yesterday,1,0) as dailyregistered, sumif(user.quitdate)... into (the new nightly record).
这使得每日统计数据变得非常简单,因为您只需将总列相加,将单个服务器值乘以服务器总计数然后除以总总数等的平均值,并有一个非常快速的仪表板高层次的观点。
我们最终做了很多索引和优化,而保留常用信息的小型本地表等技巧有助于加快查询速度。
对于较大的查询,数据库人员只是将完整的系统副本转储到备份系统上,我们会在白天使用它在本地处理它,以免对网络造成太大影响。
有一些技巧可以减少这种情况,例如共享小表(例如用户的主表等不变的数据等),这样您就不必浪费时间收集这些数据。
在实践中真正有用的另一件事是将简单查询的总和和总计汇总到每晚的表格中。
最后一件令人感兴趣的事情是,bw 问题的解决方法是将“退避”超时编程到内部“查询聚合器”中,它所做的是记录获取响应的时间,如果时间开始延迟,它会要求更少的记录并增加它所要求的查询的延迟(因为它正在报告并且对时间不敏感,这很好用)
有一些 SQL 可以自动缩放,我最近阅读了一些关于工具(但不是 php)的文章,它们将为您完成其中的一些工作。我认为它们与云虚拟机提供商有关。
这个帖子也提供了一些工具和想法:MySQL sharding approaches?
如果 NoSQL 是一个选项,您可以考虑在走这条路之前查看所有的数据库系统。
不过,NoSQL 方法可能更容易扩展,具体取决于您要查找的内容。