Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Мне кажется, критиковать mysql должен человек, который: a) попробовал mysql б) попробовал что-то иное, причем на схожих задачах. А так минусы имеет абсолютно все продукты. Насколько я знаю, репликация — это слабая сторона очень многих популярных СУБД и mysql далеко не на последнем месте
Простите, как Ваше замечание относится к заметке? У некторого подмножества пользователей MySQL/percona/MariaDB, есть ощущение, что «что-то с MySQL не так», и иногда совершенно безосновательное, иногда обоснованное(см. список багфиксов: 1, 2). Мы-же столкнулись с вполне конкретной проблемой, которая как выясняется известна, но не всем. И проблема в самой архитектуре MySQL, и относится она к очень важной функциональности БД, а именно обеспечение консистентности данных. Да, за полтора года, из за этой ошибки мы не смогли восстановить всего одну БД после падения с помощью recovery и пришлость восстанавливать её из бэкапа. Было потеряно примерно 20 часов данных. Если сказать при этом, что «менеджмент был в ярости», то это будет большое преуменьшение, которое цензурным языком не описать.
Немного офтопика.
Я понимаю, что это не ваша разработка, но хочу заметить, или спросить, как по вашему:
А удалять или обновлять данные точно нужно в тех же таблицах, в которые вы их пишите? Если это критичная информация, может быть стоило бы хранить её в виде логов (как минимум), а обработку вести в отдельных таблицах?
Я понимаю, что это не ваша разработка, но хочу заметить, или спросить, как по вашему:
А удалять или обновлять данные точно нужно в тех же таблицах, в которые вы их пишите? Если это критичная информация, может быть стоило бы хранить её в виде логов (как минимум), а обработку вести в отдельных таблицах?
Разработчики ПО, не были дураками. Модель БД хорошая, и отвечает всем требованиям. Если-бы не было вышеуказанной проблемы, о которой разработчики видимо были не в курсе, также как и многие другие, то этой заметки-бы и не было. «Если-бы, да кабы, да во рту росли грибы...»
Самое забавное, что в этой теме массивно плюсуют, оффтопики :) Первый коментарий забавляет особо. Я видимо кому-то на холиварную мозоль наступил.
Самое забавное, что в этой теме массивно плюсуют, оффтопики :) Первый коментарий забавляет особо. Я видимо кому-то на холиварную мозоль наступил.
This is the result of triggers being implemented at MySQL's SQL layer and foreign keys being implemented at the InnoDB Storage Engine level.
Не совсем сначала понял, чем это может грозить, но ниже в статье написано понятнее:
Also, the support of ForeignKeys in MySQL is not yet complete, as cascade actions are not considered as SQL statements and thus do not fire triggers etc
Если, вы прочтёте внимательно, то эти вещи никак не связаны и относятся к совершенно разным проблемам. Тот отрывок который Вы, бессовестно вырвали из контекста относится к поддержке триггеров в движках отличных от InnoDB и NDB.
эти вещи никак не связаны и относятся к совершенно разным проблемамне согласен.
Но вы бы уж тогда пояснили, как связана эта проблема и ваша ошибка:
И тогда не стоит удивляться сообщениям об ошибках вида:
[ERROR] Table ./database/table has no primary key in InnoDB data dictionary, but has one in MySQL!
ЗЫ: по какому принципу вы запятые расставляете?
Самое главное: Mysql как не умел, так и не умеет использовать индексы в средней сложности запросах при сортировке по индексированному так, что бы читать с диска не всю таблицу, а только хвост индекса.
В итоге запросы типа select * from articles where rating > 50 and is_published=1 order by published_at desc limit 40; сортируются на диске.
В итоге запросы типа select * from articles where rating > 50 and is_published=1 order by published_at desc limit 40; сортируются на диске.
Не понял. Если мускл тут будет индекс по рейтингу и is_published использовать — сортировать по-любому. Или вы хотите индекс по published_at использовать?
конечно индекс по published_at. Постгрес в два дискрида всё вынимает, а мускль сортирует.
В последних версиях с этим стало лучше, но иногда приходится использовать вложенные запросы или join таблицы с собой же.
На каждую хитрую гайку можно найти винт… И, к сожалению, нужно.
На каждую хитрую гайку можно найти винт… И, к сожалению, нужно.
Если данное утверждение верно, то буква 'C' из ACID, в нашем случае совершенно не гарантирована.
Верно. Так-как триггеры должны работать с любыми движками в MySQL. Проблема еще в том что какого-то стандарта на что умеет движок нет. Если ориентироваться на MyISAM то все весело и отлично. Он же ничо не умеет :)
Лет 10 назад, когда я только начинал пиликать сайты я попробовал MySql. На работе в то время использовали Sybase — в принципе нормальная, честная, «полная» субд. Кто-то в те же времена пробовал PostgreSQL.
В тоже время по технической необходимости мы слезали с С++ на чистый C.
И, совершенно случайно, выяснилось — без половины «свистелок и перделок» жить можно — чуть более продуманный подход к архитектуре, чуть меньше веры и доверия магиям сторонних компонент, ешелонированный бэкап, надежность топора…
В том числе полностью забили на тригеры — база должна выполнять «сервисные» функции не тогда когда она хочет, а когда мы решили что можно.
В тоже время по технической необходимости мы слезали с С++ на чистый C.
И, совершенно случайно, выяснилось — без половины «свистелок и перделок» жить можно — чуть более продуманный подход к архитектуре, чуть меньше веры и доверия магиям сторонних компонент, ешелонированный бэкап, надежность топора…
В том числе полностью забили на тригеры — база должна выполнять «сервисные» функции не тогда когда она хочет, а когда мы решили что можно.
И опять, комментарий не по теме, и опять заплюсован [здесь смайлик]. Это вирус «четверга» [и здесь].
Почему же не по теме? Разница между С/С++ примерно такая же как между MySQL/Oracle. Но разве С хуже С++? Разве jQuery сильно лучше ванильного JS?
У каждого инструмента есть свои плюсы, свои минусы, свои особенности работы. Не надо просто пытаться сделать из мухи слона, а из мускуля базу данных под ентерпрайз. Смирись %username%, и все получится.
Реально можно подстроится под сложные условия работы, например реализовать двойную буферизацию на уровне таблиц. Логирование, журналирование…
Да — вы это ждете от самой системы, быть может не надо ей так доверять?
У каждого инструмента есть свои плюсы, свои минусы, свои особенности работы. Не надо просто пытаться сделать из мухи слона, а из мускуля базу данных под ентерпрайз. Смирись %username%, и все получится.
Реально можно подстроится под сложные условия работы, например реализовать двойную буферизацию на уровне таблиц. Логирование, журналирование…
Да — вы это ждете от самой системы, быть может не надо ей так доверять?
Очень странная постановка вопроса. У продукта X есть недостаток, поэтому его нельзя использовать. Дак а в остальных как? Может быть там еще хуже. Я вот лично не знаю как с этм делом в Postgres или где-то еще. Что там будет происходить при постаояннх отключениях питания? И похоже что у вас все-таки сильно частная задача, большинство разработчиков базу в таких условиях не экслуатируют.
Я наверное, очень плохо донёс свою мысль в этом топике.
Есть конкретная ситуация, в которой нарушается один из принципов ACID. Для любой РСУБД, подобная ситуация, тем более возникшая из за архитектурных особенностей, это КО.
Есть workaround, по крайней мере для нас: изменить модель данных. Это просто расходы на переработку софта разработчиком. Вопрос чисто финансовый: «Что дороже: целостность данных, или разработка ?»
Однако если Вы поищете, в гугле вот такую строчку:
[ERROR] Table has no primary key in InnoDB data dictionary, but has one in MySQL!
То найдёте ещё 10-к ссылок, на баг этого-же класса, на разных версиях MySQL или percona. (Сразу исключите все ссылки на стандартную ситуацию возникновения этой ошибки: удаление файла из ФС).
Есть конкретная ситуация, в которой нарушается один из принципов ACID. Для любой РСУБД, подобная ситуация, тем более возникшая из за архитектурных особенностей, это КО.
Есть workaround, по крайней мере для нас: изменить модель данных. Это просто расходы на переработку софта разработчиком. Вопрос чисто финансовый: «Что дороже: целостность данных, или разработка ?»
Однако если Вы поищете, в гугле вот такую строчку:
[ERROR] Table has no primary key in InnoDB data dictionary, but has one in MySQL!
То найдёте ещё 10-к ссылок, на баг этого-же класса, на разных версиях MySQL или percona. (Сразу исключите все ссылки на стандартную ситуацию возникновения этой ошибки: удаление файла из ФС).
Без рассмотрения альтернатив это все равно плохой аргумент. «Фатальный недостаток автомобильей марки X — они бьются при врезании в стену на скорости 100 км/ч» ну бьются, ну и что. Остальные чтоли не бьются? Может быть альтерантивы еще в более тепличных условиях ломаются. В данной статье это не рассматривается.
И как я понял, эта штука происходит только при использовании каскадов одновременно с тригерами. Я вот например тригеры не использую, поулчается что у меня эта проблема не проявится, так что для меня это не является существенным аругментом.
И как я понял, эта штука происходит только при использовании каскадов одновременно с тригерами. Я вот например тригеры не использую, поулчается что у меня эта проблема не проявится, так что для меня это не является существенным аругментом.
Хм, это ответ вида — «зачем чинить ручник, я же всегда на скорости оставляю!»
Я разве где-то, что-то с, чем-то сравниваю? У меня альтернативы нет. По крайней мере для этого проекта. На объектах от 6 до 11 миллионов записей, только в исторические таблицы попадает. Терять эти данные никто не позволит.
Да для Вас, в данный момент, это вообще не проблема. А может быть и нет. Всё дело в том, что какие-то вещи в MySQL, обрабатываются на SQL уровне, а какие-то на уровне InnoDB. И что-то, где-то не стыкуется.
Перенос системных таблиц в InnoDB в версии 5.7 это отличный шаг, который кучу проблем с консистентностью репликаций снимет.
Постепенно исправят и эту ошибку. Но на данный момент, в новые проекты MySQL у нас не пойдёт.
Да для Вас, в данный момент, это вообще не проблема. А может быть и нет. Всё дело в том, что какие-то вещи в MySQL, обрабатываются на SQL уровне, а какие-то на уровне InnoDB. И что-то, где-то не стыкуется.
Перенос системных таблиц в InnoDB в версии 5.7 это отличный шаг, который кучу проблем с консистентностью репликаций снимет.
Постепенно исправят и эту ошибку. Но на данный момент, в новые проекты MySQL у нас не пойдёт.
Вставлю свои 5 копеек: в большинстве серьёзных баз, что я видел, одновременно используют и триггеры и каскады. Постгрес, конечно же.
И я скромное имхо добавлю. Много разных баз видел. На разных субд. От богом забытого Informix-a до mssql и oraсle, от firebird до netezza. И в общем случае хочу заметить, что никаких общих случаев нет. Всегда все по разному. Где-то надо одно, где-то другое. В каком-то случае конкретный баг — настолько критичен, что хоть базу меняй. А в другом месте, с ним не столкнутся никогда за все время использования. Но там будут свои грабли.
Конечно это я тут капитанствую, но вывод простой — даже самый маленьки баг может быть кому очень критичен. И наоборот — другой баг казалось бы жесть, как работать вообще можно — а у кого-то даже кейса такого никогда не возникнет за 10 лет использования.
Конечно это я тут капитанствую, но вывод простой — даже самый маленьки баг может быть кому очень критичен. И наоборот — другой баг казалось бы жесть, как работать вообще можно — а у кого-то даже кейса такого никогда не возникнет за 10 лет использования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самый главный аргумент против MySQL?