Комментарии 18
Такой сложный вопрос: а зачем вообще MySQL использовать? Да, база развивается, но ее безмерно тупой оптимизатор таковым и остается. Да и собственно как ушел с нее так и не смог за последние лет 8 придумать ни одной причины в ее пользу. Как один человек очень точно сказал: «PG это база данных, а MySQL — хрен с гвоздями», грубовато — но очень точно.
Некоторые/многие вещи делать проще и удобнее в MySQL, чем в PG.
Поэтому разводить целый PG ради бложика на 3 таблички просто-напросто нецелесообразно и неудобно.
Так же, как утверждать «БелАЗ — это машина, а Reno Logan — это хрень с гайками».
Так-то на стоянках возле гипермаркетов БелАЗов не сильно много.
Поэтому разводить целый PG ради бложика на 3 таблички просто-напросто нецелесообразно и неудобно.
Так же, как утверждать «БелАЗ — это машина, а Reno Logan — это хрень с гайками».
Так-то на стоянках возле гипермаркетов БелАЗов не сильно много.
То есть аргументов не будет? Всегда так приятно побеседовать с коллегами)
Когда говорят, что Postgres крут, это говорят с точки зрения программиста или DBA? Если с точки зрения программиста, то да, там фич значительно больше. Но вот с точки зрения DBA — postgres явно не лучше.
1) Репликация.
Чего стоит мучительная репликация, которая в mysql появилась, лет, наверное 10 назад, причём не тупо «всё реплицировать», а выбирать, какие базы, таблицы. Да, в postgres'e были всякие костыли типа slony, и даже в 9-ке появилась родная binary-репликация (и да, всё так же «все реплицировать») в одну сторону (на тот момент в mysql уже давно была master-master). Вроде бы в 10-ке появилась logical, где уже можно выбирать, что реплицировать. Да, это прорыв, но почему так поздно? С тех пор я перестал следить за PQ. Я не знаю, может в 12 появилась уже master-master репликация, тогда шансы уровнялись в этой части. А может PQ умеет реплицироваться сразу с нескольких источников? mysql такое умеет, как минимум года 3.
2) upgrade с версии на версию.
Это страшный сон всех PQ DBA, даже если версии минорные, особенно, если у тебя есть custom'ные exten'ы. Ну вот нельзя просто поставить новую версию, запустить скрипт upgrad'a и всё. И это mysql умеет очень давно. Но PQ до 9.Х включительно не имел такого инструмента. Как дела в PQ в 12-ой версии — я не знаю, возможно, спустя много лет, что-то появилось.
3) recovery table
Если таблица очень большая и дамп по каким-то причинам долго переносить/делать, то можно с рабочего сервера сделать копию файла ibd (если InnoDB) потом через DISCARD/IMPORT можно «подключить» таблицу в работающую базу. Тут успех, где-то 70%, но всё-равно не малый.
4) 32-ух битный номер транзакций. Это боль для высоконагруженных БД. Такое случается очень редко, но когда случилось — это катастрофа. Как чинить — непонятно (была статья на хабре, где писали за деньги патч под это дело). Вроде бы в 10 или 11 он уже 64-их битный, но что делать было раньше? Надеятся, что ты никогда с таким не столкнёшься?
Это самые большие проблемы, с которыми приходилось мириться (и надеятся, что они никогда не настанут) и мы перешли на mysql. Были ещё мелкие недочёты, но они несущественны.
Вы могли бы мне назвать причины, в чём PQ лучше MY, как для DBA?
1) Репликация.
Чего стоит мучительная репликация, которая в mysql появилась, лет, наверное 10 назад, причём не тупо «всё реплицировать», а выбирать, какие базы, таблицы. Да, в postgres'e были всякие костыли типа slony, и даже в 9-ке появилась родная binary-репликация (и да, всё так же «все реплицировать») в одну сторону (на тот момент в mysql уже давно была master-master). Вроде бы в 10-ке появилась logical, где уже можно выбирать, что реплицировать. Да, это прорыв, но почему так поздно? С тех пор я перестал следить за PQ. Я не знаю, может в 12 появилась уже master-master репликация, тогда шансы уровнялись в этой части. А может PQ умеет реплицироваться сразу с нескольких источников? mysql такое умеет, как минимум года 3.
2) upgrade с версии на версию.
Это страшный сон всех PQ DBA, даже если версии минорные, особенно, если у тебя есть custom'ные exten'ы. Ну вот нельзя просто поставить новую версию, запустить скрипт upgrad'a и всё. И это mysql умеет очень давно. Но PQ до 9.Х включительно не имел такого инструмента. Как дела в PQ в 12-ой версии — я не знаю, возможно, спустя много лет, что-то появилось.
3) recovery table
Если таблица очень большая и дамп по каким-то причинам долго переносить/делать, то можно с рабочего сервера сделать копию файла ibd (если InnoDB) потом через DISCARD/IMPORT можно «подключить» таблицу в работающую базу. Тут успех, где-то 70%, но всё-равно не малый.
4) 32-ух битный номер транзакций. Это боль для высоконагруженных БД. Такое случается очень редко, но когда случилось — это катастрофа. Как чинить — непонятно (была статья на хабре, где писали за деньги патч под это дело). Вроде бы в 10 или 11 он уже 64-их битный, но что делать было раньше? Надеятся, что ты никогда с таким не столкнёшься?
Это самые большие проблемы, с которыми приходилось мириться (и надеятся, что они никогда не настанут) и мы перешли на mysql. Были ещё мелкие недочёты, но они несущественны.
Вы могли бы мне назвать причины, в чём PQ лучше MY, как для DBA?
Вот, уже разговор пошел)
1. Ну во первых не пойму чем же слони костыль, да сейчас репликация есть, и мучений нет, про Master-master не в курсе, последний раз юзал bucardo, сейчас у меня нет такого типа репликаций по ряду причин.
2. Можно. pg_dump_all, create cluster, pg_restore. Да неидеальный подход, тот же оракл вроде как умеет обновлятся, но по сути — извольте ваш код переписать, сэр.
3. В голову не приходио, но любопыто, надо пошукать.
4. Раньше было раньше, ну серьезно, в этом году 14ая выходит)
Могу, он быстрее, у него куда большое возможностей по оптимизации и контролю целостности данных и развивается она быстро и есть большой запас по возможностям на вырост (например есть возможность подключить ту же TimescaleDB если нужна колоночная БД). Многих вещей в Mysql просто не завезли, я например страдаю без частичных индексов, а еще пространственные данные, trgm индексы, крутой FTS и так далее. Можно ли сказать что «для DBA»? ну тут такое себе будет обсуждение.
На самом деле вопрос кстати не праздный, я довольно давно интересуюсь у людей зачем им Mysql и большинство аргументов не приводит, да собственно как и тут, 5 минусов к комменту а обсудить чтото можно только с вами.
1. Ну во первых не пойму чем же слони костыль, да сейчас репликация есть, и мучений нет, про Master-master не в курсе, последний раз юзал bucardo, сейчас у меня нет такого типа репликаций по ряду причин.
2. Можно. pg_dump_all, create cluster, pg_restore. Да неидеальный подход, тот же оракл вроде как умеет обновлятся, но по сути — извольте ваш код переписать, сэр.
3. В голову не приходио, но любопыто, надо пошукать.
4. Раньше было раньше, ну серьезно, в этом году 14ая выходит)
Могу, он быстрее, у него куда большое возможностей по оптимизации и контролю целостности данных и развивается она быстро и есть большой запас по возможностям на вырост (например есть возможность подключить ту же TimescaleDB если нужна колоночная БД). Многих вещей в Mysql просто не завезли, я например страдаю без частичных индексов, а еще пространственные данные, trgm индексы, крутой FTS и так далее. Можно ли сказать что «для DBA»? ну тут такое себе будет обсуждение.
На самом деле вопрос кстати не праздный, я довольно давно интересуюсь у людей зачем им Mysql и большинство аргументов не приводит, да собственно как и тут, 5 минусов к комменту а обсудить чтото можно только с вами.
1. Костыль, потому что это стороннее ПО, так же как и bucardo. У нормальной DB давно такие инструменты должны быть нативные.
2. Да, можно многими способами, но процент успешной миграции в моём случае был очень невелик. Зачем мне переписывать код, если дело в конкретном exten'e? Это глупо и неправильно. Правильно было бы во время дампа указать его, что есть такой exten и лежит там-то. Но нет, как ни подсовывал ему, ему всё не нравилось. Это первый пример. Второй пример, это функция digest из стандартного exten'a pgcrypto (он правда не подключён по умолчанию, но ведь это не должно быть проблемой при дампе). Итого, исходя из ваших слов, или не пользоваться вообще exten'aми, ибо всё, что не включено по дефолту сломается при обновлении, либо каждый раз переписывать код. Зачем тогда вообще нужны такие exten'ы, которые создают больше проблем чем профита?
3.
4. Пускай хоть 15-ая. Скажите, что из этих 4-ох пунктов имеет Postgres на текущий момент, не смотря на то, что у mysql это уже как несколько лет есть? Или назовите, чем он лучше для DBA в плане обслуживания и что имеет такого, чего нет в mysql и оно реально крутое? Я сейчас не про 100500 разных индексов, а про то, что реально может быть полезно.
Вы опять всё клоните в сторону разработчика, а не DBA. DBA в первую очередь волнует как это можно масштабировать, обновить, бэкапить и потом восстановить. То, что запросы будут выполняться быстрее или медленнее, это уже второй вопрос. Да, анализатор запросов в PQ лучше, чем в mysql, тут не спорю, но ради этого менять БД — сомнительно.
Mysql может нормально работать на HighLoad, главное правильно «приготовить». Зачем mysql? Затем, что его проще и надёжнее обслуживать.
Тут хочется вспомнить анекдот про работу пожарным: «На работе хорошо и бесплатно кормят, есть бесплатная спецодежда, можно поспать в рабочее время, хороший коллектив, но когда пожар — хоть увольняйся».
Кстати, пока писал коммент, вспомнил, что для mysql есть percona toolkit, который имеет ну очень полезную фичу, которая пару раз очень выручала: сделать консистентной реплику. То есть, предположим, что в одной из реплик часть данных пропали (как, это неважно: либо кто-то случайно удалил, либо по ошибкам не дошли, либо реплика долго была отключена, либо...). Как досинкать только недостающие данные, например, на 100Гб таблице, при этом, учитывая то, что в этот момент идёт репликация? Если для postgres'a есть такое же, я за него буду только рад.
Ещё раз повторюсь для всех, меня интересует сравнение PQ и MY ТОЛЬКО в плане DBA.
2. Да, можно многими способами, но процент успешной миграции в моём случае был очень невелик. Зачем мне переписывать код, если дело в конкретном exten'e? Это глупо и неправильно. Правильно было бы во время дампа указать его, что есть такой exten и лежит там-то. Но нет, как ни подсовывал ему, ему всё не нравилось. Это первый пример. Второй пример, это функция digest из стандартного exten'a pgcrypto (он правда не подключён по умолчанию, но ведь это не должно быть проблемой при дампе). Итого, исходя из ваших слов, или не пользоваться вообще exten'aми, ибо всё, что не включено по дефолту сломается при обновлении, либо каждый раз переписывать код. Зачем тогда вообще нужны такие exten'ы, которые создают больше проблем чем профита?
3.
4. Пускай хоть 15-ая. Скажите, что из этих 4-ох пунктов имеет Postgres на текущий момент, не смотря на то, что у mysql это уже как несколько лет есть? Или назовите, чем он лучше для DBA в плане обслуживания и что имеет такого, чего нет в mysql и оно реально крутое? Я сейчас не про 100500 разных индексов, а про то, что реально может быть полезно.
Вы опять всё клоните в сторону разработчика, а не DBA. DBA в первую очередь волнует как это можно масштабировать, обновить, бэкапить и потом восстановить. То, что запросы будут выполняться быстрее или медленнее, это уже второй вопрос. Да, анализатор запросов в PQ лучше, чем в mysql, тут не спорю, но ради этого менять БД — сомнительно.
Mysql может нормально работать на HighLoad, главное правильно «приготовить». Зачем mysql? Затем, что его проще и надёжнее обслуживать.
Тут хочется вспомнить анекдот про работу пожарным: «На работе хорошо и бесплатно кормят, есть бесплатная спецодежда, можно поспать в рабочее время, хороший коллектив, но когда пожар — хоть увольняйся».
Кстати, пока писал коммент, вспомнил, что для mysql есть percona toolkit, который имеет ну очень полезную фичу, которая пару раз очень выручала: сделать консистентной реплику. То есть, предположим, что в одной из реплик часть данных пропали (как, это неважно: либо кто-то случайно удалил, либо по ошибкам не дошли, либо реплика долго была отключена, либо...). Как досинкать только недостающие данные, например, на 100Гб таблице, при этом, учитывая то, что в этот момент идёт репликация? Если для postgres'a есть такое же, я за него буду только рад.
Ещё раз повторюсь для всех, меня интересует сравнение PQ и MY ТОЛЬКО в плане DBA.
1. Костыль, потому что это стороннее ПО, так же как и bucardo. У нормальной DB давно такие инструменты должны быть нативные.
Ну не могу согласится, вот никак.
2. Да, можно многими способами, но процент успешной миграции в моём случае был очень невелик. Зачем мне переписывать код, если дело в конкретном exten'e?
Там еще был нюанс с определенным рубежом как раз в районе 9ки когда они меняли саму философию расширений и правильно сделали я считаю. Сейсас за счет расширений можно вытворять очень много всего нужного и крутого.
А про переписывание кода это уже был мой пассаж в сторону оракла, да система обновления есть, но что толку если все равно все переписывать? Это просто данность с которой нужно жить, БД как и все остальное развивается.
Я сейчас не про 100500 разных индексов, а про то, что реально может быть полезно.
То что я назвал все реально нужно и полезно.
То, что запросы будут выполняться быстрее или медленнее, это уже второй вопрос.
Это не второй вопрос. Поскольку на этом экономятся очень большие деньги.
Да, анализатор запросов в PQ лучше, чем в mysql, тут не спорю, но ради этого менять БД — сомнительно
Это ровно до тех пор пока ваша база не падает и не перестает подавать признаки жизни. У меня было множество обращений в стиле «ааа сайт дохлый валяется дадим любых денег аааа». И было так же множество случаев, когда кроме миграции на другую СУДБ, решения небыло.
Mysql может нормально работать на HighLoad, главное правильно «приготовить»
Может, тут с вами согласен. Но ровно до того момента пока вам не понадобится писать в нее с дурной скоростью (например) или с геоданными развлекаться.
(как, это неважно: либо кто-то случайно удалил, либо по ошибкам не дошли, либо реплика долго была отключена, либо...).
Точно не уверен, но если реплика сдохла, то мастер об этом в курсе и перестанет чистить wal, на это обычно делают алерт. Более того в зависимости от критичности можно покрутить еще сам тип репликации. А по вашим кейсам честно не скажу, я так глубоко в DBA не лез, поскольку стараюсь делать так чтобы с такими ошибками не сталкиваться
Ещё раз повторюсь для всех, меня интересует сравнение PQ и MY ТОЛЬКО в плане DBA.
Вы уж меня простие, но если идет обсуждение об экономии процессорного времени, увеличении скорости выполнения и самой возможности работать с определенным типом данных, работа DBA как раз сделать красиво с тем что подходит под требования, а не наоборот.
В общем, я вижу, что вы уходите от прямых ответов, поэтому спорить тут бессмысленно. У вас всё сводится к тому, что «не было, не должно быть и это должно мониториться и т.д.». Вы должны быть готовы к любым ситуациям, и, если конкретная БД этого не умеет или это будет очень и очень сложно — то зачем её использовать под эти задачи изначально?
То, что вы назвали, это реально и полезно, кому-то другому, но не DBA. Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать. Экономию денег посчитаете во время сбоя DB и сроков её восстановления.
Если мне нужно будет писать много-много данных с большой-большой скоростью, то это точно не должна быть mysql, ибо она для этого не годится. Тут или NoSQL выбирать или искать другие решения. И да, я выбираю по принципу: для каждой задачи должна быть DB максимально ей отвечающая. То есть я НЕ буду пихать везде MY, потому что она мне больше симпатизирует. Если объективно она туда не подходит — то зачем её там использовать? Доказать, что что-то может работать на MY? Смысл?
Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов. Нигде нет супер-пупер скорости отдачи страниц, особенно, когда идут какие-то оплаты. Вы можете ждать и 5 и 10 секунд, и это нормально. Нет, я не говорю о каких-то минутах. Им надёжнее отдать вам страницу позже, чем потом разбираться с тем, у кого сколько денег пропало. Это если вы говорите об экономии больших денег. Я на 99% уверен, что у них oracle, но даже в этом ключе они не стремятся к быстродействию ради милисекунд.
PS. Я прекращаю дальнейшую дискуссию.
То, что вы назвали, это реально и полезно, кому-то другому, но не DBA. Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать. Экономию денег посчитаете во время сбоя DB и сроков её восстановления.
Если мне нужно будет писать много-много данных с большой-большой скоростью, то это точно не должна быть mysql, ибо она для этого не годится. Тут или NoSQL выбирать или искать другие решения. И да, я выбираю по принципу: для каждой задачи должна быть DB максимально ей отвечающая. То есть я НЕ буду пихать везде MY, потому что она мне больше симпатизирует. Если объективно она туда не подходит — то зачем её там использовать? Доказать, что что-то может работать на MY? Смысл?
Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов. Нигде нет супер-пупер скорости отдачи страниц, особенно, когда идут какие-то оплаты. Вы можете ждать и 5 и 10 секунд, и это нормально. Нет, я не говорю о каких-то минутах. Им надёжнее отдать вам страницу позже, чем потом разбираться с тем, у кого сколько денег пропало. Это если вы говорите об экономии больших денег. Я на 99% уверен, что у них oracle, но даже в этом ключе они не стремятся к быстродействию ради милисекунд.
PS. Я прекращаю дальнейшую дискуссию.
уходите от прямых ответов
даже не пытаюсь
не было, не должно быть и это должно мониториться и т.д
Именно так, я адепт предсказания проблем и принятия мер по недопущению.
Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать
Могу вспомнить порядка 10-15 таких случаев на внушительных объемах данных.
Экономию денег посчитаете во время сбоя DB и сроков её восстановления.
Все верно, поэтому я и ставлю во главу угла непрерывность и стабильность реплики и разворачиваемость бекапа.
Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов.
У банков объем данных недостижимый для 99,9% проектов. Однако же сейчас идет тенденция к тому, что у многих интернет магазинов ровно такие же проблемы.
и это нормально
нет не нормально. Начните считать это нормальным и скоро будете ждать по 30-60 минут.
Это если вы говорите об экономии больших денег.
Деньги можно экономить по разному. Хранилища, например, тоже денег стоят.
Я на 99% уверен, что у них oracle,
он самый, но не чистый а с ЦФТшным продуктом поверху.
они не стремятся к быстродействию ради милисекунд.
стремятся, иначе эти миллисекунды потом в часы и дни выливаются
ЗЫ и вам всего доброго.
Mysql работает «оптимистически», а постгресс «пессимистически».
Перевожу. Если у вас атомарные запросы или транзакции, которые не выполняют rollback то mysql работает в разы быстрее. Если у вас есть rollbacks, то ровно наоборот, ибо откат большой транзакции в mysql может выполнятся часами.
Это просто другой подход к видению базы.
mysql рассчитан на относительно простые системы написанные людьми незнающими про транзакции и оптимизацию. И да, это работает.
Перевожу. Если у вас атомарные запросы или транзакции, которые не выполняют rollback то mysql работает в разы быстрее. Если у вас есть rollbacks, то ровно наоборот, ибо откат большой транзакции в mysql может выполнятся часами.
Это просто другой подход к видению базы.
mysql рассчитан на относительно простые системы написанные людьми незнающими про транзакции и оптимизацию. И да, это работает.
rollback то mysql работает в разы быстрее
Даже примерно это не так и опять же, молчу про оптимизатор который требует танцев с бубном (ну или при кривых руках за угол заводится запросто).
mysql рассчитан на относительно простые системы написанные людьми незнающими про транзакции и оптимизацию. И да, это работает.
Совершенно ничего не мешает те же простые вещи писать на PG. Дело то вот в чем, потом бац и уперлись. Вот только недавно видел ка краз ситуацию с uid, 3 поля, естественно текстовые и на определенном объеме это просто все сдохло, и пошли очень увлекательные танцы сначала с попытками оптимизации, потом с попытками глубокой оптимизации а потом с переездом на другую базу.
«Доброго времени суток», омг
ИнноДБ прекрасно работает.
До момента креша сервера.
После этого данные не восстановить в 50% случаев.
Такое себе удовольствие, однако.
Неправда.
Если случился обычный crash, то данные восстанавливаются в 99% автоматически. Если так случилось, что не удалось, а это бывает крайне редко, то есть метод опция innodb_force_recovery=6, в которой база поднимается в режиме RO, неважно, насколько убита InnoDB. Можно сделать дамп, даже пропустив сбойные (если например, на диски появились bad block'и) строки, это проверенный факт.
PS. Да, в версии 5.1 (но это было ого-го когда, тогда и PQ наверное от простого ребута мог завалиться) это было часто, но тогда движок InnoDB только был в зародыше. Начиная с 5.5, это успех восстановления был уже на уровне 90%, а в 5.6 он достиг уже 99%.
Если случился обычный crash, то данные восстанавливаются в 99% автоматически. Если так случилось, что не удалось, а это бывает крайне редко, то есть метод опция innodb_force_recovery=6, в которой база поднимается в режиме RO, неважно, насколько убита InnoDB. Можно сделать дамп, даже пропустив сбойные (если например, на диски появились bad block'и) строки, это проверенный факт.
PS. Да, в версии 5.1 (но это было ого-го когда, тогда и PQ наверное от простого ребута мог завалиться) это было часто, но тогда движок InnoDB только был в зародыше. Начиная с 5.5, это успех восстановления был уже на уровне 90%, а в 5.6 он достиг уже 99%.
Если вы не ставили чего-то типа innodb_flush_log_at_trx_commit =2 то все восстанавливается в практически всегда.
myisam да, не восстанавливается. А innodb имеет двойную запись и практически всегда востановима.
myisam да, не восстанавливается. А innodb имеет двойную запись и практически всегда востановима.
Спасибо за статью.
Насчет innodb_buffer_pool_size, хотелось бы сказать, что не всегда есть необходимость устанавливать от 80% доступной памяти, но как отправная точка – хорошее решение.
Насчет innodb_buffer_pool_size, хотелось бы сказать, что не всегда есть необходимость устанавливать от 80% доступной памяти, но как отправная точка – хорошее решение.
Рекомендуется выделять до 70-80% оперативной памяти сервера.
Возможно, скажу банальность, но эта рекомендация неявно предполагает, что, кроме MySQL, на этом сервере ничего нет. Если же там же крутится, например, Apache с PHP, то его потребление тоже надо учитывать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация mysql комплексная