Сначала нужно делать "в лоб", просто увеличивать счётчик при запросе. Потом, когда проблема производительности
реально возникнет, можно приступить к масштабированию схемы. Например, завести 10 (100, 1000) счётчиков, которые запросы инкрементируют, выбирая
случайно любой из них, а при чтении их агрегировать (или с какой-то периодичностью в отдельный счётчик складывать агрегат). Подобная схема, в общем-то, применяется к любым данным, не только к счётчикам, для размазывания их по отдельным ресурсам (вычислительным узлам, таблицам, строкам), чтобы при записи не возникало конкуренции между запросами (а при чтении суммы счётчиков, как правило, не возникает лока на задеваемые ресурсы).
Минутка философииВообще, у хранилищ данных в информационной системе можно выделять две условные (не всегда чёткие) роли. OLTP - это хранилище, в которое приложение может быстро писать, там нужно делать минимум обработки, главное быстро сохранить данные и "отпустить" клиента (самый прямой пример такого хранилища - лог). И OLAP - это уже хранилище предвычисленных агрегатных данных, чтобы быстро отобразить их клиенту (а не вычислять во время запроса). И когда назревает необходимость масштабирования, эти роли начинают провляться всё явнее и явнее - приходится разделять этап приёма запроса и, собственно, его обработки, обработку откладывают на потом (складывают в очередь) настолько, насколько позволителен лаг между записью и актуализацией читаемых данных.
