войти зарегистрироваться

MySQL whois

индекс
202,61

DevConf: 3 доклада + мастеркласс по MySQL: DRBD/HeartBeat/MySQL, MariaDB, Мониторинг производительности MySQL

image

3 доклада по MySQL на DEVCONF 2010 17 мая Москва



Мониторинг производительности MySQL с использованием performance
Алексей Копытов, Senior Software Developer, Sun Microsystems.
Решения высокой надежности на базе MySQL
Алик Рубин, MySQL, Норвегия
MariaDB — ветка MySQL с большими возможностями
Сергей Петруня (Monty Program Ab)

Голосуем — поддерживаем наших :-)
devconf.ru/offers

MongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ

Собственно, сегодня был запощен топик "Сравниваем производительность MongoDB и MySQL на простом примере", в котором указывалось, что MongoDB превышает по производительности MySQL в разы. Хех, когда такое пишут — я сразу лезу проверять и сомневаться. Я полез в исходники оригинального теста (спасибо за публикацию). И как оказалось автор оригинального топика сделал ошибку в три символа и на самом деле не все так:
  1. В оригинале: MongoDB быстрее MySQL пишет в 1.5 раза (ДА, правда у меня в 3 раза)
  2. В оригинале: MongoDB быстрее MySQL читает в 10 раз (НЕТ, на самом деле — MongoDB примерно на равных плюс-минус 10-30%)
  3. InnoDB vs MyISAM — плюс-минус (в оригинале не тестировалось)
Сравнение здесь происходит только как key-value storage (запись-чтение по primary key).


На графике — число операций в секунду, (больше — лучше), шкала логарифмическая.
Последняя строка — то, что тестировал автор оригинального топика (неправильное, не в критику — все мы ошибаемся и учимся).


А теперь подробнее об ошибке…

Как FriendFeed использует MySQL для хранения данных без схемы

Условия


Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Задача на сортировку

Возможно, кому-то эта задача покажется пустяковой, но лично я потратил на неё несколько часов, израсходовав подсказки «мнение зала» и «звонок другу». Зачем я это решал? Ответ прост: мне действительно нужно было реализовать такой подход для моего небольшого сайтика Одио.ру. Если вкратце, то там публикуются записи с самых разных сайтов, стягиваемые по RSS. Сложность в том, что даты в этих записях могут полностью совпадать (даже в рамках одной ленты), при этом последовательность ID имеет смысл только в рамках одной ленты, но никак не влияет на весь поток записей. Итак, давайте перейдем к условиям задачи.

Автоматическая сортировка строк с вспомогательным порядковым столбцом — средствами MySQL

sort
Недавно пришлось выполнить махинацию с БД которая, как кажется на первый взгляд, совершенно невыполнима средствами MySQL. Перед глазами у меня была таблица товаров, сортировка которых осуществляется вспомогательным столбцом `order_num` ('порядковый номер'): она позволяет задавать ручную сортировку товаров.
Но вот потребовалось автоматически заполнить этот столбец так, чтобы товары оказались отсортированы по названию: то есть, с рядом ограничений, изменить столбец `order_num` во всей таблице. Очень хотелось обойтись средствами MySQL без привлечения каких-либо дополнительных инструментов, и задача была решена :)

Сложность задачи также в том, что MySQL не умеет делать UPDATE таблицы и одновременно читать из неё: в MyISAM таблица эксклюзивно блокируется при записи и нет возможности произвести чтение в подзапросе.

Россия может спасти MySQL

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

PS. В письме много ссылок, некоторые (на мой взгляд важные) я оставлю кликабильными, остальные нет — что бы в спаме не заподозрили =)

Раздача Personal лицензий на Database Designer for MySQL

Первые восемь миллиардов лицензий на MicroOLAP Database Designer for MySQL, запрошенных до 8 утра 31 декабря 2009 со ссылкой на этот пост, раздаются бесплатно.

Количество лицензий ограничено, поторопитесь.

Видео с OpenSQL Camp o MySQL и не только

В ноябре этого года, в Портланде, США прошла конференция OpenSQL Camp посвященная опенсорс СУБД.
Совершенно случайно наткнулся на видео докладов и спешу ими поделиться. Общий уровень конференции, как мне показалось, достаточно высок, так что советую посмотреть. Часть видео, к сожалению, в плохом качестве. Все презентации, конечно же, на английском.

Тестирование MySQL: ZFS vs UFS

zfsВозникла у меня некоторое время назад нужда в создании мгновенных бекапов базы данных mysql. Желание существовало уже давно, но как-то до сих пор вроде нормально жилось с репликацией и бекапом со slave. Но случаи бывают разные, и возможность снять мгновенный снимок с файловой системы master-сервера может очень сильно облегчить жизнь. Я понял, что нужен мне snapshot. А там где snapshot, там полуавтоматически появляется на горизонте ZFS. Кроме того в ней еще есть некоторые вкусности, которые на данный момент мне вроде и не особо нужны, но в принципе их наличие может значительно скрасить жизнь.

Сам процесс получения снимка файловой системы я пока оставляю в стороне, но пытаюсь получить некоторое представление о ZFS в сравнении с UFS в моих условиях. Недавно я публиковал на хабре перевод материала от John David Duncan. Там описано все достаточно вкусно, но надо пробовать самому.

Я попробовал…

A look at MySQL on ZFS

image

Представляю вниманию общественности перевод достаточно большой статьи об использовании MySQL на ZFS, а так же сравнительное тестирование ZFS и UFS.