MySQL *

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

В опубликованной накануне (февраль, 2012) статье озаглавленной «Определение страны по IP: тестируем скорость алгоритмов» сравнивались реализации на уровне БД и нативной реализации. Мы же предлагаем рассмотреть ещё более оптимальный и простой алгоритм, который может быть реализован как в БД, так и в нативном варианте – плоские диапазоны.

Oracle пытается вернуть утраченную карму. Последний релиз MySQL Cluster 7.2 GA вышел под GPL, а 8-нодовый кластер MySQL обрабатывает 1,05 млрд запросов в минуту (17,6 млн в секунду).

Разработчики также заявляют о 70-кратном росте производительности на сложных запросах (JOIN), на самом деле в бэкенде 7.2 интегрирован модуль Memcached и реализованы нативные Memcached API.

Благодаря Memcached теперь MySQL Cluster 7.2 GA способен также получать запросы через NoSQL C++ NDB API.

На тему оптимизации MySQL запросов написано очень много, все знают как оптимизировать SELECT, INSERT, что нужно джоинить по ключу и т.д. и т.п.

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

Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

Мне каждый раз задают один и тот же вопрос, спрашивают об одном и том же: «Как перекодировать кракозябры из базы данных, хранящей строки в кодировке latin1 в нормальную кириллицу (windows-1251) или utf-8».

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

Написание этой статьи навеяно вот этой трилогией: один, два, три. Захотелось добавить свои 0.02$, по использованию трюков и особенностей.

Введение

Сейчас очень популярна тем оптимизации работы с различными СУБД. На многочисленных форумах ведутся дискуссии о «самой лучшей СУБД в мире», но часто все это перетекает в необоснованные выкрики о том, что «я познал смысл жизни и понял, что самое лучшее хранилище данных — Х».

Да, несомненно, сейчас мы можем наблюдать активное развитие NoSQL решений, которые позволяют делать многое. Но данная статья не о них. Так вышло, что я сменил работу и в нагрузку мне достался один очень интересный проект на связке php+MySQL. В нем есть много хороших решений, но он писался без расчёта на большую аудиторию. За несколько лет существования количество активных пользователей начало приближаться к числам с 7 нулями. Так как проект представляет из себя подобие социальной сети с игровыми элементами, то таблица с пользователями оказалась не самой «тяжёлой» из всех. В наследство мне достались таблицы с десятками миллионов вещей пользователей, личных сообщений, биллинговыми записями и т. п. Проект начали рефакторить, разбивать на несколько серверов и достигли значительных результатов. Сейчас все стабильно.

Но недавно мне на почту прислали новую задачу. Суть заключалась в сборе статистики. Проанализировав требования я понял, что для выполнения достаточно написать один единственный запрос, выполняющий 3 INNER JOIN'а на таблицы, размеры которых впечатляли. Каждая таблица в среднем содержала 40 миллионов записей. Получается, что временная таблица состояла бы из 4*4*4*10^21 = 64*10^21 записей. Это колоссальная цифра. И загружать СУБД таким запросом для сбора статистики — непозволительная роскошь.

Далее, собственно, я и хочу представить решение данной абстрактной задачи, которое пришло мне в голову, когда я вспоминал занятия по информатике на первом курсе университета.

