Просмотров: 39334

MySQL "на стероидах"


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

Сервер реляционной базы данных MySQL (RDBMS MySQL), в короткое время успел стать сверхпопулярной базой данных, а также незаменимой частью современного Интернета, входя в священную связку из «большой четверки» открытых web-технологий LAMP (Linux-Apache-MySQL-PHP), которая и формирует технологически по большей части весь современный Web. Роль баз данных в этой связке, в наш насыщенный информацией век, все более и более приобретает  исключительный характер, и поэтому архитектура современного сайта всегда подразумевает наличие быстрого и гибкого хранилища информации, роль которого в современном интернете в большинстве случаев уготована именно MySQL.

Исторически, первая более-менее работоспособная публичная версия MySQL имела номер 3 и была выпущена в 2000 году. Эту версию можно лишь условно назвать базой данных, — это была скорее лишь заготовка для будущего сервера БД с самой минимальной поддержкой SQL. Затем в 2004 году, после очень продолжительного тестирования и обкатки, зарелизилась очень удачная и хорошо сбалансированная по функционалу и качеству кода версия 4, которая и получила самое широкое распространение в Web-проектах, создав ту самую популярность, которую проект MySQL пожинает и по сей день.

В ней впервые появились объединения, подзапросы, поддержка b- и r-деревьев, короче, тот минимум SQL, который реально позволял использовать MySQL как свободное и эффективное хранилище данных для реальных малых и средних проектов по всему миру. Ровно через год спешно была доработана и выпущена новая версия 5, которая представляет из себя уже вполне законченную и логически зрелую базу данных со всех точек зрения, содержащую в себе такие продвинутые возможности, как например, хранимые процедуры, представления, курсоры, триггеры, транзакции и многое другое. Версия 5.1, вышедшая в 2008 году — это дальнейшая шлифовка той же «пятерки», с добавлением планировщика событий, поддержки плагинов и расширений, хранения логов и статистик сервера в виде таблиц БД и многие другие декоративные изменения-удобства.

По мере прихода известности и начала активного развития проекта, у него стали появляться и серьёзные проблемы, качество разработки только ухудшили многочисленные перепродажи и смены собственника компании-разработчика MySQL AB. Например даже последняя версия MySQL 5.1 содержит ряд серьёзных ошибок, которые хорошо документированы и известны, приводящих к краху сервера или выдаче неверных результатов — их исправление откладывается постоянно на потом, якобы в силу их серьёзной архитектурной природы. Также в новых версиях серьёзно упала производительность по сравнению с версией 4.1, короче, я бы назвал это типичной проблемой роста известного проекта. На этом переходном этапе, когда смелые желания, вскруженные успехом головы, и порождаемые столь быстрым развитием сложные проблемы стали опережать реальные возможности разработчиков, где-то в районе 2008–2009 годов появилось много недовольных вышеописанным положением дел, после чего стали как грибы после дождя появляться альтернативные форки-реинкарнации хорошо известного нам MySQL.

Из множества приведу только один пример, зато самый яркий, — это увольнение самого автора и создателя MySQL Майкла Вайдиниуса (Michael «Monty» Widenius) из Sun, именно из-за причины чрезвычайно некачественного производственного цикла разработки MySQL установленного в стенах Sun Microsystems, когда ещё объективно не готовую программу (кстати, предназначенную для промышленной эксплуатации) административными мерами принуждают релизить к заранее жестко установленным датам, объясняя это какими-то туманными маркетинговыми соображениями. По мнению Майкла Вайдиниуса, разработка также должна вестись в едином открытом пространстве, без разделения исходных текстов на коммерческую и комьюнити ветки, как это сделала Sun. Так, например, в ветке MySQL 5.1 до сих пор не исправлены 20 хорошо известных критических ошибок, приводящих к краху процесса или к искажению данных.

Monty

Майкл Вайдиниус (Michael «Monty» Widenius) — создатель MySQL

 

