mysql - 社交应用程序的数据库设计和优化注意事项

Question

通常情况。我有一个简单的应用程序，可以让人们上传照片并关注其他人。因此，每个用户都会有类似“墙”或“事件提要”的东西，他或她可以在其中看到从他/她的 friend (他或她关注的人)上传的最新照片。

大多数功能都很容易实现。然而，当谈到这个历史事件提要时，由于纯粹的性能原因，事情很容易变得一团糟。

我在这里遇到了以下困境:我可以轻松地将事件提要设计为数据库的规范化部分，这将节省我的编写周期，但会极大地增加为每个用户选择这些结果时的复杂性(对于在特定时间段内上传的每张照片，选择一定数量的照片) ，我正在关注谁的上传者/对于我关注的每个人，选择他的照片)

一个优化选项可以是引入一系列阈值约束，例如，它允许我根据上次上传的日期对我关注的人进行排序，甚至排除一些，以节省周期，并且每个用户，仅选择 5(例如)最后上传的照片。

第二种方法是为事件提要引入一个完全非规范化的模式，其中每一行代表我的一个关注者的通知。这意味着我每次上传一张照片，DB 都会在这个“drop bucket”中放入 n 行，n 表示我关注的人数，即许多写入周期。但是，如果我有这样一个表，我可以轻松地应用一些优化技术，例如智能索引，以及修剪超过特定时间段(队列)的条目。

然而，我想到的第三种方法是一种非规范化程度更低的模式，其中服务器端应用程序将减少数据库的部分复杂性。我看到一些社交应用程序(如 friendfeed)严重依赖数据库中序列化对象(如 JSON 对象)的存储。

我肯定仍在掌握可扩展数据库设计的技能，所以我确信我错过了很多东西，或者还有很多东西需要学习。如果有人至少能给我指明正确方向的方向，我将不胜感激。

Answer 1

如果您的申请成功，那么您的读取次数肯定会多于写入次数 - 我只上传一次照片(写入)，但我的每个 friend 在刷新他们的 Feed 时都会阅读它。因此，您应该针对快速读取而不是快速写入进行优化，这指向非规范化架构的方向。

这里的问题是，如果您拥有大量用户，您创建的数据量可能很快就会失控。非常大的表很难在数据库上查询，因此再次存在潜在的性能问题。 (还有足够存储空间的问题，但这更容易解决)。

如果按照您的建议，您可以在一定时间后删除行，那么这可能是一个很好的解决方案。随着您的成长和遇到性能问题，您可以减少这段时间(在一定程度上)。

关于存储序列化对象，如果这些对象是不可变的(您不会在写入后更改它们)并且您不需要对它们进行索引或查询，那么这是一个不错的选择。请注意，如果您对数据进行非规范化，则可能意味着您只有一个表用于事件提要。在那种情况下，我看不到存储 blob 的好处。如果您采用序列化对象的方式，请考虑使用一些 NoSQL 解决方案，例如 CouchDB - 它们针对处理此类数据进行了更好的优化，因此原则上您应该为相同的硬件设置获得更好的性能。请注意，我并不是建议您将所有数据移至 NoSQL - 仅针对更好解决方案的部分。

最后，根据经验提醒一句:构建可扩展的应用程序很困难，需要花时间在其他地方。在担心如何为数百万用户提供服务之前，您应该花时间担心如何让数百万用户使用您的应用程序——第一个是更困难的问题。当您取得巨大成功时，您可以重新构建和重建您的应用程序。