Mvs3d.ru: блог Web-разработчика

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

Но бывают и другие задачи – когда посетители тоже генерят данные. Или, например, данных у вас очень много и требуется какая-то хитрая их обработка или распределение по нескольким физическим дискам (партиционирование). Тогда в MySQL требуется применять более классический движок – InnoDB. Однако, с ним я много не работал и решил почитать что народ о нем пишет.. И наткнулмя сразу на очень нелицеприятную заметку в блоге: “Мой чисто практический опыт применения InnoDB на производственных мощностях показал, что данный драйвер гавно, массивные инсерты и апдейты кладут его в смерть.”

Данное заявление ставит в тупик, т.к. многие известные крупные проекты используют MySQL именно с InnoDB, и ничего, работает. Да и появился он далеко не вчера, а несколько лет назад и такими детскими болезнями не должен страдать по идее.  Есть подозрение что товарищ не совсем в теме – его “вроде там даж триггеры есть” показывает что о MySQL его знания достаточно поверностны – триггеры ведь есть и в MyISAM. Но все-таки, захотелось поизучать данный вопрос еще немного. Тем более, что есть предпосылки использовать в проекте другую СУБД – PostgreSQL (проект достался в наследство, и от предыдущей команды – база данных, написанная именно на PostgreSQL).

Покопавшись немного в интернете, нашлась заметка о прошедшей в Москве, 21 янвалря 2009 года групп пользователей MySQL и PostgreSQL. На ней выступали с докладами разработчики MySQL и PostgreSQL, и крупных проектов, их использующих:

• Константин Осипов, Sun/MySQL (активный разработчик MySQL, занимается проблемами производительности)
• Алексей Рыбак, Badoo.com (использует MySQL, 18млн. пользователей)
• Фёдор Сигаев, PostgreSQL Global Development Group (разработчик индексов GIS)
• Олег Бартунов, PostgreSQL Global Development Group (ведущий разработчик, активный участник команды разработчиков)
• Андрей Смирнов, NetStream (PostgreSQL, сервис smotri.com)

Видео можно скачать по ссылкам: первая часть (700Мб), вторая часть (700Мб). Качество удовлетворительное (видео – отлично, но звук записан на микрофон видеокамеры – не всегда хорошо слышно). Кроме этого видео обрывается (думаю пропало несколько минут – там уже к завершению шло). Можете попробовать скачать еще тут, одним большим файлом в DVD качестве (4.4Gb).

Вообще видео очень интересное. Я с большим удовольствием просмотрел эту 2-х часовую запись, и жалею что встреча была такой короткой – участники стараясь попасть в регламент говорили скороговоркой о таких вещах, которые бы послушать подробнее… Но тем не менее, для себя я полезные выводы сделал:

• обе базы данных успешно используются к крупных проектах:
  • MySQL используетя в таких проектах как Facebook.com, Wikipedia.org, Mambo, Одноклассники (причем по крайней мере, в Badoo.com используется InnoDB);
  • PostgreSQL – использует в проектах “Мой круг”, проектах компании “Раблер”, “1С” сетевая перешла с MS SQL.
• выбор, какую базу использовать, в общем случае не стоит остро – можно взять ту СУБД, которую вы лучше знаете, или по которой у вас есть знакомый гуру
• PostgreSQL не так широко распространен как MySQL, но это ни коем образом не умоляет его достоинств:
  • стабильность (”поставил и забыл”). Если в MySQL основой упор делался изначально на скорость выборки данных, то в PostgreSQL во главу угла ставится стабильность его работы и надежность хранения данных. Как результат – новые версии выходят не так часто как в MySQL.
  • чрезвычайно мощный механизм хранимых процедур (их можно писать на разных языках причем!), позволяет реализовывать прямо средствами базы данных даже такие сложные вещи как репликация или распределение нагрузки по серверам БД.
  • прозвучала информация о том, что эта СУБД более эффективно чем MySQL паралелится – лучше использует мощнсти многопроцессорных систем;
  • показывает линейную производительность при долговременной большой нагрузке (у MySQL в этих услових, мол начинает снижаться скорость);
  • есть примеры использования поистине колоссальных объемов данных – Олег Батуров и Федор Сигаев рассказали  о базе данных, которая хранит астрономические данные объемом свыше 10Тб.

