# Google 架构
> 原文: [http://highscalability.com/blog/2008/11/22/google-architecture.html](http://highscalability.com/blog/2008/11/22/google-architecture.html)
**更新 2:** [使用 MapReduce](http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html) 对 1 PB 进行排序。 PB 并非拼写错误的花生酱和果冻。 它是 1 PB 或 1000 TB 或 1,000,000 GB。 *在 4,000 台计算机上对 1PB(10 万亿条 100 字节的记录)进行分类花费了六个小时又两分钟,并且在 48,000 个磁盘上将结果复制了三次。
**更新:** [Greg Linden](http://glinden.blogspot.com/2008/01/mapreducing-20-petabytes-per-day.html) 指向 Google 的新文章 [MapReduce:简化了大型集群上的数据处理](http://labs.google.com/papers/mapreduce-osdi04.pdf)。 一些有趣的统计数据:每天执行 10 万个 MapReduce 作业; 每天处理超过 20 PB 的数据; 已经实施了超过 1 万个 MapReduce 程序; 机器是具有千兆位以太网和 4-8 GB 内存的双处理器。
Google 是可扩展性之王。 每个人都知道 Google 的庞大,精巧和快速的搜索功能,但他们不仅在搜索中脱颖而出。 他们构建可扩展应用程序的平台方法使他们能够以惊人的高竞争率推出互联网规模的应用程序。 他们的目标始终是建立性能更高,规模更大的基础架构来支持其产品。 他们是如何做到的?*
## 信息来源
1. [视频:在 Google 构建大型系统](http://video.google.com/videoplay?docid=-5699448884004201579)
2. [Google 实验室:Google 文件系统](http://labs.google.com/papers/gfs.html)
3. [Google 实验室:MapReduce:大型集群上的简化数据处理](http://labs.google.com/papers/mapreduce.html)
4. [Google 实验室:BigTable](http://labs.google.com/papers/bigtable.html) 。
5. [视频:BigTable:一种分布式结构化存储系统](http://video.google.com/videoplay?docid=7278544055668715642)。
6. [Google 实验室:适用于松耦合分布式系统](http://labs.google.com/papers/chubby.html)的胖锁服务。
7. [Google 的运作方式[Baseline Magazine]的 David Carr 撰写的](http://www.baselinemag.com/article2/0,1540,1985514,00.asp)。
8. [Google 实验室:解释数据:使用 Sawzall](http://labs.google.com/papers/sawzall.html) 进行并行分析。
9. [Dare Obasonjo 关于可伸缩性会议的说明。](http://www.25hoursaday.com/weblog/2007/06/25/GoogleScalabilityConferenceTripReportMapReduceBigTableAndOtherDistributedSystemAbstractionsForHandlingLargeDatasets.aspx)
## 平台
1. 的 Linux
2. 多种语言:Python,Java,C ++
## 里面有什么?
### 统计资料
1. 2006 年估计有 450,000 台低成本商品服务器
2. 在 2005 年,Google 索引了 80 亿个网页。 现在,谁知道呢?
3. 目前,Google 有 200 多个 GFS 集群。 一个集群可以具有 1000 甚至 5000 台计算机。 数万台计算机的池从运行高达 5 PB 的 GFS 群集中检索数据。 整个群集的总读/写吞吐量可以高达 40 GB /秒。
4. 目前,Google 有 6000 个 MapReduce 应用程序,每个月都会编写数百个新应用程序。
5. BigTable 可扩展以存储数十亿个 URL,数百 TB 的卫星图像以及成千上万用户的首选项。
### 堆栈
Google 将其基础架构可视化为三层堆栈:
1. 产品:搜索,广告,电子邮件,地图,视频,聊天,博客
2. 分布式系统基础架构:GFS,MapReduce 和 BigTable。
3. 计算平台:一堆不同数据中心中的机器
4. 确保公司人员易于以较低的成本进行部署。
5. 查看每个应用程序的价格性能数据。 花更多的钱在硬件上不会丢失日志数据,而花更少的钱在其他类型的数据上。 话虽如此,他们不会丢失数据。
### 可靠的 GFS 存储机制(Google 文件系统)
1. 可靠的可扩展存储是任何应用程序的核心需求。 GFS 是他们的核心存储平台。
2. Google 文件系统-大型的分布式日志结构化文件系统,在其中可以放入大量数据。
3. 为什么要构建它而不使用现成的东西? 因为它们控制着一切,而正是平台才使它们与其他人区分开。 他们需要:
-跨数据中心的高可靠性
-可扩展到数千个网络节点
-巨大的读/写带宽要求
-支持大小为千兆字节的大数据块。
-跨节点高效分配操作以减少瓶颈
4. 系统具有主服务器和块服务器。
-主服务器将元数据保留在各种数据文件中。 数据以 64MB 的块存储在文件系统中。 客户端与主服务器对话,以对文件执行元数据操作,并在磁盘上找到包含其所需需求的块服务器。
-块服务器将实际数据存储在磁盘上。 每个块都在三个不同的块服务器之间复制,以在服务器崩溃的情况下创建冗余。 一旦由主服务器指示,客户端应用程序将直接从块服务器检索文件。
5. 即将上线的新应用程序可以使用现有的 GFS 集群,也可以使用自己的集群。 了解他们在整个数据中心使用的配置过程将很有趣。
6. 关键在于足够的基础架构,以确保人们可以选择其应用程序。 可以调整 GFS 以适合单个应用程序的需求。
### 使用 MapReduce 处理数据
1. 既然您拥有一个良好的存储系统,那么如何处理如此多的数据呢? 假设您在 1000 台计算机上存储了许多 TB 的数据。 数据库无法扩展或无法有效地扩展到这些级别。 那就是 MapReduce 出现的地方。
2. MapReduce 是用于处理和生成大型数据集的编程模型以及相关的实现。 用户指定一个处理键/值对以生成一组中间键/值对的映射函数,以及一个归约函数,该归约函数合并与同一中间键关联的所有中间值。 在此模型中,许多现实世界的任务都是可以表达的。 以这种功能风格编写的程序会自动并行化,并在大型商用机器集群上执行。 运行时系统负责划分输入数据,在一组机器上调度程序的执行,处理机器故障以及管理所需的机器间通信的细节。 这使没有并行和分布式系统经验的程序员可以轻松利用大型分布式系统的资源。
3. 为什么要使用 MapReduce?
-在许多机器之间分区任务的好方法。
-处理机器故障。
-适用于不同的应用程序类型,例如搜索和广告。 几乎每个应用程序都有 map reduce 类型的操作。 您可以预先计算有用的数据,查找字数,对数据 TB 进行排序等。
-计算可以自动移近 IO 源。
4. MapReduce 系统具有三种不同类型的服务器。
-主服务器分配用户任务以映射和简化服务器。 它还跟踪任务的状态。
-地图服务器接受用户输入并对其进行地图操作。 结果将写入中间文件
-Reduce 服务器接受地图服务器生成的中间文件,并对它们执行 reduce 操作。
5. 例如,您要计算所有网页中的单词数。 您将把存储在 GFS 上的所有页面送入 MapReduce。 这将同时在数千台计算机上发生,并且所有协调,作业调度,故障处理和数据传输将自动完成。
-步骤如下:GFS->映射->随机播放->缩减->将结果存储回 GFS。
-在 MapReduce 中,地图将一个数据视图映射到另一个数据视图,生成一个键值对,在我们的示例中为单词和计数。
-改组聚合密钥类型。
-减少量汇总所有键值对并产生最终答案。
6. Google 索引编制管道具有约 20 种不同的简化地图。 管道使用一堆记录和聚合键来查看数据。 第二个 map-reduce 耗时较长,会得到该结果并执行其他操作。 等等。
7. 程序可能很小。 最少 20 到 50 行代码。
8. 一个问题是流浪汉。 散乱的人是比其他人慢的计算。 由于 IO 速度慢(例如控制器故障)或 CPU 暂时出现峰值,可能会导致流浪汉。 解决方案是运行多个相同的计算,并在完成一个计算后杀死所有其余计算。
9. 在 map 和 reduce 服务器之间传输的数据已压缩。 这个想法是因为服务器不受 CPU 的限制,因此有必要花数据压缩和解压缩以节省带宽和 I / O。
### 在 BigTable 中存储结构化数据
1. BigTable 是一个大型的,容错的,自我管理的系统,其中包括 TB 级的内存和 PB 级的存储。 它每秒可以处理数百万次读/写。
2. BigTable 是建立在 GFS 之上的分布式哈希机制。 它不是关系数据库。 它不支持联接或 SQL 类型查询。
3. 它提供了按键访问结构化数据的查找机制。 GFS 存储不透明的数据,许多应用程序需要具有结构的数据。
4. 商业数据库根本无法扩展到该级别,并且无法在 1000 台计算机上使用。
5. 通过控制自己的低级存储系统,Google 可以获得更多的控制权和杠杆作用来改进其系统。 例如,如果他们想要使跨数据中心操作更容易的功能,则可以将其内置。
6. 可以在系统运行时添加和删除计算机,并且整个系统都可以正常运行。
7. 每个数据项都存储在一个单元格中,可以使用行键,列键或时间戳对其进行访问。
8. 每行存储在一个或多个平板电脑中。 数位板是一系列 64KB 的块,其数据格式为 SSTable。
9. BigTable 具有三种不同类型的服务器:
-主服务器将平板电脑分配给平板电脑服务器。 他们跟踪平板电脑的位置,并根据需要重新分配任务。
-平板电脑服务器处理对平板电脑的读/写请求。 当超出尺寸限制(通常为 100MB-200MB)时,他们会拆分平板电脑。 当平板电脑服务器出现故障时,每台 100 台平板电脑服务器将拾取 1 台新平板电脑,然后系统将恢复。
-锁定服务器形成分布式锁定服务。 打开平板电脑进行书写,主控权和访问控制检查之类的操作需要相互排斥。
10. 位置组可用于将数据的相关位物理存储在一起,以实现更好的参考位置。
11. 平板电脑尽可能多地缓存在 RAM 中。
### 硬件
1. 当您有很多机器时,如何构建它们以使其具有成本效益并高效使用电源?
2. 在顶部使用超廉价的商品硬件和内置软件来应对其死亡。
3. 如果您使用容易发生故障的基础架构,而不是基于高度可靠的组件构建的基础架构,则可以将计算机功耗提高 1000 倍,而成本却降低了 33 倍。 为了使此策略有效,您必须在不可靠性的基础上建立可靠性。
4. Linux,内部机架设计,PC 类主板,低端存储。
5. 基于性能的每瓦价格并没有改善。 有巨大的电源和散热问题。
6. 混合使用搭配使用自己的数据中心。
### 杂项
1. 快速推出更改,而不必等待质量检查。
2. 图书馆是构建程序的主要方式。
3. 有些应用程序是作为服务提供的,例如爬网。
4. 基础结构可处理应用程序的版本控制,因此可以发布它们而不必担心发生问题。
### Google 的未来发展方向
1. 支持地理分布式集群。
2. 为所有数据创建一个全局名称空间。 当前,数据按群集进行隔离。
3. 更好,更好的数据和计算自动化迁移。
4. 解决将广域复制与网络分区结合使用时发生的一致性问题(例如,即使群集因维护而脱机或由于某种故障而保持服务正常运行)。
## 得到教训
1. **基础设施可以成为竞争优势**。 当然是给 Google 的。 他们可以更快,更便宜地推出新的互联网服务,而且在其他竞争者中还可以大规模地推出。 许多公司采用完全不同的方法。 许多公司将基础设施视为支出。 每个小组将使用完全不同的技术,并且几乎没有计划和如何构建系统的共性。 Google 视自己为一家系统工程公司,这是研究构建软件的一种非常新颖的方式。
2. **跨多个数据中心仍然是一个尚未解决的问题**。 大多数网站位于一个和最多两个数据中心。 我们应该说,如何在一组数据中心之间完全分配网站是很棘手的。
3. **如果您没有时间自己重新构建所有这些基础架构,请看一下 Hadoop **。 Hadoop 是此处介绍的许多相同想法的开源实现。****
4. **平台方法的一个令人赞赏的优势**是初级开发人员可以在平台之上快速而自信地创建健壮的应用程序。 如果每个项目都需要创建相同的分布式基础架构轮子,您会遇到困难,因为知道如何做到这一点的人相对很少。
5. **协同作用并不总是胡扯**。 通过使系统的所有部分协同工作,一项改进可以帮助他们。 改进文件系统,每个人都可以立即透明地受益。 如果每个项目使用不同的文件系统,那么整个堆栈就不会有持续的改进。
6. **构建无需运行系统即可运行的自我管理系统**。 这使您可以更轻松地在服务器之间重新平衡资源,动态添加更多容量,使计算机脱机并妥善处理升级。
7. **创建达尔文式基础结构**。 并行执行耗时的操作并赢得优胜者。
8. **不要忽略学院**。 学术界有很多好的想法,这些想法无法转化为生产环境。 Google 所做的大部分工作都是现有技术,而不是大规模部署。
9. **考虑压缩**。 当您有大量的 CPU 可供使用且 IO 有限时,压缩是一个不错的选择。
好文章。 真的很好。 真的非常好文章。 真的真的真的真的好文章。
亚马逊拥有“云计算”功能,可以在此规模上为您提供更好的性价比。
真的很好.. / SG
我喜欢这篇文章...天哪,你知道你的东西。 最好的部分是,由 Google 制作的这些视频是您的参考框架。 我强烈建议您甚至进一步简化它。 我喜欢这些内容,您真的应该在 Scalability 2.0 下将这些内容添加到 iMarketingGuru 中。我将放置有关这些类型的可伸缩性的文章链接,您可以随时给自己很多链接爱,并继续进行下去。 维基。 我喜欢这个东西= o)
感谢您分享这些信息。
真是胡扯。
Google 只会进行搜索和搜索,它们不会在 gmail,google talk,SDK,电子表格,Checout 或任何其他服务中发挥作用。
迟早您会弄清楚-当人们变得更聪明并停止按 Google 广告上的链接时-Google 奶牛将停止现金流...
内容丰富,但缺乏细节。 我确实同意上面的那个家伙,他们只是在搜索中大放异彩,他们需要在其他领域大力推广牛奶:)
很棒的内容。 真的很有用。 干杯!
感谢您分享此信息,它非常有用
很棒的帖子!
我想 Google 会以某种方式创建 Google 操作系统。
它只是存在于云中并且可以使用的服务器和集群的集合。 :-)
作为对您的文章的深入研究的副作用,我将其翻译为德语: [http://habacht.blogspot.com/2007/10/google-architecture.html](http://habacht.blogspot.com/2007/10/google-architecture.html)
Google 负担得起所有这种结构^)
我将不得不保存并稍后重新阅读。 这里有很多细节可以帮助解释 G 的一些怪癖。 仅仅考虑其背后的庞大体系结构,只会让我的思想融化。
Google 以前已经丢失了其电子邮件客户的数据。 不要对谷歌如此信服。 谷歌是一家拥有其他类似缺陷的公司。 他们还不像微软那么糟糕,但是给它一点时间,他们就会到达那里。 如果您想保护自己的数据安全,请自己做,并确保 99.9999%的时间都可以正常工作。
非常有趣且内容丰富的文章!
我发现它是我正在研究的某些项目的体系结构的重要参考。
真的很好!
完美的文章,谢谢。 Google 变得比搜索引擎更重要
优秀文章
哪里描述 Google LAB:GWS-Google Web Server?
Google 只是搜索者中的第一个! 例如, [http://loadingvault.com](http://loadingvault.com) 或 [http://loadingvault.com](<a rel=) “ > quickshare search 和 google.com 之间的区别?这两个网站都在搜索 正确的信息!广告管理是一件非常好的事!
好。 谢谢。 :)
Quite informative but lacks the nity grity details. I do agree to the fellow above that they only shine in search they need to pitch hard in other areas to milk :)
我曾经阅读过有关 MapReduce 体系结构的最佳文章。
知道像 Google 这样的大公司如何运作总是很有趣的。
谢谢..
给“什么废话”的人。 多么透明。 如果我们从主流中脱颖而出,就好像我们对某个主题有一些内在的,高超的知识,我们会显得聪明吗? 本文并不将 Google 定位为最终的所有软件公司。 他们是搜索引擎,而且做得很好。 这是关于他们如何做好的。 真是的 如果它们“不如微软那么糟糕”-??? Microsoft 在 200 个国家/地区拥有 60,000 名员工。 您雇用多少人? 我对这些消极,无知的人感到厌烦,这些人试图以牺牲别人的工作成果为代价看起来很聪明……
多数民众赞成在一个页面上收集的很好的信息收集。
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训