Число критических ошибок можно смело увеличить еще на 35, если учитывать нерешенные проблемы ветки 5.0, которые, скорее всего, присутствуют и в 5.1. На фоне этого нарастающего бардака терпение Майкла лопнуло и он решил уволиться после того, когда  даже критическая ошибка, связанная со сбоем при изменении первичных ключей в режиме построчной репликации, не остановила Sun от выпуска финального «стабильного» релиза MySQL 5.1. Надо ли говорить, что с переходом MySQL в собственность Oracle, ситуация с разработкой только ещё больше ухудшилась. Все эти чрезвычайно деструктивные тенденции очень сильно подхлестнули  творчество разработчиков этой популярной БД «на стороне», и если посмотреть ретроспективно, то 2008–2009 год — это резкий всплеск создания проектов-форков MySQL, и многие из них, забегая чуть вперед, оказались очень даже перспективными и успешными. Теперь давайте обзорно рассмотрим главные из них на конец 2010 года.

ExtSQL

В развитии разных веток их разработчики пошли разными концептуальными путями. С одной стороны сделана попытка наращивания ещё большей функциональности и добавление множества новых фичей, — например, это проект компании Software Workshop под названием ExtSQL. Проект параллельно ведет две ветви разработки, базирующихся соответственно на кодовой ветке 4-ой и 5-ой версий оригинального MySQL. ExtSQL разрабатывался с сильным уклоном для специализированного использования в системах web-хостинга и призван решить проблемы, связанные с организацией учета потребления ресурсов. Администраторы ExtSQL получают возможность полного мониторинга активности пользователей, всех баз и соединений.

Например, запрос «SHOW STATISTICS select, insert FROM user HISTORY» позволит узнать число запросов «select» и «insert» совершенных пользователями за последний час. Естественно, для этого в бывший MySQL добавлены новые команды и расширен диалект SQL, при этом сохранена полная обратная совместимость с MySQL. Кроме поддержки  своей версии MySQL, организация-разработчик Software Workshop входит в состав технического комитета INCITS H2, участвующего в развитии стандарта SQL, и активно пытается добиться расширения SQL в плане добавления возможностей для учета потребления серверных ресурсов. В целом, если говорить языком цифр, то независимые тестирования показывают, что плата за подобные надстройки над MySQL выражается в потери производительности сервера в среднем на 5% на обычных задачах, и на 15–20% при интенсивной работе с реально большими базами данных. Итак, ExtSQL — это своего рода редакция «MySQL Server Advanced Hoster Edition», для особенно требовательных пользователей СУБД этого класса.

Drizzle

Совершенно противоположной дорогой пошел другой популярный форк MySQL — проект Drizzle. Этот проект основан бывшим директором MySQL по архитектуре Брайаном Эйкером, и представляет собой упрощенный и более быстрый вариант MySQL, в котором тщательно отобраны и удалены все ресурсоемкие и маловостребованные возможности MySQL 5. Часть из этих возможностей всё же возможно реализовать через подключаемые плагины. Эта СУБД  позиционируется как высокоскоростная и высоконадежная БД, с поддержкой ACID-транзакций. В качестве хранилища используется InnoDB и PBXT. Что интересно, что весь сишный исходный код из MySQL был полностью переписан на языке C++. Управление проектом находится в руках независимого сообщества.

В отличие от SQLite, Drizzle не претендует на роль встраиваемого решения и реализован в виде сервера. Архитектура Drizzle построена на основе идеи микро-ядра, исповедует максимальное упрощение структуры БД и вынос логики на сторону приложений. В частности, такой дизайн СУБД позволяет организовать обработку просто ОГРОМНОГО числа параллельных запросов, при выполнении которых  в полной мере задействуются мощности современных многоядерных CPU,  как результат — Drizzl'овские пиковые показатели интенсивности обмена запросами-ответами с web-приложением завесят любой стандартный сервер MySQL 5.1, который просто захлебнётся под такой нагрузкой (тысячи или десятки тысяч сетевых соединений в случае «обычного» MySQL почти гарантированно вызывают проблемы с памятью сервера БД — см. открытые ошибки bug#26590, bug#33948, bug#49169, так что не думайте, что при такой нагрузке достаточно просто обновить железо сервера).

