MySQL *

Тема шардинга довольно обширная как с точки зрения программиста, так и с точки зрения администратора БД. Я сейчас хочу коснуться только вопросов генерации уникального ID сущности и алгоритмов выбора шарда.

Здравствуй Хабр!

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

В этих ситуациях на помощь приходит Beaver mysql logger.

Высокая распространенность баз данных MySQL приводит к её использованию в разнообразных проектах, в том числе, которые требуют безостановочной работы и минимального времени восстановления. Стандартные инструменты, такие как mysqldump неудобен для использования баз данных размер, которых измеряется десятками гигабайт. К сожалению mysqldump вызывает блокировку таблиц, и операция снятия дампа или восстановления базы может занимать далеко не один час, а порой и 5-10 часов.

Благо, к нам на помощь приходит Percona XtraBackup.

Разработчики и администраторы систем основанных на sql данных, наверняка, сталкивались с задачей — получить отсутствующее (пропущенное) значение в ряде id записей таблицы. Например номер договора, порядковый номер документа, телефонный номер, айпи-адрес и т.п. При работе с MySQL эта тривиальная задача непропорционально ресурсоемка.

Нет смысла говорить о том, насколько это актуальный вопрос. Сегодня мы расскажем, как у нас организовано резервное копирование баз данных mysql.
И одно их самых важных – это проверка, а сделался ли бекап? А успешно ли прошел дамп? А были ли ошибки? А знаю ли я о них?

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

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

На первый взгляд делать бэкапы MySQL просто. Большинство сразу вспоминает об утилите mysqldump, более продвинутые администраторы о file system snapshots и инструментах горячего копирования MySQL Enterprise Backup (MEB), Percona XtraBackup.
Все эти инструменты умеют обеспечивать целостность, но не бесплатно.
Расплачиваться приходится блокировками, в том числе глобальными, длинными транзакциями, повышенной нагрузкой на MySQL сервер и даже полной его остановкой.
Для рабочего сервера, обслуживающего миллионы соединений, всё вышеперечисленное малоприемлемо.

На мастер-классе, основанном на реальном опыте с клиентами поддержки MySQL, я расскажу как производить резервное копирование:

14 июня(суббота) в Москве пройдет DevConf 2014
Впервые в России нам удалось собрать авторов MySQL, PostgreSQL, Percona Server, Sphinx, Tarantool и экспертов NeoJ4,BigData,HandlerSocket, NoSQL в отдельном потоке DevConf::Storage — по сути это отдельная конференция по современным БД.

Программа DevConf 2014::Storage

• Круто как в гугле. Поисковые сервисы на основе Sphinx
  Владимир Федорков. Последние двенадцать лет работает в области высоких нагрузок.
• NoSQL атакует: JSON функции в MySQL сервере.
  Света (svetasmirnova) Смирнова, автор JSON функций для MySQL и книги «MySQL Troubleshooting», а также инженер технической поддержки MySQL с 2006 года, компания Oracle.
• Schema-less PostgreSQL
  Олег Бартунов, major contributor PostgreSQL, научный сотрудник Государственного Астрономического института им.Штернберга, МГУ.
• Ноотропы RDF для BigData
  Леонид Юрьев — ведущий системный архитектор в «Петер-Сервис» R&D. Ранее был замечен в Центре Инноваций Натальи Касперской и Infowatch.

Как только ваша информационная система становится рабочей (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», «фреймворк».
Казалось что в каждом посте они есть. И я решил это проверить. Подробности под катом.