MySQL *

Только сейчас наткнулся на новость о том, что Sun Microsystems купила MySQL AB за 1 миллиард долларов. Наверное это будет серьезным толчком в развитии этой СУБД. А вы как считаете, что за этим последует?

Тысячи серверов в собственных дата-центрах Facebook с трудом выдерживают нагрузку. Каждую неделю на сайте регистрируется почти два миллиона новых пользователей вдобавок к имеющимся десяткам миллионов. Все они проводят на сайте в среднем по нескольку часов и загружают сотни страниц в день, что создаёт немалые проблемы для инженеров. Один из программистов Facebook рассказывает в корпоративном блоге, с чем приходится иметь дело.

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

Впрочем, инженеры Facebook эту ситуацию предвидели заранее и уже давно начали обустройство нового дата-центра в Вирджинии, который сейчас введён в строй. Судя по всему, это далеко не последний дата-центр компании Facebook.

Значится так — есть задача вытянуть данные из таблицы mysql в простенький csv файлик, дабы его открыть быстренько в excel. Зачем белым людям нужна такая магия — мне никогда не понять, но раз заказчик попросил, то я сделал. Итак, отдаёмся во власть консоли и пишем:
mysqldump -u [USER_NAME] -p "--where=[WHERE]" "--fields-terminated-by=," "--tab=./" [DB_NAME] [TABLE] > [TABLE].txt

Вот и вся любовь (на выходе получим два файла — один с SQL и второй с CSV)

p.s. директория в которой выполняется эта команда должна быть открыта для записи, иначе оно ругаться будет ;)

29 ноября, в четверг, в 19-00 при поддержке клуба «Бизнес в стиле RU»
пройдёт 4-я встреча Moscow MySQL User Group

Тема встречи: Проектирование индексов

Встречу будет проводить Руслан Закиров,
ведущий разработчик компании Best Practical Solutions,
которая занимается разработкой открытых продуктов
Request Tracker, SVK, Jifty, а также сервиса HiveMinder.com

План встречи

1. Общие принципы устройства индексов.

2. Работа планировщика запросов:
— как планируется запрос
— как выполняется
— где в этой схеме индексы, сколько их.

3. Рассмотрим планы под лупой с помощью EXPLAIN:
— когда его читать
— как его читать, на что смотреть
— как его поменять используя индексы
— как его поменять используя дополнительные директивы
— и зачем это нужно.

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

Чтобы попасть на семинар, зарегистрируйтесь по ссылке

Адрес проведения: Москва, Мясницкая, 20, ГУ-ВШЭ, Аудитория 116

1-го ноября, в 19-00 в аудитории 116 здания ГУ-ВШЭ на Мясницкой, 20 состоится очередная встреча Moscow MySQL User Group. В качестве ведущего выступит Михаил Монашёв.

Михаил расскажет, как он с коллегами использует MySQL с мемкешедом в проекте beon.ru.

Если Вы никогда ранее не работали с мемкешедом, то узнаете что это за зверь и как с его помощью ускорить работу с MySQL-ем.

Если уже используете его в своих проектах, то возможно узнаете, как это можно делать оптимальнее.

Встреча проводится при поддержке клуба «Бизнес в стиле .RU» и для участия в ней необходимо обязательно зарегистрироваться по адресу styleru.net/register, чтобы попасть в здание ГУ-ВШЭ.

26-го сентября, в 19-00 в аудитории 116 здания ГУ-ВШЭ на Мясницкой, 20 состоится очередная встреча Moscow MySQL User Group. (Первая была 2 августа.) В качестве гостя выступит Пётр Зайцев — консультант в области разработки и настройки высоконагруженных веб-систем, использующих СУБД MySQL.

Пётр Зайцев работал техническим директором компании SpyLog, был сотрудником Группы высокой производительности компании MySQL AB, а в последние годы руководит собственной консалтинговой компанией, выступает на конференциях (например, HighLoad, которая сегодня начинается), проводит семинары и ведёт блог MySqlPerformanceBlog.com.
Пётр расскажет о своём видении развития СУБД MySQL, опыте работы на консалтинговых проектах по настройке высоконагруженных систем и ответит на вопросы.

Встреча проводится при поддержке клуба «Бизнес в стиле .RU» и для участия в ней необходимо обязательно зарегистрироваться по адресу http://styleru.net/register, чтобы попасть в здание ГУ-ВШЭ.

Компания MySQL AB, разработчик одноименной системы управления базами данных, намерена убрать из открытого доступа исходные коды корпоративной версии MySQL Enterprise Server. Об этом сообщил в своем блоге Кай Арно (Kaj Arno), вице-президент MySQL AB.

Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.

Мы уже рассказывали, на чём работает MySpace и как устроены дата-центры Google, а теперь посмотрим на более мелкие проекты, такие как digg. Здесь нет ничего особо уникального и сделанного «по спецзаказу», как в первых двух случаях, но всё равно интересно.

В момент запуска проект размещался на единственном Linux-сервере с Apache 1.3 и PHP 4.x. Для управления базами данных использовались MySQL 4.0, таблицы MyISAM и встроенный поиск MySQL. Разработчики специально старались использовать как можно больше продуктов open source, чтобы гарантировать быстрое развитие проекта без финансовых затруднений. Кроме вышеперечисленных, нашли применение свободные пакеты ImageMagick, Ispell, prototype/scriptaculous и другие. Вскоре к одному серверу добавился другой и начался бурный рост проекта.

Когда я только начал осваивать InnoDB и транзакции в MySQL (понадобилось обновить версию с 3.23 до 4.1) столкнулся с проблемой некорректного обмена данными между PHP и MySQL которая проявлялась в том, что сервер вместо символов кириллицы, в запросах генерируемых php-скриптом, вставлял в ячейки таблиц БД знаки вопроса. В процессе «выкуривания» документации, чтения форумов и изучения статей пришло понимание проблемы и нашелся способ ее решения.

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

Как узнать, какие из запросов выполняются дольше всего?
В MySQL есть встроенный функционал для ведения логов медленных запросов.