1.2 21世纪早期系统规模案例

在这场技术游戏中展望未来总是充满风险。2008年我写过：

“虽然PB^[2]数据集和千兆数据流是当今数据密集型应用程序的边缘，但毫无疑问10年后，我们会怀念这种规模下的软件系统问题，并担心正在逼近的百亿亿级应用程序所带来的困难。”^[3]

毫无悬念，这是真的，但只是百亿亿级吗？这个数量级的应用程序在当今世界几乎是司空见惯的事。谷歌在2014年报告了几个EB^[4]的Gmail（https://oreil.ly/vQ7M3），到目前为止，是否所有Google服务都管理1个YB^[5]或更多的数据？我不知道。我甚至不敢想象YB是什么概念！虽然谷歌没有公开其存储，但我不会打赌它未来不公开。同样，亚马逊到底为其客户在各种AWS数据仓储中存储了多少数据呢？例如，对于所有支持的客户端应用程序，DynamoDB每秒总共处理多少个请求？这些事情想得太久，你的脑袋会爆炸的。

各大互联网公司的技术博客有时是洞察当代运营规模的重要信息来源。除此之外，还有一些分析互联网流量的网站，它们的数据可以很直观地说明流量。请记住，以下网站提供的案例在一年甚至几年内都是新奇有趣的：

●Facebook的技术博客描述Scribe（https://oreil.ly/omAo8）解决方案每小时收集、聚合和交付PB级日志数据，具有低延迟和高吞吐量。Facebook的计算基础设施由数百万台机器组成，每台机器捕获与系统和应用程序健康相关的重要事件，并生成日志文件。处理这些日志文件（例如来自Web服务器的日志）可以让开发团队深入了解应用程序的行为和性能，并支持故障查找。Scribe是一种自定义缓存队列解决方案，它可以以每秒几TB的速率从服务器传输日志，并将它们传送到下游分析和数据仓库系统中。我的朋友们，这是海量的数据！

●你可以在Internet Live Stats（https://oreil.ly/9Acav）查看众多服务的实时互联网流量。挖掘一下，你会发现一些惊人的统计数据，例如：谷歌每天处理大约35亿次搜索请求；Instagram用户每天上传大约6500万张照片；世界上大约有17亿个网站。这是一个有趣的网站，包含丰富的信息。值得注意的是，数据不是真实的，而是根据多个数据源的统计分析进行估计的。

●2016年，谷歌发表了一篇描述其代码库特征的论文（https://oreil.ly/hyMgl）。论文报道了众多令人吃惊的事实，其中之一是：“该存储库包含86 TB的数据，包括900万个唯一的源文件，其中有约20亿行代码。”请记住，这发生在2016年^[6]。

尽管如此，互联网站点提供的关于服务规模的真实且具体的数据仍然是商业机密。幸运的是，我们可以通过某家科技公司的年度使用报告深入了解其处理的请求和数据量的规模。不过要小心，因为它来自Pornhub^[7]。你可以在这里（https://oreil.ly/hOxsP）浏览极其详细的使用统计数据，数据从2019年开始统计。这是对大规模系统能力的迷人一瞥。