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 имеет смысл только в рамках одной ленты, но никак не влияет на весь поток записей. Итак, давайте перейдем к условиям задачи.

Здравствуйте!

Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.

Все бы ничего, если бы этот случай не повторился…

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

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

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

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

К сожалению, несмотря на то, что ваши вопросы Монти были отправлены задолго до конца декабря, ответить на них он сумел несколько позже запланированного срока, что, впрочем, не умаляет интересности и актуальности его ответов (англоязычный оригинал ответов Майкла на ваши вопросы можно скачать здесь (RTF-файл, 16,6 Кбайт); ниже дан наш перевод, он может быть не идеален, так что буду рад, если укажете на возможные ошибки).

Напомню, что Майкл «Монти» Видеинус — это один из основных разработчиков популярной СУБД MySQL, которую, в свою очередь, хочет заиметь Oracle Corporation. Такое положение дел Монти по понятным причинам совершенно не устраивает, в связи с чем он в прошлом году опубликовал у себя в блоге соответствующую заметку, обращаясь за помощью к комьюнити.

Итак, Монти, вы получили вопросы от Habrahabr.ru? Люди волнуются, что вы так долго не отвечаете.
Я только что заметил. Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org, это заняло почти всё моё время в последние дни.

Как вы пришли к идее создания MySQL в 1994 году? Почему вообще решили этим заняться? Что не устраивало в существующих решениях?
MySQL была основана на более старой программе для баз данных Unireg, которую я начал разрабатывать в 1982-м. Это был генератор приложений на основе tty (screen). С помощью Unireg мы создавали прикладные программы для наших клиентов.

В 1993-м нам понадобилось обеспечить клиентам доступ к их базам Unireg через интернет. Чтобы решить эту проблему, я сделал поверх Unireg слой SQL (поскольку я полагал, что SQL будет легко встроить в скрипты HTML), а также драйвер ODBC.

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

В качестве альтернативного варианта мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и её нельзя было легко встраивать в HTML-страницы.

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

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

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

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

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

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

На хабре проскакивали статьи про PHP и Javascript beautifier'ы, но для SQL запросов я тут ничего не нашёл. Постараюсь исправить этот пробел.

Наиболее популярный SQLinForm. Единственный минус этого решения является требование Java Runtime.

Менее «фичастый» и более удобный для работы Instant SQL Formatter. Пример работы можно посмотреть здесь.

Я думаю многие знают о Sypex Dumper, если не знают то это менеджер для работы с MySQL, написанный на php и запускаемый естественно на сервере, раньше он поддерживал только функции импорта \ экспорта БД, Но после 2 летнего перерыва автор выпустил новую версию!
Встречайте Sypex Dumper 2.0.1

Доброго времени суток.

Очень хотелось поднять вопрос о древовидных структурах в MySql. А конкретно о выборках и хранении данных…
Пользователям Oracle и PostgresSQL живется хорошо, в этих БД есть встроенные средства выборки рекурентных данных (см. Иерархические (рекурсивные) запросы).
Пользователям Mysql приходится работать уже с тем, что есть, то есть работа на стороне клиента.
Поскольку эта тема не однократно поднималась, то я попробую рассказать о конкретной задаче и способе её решения.

Так получилось, что я довольно давно не работал с MySQL, поскольку в Рамблере используется, в основном, PostgreSQL. Сейчас у меня, наконец, появилось свободное время, и я решил догнать упущенное. Как выяснилось, за последние полтора года в мире MySQL изменилось довольно многое.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

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

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

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

Итак, как пользоваться:

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

Данные задачи абсолютно реальные, и в отдаленном светлом прошлом действительно имели место, и были благополучно решены жертвой некоторого количества рабочего времени и нервных клеток. Я уверен на 100% что они актуальны и по сей день, и будут актуальны еще долго. Сложными их назвать нельзя, но и очень простыми тоже (в зависимости от уровня подготовки конечно).

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.

Статья о том, как избежать путаницы с датами, хранимыми в mysql.
Эти путаницы возникают по двум причинам:
1. Разные территории нашей планеты имеют разный сдвиг времени.
2. Некоторые страны переходят на летнее время и обратно(карта со странами, переходящими на летнее время).

Многие решают эти проблемы по-разному. Кто-то делает сдвиг даты в SQL запросах, кто-то в php. Кто-то хранит даты в TIMESTAMP, кто-то в DATETIME. Я переискал много источников, но нигде не нашел верного решения данной проблемы на русском. В родной документации по mysql нашел информацию о том, как добиться корректной автоматической конвертации TIMESTAMP в локальное время, но тут тоже свои подводные камни.

Если в php настройка временной зоны делается просто, в mysql возникают сложности, особенно, если доступ к mysql серверу вам ограничен и там еще не установлены некоторые таблицы.