Оптимизация производительности баз данных для Web

Оптимизация производительности баз данных для Web

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

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

Оптимизация на уровне базы данных

Самый быстрый способ повысить производительность кода базы данных это заменить встроенные хранимые процедуры операторов sql.

Использование хранимых процедур

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

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

По сравнению с запуском sql в таких средах, как php, asp (активная страница сервера), jsp (страницы сервера Java) и В некоторых других языках программирования хранимые процедуры значительно сокращают объем сетевого трафика. Наконец, когда вам нужно масштабировать приложение, гораздо проще расширить его код на несколько серверов приложений, поскольку большая часть логики доступа к базе данных хранится и выполняется в самой базе данных.

Хранение файлов мультимедиа в файловая система

 

Медиа-файлы, будь то статические изображения, аудиофайлы или фильмы, часто рассматриваются как двоичные объекты. У них даже есть специальный термин для этого: & — blob (большой двоичный объект). Поля BLOB-объектов могут храниться в базе данных или в файловой системе. В последнем случае пути к BLOB-объектам хранятся в базе данных. Хранение больших двоичных объектов в файловой системе немного труднее, но обеспечивает гораздо лучшую производительность, чем их хранение в базе данных.

Чем больше двоичных объектов хранится, тем быстрее снижается производительность процессора базы данных. Кроме того, удаление этих объектов может оставить много мертвых зон в файлах базы данных. Когда вся информация проходит через процессор базы данных, становится труднее поддерживать многозадачность. И наоборот, хранение больших двоичных объектов в файловой системе упрощает привязку к объектам, загружаемым с веб-страниц. После загрузки информации веб-сервер поддерживает доступ к файлу, а процессор базы данных в это время участвует в других задачах. Дополнительным преимуществом является возможность легко каталогизировать и администрировать мультимедийные файлы, хранящиеся на диске, а также делать их резервные копии.

Индексирование

Индексирование & — является одним из самые верные способы увеличить данные о производительности базы данных. Это также один из основных механизмов базы данных, которому обычно уделяется незаслуженно мало внимания. Обычно строки базы данных хранятся в том порядке, в котором они были созданы. Для получения любого значения из записи базы данных требуется последующее сканирование соответствующих строк базы данных.Индекс создает отдельный набор строк, упорядоченных по выбранному вами индексу и содержащий указатели на исходные строки. Индексированную базу данных просматривать намного быстрее, чем неиндексированные таблицы. Однако при индексации «съедается» лишнее дисковое пространство. Кроме того, для изменения индексированной таблицы требуется больше времени, поскольку вам также необходимо настроить любые используемые индексы.

Использование полей с целочисленными ключами

Вы можете Возникнет соблазн обойтись без целочисленного ключевого поля при создании таблиц. Например, в таблице личных записей вы можете использовать символьные поля last_name и first_name для адреса и контактной информации, а также использовать имена полей при объединении записей, их просмотре , и выполнение с ними других операций. Мы не советуем вам следовать этой практике. Вместо этого используйте, например, числовой & — person_id. Если ваши данные не содержат такого поля, вы должны создать поле с автоматическим приращением, которое не содержат любые реальные данные и являются только ключевым полем.

Числовые поля имеют много преимуществ. Вероятность неправильного использования числа намного ниже, чем неправильного использования фамилии. При изменении имени человека (n пример из-за брака), вам не нужно изменять все ссылки на этого человека в вашем коде. Кроме того, объединение записей с числовым ключевым полем намного эффективнее, чем объединение записей с помощью текстового ключевого поля. Рекомендуется создавать числовое поле первичного ключа каждый раз при создании новой таблицы

Оптимизация кода приложения

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

С сеансами связи

Сеансы связи поддерживаются в нескольких средах веб-разработки. Сеансы связи, которые чрезвычайно популярны среди поставщиков услуг приложений и разработчиков PHP, обычно выполняются путем отправки файлов cookie. Поскольку Интернет не является средой, управляемой состоянием, он не предоставляет разработчикам никакой информации о том, что пользователь мог делать до «посещения сайта». С помощью сеансов связи разработчик может отслеживать процесс навигации пользователя. В качестве побочного эффекта многие разработчики стремятся хранить всю информацию о пользователях в переменных сеанса. Хотя заманчиво хранить ссылки на базы данных, такие как соединения или наборы записей, в переменной сеанса, это довольно плохая привычка. Запоминание соединений во время сеансов предотвращает их слияние. Более того, такая практика тратит впустую память и электроэнергию. время обработки.

