如何维护聊天数据？
我有一个好奇的问题... 我想知道如何在数据库中维护聊天数据。 我一直在使用 php-mysql 应用程序，它将用户的聊天数据存储在数据库中。
现在我的问题是，如果聊天数据增加到几百万条记录，如何存储？ mysql是否支持它，或者有什么限制或负担吗？
以 Gmail 聊天为例。我可以无限制地聊天，还可以检索我以前的所有聊天数据。怎么可能？
谁能回答我这个典型的问题吗？
I have a curious question...
I wanted to know how to maintain chat data in a database.
I have been using a php-mysql application, that stores chat data of users in a database.
Now my question is that, if the chat data increases, say, to some millions of records, how to store it? Does mysql support it, or have any limitations or burden ?
Take the example of gmail chat. I can chat unlimited and can also retrieve all my previous chat data. How is it possible ?
Can anyone answer this typical question of myne ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
聊天记录并不是那么重要。如果我计算每条消息大约 100 字节，每分钟 6 条消息，每天 5 小时（不过，这是一个非常健谈的话题），永久，作为最坏的情况，这将给出大约 61MB每个用户每年（！）。
这意味着如果有 100 万个健谈的聊天者（非常不可能），您将需要大约 58TB 的数据存储空间。
说这是最坏情况的计算，我会从最大 1TB 存储开始，设置数据库，然后看看情况如何。对于一个非常年轻的服务来说，发展得这么快是极不可能的。
另外，我个人不建议使用 Windows 系统来做这样的事情，除非你非常清楚自己在做什么。 Debian 发行版上的 MySQL 将存储数十亿条记录，并且由于操作系统级别的限制较少，可能会更快（有关详细信息，请参阅 MySQL 文档，应该有关于 Windows 限制的部分）。
Chat history isn't really that heavyweight. If I calculate around 100 bytes per message, 6 messages per minute, and 5 hours per day, (that is a very talkative chatter, though), permanently, as a worst case, that would give about 61MB per user per year (!).
That means with 1 million talkative chatters (very unprobable) you would need around 58TB or data storage.
Saying that this is a worst-case calculation, I would start off with a maximum of 1TB storage, set up the database, and see how things are going. It is highly unprobably for a very young service to evolve that fast.
Also, I would personally not recommend using a Windows system for something like this, unless you know very well what you're doing. MySQL on a Debian distribution will store billions of records, and probably do this faster due to less OS-level limitations (see the MySQL documentation for details, there should be section about the limitations on Windows).
MySQL 很乐意存储数百万甚至数十亿条记录；但某些数字类型还不够： 请参阅此 用于数字类型的最大值。正如您所看到的，对于例如自动增量字段，最好使用
BIGINT UNSIGNED。对于大型表来说，性能可能会成为一个问题，但这主要可以通过索引来解决（这意味着“在类似情况下，我发现性能在 100GB 左右下降”）。
MySQL will happily store millions, even billions of records; but some of the numeric types won't be enough: see this for the maxima of numeric types. As you can see, it would be better to use
BIGINT UNSIGNEDfor e.g. autoincrement fields.Performance may become a problem for large tables, but that can be mostly solved with indexes (meaning "I've seen performance decrease somewhere around the 100GB mark in a similar situation").
Google 拥有大量根据其需求设计的自定义存储。我的建议是你更具体地确定你的需求并确定你需要的平台。
Google has vast amounts of custom storage designed by it for its requirements. What I suggest is you determine your requirements more concretely and determine the platform you need.