Итак, в начале несколько слов, а-ля предисловие. Данный мануал не претендует на истину в первой инстанции и на построчное руководство. Скрипты можно написать куда лучше. Команды — на момент прочтения могут звучать уже по другому (даже на момент написания документация на сайте разниться с реальными командами). Многое в скриптах сделано под рутом, что в целом тоже не правильно, но для «что бы заработало а потом поправить» — оставил пока что так. Ответы на базовые вопросы по настройке Вы найдете в документации на сайте tungsten-а (http://code.google.com/p/tungsten-replicator/).

Задача:

Возникла необходимость в репликации с MySql (5.5) на Oracle (11.2) на сервере с CentOS 5.5. При чем не всего-всего, а только больших таблиц, очень-очень быстро наполняющихся и связанных со статистикой. Добавим к этому, что на сервере MySql наблюдаются проблемы с местом, и как вывод — фильтрация репликации должна происходить на нем. Ну, и при необходимости — сразу подчищаться все возможные временные файлы, опять же по причине места, на обоих серверах.

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.

В компании, где я работаю, мы используем деперсонализированную базу с Production-a. Ее суммарный объем на данный момент около 30 ГБ. Обфускация ruby скриптом занимала около 6 часов. Ускорение обработки можно добиться, если переписать это все в хранимую процедуру (stored procedure). Но у нас в проекте они запрещены… Увы и ах.

Тогда я задался вопросом: можно ли ускорить процесс по максимуму, деперсонализировать всю базу (или хотя бы полностью одну таблицу) используя только один оператор update? Проблема в том, что некоторые поля д.б. уникальными, а некоторые случайными значениями из списка.

На Хабре уже писалось, что в MySQL появилась возможность подменять встроенную процедуру аутентификации, загрузив соответствующий плагин. В таком плагине можно реализовать совершенно произвольную политику аутентификации пользователей, полностью уходя от традиционной в MySQL схемы username/password в таблице mysql.user.

А недавно Оракл выпустил PAM authentication plugin. При использовании которого сервер не ищет пароли в mysql.user, а перекладывает задачу аутентификации на PAM, подсистему специально разработанную для решения задач аутентификации в различных приложениях и контекстах, с гибко настраиваемыми правилами и на лету подключаемыми модулями.

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

«А почему-бы...» — подумал я. «Я напишу свой pam-плагин, с блэкджеком и шлюхами!»

Предисловие.

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

Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …

Введение

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

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

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

Приветствую.
Когда перед мной встал вопрос о переходе с phpmyadmin на любой другой клиент, поддерживающий ssh туннели, я перепробовал много что. Остановился на sqlyog`е. Помимо более менее понятного интерфейса, он умел синхронизировать структуры баз данных. И в общем мирился со всеми его странностями и неудобствами. Однако столкнувшись с тем, что для timestamp полей он ставит по дефолту не «DEFAULT CURRENT_TIMESTAMP», а «DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP» и при этом постоянно врёт, что это просто «DEFAULT CURRENT_TIMESTAMP» (т.е. визуально ON UPDATE нигде не отображает), моё терпение лопнуло. В поисках нового клиента, я открыл для себя гениальное, необычное, удобное и простое решение — HeidiSQL.

Продолжение. Начало тут.

Множественные песочницы.
Вы можете создавать множественные песочницы командой
$ make_multiple_sandbox /path/to/tarball
Будут созданы 3 песочницы, одной версии, без репликации.
При необходимости, также есть возможность создания множественной (3 шт) пeсочницы с использованием разных версий mysql

Периодически( а иногда и достаточно часто) возникает необходимость в тестовых, или иных других целях, поднять пару mysql серверов, а можно и с реплицированием, для откатки или отладки того или иного процесса.
Автоматизировать самому данное телодвижение зачастую нет смысла, поскольку это не так часто необходимо, как хочется.

В недрах документации MySQL на dev.mysql.com я как-то обнаружил упоминание о том, что в случае, если используется MyISAM, можно получить прирост в скорости чтения из таблицы в 5-7 раз, если читать данные из таблицы самостоятельно. Мне довольно долго хотелось проверить этот факт и вот, наконец, у меня дошли руки до того, чтобы это попробовать. Что из этого вышло, читайте под катом

Сегодня я расскажу как сделать вашу СУБД MySQL ближе к стандартам PCI DSS. Для начала вот что у нас получится:
Консоль админ пользователя mcshadow

mcshadow:~$mysql --user=mcshadow --password=mike
mysql> select current_user();
+----------------+
| current_user() |
+----------------+
| mike@localhost |
+----------------+
mcshadow:~$mysql --user=mcshadow --password=root
mysql> select current_user();
+----------------+
| current_user() |
+----------------+
| root@localhost |
+----------------+

Доступ возможен как с правами рута, так и с правами смертного пользователя mike.

---

Консоль смертного пользователя mike

mike:~$mysql --user=mcshadow --password=mike
ERROR 1698 (28000): Access denied for user 'mcshadow'@'localhost'

Доступ к БД под администратором невозможен.

---

А тем временем в syslog

^{mysqld: User:mcshadow TRY access from:localhost with privileges:mike
mysqld: User:mcshadow SUCCESS access from:localhost with privileges:mike
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:5, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'
mysqld: User:mcshadow TRY access from:localhost with privileges:root
mysqld: User:mcshadow SUCCESS access from:localhost with privileges:root
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:6, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'
mysqld: User:mcshadow TRY access from:localhost with privileges:mike
mysqld: User:mcshadow FAILED access from:localhost with privileges:mike}