平面文件与数据库 - 速度？

Question

我正在制作聊天程序，我需要一个存储消息的地方。客户端将每隔x秒与服务器联系，并使用最后收到的消息ID，服务器将在客户端已加入的房间中找到ID高于该值的所有消息。

由于我不会永远存储东西，我正在考虑使用平面文件（每个房间一个，以及直接消息），只有最后40个左右的消息。但是，我认为通过比较数字，数据库会更快。

我应该使用哪种数据存储方法？

Answer 1

平面文件可能会快一点，但从长远来看它最终会变得越来越多，因为你不必只是加载SELECT * FROM messages WHERE room=nnn AND ID > yyy，而是必须加载文件，解析它，扫描每个文件。消息ID的行，转到右侧消息，然后将其读出。

这只是第一个问题。文本文件不支持多个用户写入（如果两个人同时发布到同一个房间怎么办？），并且很容易被破坏。

考虑到所有事情，我会说使用数据库会更好，即使它像SQLite一样简单，它具有出色的PHP支持。但是，考虑到多用户条件，MySQL可能是一个更好的选择。此外，MySQL具有出色的缓存功能，因此大多数情况下，最近的数据将直接来自RAM，并且比用PHP扫描文本文件的速度更快。

Answer 2

似乎您根本不​​需要保留聊天记录，那么为什么要考虑使用永久数据存储（数据库或平面文件）方法？您可以使用内存缓存软件（如Memcashed，比数据库或平面文件更快）来执行此操作。

Answer 3

通常，数据库会快得多，因为索引会让您直接转到服务器必须发送的记录。

OTOH，只有大约40条消息，它很可能适合RAM，而且记录很少，即使是最简单的线性搜索例程也会比单个高清访问快得多。

尽管如此，使用数据库要容易得多，我会将其用于简单而不是速度。此外，如果您有很多同时发送的房间，那么自己编写这些房间意味着有很多机会可以解决不必要的延迟开发的小错误。

只需使用数据库。

Answer 4

尽管这是一个古老的问题，我还是会把我的帽子扔进戒指。为了提高速度，可靠性和易用性，数据库显然是一个很容易的选择...有一个主要的警告，很多人都在忽视，这是大多数共享主机（最常见的网络托管形式）只允许15或因此，即使VPS通常只允许100-200，专用500或更多。这意味着如果你有（n）个用户汇集每秒（s）这些连接将被快速吞噬，如果你还运行任何类型的CMS，速度会更快。在VPS上开发我自己的聊天室代码时，我自己也面临着这些问题。

到目前为止，我的方法就是这样。

• 确保传递lastMessageReceived变量以限制响应。
• 如果公共聊天室通过时间戳过滤器以及上面的
• 如果可能的话，使用像MySQLnd这样的数据库缓存引擎，启用查询缓存，并将TTL设置为合并率。
• 不要对你的汇集率感到疯狂1-2秒的时间间隔可能看起来很整洁，但它会杀死你的连接数。将其降至5秒甚至更多不会真正产生巨大的差异，用户可能不会注意到，并且您的服务器负载将会轻得多。甚至考虑在高负荷期间自身升高的可变汇集率。
• 将您的ajax编写为使用超时而不是其池的间隔，并将超时调用放在ajax成功回调中，这可以防止请求在高峰期间堆叠。
• 最大的一个，如果使用一个包含许多用户的共享聊天室，编写自己的代码将SQL查询缓存到json文件中并将其提供给ajax请求，并编写一些自定义TTL代码来检查其年龄和重新开始 - 在请求期间根据需要填充它，如果你的主机允许，CRON会很棒。检查文件并将AJAX请求重定向到它的年龄是一个更高级别的功能，与查询数据库相比，服务器开销非常小。并且不要在PHP中解析文件以寻找过滤旧消息，将文件中的第一条消息存储在文件夹中，例如chat_243.json并将其保存为已经格式化的json，然后只提供整个文件如果请求进入带有lastMessageReceived = 243的php。由于这将创建多个文件，因此您需要一个函数来清理超过（m）分钟的文件，但这也是服务器的轻量级工作。

还有一些选项，比如为聊天和套接字设计的数据库引擎（node.js），但那些需要比典型的主机帐户允许更多的服务器调整，为了我的目的，我一直在写我的聊天室，记住这个想法，它可能会在某个时候部署到共享服务器。