我正在寻找最快的存储方式读取与HTTP会话cookie相关的数据。
现在，我们有一个充满文件的目录，文件名是会话cookie（随机~150个字符），内容是二进制blob，通常只有几个字节 - 或者有时多达1或2千字节。我们还使用atime（最后读取时间戳）来查找和删除旧会话数据。
目录中的这些文件数量可以达到数百万，并且服务器会不断检查文件是否存在，它是什么时候，读/写它们，当然还有删除/创建它们。我怀疑ext3不是这种使用模式的理想方法吗？
存储此类数据的最佳方法是什么？我们测试了MySQL但它比ext3慢了几个数量级（我假设我们没有做错什么？）。即使只是建立连接也需要比执行典型的文件系统/ atime / fread周期更长的时间。
任何有经验的人都会受到赞赏。管理庞大的小型无关数据数据库的最快方法是什么？
我们正在使用PHP，在高端服务器硬件上使用CentOS（几乎可以买到最好的钱）。不需要群集/负载平衡，我们正在尝试减少中低流量网站上的每请求延迟。我们没有使用PHP的内置会话API，因为它在我们的情况下不起作用。
答案 0 :(得分：2)
假设你的PHP是顶级的并且经过优化，我会尝试将文件系统更改为ext4（或者我应该说，为会话数据创建一个ext4挂载）。相比之下，ext3非常慢，这可能是你的瓶颈。
如果你不能支持ext4，那么ext2也是一个选项（尽管现在ext4已经足够长了所以你应该可以使用它）。但是，如果您使用ext2，请确保仅为会话数据安装单独的安装，因为它不可靠且没有日志记录。
ext4在读取时比ext2表现更好，但是ext2在写入ext4时表现更好（很可能是由于缺少日志记录而造成“一些”开销，但这是我的理由，我可能错了）。
编辑：我还认为值得一提的是，较小的目录比一个较大的目录要好。但是，除非您使用自定义编译内核，将每个目录限制的32000个文件增加为ext3上的默认值，否则您可能正在执行此操作。但保持inode（目录中所有文件的索引）较小将提高性能。像根据第一个x字符数量将文件排序到目录中这样简单的事情可以实现这一点，而不会在能够选择会话文件之前添加太多的查找正确目录的处理开销。
答案 1 :(得分：2)
你看过in memory database了吗？它们很快，因为它们不需要在每次操作时触摸磁盘，而且有些选项可以偶尔在磁盘上写入数据，以使其持久化。
如果您的数据很简单，键值存储应该更快，因为它更轻量级，例如Redis或缓存解决方案，其中选项可以保留在磁盘上（不知道PHP但是Java的一个例子是EHcache。