Здравствуйте, mrTwister, Вы писали:
D>>Что там с check constraints? (Стандартная фича SQL, между прочим.) T>Внешние ключи есть, check constraints нет. Это не является препятствием для использования в крупных проектах.
Гы.
D>>А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут? T>Файлы живы, но в случае с InnoDB они никем не модифицируются, могут быть в любой момент восстановлены, а следовательно не нуждаются в журналировании.
Если бы всё было так радужно, я бы и не знал о том, что эти файлы вообще существуют. И кстати, их наличие не позволяет использовать DDL с возможностью отката, что крайне полезно при автоматическом обновлении структуры базы.
D>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>Что не мешает жить MSSQL'ю
MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
D>>значения которого сбрасываются в select(max(id)) при перезапуске сервера? T>Нет такого.
http://bugs.mysql.com/bug.php?id=41116
Статус: Not A Bug, but InnoDB restriction.
D>>А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null? T>Не понял, что ты имеешь ввиду?
T>> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
M>Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
M>И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
MyISAM — это очень специфический движек, который вместе со специфическими возможностями имеет и специфические ограничения. Он никто тебя не заставляет насильно его использовать. Есть InnoDB, который представляет собой обычную, классическую реализацию MVCC и является по сути аналогом движков от оракла или скюл сервера. Вот было утверждение, что MySQL мол не поддерживает ACID. А кто поддерживает? MSSQL? Ну дак аналогом движка MSSQL по сути является InnoDB. Да, InnoDB не поддерживает фичи MyISAM. Ну дак и MSSQL тоже не поддерживает фичи MyISAM.
Ага. Я еще ни разу не видел их использования в реальных крупных оракловых базах. Там таже форенкеи и те редкость.
D>>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>>Что не мешает жить MSSQL'ю
D>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
When started, mysql server is automatically resetting the AUTO_INCREMENT value for tables which are empty (does not reset the value for non-empty tables).
T>When started, mysql server is automatically resetting the AUTO_INCREMENT value for tables which are empty (does not reset the value for non-empty tables).
Да, тут я попутал. Впрочем, поведение всё равно дурацкое — я его запомнил только потому что кто-то на кывте жаловался и спрашивал, как сделать по-нормальному.
Здравствуйте, dimgel, Вы писали:
D>>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>>Что не мешает жить MSSQL'ю
D>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
А они и не нужны, так как есть comparable guid`ы (newsequentialid() — генерирует GUID`ы, где каждый последующий арифметически больше предыдущего), и COMB GUID`ы (сурогатные идентификаторы).
Здравствуйте, criosray, Вы писали:
D>>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю. C>А они и не нужны, так как есть comparable guid`ы (newsequentialid() — генерирует GUID`ы, где каждый последующий арифметически больше предыдущего), и COMB GUID`ы (сурогатные идентификаторы).
Спасибо, очень интересная инфа.
Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kuj, Вы писали:
kuj>>Угу, будто бы mysql подходит для крупных проектов. Не смешно.
T>Я уже просил привести аргументацию, почему не подходит. Единственный ответ был: "нет ACID"
Он уже научился распаралеливать запрос на несколько процов? Поправили уже проседание производительности в subqueries?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, mrTwister, Вы писали:
T>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Though may we should not be as surprised by these results — MySQL 6.0 still does not have hash or merge join which are frequently used for these kind of queries, and there is also no query parallelization which would allow MySQL to use CPUs and hard drives this system has more efficiently. Parallel query will be growing issue for MySQL because CPUs just continue to add more cores. Having 2 CPUs and being able to use only half of system CPU resources for query processing was not too bad, however with 16,32,64 cores it is just too bad.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Задавшись вопросом, а как с этим делом у PostgreSQL, нашёл интереснейшее обсуждение по производительности PgSQL vs MySQL: http://news.ycombinator.com/item?id=423523
Может ещё кому-нибудь понравится.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Mamut, Вы писали:
M>>При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
T>То, что у тебя есть возможность кроме InnoDB выбрать что-то другое говорит лишь в пользу MySQL. Используй InnoDB и будет тебе счастье, в чем проблема?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>Здравствуйте, mrTwister, Вы писали:
T>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Y>
Y>
Y>Though may we should not be as surprised by these results — MySQL 6.0 still does not have hash or merge join which are frequently used for these kind of queries, and there is also no query parallelization which would allow MySQL to use CPUs and hard drives this system has more efficiently. Parallel query will be growing issue for MySQL because CPUs just continue to add more cores. Having 2 CPUs and being able to use only half of system CPU resources for query processing was not too bad, however with 16,32,64 cores it is just too bad.
Здравствуйте, dimgel, Вы писали:
d> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили?
Есть простые UUID(), которые представляются строкой в UTF-8 (в 6.0 есть UUID_SHORT(), которые в 2 раза короче). Не смотря на то, что в документации явно не оговаривается его монотонное возрастание, на практике, под никсами, при наличии одной и той же сетевухи и монотонности времени, он монотонно возрастает (это может быть важно при использовании его в качестве ключа для InnoDB на больших таблицах).
Здравствуйте, ДимДимыч, Вы писали:
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках только для разработчиков FOSS.
Здравствуйте, Anton Batenev, Вы писали:
AB>Есть простые UUID()
Если он не Globally-Unique, то и радости от него ИМХО не сильно больше, чем от обычного serial. С другой стороны, GUID как правило без разницы где генерировать — в приложении или в SQL-сервере. За исключением случаев insert-select, или там insert из триггера. Тогда UDF.
Здравствуйте, yuriylsh, Вы писали:
Y>Он уже научился распаралеливать запрос на несколько процов?
да
Y>Поправили уже проседание производительности в subqueries?
да
Здравствуйте, agos, Вы писали:
A>Здравствуйте, ДимДимыч, Вы писали:
ДД>>Как минимум умеет распространяться бесплатно на законных основаниях. A>Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках только для разработчиков FOSS.
Здравствуйте, dimgel, Вы писали:
d> AB>Есть простые UUID() d> Если он не Globally-Unique, то и радости от него ИМХО не сильно больше, чем от обычного serial.
Я имел ввиду, что под это не выделено отдельной сущности. А так, он вполне себе unique (GUID — это всего лишь одна из реализаций стандарта).
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, yuriylsh, Вы писали:
Y>>Он уже научился распаралеливать запрос на несколько процов? T>да
нет
Y>>Поправили уже проседание производительности в subqueries? T>да
нет
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, mrTwister, Вы писали:
T> T>> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
T> M>Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
T> M>И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
T> MyISAM — это очень специфический движек, который вместе со специфическими возможностями имеет и специфические ограничения. Он никто тебя не заставляет насильно его использовать. Есть InnoDB, который представляет собой обычную, классическую реализацию MVCC и является по сути аналогом движков от оракла или скюл сервера. Вот было утверждение, что MySQL мол не поддерживает ACID. А кто поддерживает? MSSQL? Ну дак аналогом движка MSSQL по сути является InnoDB. Да, InnoDB не поддерживает фичи MyISAM. Ну дак и MSSQL тоже не поддерживает фичи MyISAM.
Еще раз объясняю внятно и по-русски:
1. Ни один из движков MySQL не поддеживает все фичи, заявленные для MySQL'я
2. Если говорится, что MySQL поддерживает то-то и то-то, надо говорить, какой именно движок эту фичу поддерживает и с какой версии.
3. Именно эта чехарда с движками и фичами затрудняет если нне использование MySQL, то оценку его возможностей точно
4. Движком по умолчанию в MySQL'е все равно является MyISAM
Здравствуйте, dimgel, Вы писали:
D>Задавшись вопросом, а как с этим делом у PostgreSQL, нашёл интереснейшее обсуждение по производительности PgSQL vs MySQL: http://news.ycombinator.com/item?id=423523 D>Может ещё кому-нибудь понравится.
Собственно я полностью согласен с фразой:
The differences between the two are really minor today. Choose whichever one you like, but there are definite reasons to choose either one.
Причем я бы добавил, что разница сокращается не только между Postgree и MySQL но и и в том числе MSSQL, Oracle. То есть популярные СУБД становятся все более однообразны.
