类 facebook 消息系统的数据库规范化答案

【问题标题】：Database normalization for facebook-like messaging system类 facebook 消息系统的数据库规范化
【发布时间】：2011-10-23 20:21:29
【问题描述】：

关于消息系统的讨论有很多，但主要与电子邮件结构有关。在规范化数据库中，如何成为成员消息传递的最有效方式？

我正在考虑创建一个包含五列的消息表：

ID (PRIMARY KEY)
First_Person (FK user_id)
Second_Person (FK user_id)
Message
date

我担心看这张大桌子。

查找某个人的所有消息（例如 user_id 876）

SELECT * FROM messages WHERE First_Person='876' OR Second_Person='876'

两个人之间的交流

SELECT * FROM messages WHERE (First_Person='876' OR Second_Person='876') 
AND (First_Person='1500' OR Second_Person='1500') ORDER DESC BY date

由于这种消息传递就像聊天一样，对于成千上万的成员，这张表可以增长到数十亿行（而不是数百万行）。那么，在这么大的表中搜索消息效率高吗？

【问题讨论】：

那么消息的文本存储在哪里？在另一张桌子上？
否，在消息列中（表格为消息）。
哦。我将其读作“消息日期”，因为当时尚未对其进行编辑以将它们放入代码块中，并且它们都在一行上并且没有逗号分隔。你也说它有四列，但它显然有 5。
你说的很对 :) 我稍后添加了日期。

标签： mysql database email normalization messaging

【解决方案1】：

你说得对，这么大的桌子是不能用的。如果您需要一个真正的消息保存系统，最好看看 NoSQL 解决方案（如 HBase、Cassandra、MongoDB 等），您将不得不忘记您对关系数据库的任何了解。

但是，使用 MySQL，如果将表拆分成非常小的部分，您仍然可以做一些可扩展的事情。让一个表保留最多 1k 个用户的消息（除非两个用户都来自同一个表，否则您需要将所有消息写入两次）。另外，在一个数据库中保留不超过 1k 个表，达到此限制时自动创建另一个表。拥有多个数据库（甚至在一台物理服务器上）将使 DBA 在当前服务器过载时可以轻松地将每个数据库转移到新服务器。要获取某个用户的消息，您的代码必须从您将拥有的地图中获取所需的数据库/表。

【讨论】：

感谢您的建议性回复。由于所有其他数据都在 mysql 上，因此并行运行另一台服务器（例如 MongoDB）效率不高。我理解您将行拆分为多个表的意思；但我没有得到几个数据库的用处。每个表都保存为不同的文件；因此，从一个表中检索数据不受其他表存在的影响。为什么要创建多个数据库？
将一个表拆分（分区）为多个表，使每个表变小，因此易于搜索、索引和更改。
将它们全部保存在一个数据库中将一直有效，直到您的磁盘/cpu 能够在小流量上进行读/写，但在获得普及后，您将不得不添加另一台服务器。移动整个数据库是很自然的，加上安全。在代码中连接到可变主机并不是什么大问题，作为交换，您将获得水平缩放支持。