帮助我设计这个用例

Question

我有以下实体：

数据：

1. User_id
2. 类别:利益，利益，类别A，B，C.
3. 每个类别都有子类别: Interests=Gaming、物理、编程等。
4. 现在，每个用户都可以属于多个子类别。
5. 因此，类别与用户之间存在M:N关系。

标度：

1. 10亿用户
2. 每个类别有100个子类别，范围从100 - 10,000不等。

操作需要

1. 批读写:选择和投影给user_id。例如，获取用户A的所有利益。
2. 实时读写:我需要让所有的用户对一个给定的领域感兴趣:游戏。

电流设计

对于包含用户列表的每个子类别，我使用了单独的文件。Redis server有键-值对，如

<userId_InterestId:games,programming>

然而，这种设计有许多限制，比如由于磁盘操作而导致访问时间较慢，以获得给定类别的所有用户。Redis中的大量密钥，即用户数量(sub_categories的数量)。

我需要改变设计

当前的计划是使用MongoDb来维护用户<->类别映射的层次数据。

<User_id, Interests, A, B, C>.

每个类别都有子字段。因为MongoDB是内存中的DB访问，所以使用user_id应该更快，对吗？但是反向查询如何，我将兴趣：：编程指定为关键呢？有什么更好的设计方法吗？

Answer 1

下面是我要做的:不区分类别和子类别。每个类别都有与其相关联的父类别，可能为null (类别而不是子类别)。

如果我正确理解，类别不是用户的子类，所以如果用户被删除，它就不会删除它的类别。在这种情况下，您将需要一个名为UserCategories的子用户表，该表将用户id与特定类别关联起来。

所以现在，如果您想查找用户的所有类别，那么您就有了一个子表，它为您提供了这些信息。相反，如果您有一个类别，您可以找到所有与其id相关的用户给定的UserCategories。通过消除子类别通过类别的需要，您已经将用户直接链接到子类别，从而使管理变得更加容易。

显然，在您的程序中，您可以将一个具有父类的类别作为“子类别”来处理，并对它进行不同的处理，但是在数据库中，它只意味着一个具有父类别的类别。

Answer 2

从本质上讲，该模型有三个基本方面：

1. 用户列表(使用用户id标识和索引)
2. 类别和子类别的树结构
3. 用户和类别/子类别之间的M关系。

如果有一个更简单的类别结构，如线性列表，就几乎不会有一个如何做到这一点的问题。你只需要有一张用户标识的地图:cat-id。

现在，由于类别列表是一棵树，而不是线性映射，所以它并没有那么糟糕！理想情况下，您应该创建一个哈希映射，它可以线性化每个叶节点的完全分层表示。

举个简单的例子

• HASH_VAL1 :=游戏
• HASH_VAL2 :=编程
• HASH_VAL3 :=编程->C++

现在很容易看到，MxN关系可以设置为user_id - HASH_VALX列表。

这个系统有几个简单的优点：

1. 从兴趣到用户的查找速度和其他方式一样快。反向映射不需要任何特殊的索引。
2. 您可以编辑和操作兴趣类别，或者在它周围有其他信息，这些信息可以在不需要修改用户利益_散列值关系的情况下发展。
3. 您可以将叶子转换为节点，所有这些都仍然工作。例如，另一个HASH_VALUE_X可以开始表示编程->C++->Borland++，这不会影响现有的用户关系:PROGRAMMING->C++级别。
4. 有趣的是，可以添加间接关系，例如，如果USER_X:HASH_VALUE_3=PROGRAMMING->C++意味着USER_x:散列编程，那么只需使用另一个USER_X:HASH_VALUE_2就可以维护它，而不会影响其他数据关系。
5. 最后但并非最不重要的一点是，添加数据过滤记录可能是非常线性的，因此可以通过多种不同的方式(缓存、索引等)进行优化。取决于系统的工作方式。

Answer 3

MongoDB将允许您在Interests上创建索引。当您为包含数组的字段创建索引时，每个数组条目都会得到一个单独的索引条目。因此，当您的文档看起来像这样：

{
    _id:<<Objectid>>
    interests: [
        "Programming",
        "Knitting",
        "Paragliding"
    ]
}

像db.collection.find({interests:"Programming"})这样的查询将为您提供兴趣数组有一个条目"Programming"的所有文档，并将受益于interests上的索引。