# FictionPress：在網絡上發布 600 萬本小說 > 原文： [http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html](http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html)  FictionPress 同時經營 FictionPress.com 和 FanFiction.net，擁有超過 600 萬種小說作品，來自世界各地的數百萬作家/讀者以 30 多種語言參加。 **已解決的問題**： * 支持 100+百萬行的復雜高效索引。 * 不管數據大小如何增長，可預測且一致的性能。 * 快速恢復。 * 確保大規模的可預測性能 **挑戰**： FictionPress 為龐大的用戶群提供了許多交互式功能。 其中包括討論論壇，現場消息傳遞和用戶評論。 FictionPress 決定建立自己的討論論壇，以滿足其嚴格的安全性和性能要求。 FictionPress 的首席技術官邢力指出，該網站“需要舉辦成千上萬個論壇。 現有的論壇軟件無法達到我們的性能和安全目標。” 為了確保論壇的實時響應性，FictionPress 需要具有創建和有效維護復雜索引并能夠支持數百萬個小行的能力。 此外，它需要能夠對它們建立索引，并且對資源成本和性能的影響最小。 “使所有這些工作并提供良好的客戶體驗的唯一方法是，即使行數超過 1 億，也要保證我們的數據庫后端能夠提供可預測的穩定性能。” FictionPress 考慮使用 InnoDB，它是 MySQL 的默認存儲引擎，但它無法提供可預測的大規模性能。 隨著行數的增加，索引變得非常慢，從而導致讀寫性能下降。 InnoDB 還沒有提供多個聚簇索引的性能增強功能。 **解決方案**： FictionPress 使用 MariaDB 和 TokuDB 管理其討論論壇，評論和現場消息傳遞系統。 FictionPress 在具有專用硬件的 Linux 環境中安裝了 TokuDB。 每種配置都有一個主機，其中有多個讀取從機。 Li 說：“ TokuDB 的高寫入并發性和對多個聚簇索引的支持使我們可以自由地設計和部署性能更好的大規模查詢。” 這對于 FictionPress 很重要，因為其環境在不斷擴大。 可預測的性能：“雖然原始性能很重要，但是響應時間的可預測性是我們對系統進行縮放的一個重點”。 “ InnoDB 只能有一個聚簇索引，但是 TokuDB 基本上為您提供了無限數量。 此外，MyISAM 和 InnoDB 都由于我們大小的數據庫上的許多索引而變慢。 MyISAM 還由于并發而導致復制滯后。 最后，TokuDB 為我們提供了可預測性，大規模性能以及更靈活的索引編制，而沒有其他 MySQL 選項所具有的限制。” 成本：“要獲得更高的性能，總可以向問題扔硬件”，李說。 “相反，通過使用 TokuDB，我們提高了可伸縮性，同時節省了額外的服務器硬件的成本，如果 TokuDB 不在圖中，則需要額外的服務器硬件。 此外，由于改進了壓縮，與 MyISAM 相比，磁盤空間減少了 8 倍。 節省硬件成本使遷移到 TokuDB 成為一個容易的決定。” 崩潰恢復：FictionPress 最初一直在使用 MyISAM。 Li 表示：“我們需要替換 MyISAM 來處理較小的 BLOB 數據。” “事實上，我們希望盡可能遠離 MyISAM，以縮短其長時間的崩潰恢復。 InnoDB 是一種選擇，但是 TokuDB 為我們自己的數據集提供了更好的壓縮和更小的核心數據和索引數據存儲空間。” 熱模式更改：“出于性能原因，我們需要大量索引，但也需要快速添加和維護這些索引，” Li 表示。 “ TokuDB 是我發現的唯一提供熱模式更改（例如熱索引）的 MySQL 解決方案。 熱模式更改是一項強大的功能，我們可以使用它來最大程度地減少系統范圍內升級期間的停機時間，并縮短我們的應用程序/架構開發周期。” 李說：“我寫的是關于我自己的，但是是第三人稱的。”