Сразу скажу, что с оптимизацией высоконагруженных в части БД приложений я особо не сталкивался,
поэтому с интересом выслушаю все что имеют сказать более опытные коллеги.
Приветствуются общие идеи, случаи из практики, мысли вслух.
Итак.
Архитектура типичного приложения (для меня во всяком случае) в части DAO выглядит довольно просто.
Из DAO наружу торчат интерфейсы репозиториев/сервисов для извлечения/сохранения бизнес-сущностей.
Внутри DAO — какой-то ORM для отображения бизнес-сущностей на базу.
И вот в какой-то момент мы понимаем, что производительность не вытягивает.
Допустим для определенности, что мы уже нашли конкретный репозиторий и конкретный запрос, который тормозит.
Наши действия?
Наиболее очевидные вещи:
1. Кэширование. Но если объекты меняются часто — не слишком эффективно.
2. Оптимизировать средствами ORM. Например для Linq2SQL/EF это: CompiledQuery, перестройка запросов в части where и join, отключение трэкинга в контексте.
3. Оптимизация на уровне БД: берем профайлер, смотрим запросы, создаем/перестраиваем индексы,
пробуем переписать запрос в виде stored_procedure/function, создать специализированное view.
Здравствуйте, RushDevion, Вы писали:
RD>Наиболее очевидные вещи: RD>1. Кэширование. Но если объекты меняются часто — не слишком эффективно. RD>2. Оптимизировать средствами ORM. Например для Linq2SQL/EF это: CompiledQuery, перестройка запросов в части where и join, отключение трэкинга в контексте. RD>3. Оптимизация на уровне БД: берем профайлер, смотрим запросы, создаем/перестраиваем индексы, RD>пробуем переписать запрос в виде stored_procedure/function, создать специализированное view.
RD>Дополнения? Замечания?
Посмотрите сначала нужен ли этот запрос вообще. Нужны ли все его данные именно в этом месте и в это время. Может, можно разбить его на несколько маленьких, часть из которых не меняется. Может эти данные уже есть где-то в приложении. Может, запрос дёргается в цикле, а данные в цикле почти н меняются.
Только убедившись в абсолютной необходимости запроса начинайте его оптимизировать.
