我正在构建一个英语网络词典，用户可以在其中输入单词并获取定义。我考虑了一段时间，因为数据是 100% 静态的，而且我一次只能检索一个单词，所以最好使用文件系统 (ext3) 作为数据库系统，而不是选择使用 MySQL 来存储定义。考虑到您必须连接到 MySQL 并且这本身是一个非常缓慢的操作，我认为开销会更少。
我担心的是，如果我的系统受到 500 字检索/秒的轰炸，我还是将文件系统用作数据库会更好吗？或者增加的文件系统读取会阻碍性能，而不是 MySQL 可能在幕后做的事情？
目前，层次结构由单词的第一个字母、第二个字母和第三个字母分割。因此，如果您要搜索“水”的定义，脚本 (PHP) 将尝试从“../dict/w/a/t/water.word”中读取（在清理有问题的单词和小写）
我是朝着正确的方向前进还是有更快的解决方案（不计算使用 memcached 之类的东西在内存中存储定义）？存储在任何目录中的文件数量是否会影响性能？我应该在目录中存储的文件数量的粗略基准是什么？
你有什么理由相信这个决定对解决方案的整体性能很重要？除了提供定义之外，它还能做什么？
无论如何，您是否将 MySQL 作为解决方案的一部分，或者如果您在此处选择它作为解决方案，您是否需要添加它？
定义的权威来源在哪里？（可能是复制的）文件系统，还是一些离线数据库？
从架构上看，这似乎应该存在于数据库中 - 文件系统是将大量名称映射到值的一个奇怪地方（正如您的文件系统结构通过首字母分解事物所证明的那样）
如果它在数据库中，回答诸如“有多少定义？”之类的问题。容易得多，但是如果您不关心应用程序的这些事情，这可能无关紧要。
因此，在某种程度上，这感觉像是在寻求超级优化某些性能实际上不会对整体解决方案产生太大影响的东西的性能。
我是“让它正确，然后让它快速”的粉丝，而“正确”会更直接地通过 DB 实现。
当然，最终的答案是两者都尝试，看看哪一个最适合你的情况。
保罗
字典需要的查找类型正是数据库擅长的。我认为您描述的文件系统方法将不可行。不要太难了！使用数据库。
您可以保留一个连接池以加快连接到数据库的速度。
此外，如果此应用程序需要扩展到多台服务器，则文件系统可能难以在服务器之间共享。
所以，我第三个建议。使用数据库。
但是除非它是一个非常大的字典，否则缓存将意味着您几乎总是从本地内存中获取内容，所以我认为这不会成为您的应用程序的最大问题 :)
DB 听起来非常适合您的需求。我也不明白为什么 memcached 是相关的（你的数据有多大？不能超过几 GB ......对吗？）
数据大约为几 GB。我的目标是速度、速度、速度（将使用 XHR 加载定义）。正如我所说的，数据是静态的，永远不会改变，除了每个请求的单个读取操作之外，我在任何地方都不会使用其他任何东西。所以我很难说服使用 MySQL 及其所有的臃肿。
使用这种策略，文件系统或 MySQL 在高负载下哪个会首先失败？至于扩展复制是答案，因为数据永远不会改变并且只有几 GB。
先让它工作。过早的优化是不好的。
使用数据库可以更轻松地重构您的模式，并且您不必编写基于索引的查找的实现，这实际上是不平凡的。
说连接到数据库“是一个非常缓慢的操作”夸大了问题。实际上连接不应该花费很长时间，而且无论如何您都可以重用连接。
如果您担心读取扩展，1G 的数据库非常小，因此您可以将它的只读副本推送到每个 Web 服务器，并且它们都可以从本地副本中读取。如果写入保持在不影响读取性能的水平，这将为您提供几乎完美的读取可扩展性。
此外，1G 的数据很容易放入内存中，因此您可以通过在启动时将整个数据库加载到内存中来加快速度（在该节点向负载均衡器通告自己之前）。
每秒 500 次查找是微不足道的。也许我会开始担心每台服务器每秒大约 5000 个。如果您无法在现代硬件上实现每秒 5000 次键查找（来自适合 RAM 的数据库？！！），那么您的实现存在严重错误。
同意这是过早的优化，并且 MySQL 肯定会为这个用例提供足够的性能。我必须补充一点，您还可以使用基于文件的数据库，例如非常快速的Tokyo Cabinet作为折衷方案。遗憾的是它没有 PHP 绑定，因此您可以使用它的祖父DBM。
也就是说，不要使用文件系统，据我所知，没有充分的理由这样做。
在您的 ram 中使用虚拟驱动器（谷歌它以了解如何为您的发行版），或者如果您的数据由 PHP 提供，则使用 APC，memcache 可能适用于 mysql。就我个人而言，我不认为你在这里做的优化真的是你应该花时间的地方。每秒 500 个请求是巨大的，我认为使用 mysql 会为您以后提供更好的转发功能。我认为如果你想与竞争对手区分开来，你需要专注于功能而不是速度。也有一些关于网络 UI 的好讨论，服务器速度只是整个画面中的一个小因素。
祝你好运
您可能还会考虑使用 no-sql 数据库（如 riak、mongo 甚至 redis）来处理此类问题。它们都非常快，可以帮助您进行复制。在这样的实例中，Mysql 可能会过度杀伤且难以扩展，但其他实例具有一些强大的工具