Статистика пользователя: "интерактивный расчет" или массовый расчет + кеширование

Question

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

Мы рассматриваем возможность перехода к «итеративному дизайну», в котором статистические значения хранятся в БД, и после регистрации каждого взаимодействия мы обновляем значения в зависимости от того, какой вклад вносит вклад в каждый счет, поэтому мы по сути итеративны обновление значений. (сейчас мы просто пачкаем кеш).

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

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

Answer 1

Когда я занимаюсь проектированием базы данных, я стараюсь по возможности избегать хранения избыточных данных. (В конце концов, это объект нормализации базы данных). Рассчитанные столбцы и представления в порядке - они управляются и обновляются автоматически сервером SQL. Лично я бы предпочел другие пути, прежде чем использовать БД для кэширования (действительно ли SQL-запрос - это та часть, которая требует улучшения производительности? Могу ли я упростить вещи в приложении с помощью представления SQL? И т.

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

Answer 2

Расчет на основе вставки - это, безусловно, лучший путь, ИМХО.

Чтобы решить проблемы, скажем, неспособности генерировать новую статистику немедленно (поскольку у вас нет рассчитанных данных), вы можете:

• Запуск массового отчета о новой статистике в автономном режиме

или

• Рассчитайте его на лету и объедините с кешем

В зависимости от вашей модели кэширования, статистика может быть не синхронизирована или не синхронизирована. Если это с триггерами, это происходит немедленно (при вставке в tblFoo update tblFooStats); но вы можете получить это по мере необходимости.

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

Answer 3

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

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

Некоторые подробности о том, что вы делаете, будут полезны