@GeKskill

Производительность структуры базы данных для игры?

Есть опенсорс игровой сервер Nakama и там используется такая таблица для хранения всех сущностей в игре.
CREATE TABLE IF NOT EXISTS storage (
    PRIMARY KEY (collection, read, key, user_id),
    FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE,

    collection  VARCHAR(128) NOT NULL,
    key         VARCHAR(128) NOT NULL,
    user_id     UUID         NOT NULL,
    value       JSONB        NOT NULL DEFAULT '{}',
    version     VARCHAR(32)  NOT NULL, -- md5 hash of value object.
    read        SMALLINT     NOT NULL DEFAULT 1 CHECK (read >= 0),
    write       SMALLINT     NOT NULL DEFAULT 1 CHECK (write >= 0),
    create_time TIMESTAMPTZ  NOT NULL DEFAULT now(),
    update_time TIMESTAMPTZ  NOT NULL DEFAULT now(),

    UNIQUE (collection, key, user_id)
);


Как в такой схеме реализуются связи? Допустим есть игровой объект магазин который связан с игроком, к этому магазину привязано некоторое количество других игровых объектов для продажи в нем, при этом эти самые объекты могут состоять из дочерних объектов ( объект при наличии у него дочерних можно "разобрать на части" и продавать дочерние по отдельности ). В реляционной БД вполне представляю как могут выглядеть модели и связи, а тут пока не понимаю как использовать.

К примеру как это можно записать в их таблицу:
collection: "ownership"
key: "shop"
user_id: id
value: {
name: "My Shop",
items: [
{ name: "Item name", type: "glasses", price: 1.20, child_items: [...], item_image: "src..", price_history : [...] },
{...}
]
}

И теперь представим, что в магазине сотни товаров, которые могут состоять из других объектов, это ж какого объема будет json, и как организовать поиск или фильтрацию в каталоге этого магазина? Или глобальнее, нужно найти св каком магазине есть товар по определенной цене, жуть какая-то)
  • Вопрос задан
  • 144 просмотра
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
Как в такой схеме реализуются связи?

Обычно в игровой логике избегают использования SQL систем из-за unpredictable времени
отклика. Тоесть если в финансовой системе вы можете подождать секунд 5 или минутку
обработки транзакций то внутри игры игрок быстро заскучает и выйдет из игры.

Поэтому в играх обычно используют NoSQL системы (наподобие RocksDb, Cassandra)
но в них доступ идет только по ключу. Key-Value и никакие JOINS не работают.

Если сильно хотят подружить игру с платежной системой - то заводят отдельный сервер
для денежных операций (он может быть под SQL БД) но события между игрой и платежной
системой гоняют по очередям (MQ) чтоб не было нигде блокирующих операций.

Поэтому твой вопрос по сути - это квест. Типа пойдешь на право - перформанс потреяшь
или пойдешь налево - вырастет денормализация и аномалии в БД.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы