面向Facebook的消息的数据库设计[已关闭]

Question

我目前正在计划PHP / MySQL中的新系统，并希望确保我的数据库可以处理我计划存储的数据量。 我的新项目的一个特点是像Facebook这样的“消息”功能。 我想确保为最终用户创造最佳体验。 该网站最终将处理1000个用户，并可能共有数百万条消息。 什么是数据库设计的最佳方法？ MySQL甚至是正确使用的数据库吗？

Answer 1

只要您正确设计数据库，MySQL对数百万或数亿条记录没有任何问题。

话虽如此，“像Facebook这样的消息功能”是一个相当广泛的定义。 通常，您将定义一个messages表，该messages表将每条消息链接到创建它的用户（即，在消息表中具有userId列）。 如果要将消息发送给多个用户，则可以通过存储由messageId和recipientId组成的多个记录来定义一对多关系的message_recipients表。 为这些表添加适当的索引，你就是那里的80％。

话虽这么说，剩下的20％可能是一个杀手。 不幸的是，您如何使用数据库将决定您还需要做什么，在做出判断之前，您必须提供有关应用程序的更多详细信息。 例如，您可能希望考虑使用自动归档解决方案来保持主表相对较小，并将旧数据移动到可以在必要时访问的备份表。 您可能不会马上需要它，但它可能在将来有所帮助。

Answer 2

Facebook最初使用的是MySQL，当他们拥有超过1亿用户的7TB收件箱数据时，他们才转移到Cassandra 。

资料来源： Lakshman，Malik：Cassandra - 分散式结构化存储系统 。

Answer 3

如果您计划处理大量数据（当然数百万甚至没有接近合格的数据），那么聘请数据库专业人员。 针对大型数据集的高效且有效的数据库设计是一个复杂的问题，需要专家。

回答你的问题是，如果设计很好，mysql可以轻松处理数百万条记录，如果设计不好，将会成为一场噩梦，就像任何其他现代数据库一样。

Answer 4

如果正确设计数据库，性能应随着数据量的对数而恶化。 换句话说，执行查询的时间将比数据量慢得多。

要实现这一目标，您必须对许多事情保持纪律：

• 您的数据库设计必须合理。 了解ER建模和规范化至关重要。 因此理解索引和其他物理数据结构的解剖结构。
• 拥有一个很好的规范化数据库之后，考虑一下它的某些“边缘”是否应该仅仅出于性能原因而明智地非规范化。
• 在整个过程中，请记住您的客户端应用程序^1将执行哪种查询：
  • 相应地设计索引 - 专门针对您知道您需要的查询索引，不要过度索引！
  • 一些设计决策，例如使用自然密钥和代理密钥以及识别与非识别关系可能会影响您需要的JOIN数量。
  • 尽量保持数据库设计对集群范围扫描， 仅索引扫描等的友好性。
• 使用特定于DBMS的机制，例如群集 ，分区，密钥压缩，物化视图（等等）。 如果DBMS不支持您认为必不可少的某种机制，请不要害怕切换DBMS！ 例如， InnoDB表总是聚集的 ，这在查询PK时是一个优势，但如果需要二级索引则可能是一个缺点。 如果您需要基于群集和基于堆的表，请使用一些支持它们的DBMS（例如Oracle或MS SQL Server）。 ²
• 仔细编写客户端应用程序。 宗教上使用绑定参数和查询准备 - 不仅可以最大限度地减少SQL解析和查询计划开销，还可以防止SQL注入！ ORM和库通常会使您无法手动执行此操作，但您仍应了解“幕后”的内容。
• 最后但并非最不重要的是，不要在假设上继续 - 而是衡量 ！ 数据库性能可以是一个很好的（而且相当复杂的）平衡行为，某些决策的影响可能不会立即显而易见

如果你正确地完成了这一切，那么在“经典”DBMS停止充分之前，你必须接近实际Facebook的数据量。 在这种情况下，1000个用户和数百万或消息甚至不符合“大”的条件。

---

¹从DBMS角度看“客户” - 这也可能是一个中间层。

² MyISAM也没有聚集，但有严重的限制（例如没有交易支持），无论如何都应该取消它的正常使用资格。

Answer 5

如果您有预算，请从MySQL开始，使用Zend :: DB等系统或更高级别的Doctrine。

更容易切换DMBS然后在开始时选择您的DBMS。

Answer 6

只要您将表设置为关系并设置表之间的关系，MySQL应该没问题。

可能我也建议Postgres？

Answer 7

我会说关于面向对象的数据库以及nosql系统，它是一个非常有趣的概念，被Ruby on rails这样的着名框架主动使用，它可以让你更少担心你的数据，因为你可以简单地直接转储你的对象进入数据库，我知道它有点偏离主题，但不太复杂的数据库意味着更容易过渡到可扩展系统，我只是传播意识

然而，权衡的是，没有像关系数据库那样强大的用户群，这使得在你进行中更难找到问题的答案，并且适应使用它时需要相同的时间，但是包含数据而不考虑在每个阶段编写业务逻辑的数据库设计都是一件令人惊奇的事情，并且会加快您的开发时间，但是稍后当您面临瓶颈和性能问题时，由于周围的帮助较少，因此难以解决。

Answer 8

你对自己想学的东西不是很精确。 好的。 我会尽力给你一些建议。

1. 正常化
2. 索引
3. MyISAM用于高负载下的表
4. 非规范化（原文如此！），但你应该明白你在做什么
5. 拆分
6. 简约的DB层可提供灵活性

Answer 9

对于您的“基于”基础的要求，分片肯定不是必需的......我已经处理了大量的数据，甚至没有考虑分区表和分片实现，直到有许多表包含超过10亿条记录（然后加入那些可能慢一点。 使用智能键对表进行索引，您甚至可以考虑使用eav类型结构来保持表的缩小，并减轻查询的空返回。

上面写着半睡半醒，所以忽略错别字;）

Answer 10

如果你的意思是“我的mysql表应该是什么样的消息系统”，我在我的消息系统中使用以下列：

message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread

显然，Message_id是auto_increment。 Fromuser和touser很明显。 Fromstatus和tostatus是活动的，删除，清除，草稿等。 Fromview和toview设置为“yes”和“no”。 标题，文字和'poston'日期显而易见。 根据您的html表单和消息显示脚本，线程可能需要您的一些努力。

对于表单，请基于“to：”字段创建foreach循环，并为每个收件人保存副本。

我希望这个消息系统可以容纳数百万，但数百万可能还需要几年的时间。 我保持小而简单。