Некоторые интересные факты о PostgreSQL:

Встроенной средств для репликации сейчас нет (в 8.4 должен появится на основе бинлога в марте 2009года). Сейчас существуют две версии репликации средствами БД (я так понял они сделаны на триггерах и хранимых процедурах:

• “Slony” – появился первым, – большое число возможностей, но сложна в настройке; 
• “londiste” – разработка компании SkyTools – проще в настройке, чуть меньше возможностей. Разработан при работе над сервисом Skype. Кстати, Skype – один из примеров использования PostgreSQL. В настоящее время база данных содержит 350млн пользвателей, и разработчики утверждают что она спроектирована так что способна выдержать нагрузку в 1 миллиард пользователей.
• у PostgreSQL похоже неплохое сообщество в рунете.

В общем, возвращаясь к началу, достоверность “чисто практического опыта” применения InnoDB вызывает некоторые сомнения – как-то слишком мало данных о том, что именно тестировалось и как. “Положить” сервер можно любой, для этого особого умения не требуется. Помнится мой первый опыт общения с Oracle я начал с того, что положил его запросом на выборку.. ну не положил конечно, а заставил задуматься так надолго, что админу пришлось снимать мой запрос

Конечно, есть очень большое желание попробовать PostgreSQL в проекте – очень интересная СУБД, с большими возможностями которые так хочется поизучать Но сроки там сильно сжаты, видимо придется остановится на более привычном MySQL.

Update: вспомнилось еще пара интересных моментов услышанных на видео:

• процесс разработки MySQL в компании Sun выполняется по методологии Agile, применяется парное программирование;
• после того как компания Sun стала владельцем MySQL, количество коммитов в день выросло в 10раз (до 80 против 7-8 в 2002 году), каждый коммит проходит автоматическое тестирование на большом парке машин, в том числе стресс-тесты.

Дополнено 01.04.2009: касаемо сравнения возможностей СУБД… Все-таки в MySQL возможности хранимых процедур и фукнций в настоящее время (до версии 5.1) сильно ограничены. Лично я пока наткнулся на следующие ограничения, которые мне бы пригодились: 

• нельзя передать или вернуть переменную типа “курсор” в процедуру (т.е. нельзя, например, из функции вернуть набор данных – приходится извращаться со временными таблицами);
• нельзя сгенерить собственную ошибку внутри процедуры. Хотел вот проверить параметр который передается в процедуру и если его значение недопустимо кинуть исключение из базы с понятным сообщением об ошибке.. а вот никак Как вариант, можно подключить эту UDF (чего я пока делать не планирую, – все-таки внешние либы подключать для красоты кода – перебор, непонятно ведь как это может отразиться на стабильности работы). Вот тут и тут еще варианты с UDF. Стандартные в SQL операторы SIGNAL и RESIGNAL появятся в версии 6.0 (т.е. через год примерно, судя по тому что я услышал на видео).

Не проверял, но подозреваю что в PostgreSQL таких ограничений нет. Знатоки, поправьте меня

Дополнено 12.04.2009: пример использования mysql в крупной системе. 

Интересное знание по поводу особенностей mysql было получено на этой неделе. Оказывается в настоящее время констраинты там проверяются до завершения транзакции. Т.е. если вы изменяете поле, для которого например есть уникальный ключ и при этом изменении нарушается его уникальность, то вы получите ошибку, даже если в ходе транзакции предполагалось провести несколько таких изменений без нарушения уникальности. Грубо говоря оператор update table set id = id + 1 невозможен в принципе. Я проверил на версии 5.0.x ага, так и есть.

Я прям задумался.. кажется такое-же ограничение я где то видел раньше. Interbase? Oracle? Не припомню. Если оно касается всех констраинтов, то конечно это не очень круто – придется продумывать все операции модификации данных с учетом этой “особенности”.. а жить с ней, по-моему все-таки возможно.