Если сеансы не завершаются должным образом, соединения продолжаются в течение тайм-аута, который может варьироваться, но в большинстве случаев дольше 20 минут. В течение этого времени , Вычислительная мощность ОЗУ и ЦП тратится впустую, хотя это может показаться открытием и закрытием соединения на интернет-сайте. это тратит впустую ресурсы, фактически помогает их эффективно экономить. Правило: устанавливайте соединение как можно позже и закрывайте как можно скорее. Тот же принцип применяется к наборам записей.

Используйте оптимальные запросы

Способ использования операторов sql может иметь большое влияние на производительность вашего веб-приложения. В частности, не рекомендуется извлекать длинный список записей из базы данных для отображения на одной непрерывной веб-странице. Возможно, вы захотите загрузить только несколько записей за раз (скажем, 10 или 50), а затем использовать кнопку «Следующие 50» или ссылку на веб-сайте, чтобы просмотреть следующую группу записей.

При написании этого code, попробуйте максимально использовать язык sql. Например, ограничение на количество ключевых слов ограничивает количество возвращаемых записей. Ключевое словосмещение пропускает ряд записей и возвращает следующую самую последнюю запись. Чтобы вернуть третью группу из 50 записей о клиентах, вы должны использовать такой запрос:

выберите customer_id, customer_name из заказа клиента по пределу customer_id 50, смещению 100.

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

Говоря о select, убедитесь, что вы в полной мере используете использование where. Если у вас есть несколько номеров столбцов в инструкции where, производительность будет зависеть от порядка, в котором они хранятся. Во-первых, должен быть номер столбца, который возвращает минимальный набор записей, во-вторых, номер столбца, который возвращает следующий минимальный набор записей, и так далее для всех остальных столбцов.

Используйте оператор select

Вы можете использовать один из двух методов для создания запроса, который требует от вас принятия решения на основе его результата. Самый очевидный, но и самый медленный способ & — выполнить запрос и сверить его результат с кодом приложения. Более квалифицированный и эффективный способ использовать расширенные функции sql. Оператор case в sql, как и аналогичные операторы в большинстве других языков программирования, может делать выбор на основе значения входного параметра. В этом случае вы можете управлять результатом оператора select с помощью оператора case, как в следующем примере:

 select product_name,
вещь
когда цена & lt; 5 затем "дешево"
когда цена & gt; 5 и цена & lt; 20, затем "ок"
все еще "слишком дорого на мой вкус
end as product_price from products order by product_name; 

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

***
mysql

Оптимизация производительности баз данных для Web

При своих начальных характеристиках и истории разработки база данных mysql имеет некоторые специфические проблемы с производительностью. Например, наилучшая производительность для mysql возможна на машинах Intel, работающих под управлением Linux. Для этого есть много причин, но главная из них это то, как распределяется системная память. Поэтому, если вы выберете mysql, не используйте Microsoft Windows NT, и наоборот.

