MySql vs NoSql - 社交网络评论和通知数据结构和实现

Posted 2023-02-23

【中文标题】MySql vs NoSql - 社交网络评论和通知数据结构和实现

【英文标题】：MySql vs NoSql - Social network comments and notifications data structure and implementation

【发布时间】：2014-06-19 23:47:53

【问题描述】：

我真的发现很难弄清楚社交网站（Facebook 是一个参考）如何为用户管理他们的 cmets 和通知。

他们将如何实际存储 cmets 数据？以及如何存储通知并将其发送给所有用户。一个示例场景是，朋友对我的状态进行了评论，并且喜欢我状态的每个人（包括我）都会收到通知。此外，每个用户都实现了自己的已读/未读功能，所以我想每个用户都有一个通知参考。但是这样就会有很多冗余的通知信息。如果我们使用单独的表/集合来存储这些并参考实际通知，那么这将产生实时可伸缩性问题。那么你将如何决定以哪种方式进行权衡。当我想到这一切时，我的大脑崩溃了。在网络上没有太多帮助的情况下，要计算的东西太多了。

现在将如何将每个通知发送给应该接收该通知的所有用户......以及数据结构的外观。

我阅读了很多建议使用 mysql 的实现。我的理解是那种数据（大小），也就是为了可扩展性目的使用 NoSql 会更好。 那么 MySql 如何在此类用例中运行良好，以及为什么不建议在任何地方使用像 Mongo 这样的 NoSql 来实现此类实现，而这些实现是高度可扩展的。

嗯，我知道很多问题。但我不是在这里寻找完整的答案，对特定事物的见解也会对我构建自己的应用程序有很大帮助。

【问题讨论】：

Facebook 不是开源的，因此您只能猜测其内部数据库架构的外观。此外，了解它的工作原理并没有真正的帮助，因为 1. 你不知道它对他们的效果如何以及他们有什么问题； 2. 即使你认为它工作得很好，但对他们的特殊要求有用的东西可能不会也为你工作。

facebook 在这里只是一个参考，我什至编辑了我的问题以使用社交网络而不是 facebook。我知道实际的 facebook 实现是不可能找到的。但正如我所说，我不是在寻找一个完整的解决方案，而只是对架构和设计的见解，甚至是单个组件。

我的建议是，无论哪种方式都可以，nosql 与 rdbms 都不会成为问题。规划您的数据结构，建模关系并从那里开始工作。尝试原型，然后带着绊脚石回来。

【参考方案1】：

这个问题非常广泛，但我会尽力回答。

他们将如何实际存储 cmets 数据？以及如何存储通知并将其发送给所有用户。

我通常不喜欢回答这样的问题，因为看起来您在来 SO 之前几乎没有做任何研究。您似乎也对应用程序和数据库角色感到困惑。我至少会给你一些材料/想法，然后让你自己决定。

后端设计没有“灵丹妙药”，尤其是在数据库方面。 SQL 数据库通常非常擅长大多数数据库功能，这是理所当然的；这是一项非常成熟的技术，并且经受住了时间的考验。大多数 NOSQL 解决方案专门用于特定目的。例如：如果您正在记录大量信息，您可能想查看 Cassandra。如果您正在处理大量关系数据，您可能希望使用 Neo4j（或用于 RMDBS 的 PostgreSQL/MySQL）之类的东西。如果您正在处理大量实时数据，您可能需要查看 Redis。

出于以下几个原因，问 NOSQL 与 SQL 是愚蠢的：

一般来说，NOSQL 是一个不好的术语。这并不意味着“没有 SQL”。它的意思是“不仅仅是 SQL”。不幸的是，该术语甚至包含了与数据库最极端的对立面。

只有您知道您的应用程序的全部功能。即使我知道你想要达到的基本目标，我仍然无法给你一个明确的答案。其他人也不能。这是非常主观的，而且，只有您确切地知道您的应用程序应该做什么。

最大的原因：现在是 2014 年。为什么要一个数据库？十年前，“DatabaseX 与 DatabaseY”将是一个实际问题。现在，您可以在几分钟内配置许多应用程序框架以可靠地使用多个数据库。故事的寓意：将每个数据库用于其特定目的。更多关于多语言持久性here。

就 Facebook 而言：五分钟的 Google 搜索可以揭示他们过去使用过哪些后端技术，而且研究他们当前的一些后端解决方案并不难。你不是脸书。您现在不需要为 10 亿用户做好准备。从简单、成熟的技术开始。这将使您自然地扩展您的应用程序。当这些技术开始成为瓶颈时，就要担心可扩展性。

我希望这对您开始编码之旅有所帮助，但如果您遇到代码问题，请使用 Stack Overflow 作为最后的手段。不是立即去的。