# 關于 Wayback 機器如何在銀河系中存儲比明星更多的頁面的簡短說明 > 原文： [http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html](http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html) [](https://farm6.staticflickr.com/5524/14195687156_f1ff1631aa_o.jpg) [Wayback Machine](https://archive.org/web/web.php) 如何工作？ 現在，有超過[個索引](http://blog.archive.org/2014/05/09/wayback-machine-hits-400000000000/)的網頁達 4000 億個，可以一直瀏覽到 1996 年的互聯網，這是一個更加引人注目的問題。 我看了好幾次，但是我從來沒有找到一個很好的答案。 這是來自 Hacker News 上一個線程的一些信息。 它以 [mmagin](https://news.ycombinator.com/item?id=7723291) 開頭，前存檔員工： > 我不能說說他們目前的基礎架構（盡管現在更多的是開源的-http://archive-access.sourceforge.net/projects/wayback/），但是就回溯機器而言， 任何地方都沒有 SQL 數據庫。為了使 Wayback 機器運行： > > * 存檔數據為 ARC 文件格式（http：// en 的前身）。 wikipedia.org/wiki/Web_ARChive），實質上是單獨壓縮的記錄的串聯。 也就是說，您可以尋求特定的偏移量并開始對記錄進行解壓縮。 因此，您可以使用三元組（服務器，文件名，文件偏移量）訪問任何已歸檔的網頁，從而將其散布在許多商品級機器上。 > * 構建了所有內容的排序索引，該索引使您可以查找（url）并提供時間列表或（url，time）到（文件名，文件偏移）。 它是通過構建一個排序的文本文件（首先在 url 上排序，第二次在時間上排序）并通過簡單地將其拆分為 N 個大致相等的大小在多臺計算機上分片來實現的。 在排序后的文本文件中進行二進制搜索的速度之快令人驚訝，部分原因是您在文件中查看的前幾點仍然被緩存在 RAM 中，因為您經常點擊它們。 > * （這是我有點生銹的地方），Web 前端會收到一個請求，查詢適當的索引機。 然后，它將使用一種小機制（可能是網絡廣播？）來查找（唯一）文件名所在的服務器，然后從該服務器請求特定記錄。 > * （編輯：僅供參考，我的知識已有 5 年了。我知道他們做了一些事情，以使該指數比當時更先進。） > > 至少，我會考慮將 blob 移出 MySQL 并將其放入文件系統中。 文件系統擅長于此。 您當然可以做一些像文件名一樣的內容的 SHA-1 哈希這樣簡單的事情，然后根據文件系統的性能特征，在存儲它們的樹中可以有幾個級別。 da39a3ee5e6b4b0d3255bfef95601890afd80709 進入目錄 da / 39 /，然后將 da39a3ee5e6b4b0d3255bfef95601890afd80709 插入表的“指針”字段中，以替換實際數據。 顯然，此設計假定 _that_ 文件的內容不變。 如果要更改表中該行的數據，則必須在文件系統中寫入一個新文件并更新“指針”。 互聯網檔案[的 sam 和 raj 回復了](https://news.ycombinator.com/item?id=7723726)： > Thanks! We were writing up a response at the same time:The Wayback Machine data is stored in WARC or ARC files[0] which are written at web crawl time by the Heritrix crawler[1] (or other crawlers) and stored as regular files in the archive.org storage cluster. > > 播放是通過對 WARC 數據中的指針的 2 級索引進行二進制搜索來完成的。 該索引的第二層是一個 20TB 壓縮的（URL，日期，指針）元組的排序列表，稱為 CDX 記錄[2]。 第一級適合核心，它是 CDX 索引中每 3000 個條目的 13GB 排序列表，并帶有指向較大 CDX 塊的指針。 > > 索引查找的工作方式是二進制搜索存儲在核心中的第一級列表，然后 HTTP 范圍請求從 CDX 索引加載適當的第二級塊。 最后，通過 CDX 記錄指向的范圍請求 WARC 數據加載網頁數據。 在最終輸出之前，將應用鏈接重寫和其他轉換以使回放在瀏覽器中正常工作。 > > 服務器堆棧： > > * 前端：Tengine + HAProxy 到 Wayback Tomcat 應用程序服務器池[3] > * 后端：Redis 支持的 archive.org 元數據 API [4]用于對象定位，而 nginx 在 linux 上（通過 ext4）用于數據服務 > > * [0] http://en.wikipedia.org/wiki/Web_ARChive > * [1] https://github.com/internetarchive/heritrix3 > * [2] https://github.com/internetarchive/CDX-Writer > * [3] https://github.com/internetarchive/wayback > * [4] http://blog.archive.org/2013/07/04/metadata-api/ sytelus [問](https://news.ycombinator.com/item?id=7724051)：為什么不使用哈希表而不是二進制搜索？ gojomo [回復了](https://news.ycombinator.com/item?id=7724347)： > 這里是前存檔員工（&還是偶爾的合同貢獻者）。 這是我在 2003 年加入時的第一個問題！ > > 某些 Wayback Machine 查詢需要經過排序的鍵遍歷：列出可以捕獲 URL 的所有日期，發現 URL 的最近日期，并列出所有以某個 URL 前綴開頭的可用 URL。 > > 維護（URL，日期，指針）的規范排序主索引（20TB 二級索引 rajbot 提到）可以滿足兩種查詢。 一旦有了該工件，就可以相當高效地滿足各個捕獲查找的需求。 （然后，分布式哈希表將需要額外維護。） > > 同樣，查詢也不是隨機的：存在熱范圍，甚至單個用戶的會話都從范圍查詢（URL 的所有日期）開始，然后訪問相同范圍的一個 URL。 然后，加載頁面內聯資源的最近日期捕獲開始達到相似的范圍，后續點擊鏈接或附近日期也是如此。 因此，即使主索引仍在旋轉的磁盤上（除非最近發生了一次重大的 SSD 升級，以免引起了我的注意），但瀏覽范圍卻經常出現在主內存緩存中。 > > 毫無疑問，有許多地方可以改進，但是這種基本的排序索引模型已經很適合該應用程序很長時間了，避免了過多的特定于領域的復雜性，并且適用于許多代索引/分片/復制/內部- API 調整。 > > 順便說一句，Archive 正在招聘多個技術職位，其中包括負責開發下一代 Wayback Machine 的高級職位：https：//archive.org/about/jobs.php [Vecrios](https://news.ycombinator.com/item?id=7723794) 中的一個有趣的問題：我仍然無法理解它們如何存儲大量數據并且不會用完空間？ dwhly [回答](https://news.ycombinator.com/item?id=7724035)： > 幾年前與 Brewster 的一次對話中：磁盤驅動器的密度加倍使它們在 Wayback 機器的空間方面保持相對中性。 它仍然占據著與過去 10 年大致相同的尺寸，我認為這實際上是一組大約 15-20 英尺長的機架。 > > 但是，新的電視新聞和搜索功能所需的空間甚至遠遠超過 IIRC 檔案庫，或者肯定正在朝這個方向發展。 并感謝 [rietta](https://news.ycombinator.com/item?id=7724313) 所說的 Wayback Machine 如何在銀河系中存儲比星星更多的頁面。 神話般的圖像。 據我了解，大約在 2000 年開始出現 GMR（巨磁阻比）讀取磁頭，從而使硬盤容量每年翻一番（甚至更多）。 我記得在 2000 年，典型的硬盤驅動器為 2 到 4 GB。 當然，現在是 5 到 10 TB，而它們增加到約 20 TB。 因此，我完全不難理解 Wayback 機器如何在硬盤大小相同的情況下保存“足夠”的數據。