我正在构建一个服务（或者更确切地说是一组微服务）来充当类似社交网络的网站的后端。简而言之，这意味着我的数据如下：
- 数百万个实体
- 具有数十种属性
- 随着时间的推移，实体之间可能存在数千个连接（例如在 Facebook 上，某人可能有数千个“朋友”）。
- （有不止一种类型的连接，每一种都可能有数千个）
- 连接示例：
- 实体 A 认识实体 B
- 实体 A 已阻止实体 B
- ETC。
- 从概念上讲，每个实体都维护着其他实体的一长串标识符
- 我需要能够在哪里进行搜索
- 我可以根据要匹配的一组属性搜索所有实体
- 同时过滤掉发起实体已经存在的连接
我试图弄清楚什么是存储这些数据的最佳数据库解决方案。我不精通数据库技术，所以我需要一些建议来考虑。
我知道 SQL / 关系数据库可以轻松地针对前 2 个标准（实体数量和属性数量）进行扩展，但我不确定它们是否适合管理连接。
我需要一种合适的数据库技术，它也可以以分布式方式设置——并且最好在云环境中可用。如果那是 SQL 数据库，我将如何存储和管理连接？
我将尝试吐出一些希望有用的事实。
和
在关系数据库系统 (RDBMS) 中，两个记录之间的关系（“连接”）更像是一种隐式存在或可以使用外键显式定义的逻辑结构。除此之外，在物理形式上，它由数据库中的实际行和这些行的属性定义。
社交网络的一个示例实现可能看起来像一个
Users带有UserId列（在其他属性列中）的表和一个带有列和UserFriends的链接表（因为朋友的关系本质上是多对多的）。表中的两列都是表列的外键。您可以看到这更像是一个逻辑结构。它的物理方面只是表中存在的行数。该表中的每一行都代表特定用户的一个朋友。UserIdFriendUserIdUserFriendsUserIdUsersUserFriends因此，您询问的“数千个连接”现在实际上只是表中的行或实体实例，因为您已经承认您知道 RDBMS 可以很好地处理。事实上，对于一个特定的实体来说，数千行是很小的一部分（尤其是相对于一个数百万以上的表）。
您基本上会以类似的方式对其他用例进行建模，例如，可以是包含列和等
BlockedUsers的链接表。UserIdBlockedUserId从性能的角度来看，在 RDBMS 中，这只需要对通常搜索的属性进行适当的索引。
您可以使用该
UserFriends表通过反半连接或NOT EXISTS查询类型来完成此操作。同样，只要内容被正确索引，这应该是一个有效的搜索。我会说先走再跑。在你证明你需要一个分布式系统之前，不要试图一开始就实施一个，因为当实际上不需要时，弊大于利。大多数人都可以很好地垂直扩展（尤其是在云中）他们的系统，因为数据库系统在正确架构时可以很好地扩展。此外，大多数现代 RDBMS 确实提供了分配数据和工作负载的功能，因此在选择数据库系统时，无论如何这都是一个有争议的问题。此外，如今大多数现代 RDBMS 也可在主要云提供商中使用。
这是对现代社交媒体系统通常如何实现其数据库系统的粗略解释。在像 Facebook 这样的公司，他们拥有如此多的开发人员团队和比一般开发人员需要支持的更多的微用例，通常他们实际上混合使用数据库系统。其中一些只是由开发人员的偏好决定的。但通常 RDBMS 是他们用于建模标准用例的主要数据库系统，例如您提到的那些。
可用于对两者之间的关系建模的替代数据库系统
Friends是图形数据库系统。朋友的多对多性质使其更能代表图形类问题。但是对于社交网络，通常还有其他数据点不一定像图形（例如，aPostsmakesUser）更适合 RDBMS。总体而言，RDBMS 可能最适合社交网络的大多数标准用例。