Кроме этого, в Drizzle дополнительно реализованы встроенные средства для разнесения данных по ключевому полю (шардинг) на кластер из нескольких машин, для создания эффективной балансировки нагрузки для по-настоящему сверхнагруженных проектов. По сравнению с MySQL в Drizzle удалена поддержка хранимых процедур (вместо CREATE FUNCTION следует использовать связываемые объекты), триггеров, кэша запросов (query cache), представлений (view), операции GRANT и ALTER, ограничений ACL, команды SHOW, предварительно подготовленных запросов (prepared statement) и др. Прекращена поддержка малоиспользуемых типов данных из MySQL. На вопросы оппонентов, как же можно использовать БД, например, без view'ов, разработчики отвечают в том ключе, что «все те, кому действительно серьёзно нужны view'ы — уже давно сидят на PostgreSQL или Oracle, это же касается и всех других продвинутых фичей».

Да, действительно, для запуска очень многих, например, блоговых движков написанных в связке с MySQL уже под Drizzle — понадобится модификация и некоторый тюнинг кода этих движков, впрочем, как успокаивают разработчики, изменения эти невелики и возможностей Drizzle на самом деле более чем достаточно для полноценного функционирования большинства популярных CMS, тем более что сообщество уже кастомизировало многие известные php-движки под Drizzle, что позволяет показывать их рекордную производительность на том же железе, на котором раньше крутился старый-добрый MySQL. В качестве приятного побочного эффекта, на Drizzle перестали проходить многие популярные разновидности sql-injections для MySQL, так что безопасность стала невольным бонусом этого проекта, попутно демонстрируя нам всем глубокие философские выводы о том, что минимализм есть почти тождество слова безопасность.

SkySQL

Рассмотрев, так сказать крайности, макси- и мини-варианты оригинального MySQL, давайте посмотрим какие есть т.с. более традиционно-классические, продолжения этого известного проекта. На фоне тотального исхода из Oracle разработчиков MySQL (из Oracle добровольно «катапультировалось» уже более 70% оригинальной команды MySQL AB), они, разбредаясь по миру, пытаются как-то заново пристроиться уже под новую историческую эпоху для MySQL.

Так появилась компания SkySQL, основанная уволившимися из Oracle разработчиками MySQL, частично финансируемая несколькими бывшими инвесторами MySQL AB и возглавляемая Ульфом Санбергом, бывшим вице-президентом по предоставлению глобальных сервисов MySQL. Новая компания пока не намерена развивать свой форк MySQL, а займется предоставлением коммерческой технической поддержки, консалтинговых услуг, обучением и продажей готовых решений на базе MySQL. Кроме того, SkySQL занялась выпуском и поддержкой альтернативной промышленной сборки MySQL — SkySQL Enterprise. Продукт распространяется по подписке и снабжен полноценной технической поддержкой (помощь в решении проблем, консультации по настройке, устранение последствий сбоев) и консалтинговым сервисом (планирование внедрения и проведение оптимизации), т.е. фактически полностью перезапустила бизнес своего прототипа, ныне доставшегося Oracle, шведской компании MySQL AB. Так вот, здесь очень интересно, что входит в состав этой самой SkySQL Enterprise? А входит туда, кроме сопутствующих утилит, «прозрачная замена» MySQL — MariaDB Server.

MariaDB Server

Давайте остановимся и зададимся вопросом — что же такое MariaDB Server? Для этого немного откатимся в краткий исторический обзор, чтобы понять, откуда и зачем взялся этот очередной новый форк MySQL. Майкл «Монти», создатель и бессменный лидер проекта СУБД MySQL, покинув в конце 2008 года компанию Sun Microsystems и после прекращении непосредственного участия в разработке MySQL, задумал создать максимально совместимый с MySQL, но идейно новый сервер, базирующийся на принципиально новом движке хранилища данных. Используемое новое хранилище данных  Maria — это устойчивый к сбоям клон MyISAM. Многие специалисты отмечают, что Maria Engine это, как минимум, один из лучших движков для выборки данных, из всех что сейчас существуют, тогда как в классическом MySQL дефолтный MyISAM — её самое слабое место.

