为了讨论的目的,让我们考虑一个FourSquare方案。
情境
实体:
- 用户数
- 地方
关系:
- 签到:用户<->地点,很多对很多
- 朋友:用户<->用户,多对多
数据库设计
这些很可能有错误,请指出。
关系数据库管理系统
表格:
- 用户数
- 地方
- 签到(交界处)
- 朋友(交界处)
优点:
- CAP:一致性,可用性
缺点:
- CAP:分区容限,也称为分片
- 方案=不灵活的结构
- 复制不良?
图形
对象:
- 用户数
- 地方
边缘:
- 朋友:用户<->用户
- 签到:用户->地点
- 包含时间戳
优点:
- CAP:一致性,可用性?
- 无模式,易变的对象和边缘
- 图形遍历查询,例如:
- 聚类
- 寻找一群朋友
- 寻找类似人喜欢的餐厅
- 还有其他常见/有用的查询吗?
- 聚类
缺点:
- CAP:分区容忍度?
文件/物件
3个独立的数据库?
- 用户数
- 朋友清单
- 签到
- 时间戳记
- 用户
- 地点
- 地方
优点:
- CAP:可用性,分区容限
- 无模式,易变的对象
缺点:
- CAP:一致性
问题
作为记录,他们最终使用了MongoDB。除了上述所有问号外:
- 我不确定如何实现文档数据库。
- 文档数据库如何获得分区容限?
- 为了获得单个用户的签到,我假设该操作将解析所有签到并过滤用户名的元数据(map + filter)。为每个用户解析1,000,000+个文档的性能将非常差。我认为这不是正确的行为?
- 还有哪些其他优点/缺点?