SQL Server 2005, Кэши и все такое прочее

Question

Предыстория вопроса: я пытаюсь внедрить систему кэширования для моего сайта. В настоящее время мы изучаем memcache как способ сделать это. Тем не менее, я смотрю, если что-то подобное существует для SQL Server. Я понимаю, что MySQL имеет кеш запросов, который, хотя и не распределен, работает как своего рода мера «остановки разрыва». Кэш запросов MySQL эквивалентен кешу буферов в SQL Server?

Итак, вот мои вопросы:

1. Есть ли способ узнать, хранится ли сейчас в буферном кеше?
2. Следуйте этому, есть ли способ принудительно ввести определенные таблицы или наборы результатов в кэш
3. Насколько я могу контролировать то, что происходит в буфере и кеше процедур? Я понимаю, что раньше была команда DBCC PINTABLE, но с тех пор она была прекращена.
4. Немного не по теме: должно ли вообще существовать кэширование на уровне базы данных? Или более разумно управлять кешами, используя Velocity / Memcache? Так почему? Кажется, что при обработке многих объектов с перекрывающимися триггерами аннулирование кэша является проблемой.

Спасибо!

Answer 1

SQL Server реализует пул буферов так же, как это делает каждый продукт баз данных под солнцем (более или менее), поскольку System R показала путь. Об этом подробно рассказывается в Обработка транзакций: концепции и методы . Кроме того, у него есть инфраструктура кэширования, используемая кэшем процедур, кэшем токенов разрешений и многими другими классами кэширования. Этот каркас лучше всего описан в Clock Clock - для чего они нужны .

Но это не тот тип кэширования, который обычно интересует приложения. Внутренний кеш базы данных идеально подходит для масштабных сценариев, когда более мощная внутренняя база данных может быстрее отвечать на большее количество запросов с помощью этих кешей, но современный стек приложений имеет тенденцию к масштабированию веб-серверов, и реальная проблема заключается в кэшировании результатов запросов в кеше, используемом веб-фермой. В идеале этот кеш должен быть общим и распределенным. Memcached и Velocity являются примерами такой инфраструктуры кэширования приложений. Memcache имеет долгую историю, его использование и недостатки понятны, есть значительные ноу-хау, как использовать его, развертывать, управлять им и контролировать его.

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

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

• Трудно точно определить, какие кэшированные записи должны быть признаны недействительными. Зависимости могут быть довольно сложными, вещи всегда больше, чем простая таблица / запись, есть совокупные запросы, объединения, секционированные данные и т. Д. И т. Д.
• Требуется дисциплина в коде, чтобы гарантировать, что все пути, которые изменяют данные, также делают кеш недействительным.
• Изменения данных, которые происходят за пределами области приложения, не обнаруживаются. На практике всегда есть изменения, которые происходят вне области приложения: другие приложения, использующие те же данные, задания импорта / экспорта и ETL, ручное вмешательство и т. Д. И т. Д.

Более сложной альтернативой является кеш, который уведомляется самой базой данных, когда происходят изменения. Хотя не так много технологий для поддержки этого, он не может работать без активной поддержки со стороны базы данных. SQL Server имеет уведомления о запросах для таких сценариев, подробнее об этом можно прочитать на Таинственное уведомление . Реализация кэширования на основе QN в автономном приложении довольно сложна (и часто выполняется плохо), но при правильной реализации работает нормально. Делать это в совместно масштабируемом кеше, таком как Memcached, - подвиг сил, но выполнимо.

Answer 2

Най,

Ответы на ваши вопросы следуют:

1. Из Wiki - Всегда правильно ...? : -) . Чтобы получить более Microsoft ответ, вот их описание Buffer Cache .

   Управление буфером

   SQL Server буферизует страницы в оперативной памяти для минимизировать дисковый ввод / вывод. Любая 8 КБ страница может буферизироваться в памяти, и множество все буферизованные страницы называются буферный кеш. Объем памяти доступно для SQL Server решает, как многие страницы будут кэшироваться в памяти. Буферный кеш управляется Буферный менеджер. Либо чтение из или запись на любую страницу копирует его на буферный кеш. Последующие чтения или записи перенаправляются в память копия, а не версия на диске. Страница обновляется на диске Буферный менеджер, только если в памяти кеш не был указан для некоторых время. При написании страниц обратно диск, при котором используется асинхронный ввод-вывод операция ввода / вывода выполняется в фоновый поток, чтобы другие операции не должны ждать Операция ввода / вывода для завершения. Каждая страница записывается вместе с контрольной суммой когда это написано. При чтении страница назад, его контрольная сумма вычисляется снова и сопоставлено с сохраненным версия, чтобы убедиться, что страница не имеет был поврежден или подделан в То время.

2. Для этого ответа, пожалуйста, обратитесь к ответу выше:

   Либо чтение, либо запись на любую страницу копирует ее в буферный кеш. Последующие операции чтения или записи перенаправляются в копию в памяти, а не в версию на диске.

3. Вы можете запросить столбцы bpool_commit_target и bpool_committed в представлении каталога sys.dm_os_sys_info, чтобы получить количество страниц, зарезервированных в качестве целевого объекта памяти, и количество страниц, в настоящее время зафиксированных в буферном кеше, соответственно.

4. Я чувствую, что у Microsoft было время выяснить, как кэшировать свой продукт, и ей следует доверять.

Надеюсь, эта информация была полезна,

Спасибо!

Answer 3

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

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

Вы хотите изучить: memcached, Velocity, ASP.NET Cache, P & P Caching Application Block и т. Д.

Answer 4

Кэширование может иметь много разных значений для приложения ASP.Net, распространяемого от браузера до вашего оборудования с IIS, приложением, базой данных, расположенной посередине.

Кэширование, о котором вы говорите, - это кэширование на уровне базы данных, оно в основном прозрачно для вашего приложения. Этот уровень кэширования будет включать пулы буферов, кэши операторов и т. Д. Убедитесь, что на вашем сервере БД достаточно ОЗУ. Теоретически сервер БД должен иметь возможность загружать все хранилище БД в память. На этом уровне вы мало что можете сделать, если вы предварительно не извлечете ожидаемые данные при запуске приложения и не убедитесь, что они находятся в кеше БД.

С другой стороны, система распределенного кэширования в памяти. Помимо memcache и speed, вы можете взглянуть на некоторые коммерческие решения, такие как NCache или Oracle Coherence . У меня нет опыта ни в одном из них, чтобы рекомендовать. Этот уровень кэширования обещает масштабируемость при более низких затратах. По сравнению с этим масштабировать уровень БД дорого. Возможно, вам придется учитывать такие аспекты, как пропускная способность сети. Этот тип кэширования, особенно с аннулированием и истечением срока действия, может быть сложным

Вы можете кэшировать на уровне веб-служб, используя кэширование вывода на уровне IIS (в IIS 7) и уровне ASP.Net.
На уровне приложения вы можете использовать кеш ASP.Net. Это тот, который вы можете контролировать больше всего, и он дает вам хорошие преимущества.

Затем происходит кэширование на уровне веб-прокси клиента, которым можно управлять с помощью заголовка HTTP для управления кэшированием.

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

И не забывайте, что такие устройства, как SAN-кеши, также имеют уровень доступа к физическому диску.

В целом, кеширование может происходить на многих уровнях, и вы сможете проанализировать и реализовать лучшее решение для вашего сценария. Вы выяснили стабильность и изменчивость ваших данных, ожидаемую нагрузку и т. Д. Я считаю, что кэширование на уровне ASP.Net (особенно для объектов) дает вам большую гибкость и контроль.