正确的服务器架构的大型Facebook应用程序？

关于MySQL，

1. mysqltuner是任何产品的必备工具。
2. 慢速查询日志将为您带来更多性能的应用程序。
3. 打开常规日志（简称）可以是一件好事，然后在所有查询中运行EXPLAIN以确保您具有适当的索引（没有覆盖率，良好的基数等）
4. 你在会议数据库？ 不要这样做，如果你可以避免它，但如果没有，请考虑一个MEMORY表。
5. 关于表types的主题，请考虑每个表的实际使用情况。 具有高读/写需求的交易表在InnoDB存储引擎中可能会更好。 主要写或读的表格可能最好作为MyISAM服务。 你也logging到数据库吗？ 考虑这些表的ARCHIVE引擎。

任何答案你会得到野驴的猜测。 您确实需要对您的应用程序进行适当的负载testing，并通过硬件和软件堆栈实现真实的数据和使用模式。 使用负载testing中的数字来提出一个可伸缩的计划，并且估计成本没有什么比例完美的线性增长，特别是在数据库层，所以即使你有很多数字，也有一些猜测，你可以打一个“墙”在一个特定的组件（如数据库）中。 从JMeter开始，它可以捕获HTTP会话以生成负载。 商业工具更有能力，但也非常昂贵。

如果不知道自己在做什么，那么就不可能提供铁皮的build议。 不过，我会这样说的：

花一些时间计划现在的规模。 考虑虚拟化，其好处是多方面的。

如果不是很多钱，你可以从Slicehost，Linode，Rackspace Cloud等租用一些VPS。从现在起六个月，当你成功的时候，你可以租用/购买自己的硬件，运行自己的虚拟化，或者坚持与您的供应商，或移动到“真实”的服务器，或任何。 但是，如果您认为您需要多台服务器，请针对群集设置编写应用程序。 对于专用盒子的成本，你可以运行10个“玩具”服务器。

现在通过利用廉价的虚拟化提供商，您可以确保您的架构可以向外扩展。

如果你看看你的需求，并决定你可能有一天需要运行分段的mysql数据库，你现在可以用廉价的VPS来build模。

如果你认为你要在一堆PHP框架前面加载一些负载平衡器，现在就可以做到了。

设置一些服务器/平衡器来提供静态内容也是一样（或者你可以去s3 / cloudfront路由）。

但是，如果你真的期待高负载和大量的stream量，那么明智的办法是把事情分开，而不是购买最大的专用盒子，并且祈祷你稍后可以扩展。

我想说的是用户基础的大小，这里的体系结构最重要的部分是caching和按需扩展的能力。 只要看一下Facebook就会想一想，在2009年，他们每天的数据增长量为12TB！ 是的，每天。