称重大容量数据库服务器

Question

我认为这在一定程度上是主观的，因为它可能取决于每个人对“大容量”的解释，但为了便于讨论，我想以一种假设的方式来处理这个问题。另外，如果这是ServerFault应该专有的内容，请告诉我，我会很高兴地在那里重新发布。

显然，有许多著名的数据库服务器--其中最值得称赞的可能是MySQL。许多人对SQLite、PostgreSQL甚至MSSQL发誓(诚然，我只使用了MySQL和SQLite)。我已经成功地为低中(<= 1,000,000次/月)流量处理<=，其中数据库交互要么是最小的，要么是中度的(例如，没有复杂的子查询、宽连接等)，以及中高流量的MySQL集群。也就是说，我想知道基于文件系统的系统对于极高流量的有效性(假设是100,000个并发连接)。

总有一种方法是“构建一些坚实的东西，优化它，然后通过向它扔更多的CPU来扩展它”，这在云环境下并不是不合理的，而且我也不一定害怕繁衍奴隶来保持事物的良好分布。但是从极简主义(和效率)的角度来看，对于那些并发请求的东西来说，给机器增加更多的齿轮似乎只是增加了不必要的复杂性。

我知道，使用像MySQL集群这样的工具可以支持跨工作辅助服务器重新分发查询，但是如果您有一个应用程序在逻辑上不可能将使用拆分到单独的服务器中，那么有比仅仅增加CPU更有效的解决方案吗？可能跨N个挂载点使用文件系统存储？我很想了解一下利弊。

Answer 1

请参阅维基百科有关C10K问题的内容--或该页面中的参考资料，因为维基百科页面在材料方面相当轻。可以说，C10K指的是拥有10,000个并发客户端的问题。你在问的是一个数量级大的问题--在实践中，这个问题相应地更难，也更难实现。你正在迅速侵入谷歌的搜索领域，需要谷歌规模的基础设施来应对。