非常多记录的数据库架构（例如社交网络中的消息）[关闭]

Posted 2023-02-24

【中文标题】非常多记录的数据库架构（例如社交网络中的消息）[关闭]

【英文标题】：database architecture for very many records (for example messages in social network) [closed]

【发布时间】：2012-09-30 08:56:39

【问题描述】：

我想了解如何为聊天消息构建大型站点数据库架构。（例如 facebook.com 或 gmail.com）

我认为消息被重新分配到不同的表中，因为将所有消息都放在一个表中是不可能的，原因是它们的数量很大，对吗？ （我认为这里不能分区）

那么，使用什么逻辑在不同的表中重新分配消息？我有几个变体，但我认为它们都不是最佳变体。 所以一般来说，我对你对此的看法很感兴趣？另外，如果您知道一些关于此的好文章，请发布链接。

【问题讨论】：

从 Postgres 开始，如果需要，迁移到 HBase

【参考方案1】：

目前的答案是hadoop

他们有一个分布式文件系统和一个可以使用http://hbase.apache.org的数据库

http://en.wikipedia.org/wiki/HBase

【参考方案2】：

好的，问题是如何对数据集进行分区。考虑这一点的最简单（通常也是最好的）方法是考虑访问模式。哪些消息需要快速，哪些消息可能很慢，以及如何管理每条消息。

通常较旧的消息可以保存在低网络速度/低内存/非常大的存储节点（数 TB）上。

新消息应该在高带宽网络/高内存/低存储节点上（千兆字节就足够了）。

随着流量的增长，您需要将存储添加到慢速节点，并将节点添加到快速节点（水平扩展）。

每晚（或更频繁地）您都可以将旧消息复制到历史数据库，并从当前数据库中删除消息。查询可能需要寻址两个数据库，不过这样也不算太麻烦。

当您向外扩展时，可能需要对数据进行分片，即按一些数据值拆分。用户 ID 拆分是有意义的。为了让生活更轻松，每个用户都可以存储对话的所有方面。我建议为此使用时间分段文本（磁盘访问通常在 4k 边界上），尽管最初这对您来说可能太复杂了。

查询现在需要用户感知，以便查询正确的数据库。一个简单的查找表将对此有所帮助。

另一件事是在输入时压缩消息，并在输出时解压缩。文本很容易压缩，并且可能会因 CPU 的少量增加而使您的吞吐量翻倍。

许多 NoSQL 数据库为您完成了很多艰苦的工作，但在您当前系统的容量用完之前，您可能希望坚持使用您熟悉的技术。

祝你好运！

【参考方案3】：

前段时间有一篇文章reddit是如何从小到大的。 他们没有用户消息系统，但我想这将适用于大量数据的场景 http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html

编辑：关于数据库的“有趣”部分是＃3 - 不要担心架构.. 他们使用 2 个表来处理所有事情。事物和数据。

【参考方案4】：

Facebook 将Apache Cassandra 用于他们的一些存储（文档数据库），并大量使用memcached 以使其具有良好的扩展性。

这里有更多关于FB's nuts and bolts 的信息。 您还可以在FB developer news 中找到一些宝石。

【讨论】：

Facebook 不久前为 HBase 放弃了 Cassandra。 highscalability.com/blog/2010/11/16/…