Я ищу предложения по масштабированию системы лидеров.У меня уже есть рабочая версия с использованием очень нормализованной стратегии.Эта первая версия была, по сути, таблицей, которая выглядела примерно так:
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.Проблема в том, что неделя начинается в разные часы для разных клиентов.Объединение сумм приведет к тому, что некоторые точки попадут в неправильные области.