MySQL *

При написании любого достаточно крупного проекта всегда встают более-менее похожие проблемы. Одна из них — проблема скорости получения обновлений системы. Относительно легко можно наладить быстрое получение небольших обновлений. Довольно просто изредка получать обновления большого объема. Но что если надо быстро обновлять большой массив данных?

Для Таргета Mail.Ru, как и для всякой рекламной системы, быстрый учет изменений важен по следующим причинам:
• возможность быстрого отключения показа кампании, если рекламодатель остановил ее в интерфейсе или если у него кончились деньги, а значит, мы не будем показывать ее бесплатно;
• удобство для рекламодателя: он может поменять цену баннера в интерфейсе, и уже через несколько секунд его баннеры начнут показываться по новой стоимости;
• быстрое реагирование на изменение ситуации: изменение CTR, поступление новых данных для обучения математических моделей. Все это позволяет корректировать стратегию показа рекламы, чутко реагируя на внешние факторы.

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

Везде, где используется LIMIT offset для больших таблиц, рано или поздно начинаются тормоза. Запросы вида

SELECT * FROM test_table ORDER BY id LIMIT 100000, 30

могут выполнятся очень долго. Например, в моем случае, на одном из сайтов кол-во комментариев перевалило за 200к и постраничная навигация по комментариям начала ощутимо тормозить, а в mysql-slow.log все чаще стали попадать запросы с временем выполнения 3-5сек.

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

Давайте рассмотрим простой пример.
Есть таблица:

CREATE TABLE IF NOT EXISTS shop (
  id INT NOT NULL AUTO_INCREMENT,
  article INT(4) ZEROFILL NOT NULL,
  dealer VARCHAR(45) NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (id))
ENGINE = InnoDB;

Необходимо для всех article найти dealer с максимальной ценой.

Для этой задачи существует несколько очевидных и простых решений, но я знаю одно из них, которое значительно превосходит все остальные.
Сталкивались с этой задачей? Хотите увидеть новый способ ее решения? Прошу под кат.

Начиная с версии 5.1 в MySQL реализована поддержка динамически подключаемых плагинов. А дистрибутив содержит примерный скелет кода под названием – example. Он описывает интерфейс и структуру базового обработчика – handler, копия которого создается отдельно для каждого соединения с БД. Также ему передаётся указатель на дескриптор таблицы TABLE *table и вспомогательный вектор TABLE_SHARE *share, используемый для синхронизации с другими обработчиками. Разработку плагина можно осуществлять по модульному принципу, реализуя только необходимые функции в первую очередь и закрывая заглушками более сложные операции.
Поскольку шаблон example описывает только интерфейс и не выполняет никаких операций, то в этом примере мы добавим в него реализацию CRUD-операций на основе одно-связного списка.

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

Всем привет, хабрачитатели!

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

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

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

Кто пишет на Node.js и использует MySQL, тот непременно знает, что наш дорогой товарищ Felix Geisendörfer три года назад совершил героический и самоотверженный подвиг: в одиночку разработал очень качественный драйвер для подключения к MySQL, нативно реализовав двоичный протокол этой СУБД на JavaScript. Потом к проекту подключились другие уважаемые товарищи, была реализована поддержка пулов соединений, кластеров, транзакций, восстановление при временной утере соединения и т.д. Сейчас драйвер является самым развитым, хорошо проработанным и активно поддерживаемым из того, что мы имеем в открытых репозитариях npm и github. Удивительно даже, что при хорошо проработанной низкоуровневой реализации, все удобства, которые предоставляет это драйвер для прикладного разработчика, сводятся к одному методу query. Для меня лично, этого очень мало, ну привык дедушка к удобствам для возврата скалярных значений, строк и столбцов в массивы, интроспекции структур БД. Так что, с удовольствием делюсь этими наработками с вами, мои дорогие Хабравчане, но предупреждаю, что все удобства будут на улице. Есть конечно вариант тесной интеграции с драйвером, но FelixGe желает оставить драйвер исключительно низкоуровневым, поэтому я остановился на варианте внешней библиотеки с добавлением к драйверу через примеси. В виде примесей, удобства попали и в платформу Impress, а так же, опубликованы как патч к драйверу. О функционале и вариантах использования далее.

Очень короткая статья, про то как можно использовать HAProxy в качестве балансировщика для multi-master серверов MySQL, таких как Percona или Galera.

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

Для тех кто не знаком с HAProxy, цитата о предназначении продукта:

При увеличении нагрузки или посещаемости проекта, рано или поздно вертикальное маштабирование (увеличение ресурсов сервера, таких как память, скорость диска и т.д) упирается в некий предел и не дает ощутимого прироста. В таком случае в ход идет горизонтальное масштабирование — добавление новых серверов c перераспределением нагрузки между ними.
Кроме увеличения мощности, горизонтальное масштабирование добавляет надежности системе — при выходе из строя одного из серверов, нагрузка будет сбалансирована между работающими и приложение будет жить.

