Какой способ хранения этих конкретных данных будет более эффективным? - PullRequest
Новая
       11

Какой способ хранения этих конкретных данных будет более эффективным?

0 голосов
/ 08 января 2019

У меня есть база данных для игры - в настоящее время используется MySQL для хранения информации - и я хочу протестировать ArangoDB для сравнения скорости.

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

В MySQL у меня действительно не было выбора, но я использую ArangoDB.

Например, хранение информации инвентаризации в MySQL: 

    +---------------------------+
    | user_id | item_id | count |
    +---------+---------+-------+
    |       1 |       1 |     7 |
    |       1 |       2 |     4 |
    +---------+---------+-------+

Или в ArangoDB я могу сделать либо:

  1. Единый сборник для всей информации: 

    {
    _key: "Unique User ID",
    health: 100,
    money: 52.38,
    // .... ,
    inventory:
        {
            item1: 7,
            item2: 4
            // , ....
        }
}

  2. Разделите вышеуказанную коллекцию на две разные (одна для здоровья, денег и т. Д. И одна для данных инвентаризации): 

    // 'user' collection
{
    _key: "Unique User ID",
    health: 100,
    money: 52.38,
    ....
}

// 'inventory' collection
{
    _key: "Unique User ID",
    item1: 7,
    item2: 4
    // , ....
}

Какой из двух методов выше (или даже другой, о котором я не думал) будет более эффективным?

1 Ответ

0 голосов
/ 09 января 2019

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

  • Меняются ли данные инвентаризации нечасто и обычно ли они необходимы при доступе к пользовательской информации? Если это так, то вам, вероятно, лучше всего использовать вариант 1 (хранение данных инвентаризации вместе с информацией о пользователе).

  • Хотите сделать переход от реляционного хранения документов к максимально безболезненному? Тогда вы, вероятно, можете использовать вариант 2 с отдельными коллекциями. Arangodb поддерживает объединения по всей коллекции и работает довольно хорошо.

  • Теперь, если вы не возражаете против кривой обучения, я бы предложил вариант 3: обход графиков. В этом случае вы должны хранить данные следующим образом:

    // коллекция пользовательских вершин

    { _key: "1", здоровье: 100, деньги: 52,38, .... }

    // элемент коллекции вершин

    { ItemID: 1, //, .... },

    { ItemID: 2 //, .... }

    // Инвентаризация края коллекции

    { _from: пользователь \ 1 _to: пункт \ 1, Количество: 7 },

    { _from: пользователь \ 1 _to: пункт \ 2, Количество: 4 }

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

Если бы я начинал с нуля, я бы, наверное, сначала выбрал вариант 3. Однако, как я уже упоминал в начале, это зависит от того, как вы собираетесь использовать данные.

...