|
|
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Поигрался с MySQL. Погуглил. В целом за день разобрался с новым SQL-сервером. Но задача у меня несколько критичная. Беспокоит упоминание дедлоков рядом блоггеров. На деле дедлок нормальная проблема и в MS SQL, а большинство блоггеров выдумщики. Поэтому даже ссылок на страхи ахи о погибшем MySQL под горой дедлоков писать не буду. В MS SQL типовые техники защиты от дедлоков. 1) Строго одинаковый порядок вызовов запросов если возможно. В этом случае все встают в очередь и она благополучно разгребается. 2) Упреждающие блокировки. В смысле заблокировать избыточно группу таблицу завесив всех в очередь. И не давая сделать перекрестную блокировку. В некотором плане разновидность п.1 3) Грязное чтение второстепенных таблиц-справочников, чтобы не ставить блокировки через select. Как я понимаю, MySQL даже покруче MS SQL, т.к. можно использовать MyISAM. В этом плане идет грязное чтение без блокировок, а запись всех строит в очередь, но дедлок сделать сложно. Правильно ли я понял, что это и есть основная палка-убивалка для дедлоков в MySQL? Правильно ли я понимаю, что борьба с дедлоками в режиме InnoDB делается также как в MS SQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2013, 03:59:43 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Пруфик по теме http://phpclub.ru/mysql/doc/innodb-deadlocks.html В принципе похоже, на техники для MS SQL. И все же MyISAM мне кажется вообще не дедлочно сделан. Да? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2013, 04:04:50 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2013, 04:15:42 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUИ все же MyISAM мне кажется вообще не дедлочно сделан. Да?Ну да, в некотором смысле это так... Вообще-то он сделан без транзакций, а уж "не дедлочно" - это побочный эффект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2013, 11:05:12 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
авторКак я понимаю, MySQL даже покруче MS SQL, т.к. можно использовать MyISAM жжошь. нетранзакционный движок, с только табличными блокировками, без внешних ключей, etc - и вдруг круче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2013, 11:53:04 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Есть задачи где транзакции не являются добром, я являются злом. Даже в MS SQL традиционно девелопер кучу справочных таблиц вызывает через nolock. Потом есть целый ряд данных по-сути read only, для них транзакции не нужны. Также могут применяться различные репликационные системы или криптографические механизмы как в моем случае. Мне тут транзакции нужны только в некоторых табличках статусов в остальных случаях это просто нагрузка на сервер. Поизучав MySQL, хочу отметить, что для облачных решений он продуман намного лучше чем MS SQL именно в этой области управляемых транзанкционных уровней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2013, 00:24:15 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUМне тут транзакции нужны только в некоторых табличках статусов в остальных случаях это просто нагрузка на сервер.Между движками разница не только в транзакционности, но в множестве других вещей, которые тоже могут влиять на производительность. Так что не факт, что нетранзакционный MyISAM всегда будет быстрее транзакционного InnoDB. MicrosoftProjectRUПоизучав MySQL, хочу отметить, что для облачных решений он продуман намного лучше чем MS SQL именно в этой области управляемых транзанкционных уровней.Ну да, вот так и рождаются мифы. Во-первых, в MySQL в этом плане мало что изменилось с тех пор, как слово "облачные решения" вошло в моду. И, как следствие, он не "продуман для облачных решений". Во-вторых, можете пояснить, чего ж такого нет в MS SQL в "области управляемых транзанкционных уровней" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:48:54 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
авторТак что не факт, что нетранзакционный MyISAM всегда будет быстрее транзакционного InnoDB. http://www.mysqlperformanceblog.com/2013/05/22/mysql-and-the-ssb-part-2-myisam-vs-innodb-low-concurrency/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:25:44 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
В Инете довольного много споров по этой теме. Но мне кажется большинство приходит примерно к такому выводу. http://www.handybackup.net/backup_terms/mysqldump.shtml В чем лучше MySQL чем MS SQL для облака? В облаке есть специфические задачи по сценариям работы. Особенно если облака не те что вы видите, а те что будут. Например с кринтографией в базах, когда отдельные записи поля в записях по-сути зашированные AES блобы. Для таких задач MyISAM самое то. Я конечно потестирую, но мне кажется его обогнать будет тут сложно. Облаков с криптографией сейчас будет много, т.к. основная проблема облака это SECURITY. Применение криптографии сразу же ограничивает свободу SQL-запросов. Потом надо постестить конечно, но MS SQL очень сильный сервер в чтении , но запись его слабое место. И по скорости по дедлокам. Поэтому многие облачные вендоры даже когда пишут App Server на Microsoft .Net ставят Oracle DB. Мне кажется MySQL слабее MS SQL в сложных запросах, но думаю в сценариях с интенсивным линейным чтением/записью быстрее и надежнее. Однако как я отметил, при условии что часть базы зашифрована некоторые сложные SQL-запросы просто невозможны. Как я отметил, если сайт не открытка "купи наши мусорные бачки", а с данными бизнеса, только очень чокнутый клиент потащит в облако данные без шифрования. Они могут передать данные, но зашировав и оставив ключи AES у себя. Гибридный клауд. И мне кажется, тот MyISAM самое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:48:45 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUПоигрался с MySQL. Погуглил. В целом за день разобрался с новым SQL-сервером. Но задача у меня несколько критичная. Беспокоит упоминание дедлоков рядом блоггеров. На деле дедлок нормальная проблема и в MS SQL, а большинство блоггеров выдумщики. Поэтому даже ссылок на страхи ахи о погибшем MySQL под горой дедлоков писать не буду. В MS SQL типовые техники защиты от дедлоков. 1) Строго одинаковый порядок вызовов запросов если возможно. В этом случае все встают в очередь и она благополучно разгребается. 2) Упреждающие блокировки. В смысле заблокировать избыточно группу таблицу завесив всех в очередь. И не давая сделать перекрестную блокировку. В некотором плане разновидность п.1 3) Грязное чтение второстепенных таблиц-справочников, чтобы не ставить блокировки через select. Собственно, всё то же самое ты можешь применять и в MySQL. Единственно, что на InnoDB грязное чтение не нужно, там snapshot isolation без SHARED блокировок при чтении данных. Т.е. третий пункт можно выкинуть, для Inno он не нужен, а для MyISAM он бессмысленен, там всё чтение -- грязное. MicrosoftProjectRUКак я понимаю, MySQL даже покруче MS SQL, т.к. можно использовать MyISAM. В этом плане идет грязное чтение без блокировок, а запись всех строит в очередь, но дедлок сделать сложно. Правильно ли я понял, что это и есть основная палка-убивалка для дедлоков в MySQL? Нет. палок вообще много и всё зависит от конкретной ситуации, по кому этой палкой бить. Также не понятно, чем "MySQL даже покруче MS SQL," поскольку snapshot isolation есть и в MSSQL. Ну и на счёт "покруче" -- то ещё предположение, этот MyISAM как данные блокирует -- вообще не понятно, как ему захочится. Я лично даже предположить не могу, я никогда это чудо не использовал и не собираюсь. MicrosoftProjectRUПравильно ли я понимаю, что борьба с дедлоками в режиме InnoDB делается также как в MS SQL? В общем, да, с учетом того, что я уже написал выше. Только помни, что дефолтный уровень изоляции в Inno -- ANSI repeatable read (но на самом деле это не он, а snapshot) и что в INNO дедлоки разрешаются по таймаутам (на сколько я помню), а не по графам, как в MSSQL, так что графов в логе у тебя не будет, будет только ошибка UPDATE/DELETE типа 'deadlock or timeout' и ты в принципе его даже от таймаута не отличишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 15:32:58 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
авторЕсть задачи где транзакции не являются добром, я являются злом. Нет таких задач. Т.е. если такие задачи есть -- это не задачи, а имитация бурной деятельности. авторДаже в MS SQL традиционно девелопер кучу справочных таблиц вызывает через nolock. 95% людей -- идиоты. авторПотом есть целый ряд данных по-сути read only, для них транзакции не нужны. Также могут применяться различные репликационные системы или криптографические механизмы как в моем случае. Мне тут транзакции нужны только в некоторых табличках статусов в остальных случаях это просто нагрузка на сервер. read-only транзакция в любой СУБД будет read-only и лёгкой. авторПоизучав MySQL, хочу отметить, что для облачных решений он продуман намного лучше чем MS SQL именно в этой области управляемых транзанкционных уровней. MySQL -- кусок говна, который существует по одной только причине -- в инете полно говна, которое нужно где-то хранить. И людям, которые это говно хранят, наплевать, если оно вдруг куда-то пропадет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 15:36:47 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
авторкоторый существует по одной только причине nosql существуют потому что людям еще более наплевать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 15:40:24 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MasterZivMySQL -- кусок говна, который существует по одной только причине -- в инете полно говна, которое нужно где-то хранить. И людям, которые это говно хранят, наплевать, если оно вдруг куда-то пропадет. неее, mysql - это понос! быстрый и резкий. Определенно, в вебе усредненная ценность информации ниже чем в банковском бизнесе. Но разве это мешает зарабатывать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 16:03:04 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
В современной среде транзакции не так уж и дороги, чтобы ими пренебрегать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 16:54:00 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MasterZiv, не пойму, современные люди перестали экономить и думать ? или что? зачем им отказываться от большей плотности и большей выгоды ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 17:08:12 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Почему вы реагируете на троля, который вероятно помощник держателя опахало над сисадмином ООО "Офигевшая Редиска"? :) На деле я думаю народ просто шизанутый на транзакционной целостности считая, что это "серебрянная пуля". Вон у меня как раз кусок говна MS Project Server. Уже 10 лет нестабильный софт, включая потери данные и зависания. Зато траааанзаааациии. На деле если разобраться что вышло. Усложнением логики сервера не очень опытные девелоперы MS стали лепить ad hoc запросы в SP не соблюдая порядки обхода таблиц. На деле так делает 95% девелоперов. Типа SQL сервер он же МАХИНА, как-то там вытянет. Не вытянул. Стали ставить блокировки. Самостийная очередь самого MS SQL неуправляемая. Поэтому опять дедлоки. Поэтому следущий шаг очевидный - ручная очередь в App Server без паралелизма MS SQL. Но если руки ростут из попы и девелопер уверует Истинному Господу Транзакции, то очень быстро Диавол Дедлока по мордам надет. Что дальше с MS Project Server? Хотя сделали очередь, все равно дедлоки. На лекциях для студентов любят рассказывать о дедлоках 2х пользователей. Но как-то професуре и начинающим девелоперам неведомо, то и 1н пользователь может сделать дедлок, если выпендрится посильней. Что дальше? А вот что. Поскольку сохранение данных (проектов) тоже в очереди, то срезание дедлоком очереди вообще-то срезает процесс сохранения или если он разбит на несколько транзаций для облегчения нагрузки возможна порча данных . Вот и надавал MS SQL школьничкам-студентам, которых нанял MS по мордам. Вопли на моем форуме. Ай-ай зависло. Ай-ай не сохраняется. Ай-ай испортился проект. Почитайте на досуге. microsoftproject.ru/forum/ Это все расплата за идиота, который решил транзакция серебряная пуля и решение всех проблем с надежностью. На деле проблема целостности данных, как я уже отметил выше, при использовании криптографии и кешей App Server и мобильных клиентов (особенно современных версий их с сохранением, сообенно offline кешей с редактированием) далеко не однозначна. Для начала SQL-сервер может не иметь вообще актуальной версии данных, ей может обладать клиент или App Server в кеше некоторое время. Я думаю тут лучше разблокировать все по максимум и иметь какую-то таблицу CheckPoints на транзациях, т.е. если App Server все же записал все как надо, то просто ставить чекпоинт. Нет - так можно еще раз записать. Считайте это кастомным rollback и commit. По секрету расскажу что общаясь с разработчиками MS SQL в штаб-квартире Microsoft я много раз слышал, что примерно такой же алгоритм и внутри MS SQL вокруг транзакций. Все гораздо проще и сложнее. Но серебрянной пули нет. Транзакция в современных системах не обеспечивает надежность в том числе по целостности данных. Живой пример прострелляного MS Project Server перед глазами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 19:59:12 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRU, Вон у меня как раз кусок говна MS Project Server. Уже 10 лет нестабильный софт, включая потери данные и зависания. Зато траааанзаааациии. Ms project — не субд, откуда там транзакции? А так, да, удивительно фиговый продукт, согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 21:21:33 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRU, Мужик, ты чего, бредишь? Или обкурился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 21:24:09 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Я вам просто говорю к чему привела тупая вера в транзакционную модель самый навороченный App Server в семействе SharePoint. Через 1 день (!!!) Microsoft был вынужден с позором снять MS Project Online из свободного демо-доступа, т.к. эти ненормальные в Редмонде еще решили выставить ЭТО на мультиcайтовый хостинг. Конечно ферма сдохла от нагрузки за сутки. Тут понятно детские ошибки. Экономия MS взять студней в разработку боком и вышла. Но если задуматься, то даже если предположить, что даже если бы сделали все нормально, то возникла бы проблема аля-Сноуден. А как насчет PRISM? А Canivore? А NarusInsight? Доверие корпоратива подорвано даже к Microsoft, не говоря уже о маленьких вендорах. Выход есть - КРИПТОГРАФИЯ. Тем более что развитие мобильных устройств подразумевает толстые клиенты и там можно хранить ключи и расшифровать данные. Но криптография в базе все меняет. Там даже модель целостности данных другая. Вон Lotus Domino как-то 25 лет хранит самые критичные данные Пентагона как снести полпланеты и как-то без SQL-транзакций обходится. На деле криптография имеет встроенные проверки целостности аля-CRC внутри себя. Там целый свой мир. Я думаю в базах которые будут сейчас названия точно будут шифроваться почти везде, но в реале даже целые структуры данных будут широваться, чтобы частотным анализом не выявить что за X получил 1 млн. долларов. Я сейчас приглядываюсь к MySQL потому, что в криптографических базах другие правила игры. Потом ФСТЭК сертифицировало на гостайну MySQL и PostgreeSQL (он правда постарше на 1Б). А вот MS SQL и Oracle нервно курят в сторонке без сертификатов допуска. Ибо нефиг ЦРУшникам бекдоры лепить в нагляк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 21:33:55 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUКак я понимаю, MySQL даже покруче MS SQL, т.к. можно использовать MyISAM. В этом плане идет грязное чтение без блокировок, а запись всех строит в очередь, но дедлок сделать сложно. Правильно ли я понял, что это и есть основная палка-убивалка для дедлоков в MySQL?Глупость какая... В MS SQL тоже можно использовать грязное чтение. Дедлоки - это следствие реализации бизнес-логики, а не следствие низкой квалификации программистов, писавших код движка СУБД, и могут происходить в любых системах, а не только в СУБД, хоть при обращении к драйверам устройств. Печально было бы, если бы в MySQL такую бизнес-логику реализовать нельзя (во что я конечно не верю, не настолько он плох). Думаю, ваше ошибочное мнение истекает из этого: MicrosoftProjectRUВ целом за день разобралсяЧерез годик заходите, поговорим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 22:45:49 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
Коллега, вот как вы можете доказать свою экспертизу кроме как 18000 сообщений? Форумный флуд не метод доказательства экспертности, а метод времяпрепровождения. Причем иногда в рабочее время. Поэтому если последнее предположение верное следует отметить глупость вашего шефа, которые не следить как тратяться оплаченные им рабочие часы. Я же вот сделал целый портфель проектов от Газпром-Нефти до порта Усть-Луга. Некоторые решения будут долго крупнейшие в своем классе в Восточной Европе. На деле это осуждение показывает, что экспертиза на IT-рынке недостаточная и форумная популярность некоторая разновидность рекламы по продаже себя любимого, а не экспертный обмен мнениями. Мне это лично не нужно, я покупаю траффик у Google до миллиона визитов в месяц. На деле когда начинаешь копаться, то выясняется что за "экспертами", которые вроде бы "собаки съели" все надо проверять. Вон смотрите как тут "глуподеклараторы" плавают в показания. Я неписал про nolock. Один "эксперт" сразу придал анафеме, потому пришел другой и уже грязное чтение отлично. Причем абсолютно бездоказательно. Ни на уровне тестов, ни на уровне кейсов. Я могу сказать итог обсуждения на в этом топике. Я сегодня уволил одного "форумного эксперта" в MySQL и передал работу другому специалисту, которые не пиарится, а просто делает свою работу. Просто за всем пиаром вдруг выяснилось, что "эксперт" не в курсе отличий MyISAM и InnoDB, а также смутно представляет типовые архитектурные решения по защите от deadlocks. Хабру, пописюкать, почитать так легко. Почитать документацию и еще лучше сделать тесты не барское дело видите ли. Ладно пойду планировать рефакторинг за "гением". Хорошо хоть заметит его форумные развлекушки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 23:45:12 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUКоллега, вот как вы можете доказать свою экспертизу кроме как 18000 сообщений?На работе - проектами, а тут - содержанием своих постов. Большое количество постов получается просто из за большого стажа (я тут на форуме тусуюсь в 10 раз дольше вас). И пишу сюда не для подтверждения экспертизы, а потому что мне интересно помогать людям и хочется учиться у других, как бы критику по техническим вопросам я воспринимаю с благодарностью, как возможность на халяву поучиться. И от вас бы так воспринял, если бы вы были со мной не согласны в чём то, а не начали бы писать про стаж и оценивать ум моего шефа. Вот ваш последний пост что доказывает? Вы по сути утверждаете, что если у вас есть право уволить или нанять сотрудника, то вы априори лучше разбираетесь в теории СУБД? На форуме это не прокатит, вы же тут никого не можете уволить (а некоторые участники форума могут уволить отсюда вас, к слову :-) ). Так что старатесь доказывать свою экспертизу содержанием своих постов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 00:01:21 |
|
||
|
Техника защиты от deadlocks в MySQL
|
|||
|---|---|---|---|
|
#18+
MicrosoftProjectRUКоллега, вот как вы можете доказать свою экспертизу кроме как 18000 сообщений?Увы, Вы не можете доказать свою экспертизу даже этим. MicrosoftProjectRU Я же вот сделал целый портфель проектов от Газпром-Нефти до порта Усть-Луга. Некоторые решения будут долго крупнейшие в своем классе в Восточной Европе. На деле это осуждение показывает, что экспертиза на IT-рынке недостаточная и форумная популярность некоторая разновидность рекламы по продаже себя любимого, а не экспертный обмен мнениями. Мне это лично не нужно, я покупаю траффик у Google до миллиона визитов в месяц.Вы сами себе противоречите. Единственный, кто здесь рекламирует себя - это Вы. MicrosoftProjectRUНа деле когда начинаешь копаться, то выясняется что за "экспертами", которые вроде бы "собаки съели" все надо проверять.Вы второй такой "эксперт", которого я встречаю за последнее время. (Кто первый - не скажу, но в этом топике он участие не принимал). MicrosoftProjectRUВон смотрите как тут "глуподеклараторы" плавают в показания. Я неписал про nolock. Один "эксперт" сразу придал анафеме, потому пришел другой и уже грязное чтение отлично. Причем абсолютно бездоказательно. Ни на уровне тестов, ни на уровне кейсов.Ваши речи не в меньшей степени бездоказательны. MicrosoftProjectRUЯ могу сказать итог обсуждения на в этом топике. Я сегодня уволил одного "форумного эксперта" в MySQL и передал работу другому специалисту, которые не пиарится, а просто делает свою работу.А, так Вы - менеджер? Так бы сразу и сказали, а то мы тут и правда можем подумать, что со специалистом общаемся. (Ни в коей мере не хочу сказать, что Вы плохой менеджер). Поскольку топик в свое, заданное темой, русло так и не вошел - закрываю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 00:08:45 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38337718&tid=1836410]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 352ms |

| 0 / 0 |
