Книга поможет выработать правильную тактику и оценить перспективы раз
жүктеу/скачать 1.3 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- Рефакторинг, первая точка зрения
| СУБД
Увеличение скорости MySQL 3,4 Oracle 1,2 SQL Server 1,3 То, что мы делали до сих пор, – сочетание некоторых небольших усовер- шенствований операторов SQL, разумное использование таких возмож- ностей, как управление транзакциями и правильная стратегия индекси- рования – называется «традиционным подходом» к настройке . Теперь используем подход более радикальный и рассмотрим одну за другой две точки зрения . Давайте сначала обсудим, как организована программа . Рефакторинг, первая точка зрения Как и у многих процессов, которые встречаются в реальной жизни, при- мечательной особенностью моего примера являются вложенные цик- лы . Глубоко внутри этих циклов мы обнаружим служебную функцию Простой пример 31 AboveThreshold() , которая выполняется для каждой возвращаемой строки . Я уже упоминал, что таблица транзакций содержит два миллиона строк и что одна седьмая всех строк относится к рассматриваемой «области» . В результате вызов функции AboveThreshold() происходит многократно . Когда вызов функции происходит часто, даже небольшое ускорение ее ра- боты дает заметный результат . Например, предположим, что нам удалось уменьшить продолжительность вызова с пяти миллисекунд до четырех, тогда при 200 000 вызовах мы экономим в общей сложности 200 секунд, то есть свыше трех минут . Если ожидается 20-кратное увеличение объемов в ближайшие месяцы, сэкономленное время увеличится до одного часа . Хорошим способом сократить время работы программы является умень- шение количества обращений к базе данных . Хотя многие разработчики рассматривают базу данных как мгновенно доступный ресурс, запрос к ней требует некоторого времени . На самом деле запрос к базе данных – это дорогая операция . Вы должны связаться с сервером, что вызывает не- которые сетевые задержки, особенно если ваша программа запущена не на сервере . Кроме того, то, что вы посылаете на сервер, является не непо- средственно исполняемым машинным кодом, а оператором SQL . Сервер должен проанализировать его и перевести в реальный машинный код . Возможно, сервер уже исполнял подобный оператор, тогда вычисления «подписи» оператора может быть достаточно, чтобы сервер использовал оператор из кэша . Если оператор встречается впервые, серверу потре- буется определить правильный план исполнения и запустить рекур- сивные запросы к словарю данных . Если же оператор уже выполнялся, но после заполнения кэша был затерт другими операторами, то случай аналогичен тому, как если бы он выполнялся впервые . Затем команде SQL нужно исполнить и вернуть по сети данные, которые либо храни- лись в кэше сервера базы данных, либо были считаны с диска . Другими словами, обращение к базе данных преобразуется в последовательность операций, каждая из которых необязательно является длительной, но ведет к расходованию ресурсов – пропускной способности сети, памяти, процессора и операций ввода-вывода . Конкуренция между сеансами может добавить время на ожидание доступа к неразделяемым ресурсам, к которым происходят параллельные обращения . Давайте вернемся к функции AboveThreshold() . В ней мы проверяем пре- делы, связанные с валютой . Валюты имеют особенность – хоть в мире есть около 170 валют, даже большие финансовые институты имеют дело только с небольшим количеством – локальной валютой, валютами главных торговых партнеров страны и несколькими неизбежными ва- лютами, имеющими большой вес в мировой торговле: долларом США, евро и, возможно, японской йеной, английским фунтом стерлингов и некоторыми другими . Когда я подготавливал данные, я основывался на распределении валют из выборки, взятой из приложения в большом банке в еврозоне, и вот (реальное) распределение, которое я использовал при генерировании данных для моей тестовой таблицы: |