company_banner

По следам MySQL Users Conference 2011

    Хочу с вами поделиться впечатлениями о моей поездке на MySQL Users Conference, которая прошла в Санта-Клара (Калифорния) с 14 по 17 апреля 2011 г.

    В отличие от предыдущих лет, ничего с MySQL за время конференции не произошло, что уже само по себе приятно (напомню, что два года назад именно в первый день конференции было объявлено о приобретении Sun Microsystems Oracle).

    В первую очередь для меня конференция — это общение с людьми. В этом году на конференции было не так много участников (около 1100 человек), но процентное соотношение докладчиков и экспертов к посетителям было очень высоким.

    За неделю конференции тем было обсуждено очень много, связанного рассказа в любом случае не получится, поэтому опишу в виде заметок то, что было интересно.

    Что нового в MySQL от Oracle

    Присутствие докладчиков от Oracle на конференции было достаточно ограничено и произошло это благодаря тому, что компания изначально планировала сместить фокус на Collaborate 11, которая проходила параллельно O'Reilly MySQL на другом побережье США. Надо сказать, это было ошибкой — докладчики с Collaborate 11 рассказывали, что слушателей было крайне мало (максимум 20-30 человек) и интерес к MySQL у них был опосредованный. Действительно, Oracle — application software maker и ожидать интереса к RDBMS на Collaborate 11 было бы странно.

    В основном докладе Томас Улин рассказал о MySQL 5.6, в настоящий момент это бета 5.6.2 — чьи ключевые новые возможности относятся к области репликации, также стоит отметить некоторые доведённые до «ума» возможности query optimizer из MySQL 6.0. В остальном же это инкрементальный релиз, который расширяет возможности 5.5, 5.1 и 5.0.

    Из «горячих», на первый взгляд, новых возможностей Томас рассказал о memcached API к InnoDB. Возможно, я ничего не смыслю в NoSQL-технологиях, но мне эта идея показалось не слишком живучей — без нарушения консистентности данных этот API можно использовать только для чтения, но задачи чтения из MySQL масштабируются уже сейчас достаточно легко. Для записи API подходит мало, в первую очередь потому, что memcached соединения очень редко коммитят транзакции.

    COMMIT — дорогая операция, а без регулярного коммита теряются все преимущества InnoDB перед любым другим NoSQL-решением. Если так хочется использовать MySQL в качестве NoSQL, на мой взгляд, гораздо больше подходит MySQL Cluster + Cluster API из «коробки», который позволяет получить существенно более высокую производительность без потери консистентности данных.

    Остальные новости, такие как join pushdown в MySQL Cluster 7.2 или новый Windows Installer, мне лично были не очень интересны.

    О том, что делает MariaDB

    В двух словах, Monty Program выпустила 5.2 GA и готовится выпускать 5.3 GA.
    Основная возможность 5.2 — virtual columns, то есть возможность задавать дополнительные, «вычисляемые» столбцы в таблице. Это наиболее полезно, если по такому столбцу есть индекс — можно быстро искать по результату вычисления, не перевычисляя каждый раз значение. Второе, на мой взгляд, удобное применение этого функционала — вместе с partitioning.
    Т.к. в PARTITION BY операторе можно использовать далеко не любое выражение, в качестве альтернативы можно поместить результат вычисления в хранимый виртуальный столбец, и указать уже этот столбец в операторе PARTITION BY.

    Примеры приводить не буду, они есть в
    kb.askmonty.org/v/virtual-columns
    www.openlife.cc/blogs/2010/october/what-would-you-use-virtual-columns

    5.3 содержит довольно большое количество возможностей. В каком-то смысле это MySQL 5.5 от MariaDB — все те возможности оптимизатора, над которыми мы в своё время вместе трудились в ныне почившей ветке MySQL 6.0, программисты Monty Program Ab довели до ума и включили в MariaDB 5.3.

    Из наиболее серьёзных вещей в 5.3 сделан новый cost-based оптимизатор подзапросов, реализованы hash joins, добавлена поддержка микросекунд в темпоральных типах. Всё это сложные, требующие долгой и кропотливой работы задачи.

    Именно тот факт, что код 6.0 фактически переписан ещё раз, а также то, что в Monty Program Ab трудятся лучшие инженеры по тестированию MySQL (один Филипп Стоев стоит целого отдела), вселяет уверенность, что фичи будут достаточно стабильными.

    MariaDB 5.3 основана на MySQL 5.1 и, чтобы получить преимущества как MySQL 5.5, так и MariaDB 5.3, стоит дождаться конца года, когда, по словам Монти (надо делать скидку на его оптимизм), выйдет MariaDB 5.5, комбинирующая возможности двух систем.

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

    Ссылки:
    en.oreilly.com/mysql2011/public/schedule/detail/19899
    assets.en.oreilly.com/1/event/36/New%20Query%20Engine%20Feature

    Drizzle

    Для тех, кто интересуется этим форком, уже не новость, что Drizzle выпустила свой первый стабильный релиз Drizzle7. Новостью является то, что компания Rackspace, крупный американский хостинг-провайдер, являвшийся основным спонсором разработки Drizzle, с выходом стабильного релиза прекратила финансовую поддержку этого проекта. Найдутся ли компании, готовые спонсировать его разработку, пока неясно.

    Я бы не стал предполагать скоропостижную кончину этого проекта, тем более что множество идей в Drizzle заслуживают внимания. Взять хотя бы Firebird, open-source версию популярной в своё время СУБД Interbase — мало кто знает, что проект до сих пор продолжает своё развитие.

    К сожалению, в отличие от других форков MySQL, Drizzle, на мой взгляд, так и не смог найти «своего» пользователя. Мне о таких пользователях, а также причинах, по которым Drizzle было отдано предпочтение, не известно.

    Ссылки по теме:

    krow.livejournal.com/700783.html
    en.oreilly.com/mysql2011/public/schedule/detail/17806

    Keynote от Барона Шварца

    Барон Шварц, ведущий архитектор Перкона, мне лично всегда чем-то напоминал протестантского миссионера. Миссионерским по духу был и его доклад, посвящённый будущему СУБД с открытым исходным кодом.

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

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

    Упомянуть этот доклад хотелось бы по одной причине – высказанном тезисе, что реляционная модель данных останется доминирующей в отрасли. Я с этим полностью согласен. Причины моей убеждённости, однако, вполне конкретны, и давно известны — отделение модели данных от их представления, простота, чёткий математический аппарат. Реляционная модель — это и есть тот наибольший общий делитель, объединяющий множество подходов и представлений. Именно эта непревзойденная универсальность позволяет этой модели оставаться актуальной на протяжении 40 лет.

    Доклад также содержал реверанс в сторону Oracle, упоминающий MySQL 5.5 как одно из доказательств того, что Oracle уделяет внимание MySQL. К сожалению, всегда в таких случаях упускается из внимания длина цикла разработки системного программного обеспечения: MySQL 5.5 родился в 2005 году, задолго до того, как приобретение Oracle было в каких-либо планах. Желание поддержать Oracle похвально, но упоминание 5.5 как одного из доказательств намерений Oracle уже набило оскомину.
    Если и стоит благодарить какую-то одну компанию за выход в свет 5.5, так это Sun Microsystems, в которой маркетинговые литавры долгое время успешно заменялись культурой поддержки технологических инноваций.

    en.oreilly.com/mysql2011/public/schedule/detail/17808

    Разговор с Брюсом Момжияном

    Моя первая встреча с Брюсом состоялась в 2004м году, на O'Reilly Open Source Convention в Портланде. Я тогда работал на стенде — общался с пользователям, показывал новые возможности продукта. Брюс подошёл и спросил, когда у нас появятся транзакции :)
    В этом году PostgreSQL и EnterpriseDB приняли активное участие в конференции — пленарный доклад, несколько обычных докладов, огромный стенд на выставке. Помня знакомство, я начал разговор с того, когда же в PostgreSQL, наконец, появится репликация.

    Репликация в PostgreSQL, конечно, есть уже довольно давно, но, что отрадно, с версии 9.0 она включена в сервер. В отличие от MySQL,PostgreSQL не нуждается в дополнительном логе репликации (binary log), а просто пересылает на реплику write ahead log транзакционного хранилища. Это не только позволяет уменьшить объём записи на диск, но и снимает проблему group commit и необходимость поддерживать распределённые транзакции (XA), что долго пытались эффективно реализовать в MySQL.

    Формат репликационного лога в PostgreSQL, таким образом, «физический". т.е. содержит фактические изменения страниц и файлов на диске, без привязки к таблицам и строкам. Это, в свою очередь, позволяет реализовать репликацию в MVCC (управление конкурентным доступом с помощью многоверсионности) окружении без дополнительных блокировок.

    В целом, репликация в PostgreSQL более простая и надёжная, что является как преимуществом, так и недостатком, например, в случаях, когда есть необходимость создавать сложные репликационные топологии.

    developer.postgresql.org/pgdocs/postgres/high-availability.html
    kristiannielsen.livejournal.com/12254.html
    www.theserverside.com/feature/Comparing-MySQL-and-Postgres-90-Replication

    Tungsten replication

    Продолжая тему репликации: интересным оказался доклад от компании Continuent об их продукте для репликации MySQL и PostgreSQL, Tungsten replicator. Tungsten replicator позволяет решать множество проблем, которые возникают при более-менее «нестандартном» использовании
    репликации от MySQL:

    — поддержка global replication id, что существенно упрощает восстановление при отказе одной из реплик
    — multi-source replication — то есть когда одна и та же реплика может получать данные с нескольких
    серверов. Для разрешения конфликтов Tungsten даёт возможность создавать триггеры на Java.
    — более высокая производительность при использовании репликации в несколько потоков (в настоящий момент репликация
    в MySQL всегда выполняется в один поток)
    — возможность задавать произвольные фильтры на события репликации. В MySQL для этого используются переменные
    типа replicate-do-db, replicate-wild-do и т.п.
    — проверка консистентности реплики.

    Справедливости ради надо сказать, что многие возможности репликации MySQL 5.6.2 повторяют Tungsten
    Replicator. С другой стороны, это только подтверждает актуальность реализованных решений.
    На конференции Tungsten Replicator от Continuent получил приз как лучший продукт года.

    tungsten.sourceforge.net/docs/Tungsten-Replicator-Guide/Tungsten-Replicator-Guide.html
    en.oreilly.com/mysql2011/public/schedule/detail/19268

    Доклад Мартена Микоса

    Мартен меня всегда привлекал в первую очередь как докладчик, которого приятно слушать.
    В своём докладе он попытался разобраться, как изменится мир программного обеспечения с развитием облачных вычислений. Основные тезисы этого доклада в следующем:

    — Интернет ждёт дальнейший качественный скачок с увеличением количества пользователей до нескольких миллиардов

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

    — развитие облачной инфраструктуры снимает необходимость в работе над каналами распространения программного обеспечения, такими как дистрибутивы Linux. Необходимость иметь возможность скачать пакет для своей операционной системы уходит на второй план — достаточно просто получить доступ к сервису в облаке. Цитируя Мартена:
    «GPL was about distribution of derivative works. Derivative works still exist, but few companies still distribute them».

    — облачные технологии будут построены на новых хранилищах данных и инфраструктуре, в дополнение к традиционным СУБД

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

    — модель разработки программного обеспечения для Web меняется:
    множество относительно слабых однопроцессорных виртуальных машин в облачной инфраструктуре-- новая платформа
    разработки, даже для изначально небольших сайтов

    en.oreilly.com/mysql2011/public/schedule/detail/17807

    Мой собственный доклад

    Мой доклад был посвящён новой подсистеме блокировок в MySQL 5.5. Тезисы и оценки повторять не буду, доклад полностью доступен в электронном виде, презентацию и текст можно найти в программе конференции и онлайн:

    en.oreilly.com/mysql2011/public/schedule/detail/17340
    www.slideshare.net/kostjaosipov/metadata-locking-in-mysql-55

    Mail.Ru Group

    800,00

    Строим Интернет

    Поделиться публикацией
    Комментарии 12
      +1
      Когда же уже сделают человеческую сборку MySQL в deb пакете с Sphinx и HandlerSocket? А то к Percona не компилится Sphinx, к MariaDB — HandlerSocket, а в Oracle MySQL нет пропатченного InnoDB.
        +2
        Со Sphinx ладно, а вот HandlerSocket надо бы включить…
          0
          Oracle MySQL 5.5 — более чем достойный пропатченный InnoDB. В 5.6 также есть интересные патч для InnoDB.
            0
            Я имел в виду XtraDB. Кстати, расскажите мне как к нему прикомпилить HandlerSocket и SphinxSE. Уже второй день бьюсь, никак не могу собрать. Все мануалы уже изучил.
              0
              Рассказать не получится, могу вместе с Вами попробовать прикрутить. Например на DevConf. Слишком там код быстро меняется, надо по месту понимать что и как патчить.
                0
                Вот это было бы здорово. Пишите в личку, как мы найдёмся там.
                XtraDb — это и есть InnoDb.

                Ну да, но с наложенным набором перконовских патчей, так?
                  0
                  Да. Но 5.5 во многом повторяет эти патчи. В 5.6 есть фичи которые в Percona нет. Форки расходятся.
                    0
                    Вот к 5.5 Sphinx и не компилится. Было бы здорово, если бы вы рассказали, как вы успешно сделали это по шагам. Особенно инетресуют точные номера версий (spninx и mysql) и их исходники, т.к. например исходники sphinx 1.11 для которой у меня есть патч я найти нигде не смог. А на 1.10 он накладывается с 2мя ошибками.
                0
                XtraDb — это и есть InnoDb.
              0
              А расскажите об опыте использования MariaDB, раньше слышал, сейчас почитал — заинтересовало. Она работает с большими BLOB-файлами? И как данная БД чувствует себя при существенной нагрузке в n-ное количество человек?
                0
                MariaDB — это форк MySQL. С большими блобами работает, также как MySQL. При существенной нагрузке в n человек ведёт себя хорошо.
                  –1
                  Я смотрю, и действительно:

                  MariaDB [skynet]> TRUNCATE T1000;
                  Query OK, 0 rows affected (38 min 46.10 sec)

                  Ахуительно! Ахуительно!

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое