Штайнар Гундерсон (Steinar H. Gunderson), один из авторов библиотеки сжатия Snappy и участник разработки IPv6, объявил о возвращении в компанию Google, в которой в своё время занимался разработкой сервисов поиска по изображениям и offline-картами, но теперь будет вовлечён в разработку браузера Chrome. До этого Штайнар в течение пяти лет работал в Oracle над модернизацией оптимизатора СУБД MySQL. Заметка Штайнара примечательна критическим отношением к перспективам MySQL и рекомендацией переходить на PostgreSQL...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56287
всегда использовал слоника заместо вот этого вот детища оракула
>>> всегда использовал слоникаТот, кто так говорит, явно не мог его использовать 12+ лет назад. Значит использует лет 5 от силы, т.е. для проектов однодневок. Возможно в этом и причины их мимолетности.
>>> детища оракула
Ну это полностью подтверждает сказанное выше
с 2011, мистер Холмс, сэр
> для проектов однодневокЯ аж в голос с этого клоуна!
>Тот, кто так говорит, явно не мог его использовать 12+ лет назадбред, помню, даже в 2000-м году делал пару поделок на постгресе и уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых руках, а по фичам даже 21 года назад постгрес был лучше.
хотя для 2021 оба мусор, тк монга рулит )
> бред, помню, даже в 2000-м году делал пару поделок на постгресе и
> уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых
> руках, а по фичам даже 21 года назад постгрес был лучше.Всё зависит от того, чем Вы занимаетесь. При обновлении 10-15 ГБ с ПГ Вы упираетесь в IO и уже можете наращивать скорость только за линейно, у MySQL имеется возможность такие проблемы отсрочить.
> хотя для 2021 оба мусор, тк монга рулит )
Вот всегда хотел спросить, сколько полезных проектов на Монге есть сейчас, старше 5-8 лет? Просто мой поиск мне даёт очень интересные результаты.
Ну и википедия подсказывает, что Монга это... Ну в общем, не база данных, хотя может заменить некоторые простые её функции.
Работал недавно на проекте, которому уже почти 10 лет и который является топ 1 решением в своем домене в Америке. На нём используется как раз монга. Не сказать что мы, разработчики, рады этому факту, но работает
Чат для котегафф!?
>слон медленнее мускуля только в кривых рукахВ переводе с опеннетского это видимо означает, что нужна команда высококлассных специалистов чтобы его базово настроить.
Мускл же меня никогда не подводил и работал сразу из коробки.
В 2004 делал проект биллинга провайдера на постгресе
Когда Вадиму Михееву (работал в соседнем здании и был с ним знаком) в 1995 году понадобилось написать телефонный биллинг для МГТС в Красноярске, он написал половину тогдашнего постгреса :)
Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с 8-й версии. А в многопоточке он всегда работал быстрее (гугл и другие крупные конторы делали свои патчи, чтобы у них MySQL не тормозил на параллельных запросах, эти патчи потом вошли и в Машку и в Перкону). Была даже статья с названием типа "Нет больше медленных слонов" (только я ее не нашел). Произошло это больше 12-ти лет назад. До этого Postgres с его транзакционностью был медленнее MySQL с его MyISAM без какой либо атомарности.IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет 10 назад - WordPress работает только с ним и армия php'шников использовала преимущественно MySQL. А так как веб разработка есть почти в любом проекте и эта сфера довольно большая - то MySQL до сих пор широко распространен (в средней конторе админу проще поддерживать одну базу - MySQL, чем две MySQL для веба и Postgres для остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а в MySQL с этим попроще. Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения).
Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У буржуинов противоположная ситуация.
> армия php'шников использовала преимущественно MySQL
> в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросовЧувствуется какая-то связь между этими наблюдениями...
> Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с
> 8-й версии.Это Вы про скороть чтения на одинаковом железе или сравниваете корпоративный сервер от именитых поставщиков с шаред хостингами?
> А в многопоточке он всегда работал быстрее (гугл и
> другие крупные конторы делали свои патчи, чтобы у них MySQL не
> тормозил на параллельных запросах, эти патчи потом вошли и в Машку
> и в Перкону).Вы про что опять? У MySQL всегда была большая проблема с планировщиком, а многопточность -- это требование от больших дядь на чтение во время записи, которое не имеет ничего общего с реальной многопоточностью при выборке данных (её как таковой нет ни в Мускуле, ни в ПГ)
> Была даже статья с названием типа "Нет больше
> медленных слонов" (только я ее не нашел). Произошло это больше 12-ти
> лет назад. До этого Postgres с его транзакционностью был медленнее MySQL
> с его MyISAM без какой либо атомарности.Да, что-то вспоминаю, сравнивали MyISAM и PG? Сейчас это очень своевременно и да, не имеет никакого отношения к скорости, ПГ НИКОГДА НЕ СРАВНИТСЯ ПО СКОРОСТИ, просто это стоит намного дороже в плане проектирования (планировщик у него работает почти идеально, но Вы же не можете гарантировать наличие индексов всегда? Вот и упретесь в то, что если железка не может хранить все индексы в памяти и с ними играться, то ни о каком сравнении с MySQL-ом речи быть не может). И опять же, на ПГ только искать? Для этого есть совсем другие решения, а при записи он посасывает.
> IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет
> 10 назад - WordPress работает только с ним и армия php'шников
> использовала преимущественно MySQL. А так как веб разработка есть почти в
> любом проекте и эта сфера довольно большая - то MySQL до
> сих пор широко распространен (в средней конторе админу проще поддерживать одну
> базу - MySQL, чем две MySQL для веба и Postgres для
> остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а
> в MySQL с этим попроще. Еще в MySQL раньше были менее
> жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы
> вообще не выполнял, а MySQL позволял довольно широкие отклонения).Очень субъективно, но, на мой взгляд, тут не синтаксис сыграл свое (а он местами просто уг), а то, что на 64МБ оперативки он вполне себя живенько чувствовал.
> Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У
> буржуинов противоположная ситуация.Он занимает нишу Оракла, а сайтовая ниша для MySQL-а у нас просто намного меньше.
>Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения).при этом вполне синтаксически корректные конструкции в запросе MySQL вполне может сожрать без
каких-либо замечаний, но ничего при этом не сделать.
Вот откуда берется это про "нужно настраивать"? Там все основные настройки в конфиге откомментированы и интуитивно понятны, насколько помню (2 года настройкой СУБД не занимался).
С Postgre95.
Postgres95
> всегда использовал слоника заместо вот этого вот детища оракулаНичего вы, батенька, не понимаете в залепухах для прачечных!
Зелёного?
> детища оракулаВот и выросло поколение...
Хоть википедию бы почитали бы
Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделывает его по всем параметрам.
>>> уделывает егоПо каким параметрам?
>>> по всем
А мне казалось, что применение PG -- это очень взвешенное и обоснованное решение.
Не по всем. Я, как любитель PostgreSQL, ответственно заявляю.Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё актуальны.
> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
> актуальны.Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.
миграция на более новые версии у mysql на порядок проще. мультимастер (galera в mysql). некоторый синтаксический сахар (работа с enum, например).
Когда работаешь с ORM вообще пофиг.
ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
> ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происходит под капотом. Но с Posgtres для меня все работает быстрее, и админить его ИМХО проще и удобнее.
Понятно. Упёрся в кривую ORM, свалил всё на RDBMS.
> Понятно. Упёрся в кривую ORM, свалил всё на RDBMS.Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально. Эх жаль мир потерял такого специалиста.
Не переживай, не потерял.
Когда работаешь с patroni - тоже
>более новые версииа есть менее новые? Ну или хотя бы более лучшие.
> (работа с enum, например).enum в постгресе одна из немногих вещей которая мне понравилась.
В MariaDB я его никогда не использую, так как есть более эффективный tinyint unsigned, а соответствия можно в php массивом в константе класса сохранить.Но в посгресе нет ни tinyint ни unsigned но можно определить 1 раз enum и вставлять его в 2 и более таблицы, а если нужно модифицировать то делается это 1 раз.
>> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
>> актуальны.
>Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования >Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.Я мог конечно не так понять, но вроде обоснования были такие. Там вроде одна из проблем была - массированные обновления строк. У постгреса с этим не очень хорошо (по крайней мере было, как сейчас - не знаю), тормозил нещадно по сравнению с мускулем. Поясню. У других БД (оракл, мускуль...) строка обновляется на том же месте, где валяется (in-place), т.е. ее физическое положение в блоках не меняется, кроме редких случаев. А постгря вместо редактирования старой строки тупо добавляет измененнную новую. Вроде должно быть даже быстрее, типа некий аналог Copy-on-write. Проблемы возникают, когда на таблицу навешаны индексы. Индекс - упорядоченная последовательность значений, где с каждой строчкой индекса хранится ссылка на исходную строку в таблице, в каких блоках она находится по каким смещениям. В оракле-мускуле, если в строке обновляются поля, не входящие в индекс, индекс не редактируется (адрес строки в таблице не поменялся). А вот в постгре даже при обновлении не-индексных полей надо каждый раз искать в индексе и обновлять на адрес новой, обновленной строки - там уже другой адрес, уже в других блоках ошивается строка, т.е в индексе хранится фигня, надо исправить. Т.е. представь, в таблице у тебя один-два-три индекса, для поисков, а ты 24/7 массированно меняешь поля, не входящие в индекс - и совершается куча лишней (в сравнении с мускулем) работы по обновлению индексов, да еще и куча мусора остается в виде старых исключенных строк, которые какой-нибудь автовакуум подобрать должен, периодически внося свои тормоза и задержки.
В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления.А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись.
https://ru.wikipedia.org/wiki/PostgreSQL#%D0%9C�...)
В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.
Вы, наверное, про MyISAM?
В MySQL разные движки.
Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою кастомизацию, с помощью которой они из MySQL сделали Key-Value базу данных. Вероятно тогда это было легче сделать в MySQL, т.к. там есть поддержка разных движков для хранения данных. В Postgres она появилась только недавно.
Поэтому не совсем корректно говорить, что они вернулись именно в MySQL, т.к. они фактически перешли на совершенно другой тип базы данных.
Нет. Key-value у них - это слой абстракции сверху, а не движок.
> Нет. Key-value у них - это слой абстракции сверху, а не движок.А, ну да. Но тем не менее они сделали "костыль" поверх MySQL, т.к. именно его движок хорошо показал себя с этим "костылём". С тем же успехом они могли взять готовую Key-Value базу, если бы была в тот момент подходящая под требования. Поэтому не очень корректно приводить пример Uber-а, т.к. они MySQL использовали довольно специфично. Примерно как сравнивать Postgres с Redis.
В текущей версии postgres половина названных проблем уже не актуальна.
> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
> актуальны.так причина «мы не хотим платить специалистам, поэтому наберём макак по объявлениям» всегда будет актуальна.
Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо больше)
А так в нём нет ни unsigned, не int1 и int3, и даже ALTER TABLE ... ADD ... AFTER ...; нету.
Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка тоже нету!
Ох уж эти мамкины уделыватели по всем фронтам...
> Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо
> больше)
> А так в нём нет ни unsigned, не int1 и int3, и
> даже ALTER TABLE ... ADD ... AFTER ...; нету.
> Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка
> тоже нету!
> Ох уж эти мамкины уделыватели по всем фронтам...Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), а Дельфин по умолчанию ISAM (транзакций и WAL-а нет, но бывают задачи где это всё лишняя нагрузка). Это как ткацкий станок сравнивать с вязальными спицами -- каждый хорош для своих задач.
> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),Вы не поверите, InnoDB тоже!
> а Дельфин по умолчанию ISAMMySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где нужна быстрая вставка можно и MyISAM использовать в той же самой БД!
>> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),
> Вы не поверите, InnoDB тоже!
>> а Дельфин по умолчанию ISAM
> MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где
> нужна быстрая вставка можно и MyISAM использовать в той же самой
> БД!Это под вендой. Но Инно тоже Слону не конкурент. Совершенно разного масштаба явления.
Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.
> Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.Да уже по первому комментарию и так понятно что аноним совершенно не понимает о чём пишет, а когда его аргументы мною разбиты пишет снова глупость, не понятно зачем вообще упоминая оффтопик, и просит просто поверить ему.
Ильюша, ты пишешь на пэхэпэ. Эти всё сказано о твоим интеллектуальных способностях и общей профессиональной эрудии.
Мамин илитарий, угомонись.
ПХП программисты ничем не хуже сишников и сипипишников.
Специалисты и профаны есть везде.
> ПХП программисты ничем не хуже сишников и сипипишников.ну да, почти как люди: две руки, две ноги, две задницы… в одну они едят.
> Мамин илитарий, угомонись.
> ПХП программисты ничем не хуже сишников и сипипишников.
> Специалисты и профаны есть везде.Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с потрохами разных СУБД. Ему это просто не надо.
Под какой виндой, что ты несёшь?Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)Практически везде. Просто в силу того, что ISAM для многих задач достаточен.
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?
> Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью операций. Пишем в лог, читаем из данных и лога (причем все проблемы синхронизации и доступности решает движок БД, разве не классно?). Когда не Hello World, а 300 клиентов пишут/читают единовременно из одного набора данных, такие вопросы вызывают лишь улыбку.
И да ISAM-кие движки всегда были ReadOnly after write? Или были какие-то решения для обхода ограничений?
> Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью
> операций. Пишем в лог, читаем из данных и лога (причем все
> проблемы синхронизации и доступности решает движок БД, разве не классно?).Каких ещё блокировок? Вот есть у тебя ряд реализаций MVCC, одна хранит историю в виде исходных строк в том же месте, где они были до удаления/изменения, другая пишет, условно, диффы в другое место, а на прежнем месте городит сложную структуру из цепных ссылок, третья делает что-то среднее между первым и вторым -- какие-то удалённые строки держит на прежнем месте, какие-то выносит в отдельную помойку, а какие-то изменения просто хранит в виде инструкций в журнале изменений. Какой способ лучше?
> Каких ещё блокировок?Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких дифов в набор данных не пишет (да и в логи пишутся отнють не дифы, а новые значение полей): либо переписывает измененный набор данных/релоцирует его и пишет заново, помечая старые данные как свободное место (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях как ожидающий вакуума (PG).
VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, только при использовании запросов вне индекса (при сканировании), PG требует этого "для обслуживания".> какие-то изменения просто хранит в виде инструкций в журнале изменений
Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, разрушены внешние ссылки и вообще ахтунг и ручное восстановление.
> Какой способ лучше?
Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но не на IO), нежели полное копирование всех данных при обновлении.
Если брать разработчиков этих СУБД, то второй способ хорош тем, что его можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем с низкой степенью отказа.
Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). Но не всегда. Если у тебя строка огромная, а поменял ты в ней один символ, то могилить (как делает Слон и Инно тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и этим экономится и пространство хранение и оперативное.
> Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных).
> Но не всегда. Если у тебя строка огромная, а поменял ты
> в ней один символ, то могилить (как делает Слон и Инно
> тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и
> этим экономится и пространство хранение и оперативное.Это микрооптимизация поверх определенных типов данных, которая даёт существенный прирост на синтетике. С практической т.з., если запись изменилась, то перезапись выгоднее, как минимум, своей простотой, да и частая посимвольная замена в строке говорит о проблемах совсем другого рода при проектировании приложения.
ЗЫ Но да, прикольно, не знал про это
Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это те же яйца даже не в профиль.
> Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это
> те же яйца даже не в профиль.Нет, это и близко не одни и те же "яйца". Одна чистит БД от призраков и освобождает счётчик транзакций (изменений), другая проводит пересортировку таблиц.
> другая проводит пересортировку таблиц.Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи имеет свою цену и одна из них -- большое количество мертвых данных) заполняется сортированным для чтения набором данных и пересчитанными индексами (после релокейта деток, приходится и индексы пересчитывать)
> освобождает счётчик транзакций (изменений)
В том контексте, которые используется мной, такие действия выполняются при коммите транзакции (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)
>> другая проводит пересортировку таблиц.
> Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем
> не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи
> имеет свою цену и одна из них -- большое количество мертвых
> данных) заполняется сортированным для чтения набором данных и пересчитанными индексами
> (после релокейта деток, приходится и индексы пересчитывать)
>> освобождает счётчик транзакций (изменений)
> В том контексте, которые используется мной, такие действия выполняются при коммите транзакции
> (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)Ты не в курсе. У Слона счётчик циркулярный, ещё и "меридианный". Уроборос этакий. Без вакуума он заканчивается и всё фризится.
Ну и чем тогда пурген отличается от вакуума(кроме чистки счётчика)? Риторический вопрос. В действительности, ни одна из реализаций не лучше другой. Это очередная Кока-кола против Пепси-колы.
И не коммите, а фиксации.
А вот это в корне не так, если говорить о б-жественном InnoDB. InnoDB не поддерживает OPTIMIZE напрямую, вместо этого все данные из таблицы копируются во временную таблицу, которая потом замещает оригинальную.
Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE обычно не существует.
Точнее сказать - если не удалять из нее данные)
Перепутали с постгрёй и вакуумом.
InnoDB - это не постгря, она умеет заполнять освобождённые страницы при добавлении данных.
Вообще-то умеет. но чтобы это узнать надо прочитать документацию.
>Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.
У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не язык запросов. Такой огрызок еще поискать надо...
> У мускула определенно есть некоторые плюсы в сравнении со слоном, но только
> не язык запросов. Такой огрызок еще поискать надо...Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или только один глупый и необоснованный детский бред!?
> нет ни unsigned, не int1 и int3unsigned нет в SQL стандарте. int1 это для тех кто не умеет boolean. int3 вообще какая-то эзотерика, никому не нужная. smallint достаточно. Ну уж в количестве типов тягаться с PostgreSQL не стоит. Там есть array, intrange, daterange, xml, json, inet, геометрические типы. Даже банального uuid нет.
> ALTER TABLE ... ADD ... AFTER ...
В стандарте у колонок нету порядка. Да функция удобная, но без неё можно прожить.
Про CONSTRAINT CHECK ничего не хочешь сказать? Он как бы есть, но его нет.И уж сравнивать по фичам MySQL не стоит. Подключаемые движки, это единственное что пока есть. Они хороши только для определённой нагрузки. Зато нет набора типов индексов, с помощью которых можно улучшить некоторые операции.
Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот самый набор индексов. Кстати индексы по (даже не хранимым) вычисляемым полям в MariaDB давно можно делать, и поэтому ряд вещей таким способом и решается. Но соглашусь, маразм с отсутствием DESC индексов решён пока только в ванильной восьмёрке.
Вакуум это лишь отложенное амортизированное время операции на вставку/удаление, за счёт чего это операции эти операции выполняются быстро без необходимости копировать строки в REDO. То есть устаревшие версии строк хранятся в самой таблице и раздувают её, что конечно плохо. Вся лишь разница где хранятся старые версии строк и если вакуум выполняется регулярно, то будет лишь небольшой процент мёртвого места. Но вакуум выполняется в фоне и не занимает основной поток операций.Функциональные индексы и PostgreSQL есть, недавно появились и покрывающие индексы, а кроме того там ещё есть полезные частичные индексы, что в разы уменьшает размер индекса. Частичные индексы позволяют проиндексировать только нужные значения для выборки, не включая оставшиеся ненужные строки. А что касается типов индексов, то кроме банального B-tree, есть и более интересные вроде BRIN, Bloom. Гео индексы тоже есть, но они не всем нужны.
Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы? Вообще проблема оптимизатора MySQL преувеличена. Да, в Postgres он умнее. Но и в MySQL можно добиться схожих результатов немного подкрутив. А если говорить о простых запросах, что наиболее частый юзер-кейс, MySQL вообще ничем не хуже.
Я сужу по тому как работал мой проект на рельсах. Загрузка базы в проект из yaml ну просто в разы быстрее при использовании postgres, да и отзывчивость в общем получше. Я не проводил специальных тестов просто общие впечатления от работы на одном и на другом.
Ну, на рельсах можно и постгрю, хуже уже не будет.
Постгрес нравится, но девелопер похож на обиженку- видимо чего-то недодали.
> рекомендовал использовать PostgreSQLдак я уже
А я никогда мускуль и не использовал.
А я его еще больше ку. (c)
Сейчас будет холивар? Я за Postgres! )
так вы женщина??
у тащмайора спроси, тут поди процентов 80
тут пока одни капитаны
> MySQL сильно устарел и не эффективен, при том, что большинство пользователей и разработчиков считают, что всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёдОни тут слово "My" нечаянно перед "SQL" добавили
И какая альтернатива, о великий эксперт?
Да любые NoSQL БД
На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изображают что-то более-менее одно и то же.Оптимизатор SQL-запросов способен учитывать статистику данных в таблицах, наличие индексов по нужным полям и налету может изменить порядок соединения таблиц. При изменении данных в базе SQL проверяются ограничения, ссылочная целостность. В SQL есть полноценные транзакции с возможностью откатиться до промежуточной контрольной точки.
А вот на NoSQL никаких стандартов нет, каждый выдумывает что-то своё. И похоже всё это на закат солнца вручную.
Все зависит от цели. Когда много данных и нужна скорость, но целостность - не проблема, то почему бы нет.
Хотя я согласен, Гугл даже строит новую базу себе типа SQL, называется Spanner. Вначале думали да, все проблемы можно возложить на код, но потом пришли к выводу, что проще чтобы база данных этим все-таки занималась.
Использовал и то и другое, особой разницы не заметил. Для малых и средних сайтов MySQL - идеальное решение, поскольку там лучше дока и больше туторов. А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами и оптимизациями банально не потянет.
Рукожоп.
Не знаю чем там сильно отличаются туториалы для малых и средних сайтов, так как для малых и средних сайтов база всё равно считается детской по структуре.
А вот для более серьёзных проектов (веб/десктоп, АРМ, и тд) всё таки более гибкая в проектировании PostgreSQL я считаю. Логику делать очень удобно. И как раз таки нормальная дока по нему в целом.
Вывод ты делаешь малые и средние сайты. Больше из твоего комментария нечего почерпнуть.
> А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами
> и оптимизациями банально не потянет.потянет и это. просто надо применить Секретную Оптимизацию: выгнать на мороз тебя и тебе подобных «специалистов».
Ну всё, мария не торт, мускуль не торт, постгрес не торт, и раст нас не спасёт, потому что там тоже все paзocpaлиcь.
> там тоже все paзocpaлиcьКто "все"? Модераторы CoC? Ах, увольте...
Если бы всё было так просто. Один из ключевых разработчиков забросил Rust Wasm, но активно отказывался передавать управление другим ключевым разработчикам после множества просьб.
Пользуясь полномочиями ключевого разраба, он активно банил неугодных порой без причин.Да и сам оказался в составе core team, потому что знакомый протащил.
До этого работал в npm, где пытался турнуть некоего Рода Вагга, но не прокатило, и турнули его самого.Добавим к этому активную SJW-позицию на всё про всё. Высказывание "убить всех мужиков" и было причиной для бана, вот только у модера нет прав банить. Модераторский состав, с другой стороны, состоит преимущественно из прикладников на rust. В частности, инициатором бойкота выступил не непонятный SJW'шник, а автор ripgrep.
Разработчика зовут Эшли Уильямс, подробности тут: https://news.ycombinator.com/item?id=28515306
Так что всё гораздо хуже, чем SJW-модеров уволили. Они там уже в составе разрабов.
Грустно, надеюсь, таки турнут эту Эшли.
Отличная ссылочка. Читается на одном дыхании как один большой анекдот. Только это все реальность.
Хотя если честно я не понимаю что мешает Rust Core Team обратиться к админам гитхаба и попросить передать им права, в конце концов речь идет не о группе анонимов из даркнета, а официально существующей организации.
Всегда остаётся Хаскель!
Вся надежда на Монго
..умерла в далеком 11м году
Очень зря. MongoDB вполне себе надёжная и удобная в эксплуатации база в наши дни. Я имею в виду эксплуатацию с точки зрения администрирования.Правда, консистентный бэкап шардированного кластера сделали платной фичей. Его можно повторить руками, но минимум несколько месяцев интенсивной разработки обойдётся.
Но у кого он вообще есть - бесплатный консистентный бэкап шардированного кластера? Знаю, у TiDB. У кого ещё?
>Правда, консистентный бэкап шардированного кластера сделали платной фичейпервая же ссылка https://github.com/Percona-Lab/mongodb_consistent_backup
сам не использовал
MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.
Ты ведь сейчас вордпресс имел ввиде и что УГ, да? И правильно сделал.
(Зевая) Я не знаю что там хранит вордпресс и в каком виде, но хранить в подобной базе большое количество таблиц особенно со сложной структурой и сложными запросами я бы не стал. А так пяток таблиц для блога подойдёт.
Alibaba так не считает
https://www.youtube.com/watch?v=4Yhn2Zq3mHA
у них свое ответвление MySQL с 2008-2009 года. Там от родного MySQL только названия.
Админ у них просто героический. Для hi load эта штука не имеет необходимых механизмов. Амбразуры, похоже, приходится закрывать собственным телом(пристройкой сарайчиков и землянок).
Думаю, их «сарайчики и землянки» больше походят на Форд-Нокс
это чо за тачка?
Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт.
Окей.
> Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт.
> Окей.вообще-то так и есть. но ты этого всё равно не поймёшь, что очевидно по глупости твоего комментария.
> MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.Небольших сайтов вроде FB.com и pinterest
Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это топовый OLTP движокПретензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. То есть если вы индексируете, например, новости, которые есть временной ряд -- поиск с указанием временных рамок будет крайне грустненьким
PS: У постгреса другие сильные стороны. Например, бесплатный rollback
> Реализация fulltext очень грустнаяНу так если нужно нормальный, то для этого Sphinx есть.
А то что есть это просто что бы было кому лень со сфинксом заморачиваться.
> Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ.
> Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует.
> Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это
> топовый OLTP движок
> Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования.
> То есть если вы индексируете, например, новости, которые есть временной ряд
> -- поиск с указанием временных рамок будет крайне грустненьким
> PS: У постгреса другие сильные стороны. Например, бесплатный rollbackПопутал ты всё. Какой "кластерный первичный ключ"? Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча, хотя с 12-той версии появилась возможность реализовывать индексно-организованными таблицами (но редко кто так делает). Какая разница куда "гадим" MVCC? Когда нет необходимости каждый раз плодить UNDO-данные и таскать их из одного ТП в другое это банально быстрее, но больше места жрёт в локальной перспективе времени. Тут уж надо выбирать, что ценнее пространство или время ЦП и память. В чём богомерзкость вакуума? При адекватной настройке всё просто работает. Проблемы возникают, когда в одном кластере много БД и в них сильно разные по длительности транзакции -- 31-однобитного счётчика банально начинает не хватать. Ну так это нужно учитывать при развёртывании.
Инно хорошая академическая лабораторная работа, к проду не пригодная по ряду причин, вроде того, что вектор UNDO не попадает в WAL, что при краше приводит к развалу БД.
А можно ссылочки на развал БД при краше?
> А можно ссылочки на развал БД при краше?Разверни. Запусти длительную транзакцию, не завершая её выруби питание. Т.к. данные UNDO скорее всего в полном объёме не попадут в журнал, то при обратном проигрывании при восстановлении получить несогласованную БД. Тут должны, конечно, звёзды сойтись. Чтобы грязные блоки уже попали на диск, но при этом вектор UNDO ещё нет. Но во "взрослых" СУБД это принципиально невозможно, а в Инно вполне под рабочей нагрузкой. Хотя это практически, объективно говоря, маловероятно, но при случае проблем при восстановлении добавит.
че за бред ?? -- все изменения в данных и в том же UNDO сохраняются в REDO, и пофиг длинная там транзакция или короткая, при сбросе питания все откатится до последнего COMMIT, а то что "не успело" -- вернется в пред. состояние из UNDO.
> че за бред ?? -- все изменения в данных и в том
> же UNDO сохраняются в REDO, и пофиг длинная там транзакция или
> короткая, при сбросе питания все откатится до последнего COMMIT, а то
> что "не успело" -- вернется в пред. состояние из UNDO.Нет, это не так. Возможны состояния, когда UNDO не оказалось в REDO, а изменённые блоки уже на диске.
Бред.
Ну или эксплуатация на системе, не умеющей в write barrier - там что угодно развалится, не только InnoDB.
> Бред.
> Ну или эксплуатация на системе, не умеющей в write barrier - там
> что угодно развалится, не только InnoDB.Словья-то какие воспроизводим. Ещё бы знали, что это значит )))) Write barrier тут вообще не причём. Причём тут то, что Inno не обеспечивает WAL для UNDO. Вот и всё. Сделано это из соображений, да, скорости. И, в общем, имеет право на жизнь.
Короче я не знаю, как ты умудрился InnoDB развалить - у меня за долгие годы не получилось.
У тебя просто не было длинных транзакций ...А так разваливается и при резком выключении питания (гасится ИБП) так и при нехватке свободного места ... гасится мониторингом.
А так ... Ну что спорить-то какой нож лучше ?
Ну короче да, смысла спорить нет - я хз как вы умудряетесь InnoDB развалить, видимо руки должны быть правильно заточены.
И что значит при чём тут WB.
Когда двиг выставляет fsync()/fdatasync()/sync_file_range(), он ожидает, что на диске к моменту завершения будет всё, что он отписал, и заказал. Если WB нет - с энной вероятностью хрен оно будет на диске вовремя, и рандомное выключение приведёт к интересному.
Ну и да, какой WAL для UNDO вы вообще собрались писать, если к моменту коммита в REDO данные только в REDO. Далее его флашим в таблицу как придётся, когда по нагрузке посвободнее например, даже если что-то отвалится, делаем рефлаш. Двойная нагрузка на флаш, ещё и с чтением из REDO, если из буфера вылетело, выйдет только когда REDO заполнен.Это две разные парадигмы - либо пишем в REDO и флашим в таблицу потом, либо сразу пишем в таблицу и далее начинаются пляски с UNDO: мы либо переносим, и тогда получаем двойную нагрузку в момент транзакции, либо как в постгресном, пишем CoW'ом, и тогда надо вакуумить. Если у нас UNDO есть, REDO уже не нужен.
Могу ещё подсказать как без WB редо развалить.Всё не просто, а очень просто: мы флашим редо, выставляем синк на таблицу, выставляем синк на поинтеры редо. Если таблица на диск не попала, а поинтеры внезапно попали - имеем лютый 3.14ц, в таблице старые данные, в редо уже ничего.
С андо попроще, с андо корова конечно решает, но зато корову вакуумить надо регулярно.
Похоже как раз на частичный коммит REDO в отсутствии WB.
Ну или fsync кто-то бездумно выключил xD
в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень очень давно (задолго до появления самого Azure)
> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
> очень давно (задолго до появления самого Azure)Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
>> очень давно (задолго до появления самого Azure)
> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.некластерный, heap или как хочешь еще, и он там есть и есть очень давно
PK в MSSQL может быть 2 типов
с пробуждением
>>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
>>> очень давно (задолго до появления самого Azure)
>> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
> некластерный, heap или как хочешь еще, и он там есть и есть
> очень давно
> PK в MSSQL может быть 2 типов
> с пробуждениемHeap это, пардон, куча. Т.е. когда данные хранятся вообще вне всякой упорядоченной структуры, а просто страницы в цепочку выделяются по IAM. В Сибэйсе хренелион лет назад решили, что коль уникальный индекс практически всегда создаётся, то логично в структуре этого индекса хранить и все прочие данные, которые не входят в индексный ключ, а не отдельно кучу и отдельно би-три с листами с индексным ключом. Ну и сделали такою смесь верблюда с носорогом -- сверху служебные структуры би-три, а на листах все данные. Ну вот, эту хрень и назвали кластерным индексом. В принципе, логичное решение, но проблема в том, что одного индекса в типичных условиях никогда не бывает достаточно, а хранение всех данных в структуре какого-то одного индекса зачастую приводит к смещению статистик распределения со всеми печальными последствиями. Поэтому тот же Оракл такого не делал. Я уж не помню, когда они ввели что-то подобное, по-моему, с 12-той версии. В Слоне тоже такого не было.
https://www.red-gate.com/simple-talk/databases/sql-server/t-.../Heaps are tables without a clustered index.
Я вообще не собирался лезть в детали, я про то что в MSSQL ЕСТЬ КУЧИ.
Это онли про "Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча"Куча вполне себе возможна, доступна и используется в MSSQL. Это то, что я имел ввиду.
Куча возможна если нет ниодного кластерного индекса, которым обычно и является первичный ключ (первый и часто единственный кандидат).
Никакие нюансы терминологии меня в душе не ебали в тот момент.Я только вернул кучи назад в MSSQL Server! С этим же все согласны? Ну вот и отлично.
Не серчай. Вокруг этой темы перебор всякой терминологии. У многих в результате каша. Я просто попытался немного ситуацию прояснить.
Так что, PK (первичный ключ) это Ограничение и оно НИКОГДА не реализуется кучей. Реализуется "кластерным" (исходная куча тю-тю, если была) или доп. (некластерным) индексом (доп. в смысле дополнительным к исходной куче, которая в этом случае никуда не девается, просто по данным этой кучи строится В-древо, которое эти данные структурирует, что и упрощает с одной стороны поиск, с другой -- создаёт основу для реализации условия уникальности).
> PK в MSSQL может быть 2 типовКак бы, PK это не индекс, а Constrain -- ограничение первичного ключа. Который реализуется, под капотом, созданием уникального кластерного уже Индекса, если явно не заказать создавать не кластерный индекс, а дополнительный.
> некластерный, heap или как хочешь еще, и он там есть и есть
> очень давно
> PK в MSSQL может быть 2 типовМаленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK же (Primary Key) это одно из видов Ограничений, которое реализуется либо тем, что все данные отношения помещаются в структуру индекса, либо тем, что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой на листах хранятся данные индексного ключа и ссылки на страницы кучи, где хранится оригинальная индексируемая строка.
> Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в
> куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK
> же (Primary Key) это одно из видов Ограничений, которое реализуется либо
> тем, что все данные отношения помещаются в структуру индекса, либо тем,
> что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой
> на листах хранятся данные индексного ключа и ссылки на страницы кучи,
> где хранится оригинальная индексируемая строка.Хотя, малыши, я тут несколько ошибся. Когда заказываешь PK к существующему уже отношению, в котором есть данные, то данные из кучи перемещаются в это би-три, а исходная куча удаляется, если же заказать PK при создании отношения, то и не будет создаваться, а сразу будет создано би-три, в который данные отношения и будут писаться. Если же создать PK и явно указать, что ограничение должно реализоваться доп. индексом, то будет к куче создан доп. индекс в виде би-три. Вот и всё.
> Попутал ты всё. Какой "кластерный первичный ключ"?https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
Each InnoDB table has a special index called the clustered index that stores row data. Typically, the clustered index is synonymous with the primary key.
Не попутал.
>> Попутал ты всё. Какой "кластерный первичный ключ"?
> https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
> Each InnoDB table has a special index called the clustered index that
> stores row data. Typically, the clustered index is synonymous with the
> primary key.
> Не попутал.Кластерный индекс это... хм... индекс. А Первичный ключ это... ограничение. Просто в силу того, что в МС Сиквеле (и в Инно) зачастую разраб при определении отношения сразу пишет требование ограничения PK (причём, по умолчанию оно реализуется именно кластерным индексом), то ему и невдомёк, что Ограничение и Индекс это не одно и тоже. Совсем.
> Each InnoDB table has a special index called the clustered indexЯ настоятельно рекомендую использовать терминологию официальной документации, а не вашу собственную
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично.
Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично.
Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
У пользователей MSSQL проблемы с тем, что они умудряются мешать индексы с констрейнтами, при этом их механически разделяя :D
> необходимость богомерзкого autovacuum отсутствует.Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
> Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.htmlОзнакомьтесь с документацией. Между optimize table и autovacuum есть огромная разница. Начиная с того, что optimize table -- это опция, которую можно не запускать никогда, а вот autovacuum отключать очень не рекомендуется
Ещё раз -- это разница между демоном, который в норме должен работать постоянно, и опцией, которую можно годами не запускать
Зависит от типа нагрузки, с одной без optimize table у вас диск переполнится, а с другой можно и автоваккум отключить.
Каким образом "переполнится диск" без optimize table, если innodb прекрасно умеет писать данные в освободившиеся страницы, не потрудитесь объяснить?Нет, есть там пара очень специфичных случаев, но вы их вряд ли приведёте, с ними мало кто сталкивается.
> необходимость богомерзкого autovacuum отсутствуетБогомерзкое - это писать логи. А автовакуум это красота.
У вас MVCC уже без лога работает?
И даже с индексами?На самом деле нет. Постгря всё так же прекрасно пишет redo log, просто его назвали wal.
Тьфу плин MVCC.
ACID, конечно же.
Местные Аноноимы опускают MySQL уже 20-ый год. Но только сейчас до одного из разработчиков MySQL дошло что он занимается фигнёй.
Если копры его забросят - получится отличный и стабильный продукт. Надеемся что не начнут хотеть переписать на раст или что-то.
Стагнация ещё ни один проект до добра не доводила.
Пральна, раздать все копрам, и сосать лапу. Иначе же стогнация, нелицензионность и прочая протухаемость.
Ой, да ладно! Составит компанию Firebird, делов-то.
Наконец-то мы были услышаны! Ждём осознания в станах Вордпресса, пехепешников.
Не ждите - у них там религиозный культ.
В станах "Вордпресса" давно предлагают использовать MariaDB.
С новыми проектами - ок, выбор за Postgres. Но что делать, где уже MySQL. Обновление с 5 на 8 выливается в существенное замедление.
Масштабироваться причем вертикально. Горизонтально не каждый сможет.
А как там у постгресс с вакуумом ??
он идет
А как у MySql с optimize table?
Тут два вопроса:1) Зачем конкретно? В большинстве случаев вообще не требуется. Единственное исключение - компактинг избыточно разлапистого индекса.
2) OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
Точнее второе даже не вопрос. Онлайновая операция это ныне на InnoDB, которая допускает DML во время выполнения.
А как там у mysql с ddl в транзакциях? Научились уже? :)
> всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёдНу ушли себе и ушли, это их проблемы.
А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил на себе адсенс гугла, метрику и директ яндекса. А? Это говорит о том, что вы, господа - рукожопы. И не умеете готовить мускул.
На маленьком проекте использовал гугл адсенс. Подключил скрипт JS и всё. Базу не использовал вообще. Путь к скрипту лежал в файлике. Значит можно мускуль заменить на файлик.
Про MySQL в Google Adsense - это миф, никогда он там не использовался. Вы видимо с Facebook путайте.
В mail.ru используют джангу вместе с MySQL и им норм. Но это совершенно не значит что так надо делать всем.
> А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил
> на себе адсенс гугла, метрику и директ яндекса. А? Это говорит
> о том, что вы, господа - рукожопы. И не умеете готовить
> мускул.Вряд ли. ISAM хорош, когда надо много писать в хвост и не нужны транзакции. Например, в какой-нибудь системе не слишком ответственного логирования, где источник сообщений сам имеет надёжное хранилище.
На самом деле уже давно нет.
И даже для логов нет. Потому что при обрыве записи эти гигасы вылетят на LOCK+REPAIR, и будет прелесть.
InnoDB очень шустр ныне. Годится и для write-mostly в т.ч. Объёмы итоговые только негуманные, но со сжатием терпимо.
+1Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост.
Или делать шардинг.
Все что касается административной части то у слоника все печально.
> +1
> Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост.
> Или делать шардинг.
> Все что касается административной части то у слоника все печально.Ну Слоника со всем всё прекрасно. Ещё бы кластеризацию запилили и вообще было бы прекрасно.
Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без даунтайма
> Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без
> даунтаймаА в чём сложность? Ну не RAC, конечно, но вполне можно довести до приемлемого уровня.
Можно, вопрос какой ценой.
А в случае мускула всё это очень легко и ненавязчиво.
Именно. Или пусть расскажет как будет восстанавливать X траназакций котоые удалили спустя 10-15 секунд PITR.Хотя что такое 200 потерянных транзакций и кому это может быть интересно.
уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/Ну это Мария. А это всё тот же ISAM, только навороченный. Но я не пробовал, ничего сказать не могу.
>> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
> Ну это Мария. А это всё тот же ISAM, только навороченный. Но
> я не пробовал, ничего сказать не могу.Вы что-то путаете:
---
Конечно, помимо достоинств у кластера Galera есть и ограничения (перевод фрагмента с официального сайта MariaDB):Репликация поддерживается только для таблиц в формате InnoDB;
---Да, я тоже не пробовал :)
Какой ISAM, о чём вы. InnoDB к ISAM вообще отношения не имеет, это продукт Innobase, причём эту компаху Oracle купила задолго до санок с MySQL.
лишь бы не брать монгу
Действительно, когда нужен скуль почему же не взять монгу, хмм.
Совет в духе "переходите с кефира на джек дениэлс".
Дык мускуль и задуман как бесплатная поделка для студентов. Никто никогда и не говорил, что он пригоден для коммерческих продуктов. Так что я не знаю, кого он там пугает.
очень любопытная мысль... не хотите ее развить?
Расскажите нам для чего был задуман PHP, Линукс, автомобиль, колесо...
Пусть с себя начнет
вот как рыз вы в кучу мешаете носки с помидорами. PHP был задуман для добавления динамики в хоумпаги, а большой спрос и низкая квалификация родили монстра.
>а большой спрос и низкая квалификациякто же такой умный задумывал его для хоумпегов которые будут верстаться при низком спросе и высокой квалификации?
какие такие хоумпеги имелись в виду?
Интернет задумывался как сеть для оборонного ведомства, а 640кб в своё время хватало всем. Windows 1.0 тоже был очередным унылым файловым менеджером для DOS.
(вещи, которые оказались удобны и востребованы - имеют свойство перерастать себя)
Freax тоже когда-то был личной поделкой под себя любимого, просто чтобы миних на 386 не пользовать.
> не выделяет должных ресурсов, что мешает поддержанию его в виде конкурентоспособного продукта.Опенсорс в полный рост... А как же разработка сообществом? Где миллион волонтеров пишущих код оптимизатора?
Не хотят Орацлу земные поклоны отбивать.
> Где миллион волонтеровдавно используют постгрес и довольны. а кто в постгрес нормально не смог… ну, я не уверен, что это хороший вариант для MySQL.
А всем ли нужен мощный оптимизатор запросов?
Хороший вопрос. Ответ зависит от того, сколько этот оптимизатор будет стоить.
> А всем ли нужен мощный оптимизатор запросов?да. потому что сделать из мощного хреновый просто, а вот наоборот — очень сложно.
"но в общем виде работа оценивается как доведение его до уровня технологий начала 2000-х годов"
И вот что ему не нравится. Технологию (пусть и старую) ДОВОДЯТ ДО УМА! А что постгресс? Конфетка уже?
А что никто не говорит про Group Replication в MySQL из каропки, которой в PostgreSQL и в помине нет. Чёт не догоняю чем она отстаёт...
Вот когда постгрес предложит мне мультимастер из коробки, встроенный колоночный движок и миллион приблуд вокруг потому что протокол мускуля знают все сто лет, тогда я подумаю слезть с марии.
Всему свое, нет серебрянной пули (ну конечно если вы разработкой заняты а не чтением блогов).
>> ...когда постгрес предложит мне мультимастер из коробки...Опять 25... Зачем нужен мультимастер? Почти любая СУБД тормозит при записи на диск. Если у вас есть другой мастер, то с ним надо реплицироваться. Данные второго мастера тож надо писать другими словами. Производительность НЕ увеличивается. Это работало только с MySQL который всё тянул на одном(!) ядре процессора и иногда упирался в него. Убогий костыль для масштабирования по процу. Postgres уже лет 15 умеет в многоядерность, ему этот бред ни к чему.
Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.А для бОльших гарантий есть синхронный мультимастер, Galera Cluster называется.
>Это про возможность продолжить писать в условиях полного отказа одного из мастеровВ самом деле? Кто бы мог подумать ...
На самом деле все транзакции писавшиеся на отказавшем мастере откатываются... и все что не дошло до другого мастера тоже откатывается. Вы же не зафиксируете половину атомарной записи, правда? :)
Поэтому с точки зрения "продолжать писать при отказе" - мультимастер ничем не отличается от обычного переключения слэйва на праймори...
Э-э-э, вы точно себе представляете, как репликация работает?
Я вижу, что нет.
Какая репликация? Синхронная? Асинхронная? Синхронная с кворумом? На протоколе консенсуса?
Та, которая обсуждается. Но это слишком сложно, понимаю.
Видимо, для вас действительно сложно.
Ну и я же не зря написал: с потерей части транзакций. Если потеря части данных не вызывает проблем. Для всякой негарантированной статистики - более чем.Если у нас нет строгих требований к упорядоченности - мы ещё и на любой мастер писать можем, да, будет лаг синхронизации, но см. в начало строчки.
Если нам нужен мульти-мастер с синхронностью и откатом - берём галеру. Там да, не завершённая транзакция откатывается со всех узлов. Но при этом нам не нужно ничего "переключать" - как только транзакция упавшего мастера откатится, следующие будут выполнены. Более того, мы можем на любой мастер писать.
Если нужен "мультимастер", то берём Oracle RAC, а БД размещаем поверх ceph.
>> Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.Вы не слушайте того кто вам такое говорит, он вообще не шарит. Когда primary отказывает, ближайший standby становится мастером сам. Всё. Почему это лучше мультимастера? - Очень легко избежать split brain. С асинхронным мультимастером избежать split brain вообще не всегда возможно - вопрос только "когда". Синхронный мультимастер ставит на колени производительность при географическом удалении нод в 100%, и почти всегда даже если они рядом.
Согласен на 99.99%Мультимастер действительно более живуч. Но действительно тормознее.
Практически ни кому живучесть мультимастера не нужна. Время переключения реплики - обычно меньше 1 минуты (чаше всего, 10-20 секунд). Пять переключений в год - это доступность 99.999%. Этого достаточно даже для маркетплейсов и банков (хоть они и заявляют шесть девяток, но рады и пяти девяткам).
Наоборот мульти-мастер это про производительность. Просто единственный реализованный нормальный мультимастер это RAC, где энное кол-во экземпляров работают с одним набором файлов данных (которые сами могут быть пространственно размазаны поверх сетевой фс). А галера эта муть какая-то.
GOOGLE vs ORACLEМужик-же просто отрабатывает подъемные у нового (старого) работодателя.
Все, увы, банально и старо, как мир. :)
Што, мужику отказали в возможности безальтернативный VACUUM в MySQL добавить? Так не приживётся он там, без него хорошо.
MySQL будучи карманной игрушкой Oracle по определению не может быть конкурентноспособной РСУБД, по причини наличия у Oracle своей собственной РСУБДСлон же не принадлежит никому и поэтому искуственных палок в колеса ему не вставляют, есть еще Firebird, но это классическая РСУБД без новомодных приблуд, к слову очень хорошая
А натуральные вставляют?
Должен ли велик быть обязательно чьим-то чтобы вставлять ему палки в колёса?
У вас какой уровень IQ, вьюноша?
Oracle взял свистоподелку и слепил из нее нормальный продукт.
Но если изначально были родовые травмы, то от них очень трудно избавиться.
>Oracle взял свистоподелку и слепил из нее нормальный продукт.Oracle купил (не взял, а именно купил) за много много долларооов, систему которая в тот момент уже надежно работала на половине сайтов в инете.
После продажи, автор, сделал крутой финт ушами- он потребовал чтобы Oracle вернула mysql сообществу.. и когда оракл покрутил пальцем у виска - автор сделал форк...
с тех пор так все и идет- оракл делает СО СВОИМ mysql то что считает нужным, а сообщество периодически недовольно ропщет недовольное СВОИМ mysql...
1 миллиард долларов США если интересно :)
к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...
> к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...не надо. там от продукта жизнедеятельности монти осталось примерно столько же, сколько в их компиляторе php от оригинального php.
В чем смысл коммерческой корпорации Oracle вкладывать в MySQL в ущерб своей Oracle? Или Oracle Corporation уж стал Oracle Foundation? И не разрабатывает MySQL по остаточном признаку
Мускул ниразу не конкурент ораклу. Совершенно разные целевые сегменты...
мускулем они закрывают нишу... и делают совершенно правильно.
Версий много и все они могут быть правдивы как по отдельности, так и вместе:
- диверсифицируют риски,
- расширяют количество потенциальных клиентов,
- предоставляют полный сервис по решению проблем клиента в комплексе, а не ограничиваются задачей впарить один конкретный продукт всем подряд.
Выглядит как чувак не смог (занимался оптимизацией, которая по итогу оказалась на уровне 2000-х), ему сказали "и за что тебе платить?", он обидился, свалил и решил нагадить под дверь ораклам.
Используйте инструменты по назначению, да не везде будут фишки остальных баз. Но свои функции для сайтов вполне справляется, если ты не фирма гигант конечно же!
Не вижу комментариев - зачем они нужны, когда есть SQLite ?
Это настолько самособой разумеется, что даже холиварить повода нет...
зачем нужны комментарии?
> Oracle не выделяет должных ресурсовСмешно. Не то чтобы они купили май для захоронения, но вообще Oracle скатывает всё в помойную яму, какапывая тоннами лицензий, контрактов, подписок и поливая вендорлоками.
Что первое что второе - детские погремушки на фоне того же mssql.
mssql на линухе уже научилась через шаред мемори работать?
В MSSQL особо убивает стохастика оптимизатора - финальный план запроса может меняться 100500 раз при просто последовательном выполнении одного и того же запроса. Мало того без профайлера не разгребёшь, где засада, так ещё и каждый запуск выливается в разные планы, и результаты профайлера не бьются друг с другом. Наши виндодевелоперы с ним трахаются с завидной регулярностью.
как удивительно: сервер видит повторяющиеся паттерны — и оптимизирует под них. вот же гад какой, а!
Ды не, если бы он стабильно делал, а там именно стохастика где-то, потому что планы таки повторяются, но в ряде случаев для этого надо, чтобы фаза луны сошлась. По незадаче, это как раз те случаи, где запрос здоровый, и есть какая-то проблема... которую потрекать даже с профайлером трудно, поскольку стохастика не даёт предсказать результат изменений в самом запросе.
ну. пробует разные планы, ведёт статистику. в принципе, нормальный метод оптимизации — для реальных нагрузок, где несколько плохих планов нивелируются последующими выигрышами. вполне логично, что при таких раскладах бенчмарки имеют такой же смысл, как и любая другая ИБД.
Ды там дело не в бенчмарке. Там проблема проблему трекнуть.
Оно на половине его стохастики допустим где-то костыляется, и вместо 0.01 сек выдаёт 2-3 сек на том же запросе, при _отсутствии_ параллельных запросов - в идеальном сферическом тесте в вакууме. При этом план совершенно другой, чем вызвано - никто не объясняет, как фиксить - непонятно.
(точнее понятно, и уже зафиксили) Разбили запрос на три и объединение через хранимку, в итоге вместо 0.01-2.6 стали почти стабильные 0.07-0.14, плохо, но лучше, чем вот та задница.