Эффективное определение владельца записи в иерархии с помощью MongoDB

Я пытаюсь достичь следующего:

Выбрать все записи, которыми я владею, где право собственности - это объекты, которые я создал, ИЛИ объекты пользователь, которым я управляю, создал, где управление пользователями может осуществляться в иерархии пользователей, управляющих пользователями

. Право собственности явно прямолинейно и может управляться простым идентификатором, соответствующим владельцу.Иерархия управления пользователями заставила меня работать без тяжелой работы с большими списками идентификаторов (очевидно, вы можете просто найти каждого управляемого пользователя и перечислить каждый объект, созданный любым из этих пользователей, используя предложение IN или подобное).

В идеале все это происходит в одном запросе, поэтому возможны нормальные разбиения по страницам и условия.

Я подумал, что, возможно, нужно было выполнить некоторую математику, чтобы сделать это - иметь идентификаторы, которые можно каким-то образом хэшировать, чтобы определить, принадлежат ли они кому-либо в цепочке команд.

Есть ссылки на подобные вещи?

Я упускаю что-то очевидное?

Использование MongoDB, если это имеет значение, но я рад подумать о других базах данных для вдохновения.

ОБНОВЛЕНИЕ: создали коллекцию MongoDB с 1 000 000 записей, чтобы получить надежные данные о том, что именно составляет управляемое количество параметров для предложения IN в запросе. Сообщу, когда у меня будет конкретная информация.

АНАЛИЗ:

Использование драйвера ruby-mongo и библиотеки тестов ruby.

Коллекция MongoDB с 1039944 записями

Записи определяются как:

{
    first_name: String,
    last_name: String,
    email: String,
    phone: String,
    company: String,
    owner: BSON::ObjectId
 }

Со случайно сгенерированными значениями для всех полей.

Поле «Владелец» имеет индекс.

Выполнение запросов со следующими условиями:

conditions = {"owner" => { "$in" => id_list }}
opts = {skip: rand, limit: 100}

Результаты:

    # 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)

Даже со списком из 10 тыс. Идентификаторов в запросе производительность довольно высокая.