Решение для обработки данных, которые часто меняются

Question

В настоящее время я пытаюсь найти решение для оптимальной оптимизации данных, которые будут часто меняться. На сервере работает IIS/SQL Server, и это приложение ASP.NET Web API. Моя структура таблицы что-то вроде следующего:

Таблица Пользователь: Идентификатор_пользователя PK

Таблица Статус: StatusID PK, Название VARCHAR

UserStatus Таблица: Идентификатор_пользователя PK (CLUSTERED), StatusID FK (НЕ-КЛАСТЕРИРОВАН), Дата DateTimeOffset (POSSIBLY INDEXED) - Это будет использоваться как истечение срока действия. Старые записи становятся неактуальными.

В таблице пользователей будет около 5000+ записей. Таблица состояния будет содержать около 500 записей. Таблица UserStatus имела бы частые изменения (изменяются каждые 5-30 секунд) на поля StatusID и Date в любом месте от 0 до 1000 пользователей в любой момент времени. Эта таблица UserStatus также будет иметь частые запросы SELECT, выполненные против него, а также фильтрацию записей со старыми/нерелевантными датами.

• Я рассмотрел заполнение таблицы UserStatus с записью для
  каждого пользователя и только выполнения обновлений. Это означало бы, что
  всегда будет ожидаемой записью и будет ограничивать проверки
  для существования. Меня беспокоит производительность и все фрагменты
  индексов. Затем я запрошу таблицу для записей с датами, которые относятся к нескольким минутам текущего времени.
• Я рассмотрел только включение соответствующих записей в таблицу UserStatus , обновление, когда они существуют для пользователя, и запуск задачи, которая очищает старые/нерелевантные данные. Этот метод будет поддерживать количество записей вниз, но я должен был бы проверить наличие записей перед выполнением задачи, а индексы могут препятствовать производительности .
• Наконец-то я рассмотрел MemoryCache или что-то подобное. I не знаю много о кешировании в веб-API, но из того, что у меня есть , прошу об этом, я быстро решил против этого из-за потенциальных проблем параллелизма при итерации по кешу.

Есть ли у кого-нибудь рекомендации по поводу такого сценария? Есть ли другая методология, которую я не рассматриваю?

Answer 1

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

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

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

Если недостатки SSD делают нежелательным, вы можете заглянуть в OLTP в памяти.