В новой компании вместе с Монти над ним работает около 20 сотрудников — бывших разработчиков из MySQL AB, ушедших из Sun вслед за своим идейным лидером. Создатель MySQL заявляет, что MariaDB Server — это максимально точная и совместимая интерфейсная копия SQL используемого в оригинальном MySQL 5, тогда как внутри — он уже во многом превосходит свой протип, давший ему жизнь и стартовую кодовую базу. Более того, Монти заявил, что MariaDB отныне — это единственная официальная версия MySQL, тогда как Oracle MySQL — «is now dead». Самое страшное в этом молодом проекте это то, что многие недовольны женским названием новой БД: ну так одну из дочерей автора MySQL зовут My, а вторую — Maria. Отсюда и названия баз данных. Есть правда ещё один сын, и зовут его, на всякий случай, Макс. И MaxDB уже, кстати, создана, но здесь о ней не будет сказано ни слова.

Таким образом, суммируя, часть разработчиков после ухода из Sun и Oracle осели в компании Monty Program, где день и ночь пилят новый-старый MySQL, но под уже новым названием — MariaDB Server, тогда как вторая часть программистов и сервисного персонала из бывшего MySQL AB — основали  компанию SkySQL по сопровождению и поддержке MariaDB Server. И кстати, по-моему мнению,  MariaDB Server — это самая качественная и сбалансированная замена для MySQL, после того как Oracle его похоронит (а по моему субъективному мнению, ждать этого осталось уже не долго, и первые звоночки как бы даже уже позванивают).

Например, на моем хостинге MariaDB прекрасно работает в связке с PHP5, обслуживая обычные WordPress'ы и прочие популярные движки, для работы с БД настроен обычный PhpMyAdmin, сами пользователи хостинга о существовании такой БД даже и не подозревают, принимая её за всамделишный MySQL. Хотя ради справедливости стоит заметить, что сами разработчики говорят, что расхождение с кодовой базой MySQL уже сейчас достигло примерно 20 процентов, и будет конечно нарастать и дальше. Также мною проверялась работа MariaDB в связке с MySQL Proxy  и специализированным файрволлом для MySQL — GreenSQL: обе софтины работали с MariaDB прямо как с родной MySQL, так что думаю, что как минимум одна достойная и очень перспективная альтернатива для MySQL уже состоялась.

Хочется добавить, что MariaDB Server, также как и Drizzle — очень активно развиваются и эволюционируют, и кроме того, каждый из этих двух проектов очень хорошо смотрится для своих, несколько разных целевых  ниш. И, кстати говоря, буквально на днях, у MariaDB вышел первый официально стабильный релиз за всю её молодую историю, подробности можно почитать тут.

OurDelta

Следующий проект, который мы кратко рассмотрим — это дистрибутивы от проекта OurDelta. На самом деле это популярные ре-сборки двух upstream-проектов: для MySQL 5 поддерживаются два параллельных дистрибутива, это OurDelta и OurDelta-Sail. Если в первый включаются билды собранные с применением к стандартным сырцам MySQL 5 только хорошо протестированной коллекции сторонних «неканонических» патчей, то во вторую, экспериментальную отчасти  ветвь, включается всё самое прогрессивное и максимально свежее что имеется на момент релиза, но, как понятно, часто оно толком ещё не обкатано в реальных условиях как следует, со всеми вытекающими отсюда последствиями.

Кроме этого, OurDelta точно также в параллельной ветке расширяет функциональность и MariaDB 5, которую считает прямым конкурентом и приемником MySQL, но здесь на данный момент есть только одна ветвь сборок — стабильная для MariaDB. Что же это за такие патчи, которыми регулярно потчует нас проект OurDelta?

Основная часть рабочего материала — это адаптация в одну ветвь суммарных наработок проектов MariaDB Server, а также патчсета компании Google, который она развивает для своих собственных нужд, масштабируя и, порой весьма радикально, расширяя функциональность оригинального MySQL. Следующий крупный донор проекта — это патчсеты от Марка Калагхана из Facebook, который ожесточенно «пилит под себя" MySQL для этой компании уже пятый год, ну и также от ряда других компаний, перечислять которые здесь нет смысла, в силу их абсолютной малоизвестности широкому кругу читателей и писателей, навроде меня. Таким образом, проект OurDelta — это своего рода „MySQL/MariaDB на стероидах“, делающий продвинутые накачанные новой функциональностью сборки MySQL/MariaDB на любой цвет и вкус. Хотелось лишь отметить, что в OurDelta очень охотно используют патчи также и от такого самобытного проекта-форка, как Percona, на котором давайте сейчас немного остановимся поподробнее.

