Использование Score + GUID в качестве RowKey для игры, в которой используется хранилище таблиц Azure

azure-storage query-performance azure-table-storage

289 просмотра

2 ответа

1991 Репутация автора

Я хочу создать игру, которая использует хранилище таблиц Azure для таблицы лидеров.

Было рекомендовано, чтобы, если я хочу, чтобы хранилище таблиц Azure предоставляло мне отсортированный / разбитый на страницы список, мне нужно использовать счет в качестве RowKey для моей сущности таблицы. (Я собираюсь добавить GUID игрока, чтобы гарантировать, что каждый сгенерированный RowKey уникален.)

Вот мои проблемы с этой рекомендацией:

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

  • Если использовать другое поле для поиска объекта таблицы (раздел + атрибут), например, имя игрока, запрос не будет оптимальным.

Какой метод лучше подходит для выполнения обновлений строк? Должен ли я попытаться использовать методы блокировки и поиска по RowKey? Или я ищу, используя имя пользователя?

Или я должен отказаться от идеи использовать Score в качестве RowKey и выполнить сортировку в памяти после извлечения полной таблицы для отображения страницы в таблице лидеров?

Предположим, на данный момент, что обновления счета и просмотр списка лидеров одинаково часты.

Автор: Jonas Arcangel Источник Размещён: 17.07.2016 10:17

Ответы (2)


1 плюс

12547 Репутация автора

Это не подходит для использования RowKeyили PartitionKeyдля удовлетворения ваших требований. Поскольку комбинация ключа раздела и ключа строки является идентификатором объекта в табличном хранилище. После того, как вы определили их в операции вставки, вы никогда не сможете обновить их снова. Обратитесь к теме в MSDN https://social.msdn.microsoft.com/Forums/azure/en-US/7ad92641-3b0b-4faa-989f-3506fab47325/can-we-update-partition-key-or-row- key-in-azure-table-storage? forum = windowsazuredata для подробного объяснения.

Кроме того, как описано в https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#sorting-data-in-the-table-service :

Служба таблиц возвращает объекты, отсортированные в порядке возрастания на основе PartitionKey, а затем по RowKey.

Поэтому хранилище таблиц Azure не очень подходит для вашего сценария. Вы можете использовать базу данных SQL Azure для удовлетворения ваших требований.

Автор: Gary Liu - MSFT Размещён: 19.07.2016 08:32

0 плюса

16 Репутация автора

Я представил решение для реализации таблицы лидеров с помощью таблиц Azure. Мне бы не хотелось интегрировать Redis или SQL-сервер в MMO только ради масштабируемых таблиц лидеров. Таблицы лидеров полезны для решения множества проблем в MMO, поэтому было бы здорово иметь масштабируемое и дешевое решение, которое использует таблицы Azure для хранения.

Решение, которое я представил, будет использовать две (или три) таблицы:

  1. Таблица, содержащая следующие поля: playerId (RowKey и PartitionKey имеет его) currentScore (double). Это используется для прямого просмотра счета игрока.

  2. Таблица, содержащая следующие поля: PartitionKey = идентификатор конечного узла двоичного дерева, описанного в 3 RowKey = LeadingZeros (Score) + "_" + LeadingZeros (PlayerId)

  3. Где-то в лазури (таблицы) так же создается двоичное дерево. Сохраните следующую информацию:

    • Идентификатор узла
    • MaxScore (в этом узле)
    • MinScore (в пределах этого узла)
    • Счетчик очков (количество баллов, хранящихся в этом узле, только если это конечный узел )

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

Есть вопросы, на которые нужно ответить об этом решении, так как оно не было реализовано, я считаю производительность вставки / обновления потенциально интересной проблемой.

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

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

Позже в этом году я, вероятно, попробую свои силы в реализации чего-то подобного вышеупомянутому решению, если никто не ответил на этот поток с некоторым функциональным кодом C # ранее, к тому времени, когда я доберусь до него :)

Автор: Ocemagnuf Nimda Размещён: 16.05.2018 04:13
Вопросы из категории :
32x32