MySQL или PostgreSQL?

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

Но бывают и другие задачи — когда посетители тоже генерят данные. Или, например, данных у вас очень много и требуется какая-то хитрая их обработка или распределение по нескольким физическим дискам (партиционирование). Тогда в 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 .
  • выбор, какую базу использовать, в общем случае не стоит остро — можно взять ту СУБД, которую вы лучше знаете, или по которой у вас есть знакомый гуру
  • 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 таких ограничений нет. Знатоки, поправьте меня

  • Панькив

    полезную информацию пишите

Запись навигация

Top