Percona

Компания Percona основана в 2008 году двумя отечественными разработчиками, уже бывшими членами MySQL dev.team, Петром Зайцевым и Вадимом Ткаченко. Их БД-сервер основывается на кодовой базе MySQL 5.1, которая дополнена собственными многочисленными, и что хочется отдельно подчеркнуть, весьма качественными патчами, направленными на добавление новой функциональности, повышения стабильности работы и удобства администрирования. Но главная  фича проекта — интеграция собственного движка XtraDB, основанного на коде InnoDB-plugin и полностью совместимого с ним, но отличающегося существенно более высокой производительностью. По умолчанию XtraDB не изменяет дефолтный формат хранения данных в InnoDB. Вы можете прозрачно переключаться между XtraDB и InnoDB по нескольку раз в день.

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

Так вот, в экспертных кулуарах сейчас (на конец 2010 года) как бы считается, что основная острая конкуренция разгорается именно между движками Maria Engine (движок совсем недавно был переименован в Aria) и как раз Percona XtraDB — никаких более продвинутых на данный момент storage engines просто нет в природе, так что старичок MySQL будет потихоньку по-любому сдавать свои позиции на фоне его более активных и озабоченных развитием конкурентов, если конечно Oracle вдруг не опомнится и не станет вкладывать силы/ресурсы в его дальнейшую глубокую разработку.

В дополнение, интересное видео с выступлением по-русски и подробным обзором проекта Percona можно посмотреть здесь с Евгением Степченко.

NoSQL

В заключении хотелось бы сказать, что подбор наиболее подходящей к конкретному техническому заданию модификации MySQL вовсе не ограничивается выбором оптимального дистрибутива и тюнинга его настроек, но также и принципиальным режимом работы самого сервера. В качестве примера приведу недавнюю успешную реализацию подхода NoSQL на базе MySQL-сервера. Yoshinori Matsunobu, автор этого метода и нового плагина HandlerSocket, ещё один бывший участник MySQL dev.team, в своей подробной технической статье  „Использование MySQL в режиме NoSQL — История о том, как достичь обработки 750,000 запросов в секунду“ рассказывает об этой новой методике, а также делится тестами и реальным кодом клиентов, который можно уже прямо сейчас использовать в своих высоконагруженных проектах.

Ну что тут сказать — решение очень красивое, — при этом позволяет гибко переключаться между обычным SQL-синтаксисом из обычных клиентов, так и собственным HandlerSocket-протоколом для переключения в режим сверхвысокой производительности через реализованный в виде плагина NoSQL-режим работы MySQL, и всё это чудо мгновенного преобразования в суперпроизводительную БД — на самом обычном железе! Работая в этом режиме, автор фактически уперся в пропускную способность имеющегося 1Gb канала, так что расти ещё есть куда;-)

Кстати в заключении, уж коль её упомянули, о производительности: здесь можно почитать про реальное сравнительное тестирование некоторых наших героев, — уж как говорится, выводы делайте сами!

Завершая свою обзорную статью о жизненном цикле MySQL, хочется пожелать вам вдумчивого выбора, приемлемых нагрузок на ваших серверах БД, и конечно же всем нам — дальнейшего развития замечательных форков, такое разное множество которых объединяет только одно — общий знатный родитель — замечательная  СУБД MySQL!

 


Важный апдейт статьи: В силу целого ряда причин, мне пришлось её существенно дополнить по просьбе одного издания для её печати, поэтому, чтобы добру не пропадать, а саму заметку не редактировать задним числом (чего я очень не люблю делать), я решил выложить её сильно дополненную, на основе той первой версии статьи, но уже в виде PDF-файла (т.к. информации стало заметней больше, думаю, что так будет просто удобней читать).

Поэтому, все интересующиеся судьбой MySQL и её клонов, могут скачать сей апдейт прямо сейчас.

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , , , , , , , , ,
Эта запись опубликована: Среда, 3 ноября 2010 в рубрике Unix'овое.

комментариев

Следите за комментариями по RSS
  1. Anton Golinko

    Спасибо за развернутый обзор!

  2. Обзор классный!

    С момента публикации ссылки на Хабре количество просмотров заметно увеличилось, но что-то комментариев особо не прибавилось... Тем более странно, что материал очень полезный.

  3. Prekrasnaia statia.

    A to v poslednee vreme otstal ot togo 4to proishodit s MySQL.

  4. СПАСИБО! ОЧЕНЬ качественная обзорная статья по MySQL. Хоть я и сам админ, но узнал для себя много нового - теперь буду копать дальше уже сам и тестить некоторые форки под свой проект. СПАСИБО Игорю!

  5. Андрей Булачев

    Отличный обзор! Автору большое спасибо, за интересную и полезную статью!

  6. Алексей

    Не специалист. Статья понравилась, спасибо.

  7. После такой подробной развёрнутой статьи невольно напрашивается вопрос к разработчикам KDE: когда они откажутся от mysql в своих поделиях (akonadi, digikam, etc)?

  8. Статья интересная. Спасибо.

  9. obzor klass!

    vsegda priatno chitat takie obzori :)

  10. Дмитрий

    Отличный обзор, благобдаря ему я всерьез задумываюсь отказаться от MySQL, честно говоря посматриваю на PostgeSQL и MariaBD

  11. Evgeniy Stepchenko

    То, что Aria и XtraDB конкуренты, не совсем верно. Percona и Monthy Program активно сотрудничают. Aria - замена для MyISAM, XtraDB - развитие InnoDB plugin. Оба движка включены в дистрибутив MariaDB сервер, который, в свою очередь, является развитием и заменой MySQL.

    Так что конкуренция здесь примерно на уровне MyISAM vs InnoDB - оба сосуществуют и каждый выбирает под свои задачи.

  12. Отличный обзор, спасибо :) Надо будет попробовать MariaDB.

  13. Спасибо. Обзор просто замечательный.

  14. Евгений

    Спасибо, прочел с интересом.

  15. Обзор неплох, но в коце не хватает сравнительной таблички в духе Chip. Такая-то CMS, основывается на той-то ветке мускуля, пара ключевых особенностей, зона применения итд )

  16. Максим Щербаков

    Отличная статья! В своем ПРОЕКТЕ, описание которого находится на [URL-вырезано цензурой] я тоже упоминаю об отхождении от мускула к пострескуэлу.

  17. В одном месте собрать все форки мускуля и сравнить их - хорошая работа. Большое спасибо!

  18. А кто нибуть пробовал заменить MySQL на MariaBD в UBUNTU-10.10 как высе работает и

    не возникает ли конфликтов по зависимостям с GNOME и KDE (qt зависит от mysql-client). По моему MariaBD - это именно то, что нужно. А там где нужна обработка

    транзакций, я использую PostgeSQL, так как innoDB все равно ему не конкурент.

  19. Спасибо,

    открыл для себя Drizzle, напомнили про XtraBackup

    Грац!

  20. На мой взгляд несправедливо обделен вниманием перконовский форк XtraDB

  21. замечательная статья, спасибо большое за подробный обзор. к слову действительно большой интерес вызывают NO-SQL key-value движки - для меня право открытием послужила информация об адаптации MySQL командой разработчиков Facebook - почему-то ранее я считал что они пользуються чем-то вроде MemcacheDB.

  22. Андрианов Игорь

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

  23. А куда делся Falcon? Даже был в планах, в 6.0, и какие-то альфа-версии были.. Или XtraDB это оно же, но отделенное от ориг сборки?

  24. Спасибо,

    статья написана безупречно,

    проблему обсудили на новогодней вечеринке,

    мнения разошлись,

    надо подумать.

  25. Хорошая статья у mysql есть будущее не зря Oracle купила Sun Microsystems со всеми её проектами. На счёт PostgreSQL то там нужно по больше поучиться чтобы не делать deadlock - и а то будете сервак постояно перезапускать.

  26. Александр

    Спасибо за хорошую статью. Вот еще немного про планировщик событий: http://plutov.by/post/mysql_event

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз