我想了解如何为聊天消息构建大型站点数据库架构。（例如 facebook.com 或 gmail.com）
我认为消息被重新分配到不同的表中，因为将所有消息都放在一个表中是不可能的，原因是它们的数量很大，对吗？（我认为这里不能分区）
那么，使用什么逻辑在不同的表中重新分配消息呢？我有几个变体，但我认为它们都不是最佳变体。所以一般来说，我对你对此的看法很感兴趣？另外，如果您知道一些关于此的好文章，请发布链接。
问问题
851 次
4 回答
2
于 2012-09-30T09:03:57.283 回答
1
前段时间有一篇文章reddit是如何从小到大的。他们没有用户消息系统，但我想这将适用于具有大量数据的场景 http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building -reddit-to-270-million-page.html
编辑：关于数据库的“有趣”部分是#3 - 不要担心模式.. 他们使用 2 个表来处理所有事情。事物和数据。
于 2012-09-30T09:00:13.510 回答
1
好的，问题是如何对数据集进行分区。考虑这一点的最简单（通常也是最好的）方法是考虑访问模式。哪些消息需要快速，哪些消息可能很慢，以及如何管理每个消息。
通常较旧的消息可以保存在低网络速度/低内存/非常大的存储节点（多 TB）上。
新消息应该在高带宽网络/高内存/低存储节点上（千兆字节就足够了）。
随着流量的增长，您需要将存储添加到慢速节点，并将节点添加到快速节点（水平扩展）。
每天晚上（或更频繁），您可以将旧消息复制到历史数据库，并从当前数据库中删除消息。查询可能需要处理两个数据库，但这并不太麻烦。
当您向外扩展时，可能需要对数据进行分片，即按某个数据值拆分。用户 ID 拆分是有意义的。为了让生活更轻松，每个用户都可以存储对话的所有方面。我建议为此使用时间分段文本（磁盘访问通常在 4k 边界上），尽管最初这对您来说可能太复杂了。
查询现在需要用户感知，以便查询正确的数据库。一个简单的查找表将对此有所帮助。
另一件事是在传入的过程中压缩消息，并在传出的过程中解压缩。文本很容易压缩，并且可以使您的吞吐量增加一倍，以增加少量的 cpu。
许多 NoSQL 数据库为您完成了许多艰苦的工作，但在您当前系统的容量用完之前，您可能希望坚持使用您所知道的技术。
祝你好运！
于 2012-10-01T09:09:37.637 回答
0
Facebook 将Apache Cassandra用于他们的一些存储（文档数据库），并大量使用memcached以使其具有良好的扩展性。
于 2012-09-30T09:01:00.593 回答