LINUX.ORG.RU

Встреча с разработчиком MySQL Дмитрием Леневым

 ,


1

2

В субботу, 17 ноября, в петербургском офисе компании Oracle состоится встреча сообщества CodeFreeze с Дмитрием Леневым — разработчиком MySQL Server. Доклад Дмитрия охватывает ряд архитектурных и организационных проблем, которые возникали в процессе разработки MySQL Server. Будут рассмотрены пути, которыми они решались, а также влияние, оказанное выбором того или иного пути решения, на дальнейшее развитие сервера. В частности, речь пойдёт о том, как в MySQL добавляли транзакции, как менялся цикл разработки продукта и как развивали подсистему диагностики.

Участие бесплатное! Зарегистрироваться и посмотреть подробности можно здесь.

★★★☆☆

Проверено: Shaman007 ()

В частности, речь пойдёт о том, как в MySQL добавляли транзакции

через одно место, вестимо, даже SQLite умеет DDL в транзакциях, а MySQL - нет

wota ★★ ()
Ответ на: комментарий от wota

DDL в транзакциях

Это шутка? Такое даже быдлокодом не назовешь, скорее анацефалокодом.

anonymous ()
Ответ на: комментарий от anonymous

Это шутка? Такое даже быдлокодом не назовешь, скорее анацефалокодом.

можешь смело направить свое обращение разработикам оф. гуя под MySQL - MySQL Workbench, который при синхронизации модели на половине выдает ошибку и оставляет БД в сломанном состоянии

П.С. проверял ес-но на тестовом сервере, MySQL вообще не пользуюсь

wota ★★ ()

Мальчика в инвалидном кресле возьмите.

cipher ★★★★★ ()
Ответ на: комментарий от wota

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

anonymous ()
Ответ на: комментарий от anonymous

«Разработчик, программирующий с помощью мышки, разработчиком не является, пора бы это уже запомнить. »

Правильно, тру-разработчики пишут программы ручкой на листах бумаги. PS С каких это пор дебилоиды считают, что форма разработки важнее результата?

anonymous ()
Ответ на: комментарий от anonymous

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

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

wota ★★ ()

Лучшая информация о MySQL это инструкция по переходу на Postgresql.

Alve ★★★★★ ()
Ответ на: комментарий от wota

Транзакции нужны только для данных. Если не можешь определиться со схемой хранения данных - бери MongoDB, там с таким быдлоархитектом гораздо лояльнее.

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

anonymous ()
Ответ на: комментарий от anonymous

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

В квотезы!

encyrtid ★★★★★ ()
Ответ на: комментарий от anonymous

Если не можешь определиться со схемой хранения данных

и еще один теоретик, который умеет быдлоархитектить продумать БД из сотен таблиц на годы вперед

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

тебе виднее

wota ★★ ()
Ответ на: комментарий от wota

и еще один теоретик, который умеет быдлоархитектить продумать БД из сотен таблиц на годы вперед

Я не спорю, есть задачи, в которых довольно часто надо допиливать схему данных. Но изменения должны быть инкрементальными - и транзакции тут лишний оверхед.

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

anonymous ()
Ответ на: комментарий от anonymous

Но изменения должны быть инкрементальными - и транзакции тут лишний оверхед.

согласен, их тоже надо далеко не всегда применять

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

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

wota ★★ ()
Ответ на: комментарий от wota

С такими ломающими изменениями схемы все делается гораздо проще. Либо пользователи вышибаются/изолируются в «плановый перерыв», либо нужно идти в обход - вместо переименования поля заводить новое, создавать версионные вьюшки и т.д. А насчет частного случая - при разработке СУБД нужно предусмотреть ВСЕ частные и граничные случаи. И весь этот гемоорой ты предлагаешь ради того, чтобы не ломалось непроверенное на тестовом сервере обновление? Разработчик тоже не желает бежать за негром, ловить его и вдувать обратно, у него есть более важные цели.

anonymous ()

когда у них появится мулти-мастер репликация официально

argin ★★★★★ ()
Ответ на: комментарий от anonymous

Либо пользователи вышибаются/изолируются в «плановый перерыв»,

главное, чтоб он не затянулся, если вдруг во время обновления что-то пошло не так

либо нужно идти в обход - вместо переименования поля заводить новое

создание нового поля и копирование всех данных - отличный повод поставить раком СУБД (с)

И весь этот гемоорой ты предлагаешь ради того, чтобы не ломалось непроверенное на тестовом сервере обновление?

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

wota ★★ ()
Ответ на: комментарий от wota

создание нового поля и копирование всех данных - отличный повод поставить раком СУБД (с)

Ты думаешь, в транзакции это не будет делаться, да? У меня для тебя плохие новости.

уже повод обломаться на униках, например, или на блокировках

«облом на униках» == «я тупой долбоёб, который при обновлении не делает предварительных проверок на коллизии». А боишься блокировок - вышибай пользователей или принудительно лочь все объекты.

100% гарантии на успешное применение изменений ни у кого нет

Ну так транзакции тебя при этом точно не спасут, а уж как они усложнят СУБД и затянут сами DDL, похоже, тебе вряд ли объяснишь.

anonymous ()

