Проектирование системы таблицы лидеров с масштабируемыми точками с использованием SQL Server - PullRequest
2 голосов
/ 18 марта 2011

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

UserPoints - PK: (UserId,Date)
+------------+--------+---------------------+  
| UserId     | Points | Date                |  
+------------+--------+---------------------+  
| 1          | 10     | 2011-03-17 07:16:36 |  
| 2          | 35     | 2011-03-17 08:09:26 |  
| 3          | 40     | 2011-03-17 08:05:36 |  
| 1          | 65     | 2011-03-17 09:01:37 |  
| 2          | 16     | 2011-03-17 10:12:35 |  
| 3          | 64     | 2011-03-17 12:51:33 |  
| 1          | 300    | 2011-03-17 12:19:21 |  
| 2          | 1200   | 2011-03-17 13:24:13 |  
| 3          | 510    | 2011-03-17 17:29:32 |  
+------------+--------+---------------------+  

Затем у меня есть хранимая процедура, которая в основном делает UserB GroupBy и суммирует точки.Я также могу передать параметры @StartDate и @EndDate, чтобы создать таблицу лидеров за определенный период времени.Например, временные окна для топ-пользователей на день / неделю / месяц / время жизни.

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

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

К сожалению, у меня нет доступа к «Заданиям», поскольку я использую SQL Azure, а агентпока недоступно).Но я открыт для идеи масштабирования с использованием другой системы хранения, если вы достаточно убедительны.

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

Обновление

В конечном счете, я бы хотел поддерживать пользовательские списки лидеров, которые могут выходить с понедельника.8 утра - пятница 6 вечера каждую неделю.Но это в будущем, и поэтому я пытаюсь не слишком увлекаться агрегацией.Я сейчас согласен с основными окнами День / Неделя / Месяц / Год / AllTime.

Хитрость заключается в том, что я действительно не могу хранить их денормализованными, потому что мне нужны эти окна для конвертации в TimeZone.Система является мультитенантной, поэтому все данные хранятся в формате UTC.Проблема в том, что неделя начинается в разные часы для разных клиентов.Объединение сумм приведет к тому, что некоторые точки попадут в неправильные области.

Ответы [ 3 ]

3 голосов
/ 18 марта 2011

вот несколько мыслей:

  1. Придерживайтесь SQL Azure: у вас может быть другая таблица, PointsTotals. Каждый раз, когда вы добавляете строку в свою таблицу UserPoints, также увеличивайте значение TotalPoints для данного UserId в PointsTotals (или вставляйте новую строку, если у них нет строки для увеличения). Теперь у вас всегда есть итоговые значения для каждого идентификатора пользователя.
  2. Работа с хранилищем таблиц Azure. Создайте таблицу UserPoints, ключом раздела которой будет userId. Это объединяет все строки точек пользователя, чтобы вы могли легко их суммировать. И ... вы можете позаимствовать идею из предложения № 1, создав отдельную таблицу PointsTotals, в которой PartitionKey будет UserId, а RowKey, вероятно, будет общим количеством очков.
0 голосов
/ 31 марта 2011

Я решил пойти с идеей сохранения точек вместе с временным интервалом (столбцы StartDate и EndDate), локализованными в соответствии с текущими настройками TimeZone клиента.Я понял, что дополнительное преимущество заключается в том, что я могу «очистить» старые данные раунда лидеров после нескольких месяцев, не влияя на общее количество очков.

0 голосов
/ 31 марта 2011

Если бы это была моя проблема, я бы проигнорировал временные метки и сохранил бы общее количество пользователей и очков за день

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...