Предполагалось, что mysql & — является чрезвычайно быстрой базой данных. Многие даже утверждают, что по скорости она превосходит любую другую коммерчески доступную базу данных. Компания под названием tcx, которая активно продвигает mysql, создала веб-сайт (http://www.tcx.com), который сравнивает его с другими базами данных и дает результаты, сравнивая его производительность на различных программных платформах. Согласно этим результатам, производительность процессора базы данных mysql превосходит все остальные процессоры базы данных в среднем на 40%. Но давайте посмотрим на вещи со здравым научным скептицизмом.

Проблема в том, что высокую производительность mysql вы получаете не даром, а потому, что он не обрабатывает транзакции. Транзакции значительно снижают производительность процессора базы данных. Кроме того, они требуют обработки файлов журналов, которые позволяют постепенно отменять изменения, внесенные транзакциями, или их полную отмену. Администратор должен терпеливо «следить» за файлом журнала, следя за тем, чтобы он не разрастался слишком сильно. Кроме того, файлы журналов должны быть скопированы вместе с резервной копией базы данных.

Ограничения

Ограничения используются для обеспечения взаимосвязей между таблицами и обеспечения целостности данных. Основное преимущество ограничений заключается в том, что они защищают от потенциальных последствий множественных ошибок программирования. В mysql ограничения не нашли общего применения. И советуем по возможности избегать их. Гораздо разумнее убедиться, что логика вашего приложения полностью соответствует всем требованиям.функциональна и обеспечивает согласованность всех данных. Таким образом, вам не придется жить в страхе, что однажды ваше приложение обрушится на вас со всей своей тяжестью только потому, что одно из ограничений кода было неправильно установлено и нарушено.

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

Типы таблиц, используемые в mysql

Есть четыре типа таблиц в mysql: статический, динамический, динамический и сжатый. Согласно руководству по mysql, статические таблицы самые быстрые из трех типов таблиц на диске. Однако они не могут содержать столбцы переменной длины. Если таблица содержит хотя бы один такой столбец, mysql вынужден создать динамическую таблицу вместо статической. Динамические таблицы содержат гораздо больше данных, особенно о размере таблицы, но они намного медленнее, чем статические таблицы.

Два других типа таблиц являются особыми. Таблицы кучи существуют только в ОЗУ и поэтому могут считаться чрезвычайно быстрыми. Однако столы этого типа доступны только в малых и средних размерах. Сжатые таблицы доступны только для чтения и работают очень быстро. Более подробную информацию обо всех типах таблиц можно найти в руководстве по mysql (http://www.mysql.com/doc).

Мертвое пространство MySQL

При изменении данных переменных столбца , с новыми данными меньшей длины, файлы данных mysql создают "мертвое пространство". Нет программного обеспечения, которое могло бы решить эту проблему. Другая проблема производительности связана с нормальным использованием индексов из-за их постепенной деградации. Программное обеспечение mysql имеет инструмент называется myisamchk, который позволяет освободить мертвое пространство и повторно оптимизировать индексы. Эту программу следует периодически запускать для базы данных, чтобы держать ее под контролем.

Postgresql

В отличие от mysql, База данных postgresql поддерживает хранимые процедуры, ограничения и транзакции. Разработчики этой базы данных не пошли на компромисс в отношении функциональности ради производительности. Богатый набор функций Postgresql имеет свои преимущества. Postgresql имеет две оригинальные встроенные функции. который можно использовать для повышения его производительности & — команды вакуума и объяснения.

Когда postgresql изменяет строку, он сохраняет исходную строку и создает новую в конце своего внутреннего канала. Старая строка помечается как устаревшая и используется другими транзакциями, которые все еще используют предыдущее состояние базы данных, существовавшее до отправки текущей транзакции. Тот же процесс происходит при удалении строк. Команда Vacuum удаляет устаревшие строки из базы данных и сжимает базу данных. Чтобы база данных оставалась чистой, периодически запускайте эту команду.

Один из важных способов отладки кода оптимизация выполнения запроса. Если вы просто просмотрите свой запрос и попытаетесь определить в нем узкие места, вы обнаружите, что это ни к чему не приведет. Чтобы избежать такого примитивного подхода, в большинстве баз данных есть функция синтаксического анализа, которая не выполняет запрос, а только анализирует его для пользователя. В postgresql эта функция называется объяснять. Вот пример того, как его использовать:

объясните выберите phone_number из людей, где id = 930;
примечание: план запроса: последовательное сканирование по людям (стоимость = 0,00..30,50 строк = 20 ширины = 15)

База данных сообщает, что необходимо последовательное сканирование.

Оптимизация производительности баз данных для Web

Мы приводим значения стоимости только для сравнения. Значение rows это количество строк, которое, как ожидается, будет возвращено запросом. Последнее значение & — ширина & — ширина строки в битах. Если вы запустите команду вакуума в этой базе данных, скорее всего, вы заметитеповышение производительности, прогнозируемое функцией объяснения.Кроме того, создав индекс для столбца phone_number, мы ускоряем выполнение запроса, заменяя последовательное сканирование сканированием индекса.

 
Оцените статью