кто пойдёт, спросите у него, почему не работают check constraints?

ukr_unix_user ★★★ ()
Ответ на: комментарий от anonymous

Ты думаешь, в транзакции это не будет делаться, да? У меня для тебя плохие новости.

не будет, в WAL или журнал лягут только данные о таблице, но не из нее

«облом на униках» == «я тупой долбоёб, который при обновлении не делает предварительных проверок на коллизии»

создание уника подразумевает проверку, нет смысла ее делать вручную

уж как они усложнят СУБД

да, усложнят, особенно если говорить про вложенные транзакции, но в том же postgres, например, разработчики позаботились об реализации, они вообще намного больше о чем позаботились

и затянут сами DDL

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

wota ★★ ()
Ответ на: комментарий от wota

не будет, в WAL или журнал лягут только данные о таблице, но не из нее

и при смене типа поля?

создание уника подразумевает проверку, нет смысла ее делать вручную

хочешь, чтобы обновление выполнилось консистентно, а не прерывалось посередине - сначала все проверь и не начинай, если есть проблемы.

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

Ага, и сделать этакую ограниченную транзакционность, которую можно будет применять только при сферическо-вакуумных условиях. И что делать, если в эту транзакцию врезается нетранзакционная команда? Правильно - коммитить. В лес.

anonymous ()
Ответ на: комментарий от anonymous

И что делать, если в эту транзакцию врезается нетранзакционная команда?

проверить код запроса на наличие нетранзакционных команд и отказаться выполнять?

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

стиви, лежи и не рипайся. А если этот SQL с терминала идет построчно? Да и смысла тогда в такой транзакции мало - обновление точно так же упадет, как если без транзакций.

anonymous ()
Ответ на: комментарий от anonymous

А если этот SQL с терминала идет построчно?

в интерактивном режиме? Тогда спрашиваем: или ролбэк, или не было. Ничего не упадет, потому что ролбэк, на то и транзакция. Смысл в том, чтобы пользователи не заметили, что ведутся какие-то там технические работы.

stevejobs ★★★☆☆ ()
Ответ на: комментарий от anonymous

и при смене типа поля?

уже писал

хочешь, чтобы обновление выполнилось консистентно, а не прерывалось посередине - сначала все проверь и не начинай, если есть проблемы.

ок, я mysql почти не знаю, но спрошу - есть таблица T1, в ней PK - f1, нужно создать T2 с FK на T1, простейший случай, что мне надо проверить?

Ага, и сделать этакую ограниченную транзакционность, которую можно будет применять только при сферическо-вакуумных условиях. И что делать, если в эту транзакцию врезается нетранзакционная команда? Правильно - коммитить.

я уже приводил примеры связанных изменений, которые легко ложатся на отдельные транзакции, назови свой пример, где «в транзакцию врезается нетранзакционная команда», тогда можно будет говорить об уместности применения этих изменений вместе

wota ★★ ()
Ответ на: комментарий от anonymous

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

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

mashina ★★★★★ ()
Ответ на: комментарий от anonymous

Либо пользователи вышибаются/изолируются в «плановый перерыв», либо нужно идти в обход - вместо переименования поля заводить новое, создавать версионные вьюшки и т.д.

А вот в постгресе это почему-то не нужно. Можно все просто завернуть в транзакцию. Наверное, разработчики постгреса тупые, великого DBA всея Руси Анонимуса не читали, что надо через жопу делать, и сделали нормально. На кол их, еретиков!

shimon ★★★★★ ()
Ответ на: комментарий от anonymous

предварительных проверок на коллизии

Между проверкой и изменением проходит ненулевое время, дурачина. Race condition — слыхал, есть зверь такой?

shimon ★★★★★ ()
Ответ на: комментарий от shimon

Между проверкой и изменением проходит ненулевое время, дурачина. Race condition — слыхал, есть зверь такой?

Есть еще один зверь - Global table lock. В этом случае становится пофиг и на «ненулевое время», и на возгласы людей с собакой-алкашом на аватаре.

anonymous ()
Ответ на: комментарий от wota

есть таблица T1, в ней PK - f1, нужно создать T2 с FK на T1, простейший случай, что мне надо проверить?

Для собственно создания таблицы - ничего не надо, создастся и так. А вставка новых данных будет завязана на PK f1 и замечательно ляжет в транзакцию.

назови свой пример, где «в транзакцию врезается нетранзакционная команда», тогда можно будет говорить об уместности применения этих изменений вместе

Ты говоришь, что на многих операциях будет слишком большой оверхед => подразумеваешь, что не все команды должны быть транзакционными. Ну и сделай выводы сам.

anonymous ()
Ответ на: комментарий от anonymous

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

shimon ★★★★★ ()
Ответ на: комментарий от anonymous

Для собственно создания таблицы - ничего не надо

как минимум надо проверить какой engine у T1

Ты говоришь, что на многих операциях будет слишком большой оверхед => подразумеваешь, что не все команды должны быть транзакционными. Ну и сделай выводы сам.

большой объем данных - всегда ограничение, которое очень часто вносит свои коррективы в самые разные аспекты работы с СУБД, на небольших объемах - исключения делать не надо

wota ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.