# 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 解决方案。 热模式更改是一项强大的功能，我们可以使用它来最大程度地减少系统范围内升级期间的停机时间，并缩短我们的应用程序/架构开发周期。” 李说：“我写的是关于我自己的，但是是第三人称的。”