Хранение сообщений и потоков в Windows Azure Table Storage

Question

Я разрабатываю простую службу обмена сообщениями с использованием ASP.NET MVC / Windows Azure Table Storage. У меня есть два вида сущностей - сообщения и ветки сообщений. Связь между ними проста - каждый поток может иметь несколько сообщений, но сообщение может быть назначено только одному потоку.

Хранение таблиц не является реляционной БД, поэтому представление отношений всегда немного сложнее. Мне нужно выбрать между 2 подходами:

1. Наличие одной большой таблицы для потоков и одной для сообщений. И наличие threadId в качестве ключа разделения сущности сообщения, чтобы сообщения были разделены по потокам.

2. Динамически создавая специальную таблицу для каждой цепочки сообщений и имея в качестве имени таблицы threadId.

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

Как вы думаете, это может быть проблемой?

Answer 1

Вы также можете рассмотреть возможность использования только одной таблицы, в которой хранятся сущности Thread и Message. Это обеспечит вам поддержку транзакций, и вы сможете использовать гибридный подход Lucifure для этой таблицы.

Answer 2

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

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

Например, вы можете разделить таблицы на основе даты и степени детализации дня или месяца.Таким образом, имя таблицы, например «Thread201202», может использоваться для всех потоков , запущенных в феврале 2012 года.

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

Старые потоки можно легко удалить, удалив таблицы, скажем, более года назад.

Answer 3

Создание большого количества таблиц может быть проблемой, в зависимости от того, как вы хотите управлять ими. базовый API REST для перечисления таблиц работает как запрос для сущностей таблиц. Он возвращает только первые 1000 таблиц, после чего вы должны использовать токен продолжения. Все исследователи хранилищ, которые я видел, не позволяют запрашивать таблицы по имени, им просто нравятся первые 1000 таблиц. Если у вас 20000 потоков, вам может понадобиться некоторое время, чтобы добраться до нужного стола.

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

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

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