Эффективно определить владельца записи в иерархии с MongoDB - PullRequest
10 голосов
/ 21 ноября 2011

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

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

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

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

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

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

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

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

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

АНАЛИЗ:

Использование ruby-mongo-driver и библиотеки тестов 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 000 идентификаторов в запросе производительность довольно высокая.

1 Ответ

1 голос
/ 21 ноября 2011

Если вы пытаетесь «выбрать» записи из MongoDB на основе «столбца», имеющего значение из набора возможных значений, для определения которого вам потребуется соединение с таблицей управления пользователями, то NoSQL работает против вас...

Если список идентификаторов пользователей все еще поддается управлению, вы можете выполнить запрос типа where ownerId in (?,?,?,?,?...) (предварительно определив список):

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

Путь NoSQL:возможно, для денормализации, например, путем включения в документ не только идентификатор владельца, но и полного пути вверх по иерархии управления:

{  _id: 'the document A',
   owner : 1234,
   managers: [ 2345, 4444, 77777, 99999 ]
}

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

...