Блог

Давайте представим, что у меня есть социальная сеть. Я всегда показываю пользователю, сколько пользователей зарегистрировано и активировали свой профиль. Итак, каждый раз, когда один пользователь входит в систему, он переходит в DB и создает:

 select count(*) from users where status = 'activated'
  

итак, если 5.000 пользователей войдут в систему или просто обновят страницу, это сделает 5.000 запросов к SQL выше.
Мне было интересно, не лучше ли где-нибудь разместить переменную (которую я до сих пор понятия не имею, куда поместить), чтобы каждый раз, когда пользователь активирует свой профиль, добавлялся 1, а затем, когда я захочу показать, сколько пользователей зарегистрировано в этой социальной сети, я получу только значение этой переменной.

Как я могу это сделать? Действительно ли это лучшее решение по сравнению с тем, что у меня есть?

Вы могли бы использовать индексированное представление, которое SQL Server будет автоматически поддерживать:

 create table dbo.users (
    ID int not null,
    Activated bit not null
)
go
create view dbo.user_status_stats (Activated,user_count)
with schemabinding
as
    select Activated,COUNT_BIG(*) from dbo.users group by Activated
go
create unique clustered index IX_user_status_stats on dbo.user_status_stats (Activated)
go
  

Это всего лишь два возможных статуса, но может расширяться до большего, используя другой тип данных. Как я уже сказал, в этом случае SQL Server будет вести подсчеты за кулисами, поэтому вы можете просто запросить представление:

 SELECT user_count from user_status_stats with (NOEXPAND) where Activated = 1
  

и ему не придется запрашивать базовую таблицу. Вам нужно использовать WITH (NOEXPAND) подсказку о редакциях ниже (Enterprise / Developer).

Хотя, как предложил @Jim, выполнение ПОДСЧЕТА (*) по индексу, когда столбцы индекса могут удовлетворять критериям запроса, используя сравнения на равенство, также должно быть довольно быстрым.

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

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

В качестве альтернативы у вас может быть задание, которое регулярно запускает ваш SQL и обновляет центральное значение «количество пользователей».

В качестве альтернативы # 2, вы могли бы использовать что-то вроде MemCache для хранения вычисленного значения в течение определенного периода времени, а затем, когда срок действия кэша истечет, пересчитать его снова.

Есть несколько вариантов, которые вы могли бы рассмотреть:

1) как вы сказали, поддерживайте глобальное количество при каждой активации профиля, чтобы каждый раз сохранять попадание в таблицу users. Вы могли бы просто сохранить это количество в таблице «Статистика», а затем запросить это значение оттуда.

2) не показывайте фактическое «текущее» количество, показывайте количество, которое «в значительной степени обновлено» — например, кэшируйте количество в вашем приложении и периодически обновляйте значение, чтобы вы реже запрашивали количество. Или, если вы сохраняете количество в таблице «Статистика», как указано выше, у вас может быть запланированное задание, которое обновляет количество каждый час, а не при каждой активации профиля.

Зависит от того, хотите ли вы отображать точную цифру в режиме реального времени или можете смириться с задержкой. Очевидно, что объемы данных тоже имеют значение — если у вас большая база данных, то наличие слегка устаревшего кэшированного значения может иметь смысл.

С чисто точки зрения SQL Server, нет, вы не найдете лучшего способа сделать это. Если, возможно, ваша социальная сеть не размером с Facebook. Денормализация вашего дизайна данных (например, ведение подсчета в отдельной таблице) приведет к тому, что возможные источники данных не будут синхронизированы. Это не обязательно должно выйти из синхронизации, если оно закодировано правильно, но это возможно…

Просто убедитесь, что у вас есть индекс состояния. В этот момент SQL не будет сканировать таблицу на предмет количества, но вместо этого он будет сканировать индекс. Индекс будет намного меньше (то есть на странице диска поместится больше данных). Если бы вы преобразовали свой статус в int, smallint или tinyint, вы получили бы еще больше индексных листов на странице диска и, следовательно, намного меньше операций ввода-вывода. Чтобы получить ваше описание («активировано» и т.д.), Используйте справочную таблицу. Справочная таблица была бы настолько маленькой, SQL просто сохранил бы все это в оперативной памяти после первого доступа.

Теперь, если вы все еще считаете, что это слишком большие накладные расходы (а так не должно быть), вы могли бы придумать гибридный метод. Вы могли бы сохранить свой счет в отдельной таблице (которую SQL сохранял бы в оперативной памяти, если это только одна запись) или предполагая, что ваш сайт находится в asp.net вы могли бы создать переменную приложения для отслеживания количества. Вы могли бы увеличить ее в Session_Start и уменьшить в Session_End. Но вам нужно будет придумать способ сделать поток инкремента и декремента безопасным, чтобы два сеанса не пытались обновить значение одновременно.

Вы также можете использовать глобальную временную таблицу. Вы всегда получите быстрый поиск. Даже если вы устанавливаете 30-секундный пинг. Пример триггера Link1, пример триггера Link2 будут поддерживать такие действия в этой таблице.