MySQL *

Как только ваша информационная система становится рабочей (prоduction), появляется необходимость иметь как минимум две копии ее базы данных. Первая, резервная, с некоторой частотой создается при помощи штатных утилит и представляет собой согласованный дамп (consistent dump). Цель его создания — восстановление системы после сбоя (disaster recovery).

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

Для синхронизации файлов проекта, ведения истории мы используем системы контроля версий, например, Git. Однако, когда у меня встал вопрос о контроле версий структуры базы MySQL — удовлетворяющего решения найти не удалось.
Замечу, во многих фреймворках и ORM существуют необходимые механизмы «из коробки» — миграции, версионность и т.д. А вот для нативной работы с MySQL — приходится все делать ручками. И пришла идея попытаться создать автоматическую систему для отслеживания изменений.

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

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

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

Есть немало книг, описывающих особенности и специфику конкретных БД.
Значительно меньше «программно-независимых» изданий, которые рассказывают об общих правилах и законах проектирования баз, принципах построения, нарушение которых может привести в дальнейшем к серьёзным ошибкам и проблемам. Где рассмотрена вся методологическая цепочка от постановки задачи до итогового анализа уровня целостности данных для каждого приложения.

Мы сейчас обсуждаем возможность издать на русском языке книгу Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design и хотели бы включить в эту дискуссию «коллективный разум».

Уважаемые читатели! Пожалуйста, оцените это издание по пятибалльной шкале. Насколько оно раскрывает тему? Будет ли оно полезно разработчикам БД — лично вам, или, может быть, вашим менее опытным коллегам, которые смогут избежать ошибок проектирования?
Комментарии своей оценки, как всегда, приветствуются.

Везде, где используется 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 с максимальной ценой.

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

Привет, Хабр!

Я привык выполнять свою работу добросовестно и перед написанием этого поста параноидально проверил несколько раз, насколько подмеченное мной является действительно багом (а не последствиями бессонной ночи перед компьютером), а также попытался найти что-либо похожее в интернетах. In vain. Verloren. Тщетно.

Итак, если интересно, добро пожаловать под кат, чтобы увидеть несложный архитектурный элемент, на котором некорректно срабатывает добавление первой записи в составной VIEW.

Я работаю в организации, которая занимается аутсорсингом по всей России, в том числе монтажом СКС в магазинах наших заказчиков. Заказов на монтаж в последнее время стало намного больше и был создан новый отдел, который занимается мониторингом этих открытий. Мне была поставлена задача разработать небольшой сайт для мониторинга данных работ. На сайте должны быть счетчики обратного отчета, отображающее время до открытия магазина, строка с данными об этом магазине (заказчик, бренд, город, адрес, номер заявки в нашей основной информационной системе, тип работ и дата открытия), а вся эта информация на сайте должна браться из таблицы, находящийся на Google docs.

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

Введение

В процессе создания более ли мене сложного сайта приходится задумываться об организации доступа к БД(базе данных). Если сайт создается на базе существующего фреймворка или CMS, то там как правило имеются встроенные механизмы ORM (с англ. — Объектно-реляционное отображение, подробнее в вики). В данной статье я расскажу как можно прикрутить популярную и простую ORM систему ActiveRecord к собственному фреймворку.

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

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

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

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

Всем привет!
Удобно смотреть отчёты через браузер, не надо пользователю никакие программы устанавливать.
Для более удобной работы с данными журнала использования Интернета (WEB) и журналом брандмауэра (FWS) сервера MS TMG их можно загрузить в базу MySQL. Можно написать сколько угодно отчётов по этим данным. Для доступа к отчётам используется веб-интерфейс.
Пример реализации под катом.

Собственно, столкнулся с банальной задачей — есть база, в которой есть масса данных ФИО, написанных латиницей. Зачастую достаточно безграмотно и непредсказуемо транслитерировано. Вроде бы и есть ГОСТ 7.79 (ISO 9), но на практике его далеко не всегда соблюдают.
Задача — есть БД с записями (как правило, ФИО) латиницей. Плохой латиницей. Требуется по русской подстроке поиска в вэб-приложении выбрать из БД (MySQL) записи, похоже транслитерированные на латиницу.

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

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

Однажды мне потребовалось узнать номера улиц и домов Минска. Каково же было мое разочарование, когда я узнал, что полных данных нигде нет, и что делать если появляются новые улицы и дома. Вот тут и пришел на выход OpenStreetMap с открытым кодом и постоянными обновлениями. Беда в том, что карты представляют собой xml документ, объёмом аж целых 2 Гб и информация о домах представлена в таком виде:

<way id="25324320" >
  <nd ref="275904968"/>
  <nd ref="275904882"/>
  <nd ref="275904881"/>
  <nd ref="275904969"/>
  <nd ref="275904968"/>
  <tag k="addr:housenumber" v="17"/>
  <tag k="addr:postcode" v="220013"/>
  <tag k="addr:street" v="улица Якуба Коласа"/>
  <tag k="building" v="yes"/>
 </way>  

Обрабатывать 1.5 Гб данных проще, когда данные упорядочены а не представлены в виде строк. Так мной было принято решения конвертировать данные в БД. Сказано – сделано, в качестве рабочего инструмента выбраны: Eclipse(Java SE) и джентельменски набор денвера.

Вчера Oracle Certification запустила beta-сертификацию MySQL 5.6 DBA и MySQL 5.6 Developer Beta-программа продлится около двух месяцев. В это время у вас есть возможность получить сертификаты за 50 USD

Это первый официальный экзамен по MySQL за очень долгое время: предыдущий был для версии 5.0 и много багов утекло с той поры. Для меня лично это событие значимо ещё и потому, что я принимала активное участие в создании и редактировании вопросов вместе с другими инженерами из команды MySQL Support. А гордиться нам есть чем.

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

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

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

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

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

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