使用MongoDB有效地确定层次结构中记录的所有者

Tob*_*ede 10 database database-design database-permissions mongodb

我想要实现以下目标:

选择我拥有的所有记录,其中所有权是我创建的对象或我管理的用户创建的对象,其中用户管理可以是管理用户的用户层次结构

所有权显然是直截了当的,可以通过与所有者对应的简单ID来处理.用户管理的层次结构让我有点难以在不通过大量ID列表的情况下执行(显然,您可以找到每个被管理的用户并使用IN子句或类似内容列出由这些用户创建的每个对象).

理想情况下,这一切都发生在单个查询中,因此可能发生正常的分页和条件.

我当时认为可能有一些数学要做到这一点 - 拥有可以某种方式进行哈希处理的ID,以确定它们是否归命令链中的任何人所有.

对这类事情的任何引用?

我错过了一些明显的东西吗

使用MongoDB如果有所作为,但很高兴考虑其他数据库的灵感.

更新: 创建了一个包含1,000,000条记录的MongoDB集合,以获得有关查询上IN子句的可管理数量参数的确切内容的一些可靠数据.当我得到一些具体信息时会报告.

分析:

使用ruby-mongo-driver和ruby基准lib.

MongoDB Collection包含1039944条记录

记录定义为:

{
    first_name: String,
    last_name: String,
    email: String,
    phone: String,
    company: String,
    owner: BSON::ObjectId
 }
Run Code Online (Sandbox Code Playgroud)

随机生成所有字段的值.

Owner字段有一个索引.

使用以下条件运行查询:

conditions = {"owner" => { "$in" => id_list }}
opts = {skip: rand, limit: 100}
Run Code Online (Sandbox Code Playgroud)

结果:

    # 10201 ids
    #              user     system      total        real
    # 0:       0.240000   0.000000   0.240000 (  0.265148)
    # 1:       0.240000   0.010000   0.250000 (  0.265757)
    # 2:       0.240000   0.000000   0.240000 (  0.267149)
    # 3:       0.240000   0.000000   0.240000 (  0.269981)
    # 4:       0.240000   0.000000   0.240000 (  0.270436)
    # Find:    0.240000   0.000000   0.240000 (  0.266709)


    # 5201 ids
    #              user     system      total        real
    # 0:       0.120000   0.000000   0.120000 (  0.133824)
    # 1:       0.120000   0.000000   0.120000 (  0.134787)
    # 2:       0.110000   0.000000   0.110000 (  0.133262)
    # 3:       0.110000   0.000000   0.110000 (  0.136046)
    # 4:       0.120000   0.000000   0.120000 (  0.141220)
    # Find:    0.130000   0.000000   0.130000 (  0.139110)

    # 201 ids
    #              user     system      total        real
    # 0:       0.010000   0.000000   0.010000 (  0.006044)
    # 1:       0.000000   0.000000   0.000000 (  0.004681)
    # 2:       0.010000   0.000000   0.010000 (  0.004578)
    # 3:       0.000000   0.000000   0.000000 (  0.007048)
    # 4:       0.010000   0.000000   0.010000 (  0.008487)
    # Find:    0.000000   0.000000   0.000000 (  0.005990)

    # 1 id (NOT using IN)
    #              user     system      total        real
    # 0:       0.000000   0.000000   0.000000 (  0.002868)
    # 1:       0.000000   0.000000   0.000000 (  0.004937)
    # 2:       0.010000   0.000000   0.010000 (  0.003151)
    # 3:       0.000000   0.000000   0.000000 (  0.002983)
    # 4:       0.000000   0.000000   0.000000 (  0.003313)
    # Find:    0.000000   0.000000   0.000000 (  0.002742)
Run Code Online (Sandbox Code Playgroud)

即使查询中包含10k ID列表,性能也非常活泼.

Thi*_*ilo 2

如果您尝试根据“列”从 MongoDB 中“选择”记录,该“列”的值来自一组可能的值,您需要通过连接用户管理表来确定该值,那么 NoSQL 就会对您不利......

如果用户 ID 列表仍然可以管理,您可以执行一种where ownerId in (?,?,?,?,?...)查询(在首先确定列表之后):

db.documents.find({owner:{$in: [1234, 2345, 4444, 77777, 99999]}})
Run Code Online (Sandbox Code Playgroud)

NoSQL 方法可能是非规范化的,例如,不仅在文档中包含所有者 ID,还包含管理层次结构的完整路径:

{  _id: 'the document A',
   owner : 1234,
   managers: [ 2345, 4444, 77777, 99999 ]
}
Run Code Online (Sandbox Code Playgroud)

当然,当用户层次结构发生变化时,这将需要更新。