Существует ли простой способ масштабирования счетчика просмотров или загрузок в строке БД?

Question

Я работаю над небольшим веб-проектом, который должен поддерживать счетчик NumViews для каждого объекта / строки в таблице БД. Я имею в виду, что все обновления в строках начнут действительно снижать производительность, так как таблица будет увеличиваться в количестве объектов, и сайт будет расти в использовании.

Я использую .NET 3.5 с MSSQL 2K5, если это имеет значение.

Есть предложения?

Заранее спасибо!

- Joel

---

Наши нынешние предположения об использовании БД составляют примерно 66 чтений в секунду.

Мне нравится идея разделения счетчиков на отдельную таблицу. Знаете ли вы какие-либо статьи или белые страницы, поддерживающие это, или это одна из вещей, которые все просто делают? : -Р

Кроме того, блокирует ли БД всю таблицу или только эту конкретную строку? Я бы предположил только ряд, но не был уверен.

Спасибо

- J

Answer 1

Рассмотрите возможность использования таблицы событий «Представления», только для записи, в которой каждое представление хранится с отметкой времени. Нет проблем с блокировкой, нет пота, полный контрольный журнал на самом детальном уровне. Маленькие крошечные записи, ~ 5 мм записей в день?

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

Answer 2

Я бы предложил:

1. Помещение строки -> подсчитать данные в другую таблицу (со столбцами фиксированного размера), чтобы вы не могли непрерывно записывать в основную таблицу только для сохранения значений

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

Answer 3

Я бы подумал сделать одно из следующих действий:

• Использование буфера в приложении и пакетная запись набора представлений при каждом заполнении буферов
• Использование локального файла журнала и агрегирование его результатов в периодической загрузке время от времени
• Используйте систему событий (Pub / Sub) для запуска событий из вашего приложения, которые впоследствии будут обрабатываться другим приложением (подписчиком) асинхронно. Взгляните на следующий проект

Answer 4

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