我正在尝试为网站创建聊天，我想知道在大量用户的情况下，数据库解决方案是否是最佳解决方案。
如果db是可接受的解决方案，我想知道哪种是最好的设计方法：
一个表是否足以存储来自所有用户的所有消息？每次用户发送消息时我是否必须存储每条消息（如同一条记录中的简单“你好”）？
我是否必须为每个聊天创建一个单独的表？
显然假设索引和分区已经完成。
我很害怕这个阶段的表现（db级别）。然后我可以更好地集中到中间件部分并在那里进行管理。
答案 0 :(得分：9)
MySQL显然不是聊天的最佳解决方案：您没有理由使用多年积压来获取最新消息，也不想每秒为每个活动用户触发查询。关系数据库的开销不容忽视。
我会选择redis：它是一个高级键值存储，具有实时交互（PUB / SUB）功能，自动过期，当涉及到大量简单数据时，它肯定比MySQL快
编辑：是的，它的所有数据都在ram中。对于世界上每个图书馆的每本书来说，一个公羊的Gb就足够了。也就是说，MySql也使用ram缓存（查询缓存）。而redis是ACID。 （过度简化：您可以启用保存到磁盘。）
如果您决定使用MySQL，则必须将每一行写入数据库，以便其他人可见。更明确的是，您需要对每条消息进行提交。确保你有某种清理机制，例如一个cronjob将超过一天的所有消息移动到一些存档表中。
想象一下你房间里有100个用户，每个用户每3秒检查一次新消息。每秒300次查询？ （好吧，体面的服务器可以处理这个，但你要求一个很好的解决方案）另一种方式：有一个memcached / redis-saved标志“Last message id”。每当有人写一些东西到聊天时改变它。现在让客户端提交它最后已知的消息ID。如果你有一个命中，即使没有MySql启动也立即退出。如果你真的很好，你可以让PHP甚至make返回适当的ETag。
关于前端客户端：每隔n秒不要发出重新加载或ajax请求！告知自己有关Websocket和长民意调查的信息。这是一种技术，浏览器打开一个不会立即返回结果的网站，但会保持连接打开，直到有东西要报告（或发生超时）
这取决于你的知识。我会选择PHP和redis，但这是因为我很了解它们。如果您更喜欢Java，请使用它。如果你没有偏好：Java更通用，php更容易开始学习。没有客观的“一刀切”的答案。
答案 1 :(得分：1)
使用NOSQL，因为它将数据存储为适合大型数据库的文件
答案 2 :(得分：0)
确定您想要的功能。我可以想到的一些可能会产生影响：