如何在IM（即时消息系统）的数据库中设计和存储历史消息？

Question

通过将历史消息存储在持久化存储中，我们可以实现多设备同步和消息漫游。
但是如何设计表模式和划分表呢？
在我最直接的想法中，也许每个聊天组都应该有一个表，然后在聊天组或频道中发送的消息将附加到表中。
这样，我们就会有很多表，比如table group_123,table group_345,table group_${gid}。这种方法的唯一问题是划分这么多表是否不好。
之前搜索过一些答案，大部分都存放在一张大表中，其中$gid只是表中的一个字段。
另外，这个场景mysql和mongodb的区别也让我很疑惑。我不知道哪个更好，例如为什么使用mysql或为什么不使用mysql或为什么使用mongodb或为什么不使用mongodb。

Answer 1

对任何以“我将为每个 X 创建一个表”开头的设计都非常谨慎，因为无论 X 是什么，它都可能变得太多，很快你就会拥有数千个表，并且发现仅仅管理元数据成为负担。

一般来说，关系表设计的方法是遵循database normalization的规则。您存储消息的表是一组类似的对象。归一化不区分大小适中的集合和大大小的集合。如果它们是同一类型的东西，它们会放在同一张桌子上。至少这就是规范化将指导我们做的事情。

不过，任何实现都存在实际限制，您可能会发现需要通过使用各种形式的分区或分片来改变规范化规则。规范化甚至不需要定义索引，但帮助优化查询是一个好主意。

这是关键：必须在您需要在应用程序中运行的特定查询的上下文中选择任何优化策略。优化意味着以牺牲其他类型的查询为代价来提高一种类型查询的效率。在不了解查询的情况下，您无法选择最适合您的应用程序的优化策略。

这也是在关系型和非关系型数据库之间进行选择的方法。非关系型数据库针对某些查询类型进行了优化，因此在选择任何非关系型技术或在选择该技术后选择哪种数据模型之前，您需要知道哪些查询在您的应用程序中最重要。