От слов к делу, установка и настройка очень просты:

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

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Привет Хабравчанам!

Рады сообщить, что в ближайшие две недели офис Jelastic навестят настоящие гуру IT-индустрии: Майкл Видениус (или Монти, создатель MySQL), Расмус Лердорф («отец PHP») и Марк Збиковски (бывший архитектор компании Microsoft).


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

Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.

Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и длительность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.

Выводы из условия:

— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.

Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

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

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

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

Проект phpMyAdmin появился на свет 9 сентября 1998 года, когда Тобиас Ратшиллер (Ratschiller) выпустил версию 0.9.0. За прошедшие полтора десятилетия phpMyAdmin превратился в один из основных инструментов для администрирования MySQL и других MySQL-подобных баз данных, с гордостью пишут разработчики.

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

К созданию phpMyAdmin причастны 669 разработчиков, а основная группа разработчиков выросла с 1 до 9 человек.

Хотим «phpMyAdmin» (читай web GUI) для ноды

Отсутствие универсальных веб-интерфейсов для управления распространенными СУБД, несколько усложняет освоение Node.js, а разворачивать рядом другой веб-сервер и другой язык с инфраструктурой, ой как не хочется. Открывать порты и управлять базами, подключаясь с другого сервера или со своего рабочего компьютера — это и неудобно и есть соображения безопасности. Поэтому мы решили включить такой инструмент в платформу для веб-приложений Impress, которую анонсировали, о которой я немного писал и которая доступна в открытом коде для всеобщей пользы. Задумка такая: реализовать простой и удобный унифицированный интерфейс для СУБД, которые чаще всего применяются в связке с Node.js, позаботиться о быстром развертывании (просто скопировать папку) и независимости от среды. В бета-версии уже поддерживаются MySQL, MongoDB и в скором времени очередь дойдет до PostgreSQL и Oracle.

Можно ли уместить исходники MySQL клиента на 1 страничке формата A4? Оказывается, если 8 кеглем (в принципе читаемо) и после обфускации, то можно! А если нормальный код без обфускации и 10 кеглем, то таки нельзя: надо целых 6 страничек.

В ходе работы над всяким у меня тут случайно получился крохотный, но работающий MySQL клиент размером чуть больше 1000 строк. Стало интересно, насколько компактнее можно сделать. Потратил половину воскресенья, изолировал и минимизировал код. В результате появился nanomysql, CLI клиент для MySQL, полные исходники которого занимают чуть менее 380 строк и примерно 10500 байт, и при этом компилируются и работают под Linux, Windows, MacOS. Написано на C++ с абсолютным минимумом STL.

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

Хорошей пятницы, Хабр!

Как многим известно, отдельные баги в MySQL не закрываются годами. Но все еще открытому багу #20786 «mysqldump always includes AUTO_INCREMENT» повезло больше других — на свое семилетие он хотя бы получил самый настоящий праздничный торт!




Страница бага

Один из основателей проекта MySQL, на данный момент руководитель проекта MariaDB Ульф Майкл Видениус (известный также под ником Монти), в интервью ITwire говорит о том, что Oracle провалила попытку сделать MySQL успешным продуктом, потому что компания не понимает открытую модель разработки программ.

«Это не в их ДНК», — добавил Монти. — «Они пытаются вести открытый проект в той же самой манере, в которой они разрабатывают свои закрытые продукты, и это большая ошибка».

Недавно Red Hat — компания, стоящая за разработкой наиболее популярного дистрибутива Linux в бизнес-секторе — объявила о том, что в готовящейся к выпуску седьмой версии дистрибутива MySQL будет заменён его ответвлением — MariaDB. За разработкой MariaDB в свою очередь стоит Монти и основанная им компания Monty Program Ab. Ранее под крылышко компании Монти также перешла компания SkySQL, вместе с другим со-основателем MySQL Дэвидом Аксмарком, который работал там как технический директор. Третий со-основатель MySQL — Алан Лариссон — также работает с Монти, помогая ему по мере необходимости своим советом и делом.

Монти сказал, что главной причиной, по которой всё больше и больше людей и компаний стали искать альтернативу MySQL, послужил в большей степени тот факт, что Oracle ясно показала своё нежелание играть по принятым правилам с сообществом разработчиков. Объясняя своё мнение, он добавил, что «выделение открытого ядра MySQL, удаление тестов из исходных кодов (большей частью для того, чтобы усложнить жизнь проектам, основанным на его кодовой базе) и создание таких условий, при которых никто не может разрабатывать MySQL с теми же привилегиями, какие есть у Oracle», это всё послужило причиной сложившейся ситуации.