Как лучше сделать «переменные» пользователя в MongoDB?

Question

[fedot1325]

Собственно, с переходом на монгу встал вопрос - как лучше (для скорости получения этих данных в дальнейшем и т.д.) хранить пользовательские переменные?

Допустим, пользователь Вася захотел создать переменные name = Вася, yold = 21, car = Лада Калина. В мускуле я бы сохранил это в виде:
user_id | var_key | var_value
2 | name | Вася
2 | yold | 21
2 | car | Лада Калина

Позже я смогу их легко вытащить значения переменных запросом SELECT var_value FROM variables WHERE user_id=2 AND var_key='name' ...

С монго я нашел 2 способа, как можно хранить такие переменные.
Способ 1:

{
    user_id: 2,
    variables:  [
        {
            var_key: 'name',
            var_value: 'Вася'
        },
        {
            var_key: 'yold',
            var_value: 21
        }
        ...
    ]
}

Способ 2:

{
    user_id: 2,
    variables:  {
        name: 'Вася',
        yold: 21,
        ...
    }
}

Какой вариант будет удобнее использовать? Или может быть есть еще какие-нибудь варианты?

Answer 1

[lega]

1) Можно добавлять дублирующие ключи, можно проиндексировать все значения одним индексом (т.к. имя ключа одно), это список можно делать add/del
2) Проще обновлять значение (по прямому пути), дает уникальность по ключу - не будет дублирующих ключей по элементу.
У каждого подхода свои плюсы.
Ещё можно так же как и в mysql, но зачастую это неэффективно.

Comments

[fedot1325]

Дублирующие ключи не планируются, думаю в первом варианте это можно будет организовать с помощью $addToSet. Так как мне нужна высокая скорость чтения по имени ключа, потребуется проиндексировать его, а это вроде возможно только в первом варианте, так что судя по всему, тут выбор очевидный. Поправьте если не прав.

[lega]

не уверен что $addToSet будет работать с объектами, он рассчитан на простые типы.
так же для второго варианта можно сделать вспомогательный массив рядом, который будет индексировать все что нужно.

[fedot1325]

lega: $addToSet работает, пробовал в другом запросе. Сейчас еще посидел подумал, и первый вариант все меньше кажется выигрышным.
Немного не понял про вспомогательный массив. Можете привести пример?

[lega]

fedot1325:
{
variables: { ..... },
arrayForIndex: [21, 'Вася', 'some_value' ]
}
т.к. обновления атомарные, то можно этими же обновлениями поддерживать нужные значения для индекса, т.е. складывать все нужные значения по которым нужно будет найти документ.
Минус - это будет дублированная информация, но зато достаточно одного индекса и его можно гибко "настроить".

[fedot1325]

lega: а разве изменение проиндексированных полей не скажется на производительности?

[lega]

fedot1325:
Не понял вопроса,
изменение проиндексированных полей изменяют индекс, индекс как работал так и будет работать, размер индекса влияет на производительность, без индекса будет тормозить.

[fedot1325]

lega: я про вот это:

How do write operations affect indexes?
Write operations may require updates to indexes:
If a write operation modifies an indexed field, MongoDB updates all indexes that have the modified field as a key.
Therefore, if your application is write-heavy, indexes might affect performance.