Sysbench - утилита для тестирования производительности MySQL (и других СУБД), а также параметров операционной системы. Подобный инструмент незаменим для предварительного тестирования эффективности системы с (потенциально) высокой нагрузкой. Sysbench позволяет оценить производительность сервера СУБД и операционной системы в различных условиях при различной нагрузке.
Одним из основных принципов разработки масштабируемых и эффективных приложений является выбор подходящих технологий для решения той или иной задачи. Многие современные РСУБД представляют из себя решения универсальные, но во многих случаях в них просто нет необходимости.
Одним из альтернативных решений для хранения и обработки данных является СУБД Mongo DB (”humongous” - огромный, невероятный).
В этой статье поговорим об одном из самых шумных и растущих проектов - Twitter.com (далее - Твиттер).
Разработка и развитие этого проекта совпадает с классической схемой удачного стартапа. Стартовал проект с простенького прототипа, написаного на скоркую руку на платформе Ruby-on-Rails. После этого в проекте было сделано огромное количество изменений в архитектурном и техническом плане. Твиттер не раз сталкивался и преодолевал проблемы быстрого роста нагрузки.
Разработчики Твиттера делятся своим опытом.
check-unused-keys - это PERL утилита, которая выводит статистику о неиспользуемых индексах (и таблиц) в MySQL. Утилита собирает информацию, основываясь на патче user_stats (от Google + Percona). Патч пользовательской статистики добавляет несколько таблиц в БД INFORMATION_SCHEMA, в том числе таблицу INDEX_STATISTICS. Она содержит данные по использованию того или иного индекса.
В системах с высокими нагрузками особое внимание следует уделять резервному копированию (бекапам) данных. Зачастую самая важная часть данных находиться в СУБД. Проблема заключается в том, что копирование данных нужно проводить незаметным для работающей системы образом. Блокировка данных на момент создания бекапа тут не работает, т.к. время блокирования будет неприемлемым.
Одним из популярных решений является репликация, которая обеспечивает высокую степень надежности и почти нулевую потерю данных при сбое основного сервера. Но репликация требует аппаратных затрат, к тому же резервный сервер должен не уступать по характеристикам основному серверу, иначе от репликации не будет толку.
Другой подход резервного копирования - это использование специальных утилит, которые позволяют делать снимки состояния СУБД на жесткий диск, и восстанавливать состояние обратно по такому снимку. На этом остановимся подробнее.
Поскольку MySQL является одним из самых популярных решений в Web’е сегодня, рассмотрим инструменты для бекапов для этой СУБД.
XtraBackup - это утилита от Percona Labs, предназначенная для горячих бекапов таблиц InnoDB и XtraDB.
Maatkit - это набор инструментов, который предоставляет собой расширенные средства по управлению MySQL, сбору аналитической информации и ее обработке, проведению рутинных операций, восстановлению данных и прочего. В пакет входит множество полезных инструментов, которых к сожалению нет в стандартной поставке с БД, но обязательно нужны для максимально эффективной работы. Этот пакет разработан и поддерживается компанией Percona - известных экспертов в области консультирования вопросов производительности.
Пакет Maatkit входит во все распространенные дистрибутивы Linux систем, поэтому не придется терять время на установке. Хотя, если Вы хотите получить наиболее последнюю версию, следует качать версию с сайта (обновления выходят очень часто).
После установки Вам станет доступно почти 20 различных инструментов, входящих в поставку. Некоторые из них мы и рассмотрим.
Компания Percona, занимающаяся консультированием по вопросам производительности и масштабирования объявила о запуске нового проекта - Percona.tv. Этот сайт будет наполняться полезными скринкастами, видео с коференций и просто полезными роликами на темы, касающиеся СУБД и не только.
Как мы выбираем, по каким колонкам в MySQL строить индексы? Иногда не все так очевидно, как кажется. Эффективность того или иного индекса зачастую зависит от распределения данных в таблице. Правильный, на первый взгляд, индекс может работать крайне не эффективно в зависимости от специфики и частоты данных.
Как это можно выяснить? Простой и очень интересный пример взят с блога mysqlPerformanceBlog. Этот способ анализа индексов применим не только к MySQL, а и к другим СУБД.
SELECT * FROM articles ORDER BY id LIMIT 20000, 20
Что приходит Вам на ум, когда Вы видите такой код? Да, это реализация постраничного вывода на уровне SQL. А еще это выбор результатов для отображения 1000-й страницы.
И Вы сталкиваетесь с тем, что этот запрос работает очень быстро для выборки первых страниц, и невероятно медленно для последних. Почему и как это исправить? Рассмотрим пример для MySQL, хотя описанные принципы применимы для любой СУБД.
Многие разработчики крупных (что весьма относительно) проектов приходят к выводу о том, что один единственный сервер базы данных никак не сможет справится с нагрузками. Это может быть как на этапе проектирования, так и на этапе роста - не важно. Вопрос в том, какую стратегию выбирать, если Вы уверены, что столкнетесь с такой ситуацией!
Если Ваш заказчик готов купить супер сервер за несколько миллионов долларов (а по мере роста - десятков миллионов и т.д.), что-бы сэкономить время, но сделать все быстро, можете дальше эту статью не читать :). Эта ситуация покажется Вам маловероятной, так и есть. Что выбирать, на основе чего основывать свой выбор и когда выбирать - это вопросы мы рассмотрим в рамках статьи.
Этот блог посвящен вопросам производительности и масштабирования Web систем. Тут мы делимся собственным опытом и соображениями, пишем о технологиях и их применении. Все, кому есть, что добавить - регистрируйтесь и присоединяйтесь!
Комментарии