Еще раз про кэширование

Гравицап
Дата: 18.02.2010 11:17:18
Пример части системы.
В системе есть десятки тысяч пользователей.
Предполагается, что одновременно с системой может работать примерно 10 тыс. юзеров.
Упрощенно и в общем-то приближено к реальности предполагается, что есть одна таблица,
в которой есть данные для каждого из пользователей.
То есть типа состоит из полей:
ID - PK самой таблицы
USERID - ID пользователя
INFOFORUSER - поле, содержащее инфу для юзера.

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

То есть по сути вопрос сводится к: есть ли в MSSQL средства позволяющие образовать в базе объект типа таблица, лежащий в памяти и руками управлять его содержимым (insert/delete/update)?

Еще более точно возможно ли в MSSQL включить такой механизм кэширования таблицы:
1. прошел селект подобрал данные, поместил их в кэш
2. прошел второй селект, сначала смотрим есть ли по PK эти записи в памяти
3. если нет, достаем их и помещаем в кэш
4. по достиженем определенного размера наиболее старые записи чистятся из кэша (понятно, что определение "старой" записи в кэше само по себе бред т.к. будет затормаживать наверно) ну короче, чтобы кэш как-то чистился конечно чтобы не свопился в общем )))

PS наверяка в этой СУБД есть некие механизмы кэширования, которые итак работают, но хотелось бы узнать, можно ли этим кэшем как-то управлять в разрезе отдельной таблицы например?
Glory
Дата: 18.02.2010 11:23:00
Гравицап


То есть по сути вопрос сводится к: есть ли в MSSQL средства позволяющие образовать в базе объект типа таблица, лежащий в памяти и руками управлять его содержимым (insert/delete/update)?

Нет. Сервер сам кэширует данные. Особенно те, которые часто испольузются


Гравицап

Еще более точно возможно ли в MSSQL включить такой механизм кэширования таблицы:
1. прошел селект подобрал данные, поместил их в кэш
2. прошел второй селект, сначала смотрим есть ли по PK эти записи в памяти
3. если нет, достаем их и помещаем в кэш
4. по достиженем определенного размера наиболее старые записи чистятся из кэша (понятно, что определение "старой" записи в кэше само по себе бред т.к. будет затормаживать наверно) ну короче, чтобы кэш как-то чистился конечно чтобы не свопился в общем )))

Именно так и работает кэширование сервера.
Crimean
Дата: 18.02.2010 11:23:14
судя по вопросу, реально с СУБД вообще никогда не работали? при наличии индекса это все будет работать на достаточно среднем оборудовании
Гравицап
Дата: 18.02.2010 12:00:27
Crimean
судя по вопросу, реально с СУБД вообще никогда не работали?

Лет пять работаю с ораклом, но разарбатываю системы, с максимум 1000 одновременно работающих юзеров и потом это далеко не OLTP-системы.
Видел так сказать, со стороны базы на оркале, работающие одновременно с примерно 5000 тысячами пользователей, не считая моря работающих джобов.
При этом быстродействие обеспечивалось в большОй степени железом, то есть дисковые массивы и т.д., кластер из порядка 60 машин...

У меня же предполагается только одна машина и может быть разживусь на массивчик...
В рамках моей задачи, не спорю, что может и вполне хватит просто индекса по PK, но MSSQL мало работал, подумал мало ли может там есть нечто такое супер-пупер быстрое :)
Возможно, вопроса бы не возникло, если бы проверил сам.
Может быть тогда кто-нибудь подскажет есть ли какие-то средства нагрузочного тестирования базы?

То есть как замерить время отклика если перманентно в очереди висит примерно 10 000 запросов например?
Теоретически и практически можно написать хранимку, которая выполнит эти 10 000 запросов и посмотреть время.
Или вообще судить по одному запросу - один запрос столько-то милисекунд выполняется, значит 10 0000 будет примерно столько-то...
Обычно так провреяю, но правильно ли это, может я чего-то не понимаю и это некорректный вариант? :)

Ну а вообще обнадежили, понадеюсь на то, что справится одна машина просто по индексам.
Гравицап
Дата: 18.02.2010 12:04:09
Glory
Именно так и работает кэширование сервера.

Ок тогда поищу на вс. случай как в MSSQL задать размер кэша...
Glory
Дата: 18.02.2010 12:07:00
Гравицап
Glory
Именно так и работает кэширование сервера.

Ок тогда поищу на вс. случай как в MSSQL задать размер кэша...

Просто дайте серверу памяти. Он сам все задаст
Гравицап
Дата: 18.02.2010 12:12:56
Glory
Просто дайте серверу памяти. Он сам все задаст

Как-то все слишком просто :) ну ладно попробую, очень обнадежили в общем, практика покажет.
А можно будет как-то отследить сколько памяти было отведено по кэш и если вдруг эта велична в MSSQL плавающая по ходу работы базы, то как бы отследить максимальное значение или еще лучше вообще динамику изменения, хотя бы на начальном этапе, чтобы понять примерно насколько нагружена база и надо ли думать либо о еще большем увеличении памяти или наоброт, например, база нагружена, время отклика большое, а кэш маленький (понятно, что зависит и от дисков и от специфики запросов), но все-таки как бы отмониторить на вс. случай?
Glory
Дата: 18.02.2010 12:17:07
Гравицап
Glory
Просто дайте серверу памяти. Он сам все задаст

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

А почему должно быть сложно ?
Системные представления начинающиеся на sys.dm_os_memory
Гравицп
Дата: 18.02.2010 12:21:21
Glory, спасибо большое, буду пробовать.
Crimean
Дата: 18.02.2010 12:27:48
"5000 тысяч пользователей" - действительно много :)

нагрузочное тестирование - мы делали себе именно "распределенный" нагрузочный тест
с кучи машин запускалось по 2-3 десятка приложений, которые ждали "сигнала" и начинали фигачить. "контроль" ждал полного открытия всех соединений от всех клиентов и с этого момента делал засечку "старт". после считал нужный объем выполненного и делал засечку "стоп". а дальше - разбор полетов
это все пускали на разном железе с ровной нагрузкой и на каждом железе с ростом нагрузки для получения данных по масштабированию
тестики писали сами, обычные t-sql батчи и чуть-чуть обвязки в виде батников и еще чуть .net кода. после результаты в базу и несложные выборки для построения диаграмм