Comments 181
Javascript:
0 == 'Sean'
false
0 == 'Sean'
false
Я не эксперт в JavaScript, но подозреваю, что там своих gotchas с приведением типов хватает.
Да ладно, в JavaScript своего веселья хватает:
Транзитивность? Не, не слышал. Таких примеров много.
(disclaimer: мне-таки нравится JavaScript).
var a = 0;
var b = [0];
var c = "";
console.log(a == b); // true
console.log(b == c); // false
console.log(c == a); // trueТранзитивность? Не, не слышал. Таких примеров много.
(disclaimer: мне-таки нравится JavaScript).
Может я чего-то не понимаю, но как, даже в языке с динамической типизцией, 0 == 'Sean' >> true? Как это должно работать под капотом, чтобы получилось true?
А как должно работать в JS я понимаю и, как следствие, понимаю почему там false получается :)
PHP
var_dump(!!0); // false
var_dump(!!'Sean'); // true
var_dump(0 == 'Sean'); // true... wtf?
var_dump(false == true); // false
var_dump((bool) 0); // false
var_dump((bool) 'Sean'); // true
var_dump(0 == 'Sean'); // true... wtf?
var_dump(false == true); // false
var_dump((bool) 0 == (bool) 'Sean'); // false
А как должно работать в JS я понимаю и, как следствие, понимаю почему там false получается :)
var_dump((int)'Sean');
int(0)
Не путайте динамическую и не строгую (утиную) типизацию. В Python например типизация тоже динамическая, но она строгая.
Не путайте нестрогую типизацию с утиной.
В том же Python типизация строгая — но это не мешает ей быть утиной. К примеру, библиотечная функция select.select не спрашивает типы объектов, а принимает любые где определен метод
В том же Python типизация строгая — но это не мешает ей быть утиной. К примеру, библиотечная функция select.select не спрашивает типы объектов, а принимает любые где определен метод
fileno().
По поводу того, что MySQL используют как key value.
На новом нашем проекте ребята все-таки уговорили меня использовать postgres вместо MySQL, но как ни странно мы postgres тоже используем как key value, потому что sphinx все равно быстрее.
Так что история про key value никак не может быть аргументом для любой РСУБД, потому что все равно найдется специализированный инструмент, который будет работать быстрее.
По поводу MYISAM кстати, я сам не сталкивался потому что давно на сфинкс перешел, но читал что MYISAM может быть интересен своими патченными версиями с интересными индексами, например индексом для координат и гео поиска (сферическая система координат и все такое). Вроде там есть еще какие то ситуативные индексы, которые могут быть интересны. До недавнего времени еще был поднотекстовый поиск, но сейчас уже не актуально.
На новом нашем проекте ребята все-таки уговорили меня использовать postgres вместо MySQL, но как ни странно мы postgres тоже используем как key value, потому что sphinx все равно быстрее.
Так что история про key value никак не может быть аргументом для любой РСУБД, потому что все равно найдется специализированный инструмент, который будет работать быстрее.
По поводу MYISAM кстати, я сам не сталкивался потому что давно на сфинкс перешел, но читал что MYISAM может быть интересен своими патченными версиями с интересными индексами, например индексом для координат и гео поиска (сферическая система координат и все такое). Вроде там есть еще какие то ситуативные индексы, которые могут быть интересны. До недавнего времени еще был поднотекстовый поиск, но сейчас уже не актуально.
Spatial indexes для InnoDB появились в 5.7. Что в общем было последним существенным аргументом в пользу MyISAM, да и то в не самых распространённых случаях.
А что слышно про Aria в MariaDB?
Вот здесь всё написано: mariadb.com/kb/en/mariadb/aria-faq
Но я бы не возлагал особых надежд на версию 2.0 — скорее всего она никогда не случится.
Но я бы не возлагал особых надежд на версию 2.0 — скорее всего она никогда не случится.
Просто скажите наркотикам MyISAM нет, все её проблемы не стоят каких-то скромных бонусов в производительности.
Мне не совсем понятно, почему Вы игнорируете невозможность избавления от MyISAM, даже в версии 5.7. Вы не исправили предыдущую статью, после моего коментария и ссылки на документацию о том, что избавиться от MyISAM полностью невозможно, т.к системны таблицы ВСЕГДА используют MyISAM. Более того, документация прямо говорит (перевод):
Важно
Не конверируйте системные таблицы MySQL в БД mysql (такие как user или host) в тип InnoDB. Это не поддерживаемая операция. Системные таблицы всегда должны быть типа MyISAM.
Оригинал:
Important
Do not convert MySQL system tables in the mysql database (such as user or host) to the InnoDB type. This is an unsupported operation. The system tables must always be of the MyISAM type.
Мултидвижковость MySQL, и использование MyISAM для системных таблиц в частности, является одной из архитектурных проблем БД:
1. Есть древний баг, который актуален до сих пор, — #49744. Этот баг никогда не будет исправлен.
2. Инконсистентность INFORMATION_SCHEMA.PROCESSLIST, как пример проблем мултидвижковости.
Требуются-ли развёрнутые пояснения связи двух этих пунктов?
Очевидно, что проблемы репликации, так и останутся проблемами, до тех пор пока системные таблицы также не перенесут в InnoDB.
Пожалуйста уберите из обеих статей разделы о MyISAM, либо укажите, что MyISAM, всётаки является проблемой для MySQL.
Я это повторял уже, но видимо придётся ещё не раз. В статьях речь идёт об использовании MyISAM для пользовательских данных. И этого действительно не нужно делать.
Bug #49744 — это совсем из другой оперы. И да, я бы хотел пояснения как по поводу неконсистентности I_S.PROCESSLIST, так и по его связи с багом.
Системные таблицы, относящиеся к репликации уже давно в InnoDB: dev.mysql.com/doc/refman/5.6/en/slave-logs-status.html О каких конкретно проблемах речь?
Bug #49744 — это совсем из другой оперы. И да, я бы хотел пояснения как по поводу неконсистентности I_S.PROCESSLIST, так и по его связи с багом.
Системные таблицы, относящиеся к репликации уже давно в InnoDB: dev.mysql.com/doc/refman/5.6/en/slave-logs-status.html О каких конкретно проблемах речь?
Ок. Специально поставил версию 5.6.26 MySQL-a, и да Вы правы, таблицы связанные с репликацией перенесены в InnoDB.
Остались сущие мелочи:
Попытался симулировать ситуации, при которых информация в индексах не соотвествовала данным в таблицах и в 5.5 приходилось проводить recovery в ручную. Не получилось. На текущий момент впечатления от 5.6 вполне положительные. Жаль в продуктив так быстро её не установить. Посмотрим, потестируем…
mysql> select table_name, table_type FROM information_schema.tables where engine = 'InnoDB';
+----------------------+------------+
| table_name | table_type |
+----------------------+------------+
| innodb_index_stats | BASE TABLE |
| innodb_table_stats | BASE TABLE |
| slave_master_info | BASE TABLE |
| slave_relay_log_info | BASE TABLE |
| slave_worker_info | BASE TABLE |
Остались сущие мелочи:
mysql> select table_name, table_type FROM information_schema.tables where engine = 'MyISAM';
+---------------------------+-------------+
| table_name | table_type |
+---------------------------+-------------+
| COLUMNS | SYSTEM VIEW |
| EVENTS | SYSTEM VIEW |
| OPTIMIZER_TRACE | SYSTEM VIEW |
| PARAMETERS | SYSTEM VIEW |
| PARTITIONS | SYSTEM VIEW |
| PLUGINS | SYSTEM VIEW |
| PROCESSLIST | SYSTEM VIEW |
| ROUTINES | SYSTEM VIEW |
| TRIGGERS | SYSTEM VIEW |
| VIEWS | SYSTEM VIEW |
| columns_priv | BASE TABLE |
| db | BASE TABLE |
| event | BASE TABLE |
| func | BASE TABLE |
| help_category | BASE TABLE |
| help_keyword | BASE TABLE |
| help_relation | BASE TABLE |
| help_topic | BASE TABLE |
| ndb_binlog_index | BASE TABLE |
| plugin | BASE TABLE |
| proc | BASE TABLE |
| procs_priv | BASE TABLE |
| proxies_priv | BASE TABLE |
| servers | BASE TABLE |
| tables_priv | BASE TABLE |
| time_zone | BASE TABLE |
| time_zone_leap_second | BASE TABLE |
| time_zone_name | BASE TABLE |
| time_zone_transition | BASE TABLE |
| time_zone_transition_type | BASE TABLE |
| user | BASE TABLE |
+---------------------------+-------------+
31 rows in set (0,04 sec)
Попытался симулировать ситуации, при которых информация в индексах не соотвествовала данным в таблицах и в 5.5 приходилось проводить recovery в ручную. Не получилось. На текущий момент впечатления от 5.6 вполне положительные. Жаль в продуктив так быстро её не установить. Посмотрим, потестируем…
А вот что в 5.7.9:
mysql> select table_name, table_type FROM information_schema.tables where engine = 'InnoDB'; +---------------------------+-------------+ | table_name | table_type | +---------------------------+-------------+ | COLUMNS | SYSTEM VIEW | | EVENTS | SYSTEM VIEW | | OPTIMIZER_TRACE | SYSTEM VIEW | | PARAMETERS | SYSTEM VIEW | | PARTITIONS | SYSTEM VIEW | | PLUGINS | SYSTEM VIEW | | PROCESSLIST | SYSTEM VIEW | | ROUTINES | SYSTEM VIEW | | TRIGGERS | SYSTEM VIEW | | VIEWS | SYSTEM VIEW | | engine_cost | BASE TABLE | | gtid_executed | BASE TABLE | | help_category | BASE TABLE | | help_keyword | BASE TABLE | | help_relation | BASE TABLE | | help_topic | BASE TABLE | | innodb_index_stats | BASE TABLE | | innodb_table_stats | BASE TABLE | | plugin | BASE TABLE | | server_cost | BASE TABLE | | servers | BASE TABLE | | slave_master_info | BASE TABLE | | slave_relay_log_info | BASE TABLE | | slave_worker_info | BASE TABLE | | time_zone | BASE TABLE | | time_zone_leap_second | BASE TABLE | | time_zone_name | BASE TABLE | | time_zone_transition | BASE TABLE | | time_zone_transition_type | BASE TABLE | | sys_config | BASE TABLE | | enums | BASE TABLE | | strings | BASE TABLE | +---------------------------+-------------+ 32 rows in set (0.01 sec) mysql> select table_name, table_type FROM information_schema.tables where engine = 'MyISAM'; +------------------+------------+ | table_name | table_type | +------------------+------------+ | columns_priv | BASE TABLE | | db | BASE TABLE | | event | BASE TABLE | | func | BASE TABLE | | ndb_binlog_index | BASE TABLE | | proc | BASE TABLE | | procs_priv | BASE TABLE | | proxies_priv | BASE TABLE | | tables_priv | BASE TABLE | | user | BASE TABLE | +------------------+------------+ 10 rows in set (0.01 sec)
Ну 5.7 пока ещё до продуктива совсем далеко… Тут до миграции на 5.6 ещё руки не дошли :/
300 БД по ~180ГБ разнесённых территориально, за один день не мигрируешь. Один план ППР на эти работы пробить, — на 1 год постареть.
300 БД по ~180ГБ разнесённых территориально, за один день не мигрируешь. Один план ППР на эти работы пробить, — на 1 год постареть.
А что на счет «Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL потому что она включена в LAMP по уомочанию, а так им вообще пофигу какая будет SQL, потому что разницы они не заметят»?
Ну а все-таки, что есть такого в MySQL, чего нет в postgres? Хотелось бы конкретики. Из-за чего википедия и т.д. сейчас выбрала бы mysql?
Потому что на простых запросах MySQL требует меньше ресурсов.
Смотреть в поисковике: «нити», «потоки». Там будет много шума, но в сухом остатке: MySQL на простых запросах тратит меньше ресурсов, на сложных запросах — наоборот. Но ведь не секрет, что почти любой проект начинается с простой модели, которая постепенно усложняется :-)
К тому моменту когда проект дорастает до масштабов когда, может быть, и выгоднее было бы использовать PostgreSQL — он уже плотно «завязан» на MySQL и переделывать его никто не будет…
Смотреть в поисковике: «нити», «потоки». Там будет много шума, но в сухом остатке: MySQL на простых запросах тратит меньше ресурсов, на сложных запросах — наоборот. Но ведь не секрет, что почти любой проект начинается с простой модели, которая постепенно усложняется :-)
К тому моменту когда проект дорастает до масштабов когда, может быть, и выгоднее было бы использовать PostgreSQL — он уже плотно «завязан» на MySQL и переделывать его никто не будет…
> Потому что на простых запросах MySQL требует меньше ресурсов.
сильно сомневаюсь
сильно сомневаюсь
А вы не сомневайтесь, вы проверьте. Создайте базу на виртуалке со, скажем, 1GiB памяти (минимальная доступная сейчас виртуалка… не так давно 256M было), положите туда несколько пару миллионов записей (а сколько их у вас в базе будет если вы стартап?) и посмотрите как отработает тысяч 100 запросов, пущеннах в 100 потоков.
Только не нужно рассказывать мне про то, что я PostgreSQL «готовить не умею»: это не так важно, в стартапе из трёх человек его тоже «некому готовить», никто с default'а никакие кнопки двигать не будет.
Только не нужно рассказывать мне про то, что я PostgreSQL «готовить не умею»: это не так важно, в стартапе из трёх человек его тоже «некому готовить», никто с default'а никакие кнопки двигать не будет.
Вот как раз при «пущенных в 100 потоков» еще недавно мускул вставал в позу «да пошли вы все».
Я боюсь что вы что-то пропустили. Либо у вас запросы требовали чего-то достаточно сложного, либо транзакции, либо ещё чего. Потому что описанный сценарий — это то, что AdWords использовал больше десяти лит (до миграции на F1). И нагрузки там был, мягко скажем, немаленькие.
я погулял по вот этим граблям: www.percona.com/blog/2014/01/23/percona-server-improve-scalability-percona-thread-pool
Причем еще в 11м. Возможно, есть позы и условия когда всё лучше, но я тогда уходил сперва на физическое разнесение реплик через прозрачные репликаторы, а потом просто на слоника.
Причем еще в 11м. Возможно, есть позы и условия когда всё лучше, но я тогда уходил сперва на физическое разнесение реплик через прозрачные репликаторы, а потом просто на слоника.
Можно конкретику, но потом :) Думаю, что причины, по которым википедия выбрала бы mysql сейчас не сильно отличаются от изначальных причин много лет назад.
А с чего вы взяли, что википедия сейчас бы выбрала MySQL?
С того, что если бы были какие-то очевидные плюсы от использования других СУБД, википедия бы давно переехала. Это не так сложно, как кажется. Та же MediaWiki умеет работать с PostgreSQL в качестве бэкенда. И в функциональном смысле естественно PostgreSQL содержит всё, что нужно википедии и гораздо больше. Разница в эффективности.
Мы использовали PG на не маленьком проекте. Проблемы с производительностью были, но все они решались оптимизацией запросов и индексов. Кстати, в плане оптимизации запросов (WITH, например) у PG больше возможностей, да и в плане оптимизации индексов (функциональные индексы, например) — тоже всё лучше, чем в MySQL. Я не уверен, что в MySQL появились функциональные индесы. Или появились?
Лично мои ощущения после перехода с MySQL на PG — ощущение того, что раньше я пользовался какой-то неполноценной СУБД…
Лично мои ощущения после перехода с MySQL на PG — ощущение того, что раньше я пользовался какой-то неполноценной СУБД…
А автовакуум в PG вас не напрягает? И постоянно пухнущие индексы?
Нет, ну с ощущениями спорить невозможно. К тому же, я понимаю, что пишу в блоге PostgreSQL, а не MySQL, поэтому готов ко всяким эмоциональным вещам :)
Но я не об этом пишу. У меня вообще нет в целях кого-то «переубедить», «защитить MySQL» и прочего евангелизма. И даже цели собрать всю критику MySQL у меня нет. Вот, например, утверждение «в MySQL нет подключаемых типов данных» я в коллекцию не вношу — это правда и сформулировано технически корректно, потому для меня здесь нечего обсуждать. Цель статей — отсеять очевидный шлак в критике MySQL из сообщества PostgreSQL. Которого гораздо больше, чем технически корректных утверждений. Только и всего.
Но я не об этом пишу. У меня вообще нет в целях кого-то «переубедить», «защитить MySQL» и прочего евангелизма. И даже цели собрать всю критику MySQL у меня нет. Вот, например, утверждение «в MySQL нет подключаемых типов данных» я в коллекцию не вношу — это правда и сформулировано технически корректно, потому для меня здесь нечего обсуждать. Цель статей — отсеять очевидный шлак в критике MySQL из сообщества PostgreSQL. Которого гораздо больше, чем технически корректных утверждений. Только и всего.
Я сам скачивал и поднимал дамп википедии на PostgreSQL. Не все таблицы, правда, но основные, со статьями.
Производительность не сравнивал, но возможность этого есть.
Вот тут есть схема для постгреса. Уровнем выше — для других баз тоже. Возможно, они не так хорошо поддерживаются, поскольку мне приходилось подправлять их руками для своих нужд, но декларировать «невозможность» не стоит. И вполне возможно что оценки ведутся.
Таким образом перейти на Postgres технически проблем нет, но есть какие-то другие причины. Возможно просто потому что работает и все устраивает. В таком случае ЧТД.
Производительность не сравнивал, но возможность этого есть.
Вот тут есть схема для постгреса. Уровнем выше — для других баз тоже. Возможно, они не так хорошо поддерживаются, поскольку мне приходилось подправлять их руками для своих нужд, но декларировать «невозможность» не стоит. И вполне возможно что оценки ведутся.
Таким образом перейти на Postgres технически проблем нет, но есть какие-то другие причины. Возможно просто потому что работает и все устраивает. В таком случае ЧТД.
Про недостатки enum, которые якобы относятся к любой СУБД, имхо неправду написали. В Постгресе замечательные енумы, они очень помогают, никаких проблем (в том числе теоретических) с ними не замечено.
Каким образом? Чем это лучше enum в бизнес логике приложения?
Логика базы и бизнес-логика приложения — «это разные люди».
Это особенно заметно когда одно приложение может работать с несколькими базами, а в одну базу пускают несколько существенно разных приложений и живых пользователей.
Это особенно заметно когда одно приложение может работать с несколькими базами, а в одну базу пускают несколько существенно разных приложений и живых пользователей.
Я о том что енам в базе данных это не гибко. Например вы храните статус о доставке: 0 — не доставлено, 1 — доставлено. Спустя полгода заказчик просит добавить еще один статус «доставлено на склад». Что вы будете делать? Добавлять поля? Пересобирать енам?
Я буду переписывать всю логику, которая была завязана на два конкретных статуса. На фоне этого «пересборка энама» будет меньшей из проблем…
Если честно, как-то так сложилось, что я изначально его не использую, благо в Postgres есть широкий выбор альтернатив, например hstore + contstraint на значение. Но конкретно бизнес-логика приложения и логика базы — это всё-таки очень разные вещи. В конкретном приложении может быть значительно меньше опций (а точнее в бизнес-роли), чем в самой базе.
Разным приложениям и ролям может быть доступно разное подмножество статусов. Разница именно в этом. Причём о некоторых деталях хранения в базе приложению вообще знать не обязательно. База точно так же может прятаться за интерфейсом из хранимок и вьюшек, как и серверное ПО за внешнее API, что позволяет некоторую гибкость (как всегда ценой некоторого усложнения). Доводилось сталкиваться примерами, когда вся база была спрятана за хранимками. Сам я предпочитаю «абстрагироваться» в отдельных случаях, вроде хранения журналов бизнес-транзакций и конфиденциальной информации — как одна из контр-мер против ошибки в приложении или sql-инъекции на непривелигированном аккаунте.
Задача базы — хранение данных, желательно в целостном виде :-) Подключение клиента с несоответствующей версией с ошибкой в логике сохранения данных или, хуже того, зоопарк клиентов (совсем ужас — зоопарк разработчиков) — это проблема, если сама база не контролирует вопрос. Это особенно болезненная тема в СУБД, поощряющих нестрогое обращение с данными и не предоставляющих инструменты контроля целостности, вроде Mongo. В результате приложения превращаются в «китайскую вермишель» if-ов на все варианты сохранения документов, но проблему это не решает. В общем, грустная история, поскольку этот нестрогий подход очень импонирует начинающим разработчикам, не желающим «возиться со схемой данных» — гремучая смесь.
Разным приложениям и ролям может быть доступно разное подмножество статусов. Разница именно в этом. Причём о некоторых деталях хранения в базе приложению вообще знать не обязательно. База точно так же может прятаться за интерфейсом из хранимок и вьюшек, как и серверное ПО за внешнее API, что позволяет некоторую гибкость (как всегда ценой некоторого усложнения). Доводилось сталкиваться примерами, когда вся база была спрятана за хранимками. Сам я предпочитаю «абстрагироваться» в отдельных случаях, вроде хранения журналов бизнес-транзакций и конфиденциальной информации — как одна из контр-мер против ошибки в приложении или sql-инъекции на непривелигированном аккаунте.
Задача базы — хранение данных, желательно в целостном виде :-) Подключение клиента с несоответствующей версией с ошибкой в логике сохранения данных или, хуже того, зоопарк клиентов (совсем ужас — зоопарк разработчиков) — это проблема, если сама база не контролирует вопрос. Это особенно болезненная тема в СУБД, поощряющих нестрогое обращение с данными и не предоставляющих инструменты контроля целостности, вроде Mongo. В результате приложения превращаются в «китайскую вермишель» if-ов на все варианты сохранения документов, но проблему это не решает. В общем, грустная история, поскольку этот нестрогий подход очень импонирует начинающим разработчикам, не желающим «возиться со схемой данных» — гремучая смесь.
проблемы, к сожалению, замечены: не добавить значение enum внутри транзакции
Теоретические недостатки, которые не могут быть не замечены:
— повторение енумов в каждом столбце, его использующего (создавать отдельный тип из енумов — уже другая история)
— сложность получения списка допустимых значений.
— повторение енумов в каждом столбце, его использующего (создавать отдельный тип из енумов — уже другая история)
— сложность получения списка допустимых значений.
Из ваших заметок пока видится только один посыл: не критикуйте MySQL. Лучше бы побольше писали про настоящие недостатки, на которые нужно смотреть при сравнении с Postgres.
Если честно — фиговенькая попытка. Убедительных доводов «в защиту» в статье не особо увидел (ну правда, хватит уже тыкать мне в лицо этим списком компаний), а вот в унылые вялые оправдания статья скатилась бодренько. "Ну даа, есть проблема… ну даа, печально известный баг… нуда..."
Итоговое впечатление "всё равно его не брошу, потому что он хороший". А я не выберу MySQL, как хранилище данных, какие бы критерии у проекта ни были — потому что вижу, что потенциального геморроя можно словить на порядок больше, чем… А даже преимуществ-то не вижу. Что, первичная простота развёртывания? Смешно.
Итоговое впечатление "всё равно его не брошу, потому что он хороший". А я не выберу MySQL, как хранилище данных, какие бы критерии у проекта ни были — потому что вижу, что потенциального геморроя можно словить на порядок больше, чем… А даже преимуществ-то не вижу. Что, первичная простота развёртывания? Смешно.
И я раньше натыкался на статьи о том как решать ту или иную проблему в MySQL. Потом удивлялся почему об этих проблемах не пишут про PG, подумал, что мало где используется, хреновое сообщество или люди просто не хотят делиться наработками. А поработав с пол годика с PG понял, что таких проблем там просто нет, поэтому о них никто и не пишет.
Дело было года 3-4 назад, вспомнить с какими проблемами конкретно я сталкивался не получается :( Но помню точно, что их не было при работе с PG.
Дело было года 3-4 назад, вспомнить с какими проблемами конкретно я сталкивался не получается :( Но помню точно, что их не было при работе с PG.
По-моему это и не было защитой. Вы уверены что вы читали обе статьи?
Автор признает ошибки, но пытается донести мысль, что аргументы, которые приводятся обычно — не совсем честные аргументы и лишь только приводят к тому что никто внятно не может объяснить почему именно в его проекте не нужно выбирать MySQL, а нужен именно Postgres: «потому что вижу, что потенциального геморроя можно словить на порядок больше». Потенциальный геморрой с постгресом тоже можно найти. просто сейчас тренд — «ругаешь MySQL — ты крутой и современный. Защищаешь — ты олдфаг».
Можете сразу ответить на вопрос — в чем бы в вашем существующем проекте вы бы получили проблемы на MySQL?
Автор признает ошибки, но пытается донести мысль, что аргументы, которые приводятся обычно — не совсем честные аргументы и лишь только приводят к тому что никто внятно не может объяснить почему именно в его проекте не нужно выбирать MySQL, а нужен именно Postgres: «потому что вижу, что потенциального геморроя можно словить на порядок больше». Потенциальный геморрой с постгресом тоже можно найти. просто сейчас тренд — «ругаешь MySQL — ты крутой и современный. Защищаешь — ты олдфаг».
Можете сразу ответить на вопрос — в чем бы в вашем существующем проекте вы бы получили проблемы на MySQL?
Убил двое суток на задачу (упрощенно): заджойнить три (пускай даже две) таблицы (сущность и «лог» операций с ней) так, чтобы запись результирующего запроса состояла из записи сущности и последней (сортировка через ORDER BY по нескольким полям, первичный ключ обычный автоинкремент, в данной задаче можно считать его случайным) с фильтрацией по одному из полей «лога». Удалось добиться перемножения двух таблиц только путем добавления поля «номер» в «лог» и предварительного его заполнения. Иначе на полумиллионе сущностей и более двадцати миллионах «логов» за полчаса результата не дожидался.
Ну так я ещё даже не начинал ни защищать MySQL, ни критиковать PostgreSQL. Я вообще о другом говорю.
what-postgresql-has-over-other-open-source-sql-databases
www.compose.io/articles/what-postgresql-has-over-other-open-source-sql-databases
www.compose.io/articles/what-postgresql-has-over-other-open-source-sql-databases
Приятно, что сподвиг автора на новую статью своими комментариями. :) жду статью про репликацию. Очень хотелось бы видеть способы борьбы с подводными камнями.
Кстати, лично я не видел людей, кто поработав с постгресом полгода, решил перекатиться на MySQL. У нас в компании даже mysql-dba считает что мускуль не нужен в новых проектах. Речь о Рамблере, если что :)
Кстати, лично я не видел людей, кто поработав с постгресом полгода, решил перекатиться на MySQL. У нас в компании даже mysql-dba считает что мускуль не нужен в новых проектах. Речь о Рамблере, если что :)
А можно еще немножко вбросить? )
На недавней конференции, Илья Космодемьянский заметил одну интересную вещь: MySQL никто не рассматривает как альтернативу Oracle, в отличие от PostgreSQL.
На недавней конференции, Илья Космодемьянский заметил одну интересную вещь: MySQL никто не рассматривает как альтернативу Oracle, в отличие от PostgreSQL.
Может потому, что у PG на порядки больше общего с Oracle, чем у MySQL? :)
Из личных наблюдений.
Из Postgres на Oracle и из Oracle на Postgres люди мигрируют без особого дискомфорта.
Про направление MySQL -> PG уже не раз говорили выше.
PG -> MySQL… Лично знаю пару человек, которым при переходе на другую работу пришлось пересесть с PG на MySQL. Цитировать высказывания не буду, ибо забанят, но скажу, что оба переживают такую перемену весьма болезненно.
Из Postgres на Oracle и из Oracle на Postgres люди мигрируют без особого дискомфорта.
Про направление MySQL -> PG уже не раз говорили выше.
PG -> MySQL… Лично знаю пару человек, которым при переходе на другую работу пришлось пересесть с PG на MySQL. Цитировать высказывания не буду, ибо забанят, но скажу, что оба переживают такую перемену весьма болезненно.
И тут бы очень пригодились ссылки на источники о желающих перейти туда или сюда. Были?
3-го ноября в офисе mail.ru будет конференция на тему перехода с Oracle на PostgreSQL. Там будет доклад от Банк Москвы, например.
Я про это утверждение: «MySQL никто не рассматривает как альтернативу Oracle, в отличие от PostgreSQL». Я не против, пусть так (хотя и контрпримеры встречаются). Но интересно, на чём это основано. Если на личных ощущениях — это одно. Если на каких-то исследованиях, было бы интересно почитать.
Это было на этой конференции:
www.youtube.com/watch?v=jGOkSerUPw4&feature=youtu.be
www.youtube.com/watch?v=jGOkSerUPw4&feature=youtu.be
Работал и с тем и с другим довольно плотно.
Везде свои плюсы и минусы.
В MySQL напрягали очень долгие DDL команды на больших таблицах (до версии 5.5, хз как сейчас). В PG напрягает архитектура UPDATE=DELETE+INSERT, отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы).
Везде свои плюсы и минусы.
В MySQL напрягали очень долгие DDL команды на больших таблицах (до версии 5.5, хз как сейчас). В PG напрягает архитектура UPDATE=DELETE+INSERT, отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы).
отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы)
А расскажите, если плотно работали, что за проблемы с автовакуумом? Мое впечатление: с появлением демона автовакуума — включил и забыл.
Проблема тут скорее архитектурная. Добрые молодцы в PostgreSQL придумали версионность через неизменение старых картежей, а разгребать последствия предлагают пользователю через костыль — автовакуум. Почему нельзя было скрыть механизм чистки старых кортежей? хз
если таблицы у вас до 10к строк и вялое изменение данных — ок, из коробки автовакуум работает.
Но если размер больше или нагрузка выше — автовакуум может висеть минутами, блокируя полный доступ к таблице. Если много транспортных таблиц — то самого кол-ва потоков автовакуума может не хватать (пока 3 дефолтных чистят 3 таблицы — еще 6 уже забились) Причем это сложно отловить — в коде выполняется очень простые SQL — все должно «летать». Но периодически система «подвисает». Идем в базу — select * from db_activity — а там висят… «богатыри»… молотят.
если таблицы у вас до 10к строк и вялое изменение данных — ок, из коробки автовакуум работает.
Но если размер больше или нагрузка выше — автовакуум может висеть минутами, блокируя полный доступ к таблице. Если много транспортных таблиц — то самого кол-ва потоков автовакуума может не хватать (пока 3 дефолтных чистят 3 таблицы — еще 6 уже забились) Причем это сложно отловить — в коде выполняется очень простые SQL — все должно «летать». Но периодически система «подвисает». Идем в базу — select * from db_activity — а там висят… «богатыри»… молотят.
На pgday рекомендовали иметь график, сколько автовакуумов работает в какой момент времени. Если часто бывает ситуация, когда все автовакуумы работают по максимуму (например, 10 из 10), значит надо увеличить их количество.
Ну и вообще, обычно их ставят агрессивнее, чем по дефолту
Ну и вообще, обычно их ставят агрессивнее, чем по дефолту
это все я знаю, но это уже следствие такой архитектуры, это все уже мануалы аля «FAQ как обойти наш костыль»
я как-то лично спрашивал того же Илью Космодемьянского, упоминавшегося выше, зачем такой механизм с мертвыми кортежами, ведь от него только одна головная боль с этими автовакуумами — он просто пожал плечами — «мол, такая архитектура»
я как-то лично спрашивал того же Илью Космодемьянского, упоминавшегося выше, зачем такой механизм с мертвыми кортежами, ведь от него только одна головная боль с этими автовакуумами — он просто пожал плечами — «мол, такая архитектура»
а еще настроенный автовакуум слетает, когда изменяется нагрузка на БД. Настроил ты его на один показатель, таблицы выроста в 10 раз — и все, он уже не будет справляться — его постоянно нужно отслеживать и крутить — я считаю это проблемой. В том же MySQL один раз выставили на большой объем данных — и забыли. Так что, у каждого свои тараканы под кроватью.
Проблема тут скорее архитектурная. Добрые молодцы в PostgreSQL придумали версионность через неизменение старых картежей
Нет, проблема принципиальная, связанная с механизмом транзакций: если в момент апдейта в системе присутствуют какие-либо еще транзакции, то БД обязана тем или иным способом сохранять обе версии данных. В оракле (и в mysql InnoDB) тоже есть UNDO логи, которые как-то там чистятся.
Почему нельзя было скрыть механизм чистки старых кортежей?
Он, можно сказать, и скрыт: при низкой нагрузке вам ничего делать не надо. А при высокой, уж извините, в любой СУБД что-нибудь где-нибудь вспухнет рано или поздно, и приходится разбираться и настраивать. За это DBA денюжку и получают.
Хотя согласен, что могли бы сделать сам демон малость поумнее, чтобы он подстраивался под нагрузку.
Может и ведутся какие-то в этом направлении. Я вот припоминаю, сколько раньше надо было телодвижений сделать для настройки стендбая (архивирование логов, перенос, удаление ненужных, отдельная история со switchover), — упростили же.
Ох, не знаю как сделать его по-умнее… Ведь тяжело понять сколько иопсов у нас еще может выдержать диск. Может нужно как-то отталкиваться от busy rate: если думать, что загреженный диск — это 50% busy.? Предположим, мы решили проблему с вычислением busy rate в разных ОС. Остаётся другая проблема: постгрес не знает какого типа носители находятся под базой (hdd, ssd) и какой процент busy нужно считать «плохим». Уверен, это как-то можно решить для конкретной ОС, но код будет не портабельным.
Вы мне дали пищу для исследований.
Вы мне дали пищу для исследований.
В оракле (и в mysql InnoDB) тоже есть UNDO логи, которые как-то там чистятся.
Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали и сделали эту чистку максимально производительно. Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции. Везде всегда говорят — настраивайте автовакуум агрессивнее, но что может быть агрессивнее, чем чистить сразу за собой?
тогда вставки / апдейты будут слишком медленные
вы это говорите как знающий человек? или просто так?
А что тут знать?
Демоны автовакуума усердно работают в несколько потоков — значит им есть что делать. Если это будет происходить непосредственно при удалении или апдейте, то время затрачиваемое автовакуумами распределится по конкретным комитам, значит эти комиты будут работать дольше. Кроме того, оптом наверняка дешевле.
Демоны автовакуума усердно работают в несколько потоков — значит им есть что делать. Если это будет происходить непосредственно при удалении или апдейте, то время затрачиваемое автовакуумами распределится по конкретным комитам, значит эти комиты будут работать дольше. Кроме того, оптом наверняка дешевле.
Но время выполнения транзакций будет более предсказуемым. Оно будет больше зависеть от того, что делает сама транзакция, чем от того, что делали другие транзакции. Анализ затыков базы будет куда проще, легко будет оптимизировать запросы по общему времени выполнения (включая время очистки псоле себя).
Это вы применительно к какому случаю?
В подходе PG как раз поведение более простое и предсказуемое: не надо лезть в UNDO сегменты, не надо ничего восстанавливать.
В подходе PG как раз поведение более простое и предсказуемое: не надо лезть в UNDO сегменты, не надо ничего восстанавливать.
Исходим из требования, что в базе должны быть только данные закоммиченных транзакций и данные ещё незавершенных (не важно коммитом или ролбэком). Исходим из требования, что нам важнее более предсказуемое время выполнения, чем как можно более быстрый ответ. Какой ещё разумный способ, кроме как чистки самой транзакцией, можно предложить?
Увы, но для такого поведения нужно либо неограниченное дисковое пространство, либо какой-то сборщик мусора, который сложно представить, не мешающим выполняемым сейчас транзакциям, если база должна быть доступна постоянно.
Увы, но для такого поведения нужно либо неограниченное дисковое пространство, либо какой-то сборщик мусора, который сложно представить, не мешающим выполняемым сейчас транзакциям, если база должна быть доступна постоянно.
Исходим из требования, что нам важнее более предсказуемое время выполнения, чем как можно более быстрый ответ.
Не понимаю, откуда возьмется «более предсказуемое время выполнения». Подход постгреса требует меньше работы в каждой транзакции и меньше времени. Если вы про то, что в бекграунде какое-нибудь тормозилово (типа вакуума) может этому помешать, то оно везде может по бесчисленному множеству причин (если у вас не RTOS, конечно).
Какой ещё разумный способ, кроме как чистки самой транзакцией, можно предложить?
Ну не может она сама в общем случае почистить. И в оракле с мускулем не чистит.
Увы, но для такого поведения нужно либо неограниченное дисковое пространство, либо какой-то сборщик мусора, который сложно представить, не мешающим выполняемым сейчас транзакциям, если база должна быть доступна постоянно
Почему сложно? Если сборщик мусора удаляет ненужные записи, на логическом уровне он мешать же не будет (блокировок нет)? Остается вопрос распределения по времени физической нагрузки, тут да, пока не все шоколадно, но, по-моему, принципиальных препятствий нет.
Кстати, в PG чистка идет НЕ ТОЛЬКО в процессе автоваккума. В процессе доступа к страницам (в последующих транзакциях) тоже: momjian.us/main/writings/pgsql/mvcc.pdf
Так что подход комбинированный.
Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали
А я не уверен. В mysql так обычно: в одном месте они подумали (как автор приводил пример с теми же float'ами), а в трех других или не думали, или уж лучше бы не думали.
Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции
Я не спец в транзакционных движках, но выше основную мысль до вас пытался донести. При коммите КАКОЙ транзакции и чего чистить? Если в базе идут одновременно много транзакций, то до тех пор пока не закончатся все те, что пересеклись по времени с данной транзакцией, нельзя в общем случае ничего чистить. И это только одна (но принципиальная) проблема. Добавьте сюда особенности записи WAL, репликацию и прочую внутреннюю кухню.
При коммите КАКОЙ транзакции и чего чистить? Если в базе идут одновременно много транзакций, то до тех пор пока не закончатся все те, что пересеклись по времени с данной транзакцией, нельзя в общем случае ничего чистить.
вы говорите как гуманитарий. Транзакция X изменила строку с А на В. Транзакция Х коммитится. С этого момента ресурс А для новых транзакция не нужен (и для старых тоже, исключая если что SERIALIZABLE изоляцию), в худшем случае ждем завершения текущих транзакций и удаляем А.
Падаю все ниже и ниже. Был евангелистом постгреса, теперь вот гуманитарий уже. Скоро медицинские диагнозы пойдут.
Какая мелочь, право! Может вообще забить на эти уровни изоляции?
И кстати, каждый отдельный запрос внутри себя работает как минимум на уровне REPEATABLE READ (он ведь не должен видеть записи, появившиеся в процессе его работы).
Кто ждать должен? Транзакция Х? А СУБД в целом так и делает, это и есть автовакуум. Или вы предлагаете вешать условный триггер на коммит каждой транзакции и кусочно удалять все, что ее существование блокировало? Не лучше ли с точки зрения производительности удалять все сразу и в фоне?
Почитайте еще коммент выше, кстати: habrahabr.ru/post/269463/#comment_8629905
Постгрес не только в процессе автовакуума умеет чистить.
для старых тоже, исключая если что SERIALIZABLE изоляцию
Какая мелочь, право! Может вообще забить на эти уровни изоляции?
И кстати, каждый отдельный запрос внутри себя работает как минимум на уровне REPEATABLE READ (он ведь не должен видеть записи, появившиеся в процессе его работы).
в худшем случае ждем завершения текущих транзакций и удаляем А
Кто ждать должен? Транзакция Х? А СУБД в целом так и делает, это и есть автовакуум. Или вы предлагаете вешать условный триггер на коммит каждой транзакции и кусочно удалять все, что ее существование блокировало? Не лучше ли с точки зрения производительности удалять все сразу и в фоне?
Почитайте еще коммент выше, кстати: habrahabr.ru/post/269463/#comment_8629905
Постгрес не только в процессе автовакуума умеет чистить.
Автовакуум не просто так по дефолту не самый агрессивный.
— в разные время суток/дни недели нагрузка может быть сильно разная, можно процедуры вакуума настроить в соответствии: потерпеть распухание днём/в будни и агрессивно почистить ночью/в выходные (вплоть до vacuum full, если ожидается период простоя), но даже отстающий в пиках нагрузки автовакуум будет «нагонять» в периоды спада активности.
— транзакции нужно заканчивать как можно быстрее — это важнее, чем «чистить за собой», поскольку увязание транзакций в блокировках может на корню убить производительность и базы, и приложения в пики нагрузки.
С Postgres нужно понять сначала одну существенную вещь: это НЕ та СУБД, что «настроил и забыл». Postgres — это набор инструментов, граничащий с понятием «фреймворк» в языках программирования. С этого момента наступает просветление и понимание как с ним работать и раскрываются горизонты возможностей. А комплект дефолтных настроек нужен только для одного — убедиться, что демон стартует ;-)
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары. Когда про какие-то возможности говорят «здесь это не нужно», в контексте MySQL или Postgres имеют в виду очень разные вещи. В MySQL ориентируются на одно, в Postgres — на другое. Если совсем уже вульгарно: кому-то мыльница, кому-то — профессиональная камера. (На самом деле не хочу сказать, что MySQL — это конкретно «мыльница» — всё-таки за прошедшие годы таки много сделано и определённые фичи — таки круты, а нишу «мыльниц» прочно заняла Mongo; MySQL — это сейчас скорее «крепкий середнячок»).
— в разные время суток/дни недели нагрузка может быть сильно разная, можно процедуры вакуума настроить в соответствии: потерпеть распухание днём/в будни и агрессивно почистить ночью/в выходные (вплоть до vacuum full, если ожидается период простоя), но даже отстающий в пиках нагрузки автовакуум будет «нагонять» в периоды спада активности.
— транзакции нужно заканчивать как можно быстрее — это важнее, чем «чистить за собой», поскольку увязание транзакций в блокировках может на корню убить производительность и базы, и приложения в пики нагрузки.
С Postgres нужно понять сначала одну существенную вещь: это НЕ та СУБД, что «настроил и забыл». Postgres — это набор инструментов, граничащий с понятием «фреймворк» в языках программирования. С этого момента наступает просветление и понимание как с ним работать и раскрываются горизонты возможностей. А комплект дефолтных настроек нужен только для одного — убедиться, что демон стартует ;-)
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары. Когда про какие-то возможности говорят «здесь это не нужно», в контексте MySQL или Postgres имеют в виду очень разные вещи. В MySQL ориентируются на одно, в Postgres — на другое. Если совсем уже вульгарно: кому-то мыльница, кому-то — профессиональная камера. (На самом деле не хочу сказать, что MySQL — это конкретно «мыльница» — всё-таки за прошедшие годы таки много сделано и определённые фичи — таки круты, а нишу «мыльниц» прочно заняла Mongo; MySQL — это сейчас скорее «крепкий середнячок»).
omg
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары.
Одно из следствий подхода том, что из-за того, что даже в средних не-Ит компаниях выделенного администратора БД обычно нет, есть разработчики приложений и есть системные администраторы, и никто из них не хочет брать на себя ответственность за переход на Postgres в инициативном порядке.Ни разработчики, не системные администраторы не мотивированы на то, чтобы становиться профессионалами в администрировании Postgres, с гораздо более крутой кривой вхождения, чем у MySQL. Мне как разработчику Postgres нравится, но вот администрировать его, наслушавшись ужасов в холиварах, мне как-то совсем не хочется.
Наслушавшись сказок на ночь (по вкусу — насмотревшись ужастиков) — можно дойти до того, что без света не спится ;-)
Честно сказать, не вижу проблемы в детальном знании одного из неотъемлемых инструментов разработки. Не боги горшки обжигают. Если разработчика не смущает изучение языка и среды разработки, тестирование и профилирование кода приложения, почему его должно смущать оное в отношении активно используемого хранилища данных? Причём это вполне касается и MySQL/Mongo/(далее по списку) — в MySQL что-ли настраивать и профилировать нечего? Такое же хранилище, с теми же фундаментальными компромиссами «диск/память/процессор». ИМХО, системного администратора это касается куда в меньшей мере, чем самого разработчика, решающего, что, где и как в базе.
А крутой DBA — это уже для крупных команд и проектов, где пошло расслоение по классам фронтендщиков, и он в не меньшей степени разработчик, поскольку его мнение а-ля «вот здесь всё переделываем, а транзакцию с блокировками организовываем по такому-то сценарию, а вот здесь добавляем скрипт обслуживания данных, иначе через неделю всё загнётся» — прямое руководство к действию и смене планов, как и мнение СЕОшника, или специалиста по UX.
Понятно, что узкий специалист будет лучше разбираться в вопросе, на котором специализируется, но если уж команда не может себе позволить узкого специалиста и всё зависит от «инициативы снизу» (со стороны абсолютно не заинтересованного временного сотрудника), а не целесообразности для бизнеса… ну, что я могу сказать, так тоже бывает — сплошь и рядом. Всякое встречается, как от недостаточности, так и от избытка инициативы.
Ну и как всегда: «самая короткая дорога та, которую знаешь» и «работает — не трожь». Хотя хороший навигатор не помешал бы.
Честно сказать, не вижу проблемы в детальном знании одного из неотъемлемых инструментов разработки. Не боги горшки обжигают. Если разработчика не смущает изучение языка и среды разработки, тестирование и профилирование кода приложения, почему его должно смущать оное в отношении активно используемого хранилища данных? Причём это вполне касается и MySQL/Mongo/(далее по списку) — в MySQL что-ли настраивать и профилировать нечего? Такое же хранилище, с теми же фундаментальными компромиссами «диск/память/процессор». ИМХО, системного администратора это касается куда в меньшей мере, чем самого разработчика, решающего, что, где и как в базе.
А крутой DBA — это уже для крупных команд и проектов, где пошло расслоение по классам фронтендщиков, и он в не меньшей степени разработчик, поскольку его мнение а-ля «вот здесь всё переделываем, а транзакцию с блокировками организовываем по такому-то сценарию, а вот здесь добавляем скрипт обслуживания данных, иначе через неделю всё загнётся» — прямое руководство к действию и смене планов, как и мнение СЕОшника, или специалиста по UX.
Понятно, что узкий специалист будет лучше разбираться в вопросе, на котором специализируется, но если уж команда не может себе позволить узкого специалиста и всё зависит от «инициативы снизу» (со стороны абсолютно не заинтересованного временного сотрудника), а не целесообразности для бизнеса… ну, что я могу сказать, так тоже бывает — сплошь и рядом. Всякое встречается, как от недостаточности, так и от избытка инициативы.
Ну и как всегда: «самая короткая дорога та, которую знаешь» и «работает — не трожь». Хотя хороший навигатор не помешал бы.
Вообще говоря, в MySQL InnoDB операция update это точно такой же delete+insert, и хоть там нет необходимости делать vacuum, там тоже есть похожие проблемы с purge thread и необходимостью делать optimize table, если purge thread не успевает спуржить все записи при интенсивном потоке update/delete. Об этом, кстати, в статье ни слова сказано не было, а жаль.
А подскажите, вроде как IBM Netezza изначально отпочковалась от Postgre. Вопрос — насколько SQL схожи остались? Нужно потестировать простенькие запросы, но доступа к Netezza нет.
Впору выпускать памятку «как не надо критиковать неправильно критикующих» )))
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
«Но, если начать копать, то выясняется, что MySQL там з_а_ч_а_с_т_у_ю используется как key-value хранилище».
Я, конечно, понимаю, что взаимоисключающие параграфы разных источников сковались в одну болванку, но всё же, лучше от этого не становится, это больше похоже на борьбу с ветряными мельницами (от которой сами же вроде пытаетесь отговорить), тем более, что следом сами же подтверждаете мой тезис про Facebook и Twitter: «ибо специфика у них такая».
Сам по себе тезис: «Длинный список использующих MySQL компаний ничего не значит» вполне верен в контексте того, что он не доказывает, что эти конторы, имея опыт использования MySQL не выбрали бы тогда или теперь другую СУБД, не обязательно Postgres (и это никак не проверить — «история не любит сослагательное наклонение»), а тем более в контексте «есть много разных сервисов, для каждого — что-то своё». То есть сама постановка вопроса бессмысленна без всех этих уточнений.
В то же время этот длинный список вполне можно интерпретировать и в духе «даже с MySQL можно жить и зарабатывать» (список потенциальных набросов можно долго продолжать, но я надеюсь идея понятна).
Длинный список компаний использующих некоторую СУБД на самом деле задаёт не верхний предел «это лучшая в совокупности характеристик СУБД», а нижний «это не фундаментальный фактор риска для бизнеса — другие достигали успеха, а естественный отбор не убивает тех, кто эту СУБД выбрал, за стабильностью платформы внимательно следят и вкладываются многие, рынок труда изобилует специалистами по данной технологии». Бизнес, на самом деле, интересуют немного другие вещи, чем те, о которых могли бы спорить технические специалисты.
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
«Но, если начать копать, то выясняется, что MySQL там з_а_ч_а_с_т_у_ю используется как key-value хранилище».
Я, конечно, понимаю, что взаимоисключающие параграфы разных источников сковались в одну болванку, но всё же, лучше от этого не становится, это больше похоже на борьбу с ветряными мельницами (от которой сами же вроде пытаетесь отговорить), тем более, что следом сами же подтверждаете мой тезис про Facebook и Twitter: «ибо специфика у них такая».
Сам по себе тезис: «Длинный список использующих MySQL компаний ничего не значит» вполне верен в контексте того, что он не доказывает, что эти конторы, имея опыт использования MySQL не выбрали бы тогда или теперь другую СУБД, не обязательно Postgres (и это никак не проверить — «история не любит сослагательное наклонение»), а тем более в контексте «есть много разных сервисов, для каждого — что-то своё». То есть сама постановка вопроса бессмысленна без всех этих уточнений.
В то же время этот длинный список вполне можно интерпретировать и в духе «даже с MySQL можно жить и зарабатывать» (список потенциальных набросов можно долго продолжать, но я надеюсь идея понятна).
Длинный список компаний использующих некоторую СУБД на самом деле задаёт не верхний предел «это лучшая в совокупности характеристик СУБД», а нижний «это не фундаментальный фактор риска для бизнеса — другие достигали успеха, а естественный отбор не убивает тех, кто эту СУБД выбрал, за стабильностью платформы внимательно следят и вкладываются многие, рынок труда изобилует специалистами по данной технологии». Бизнес, на самом деле, интересуют немного другие вещи, чем те, о которых могли бы спорить технические специалисты.
Да, приходится обобщать много сообщений в одно, детали при этом теряются, уж извините. Но утверждение со словом «зачастую» в общем тоже бы хорошо чем-то подтверждать.
Тезис о том, что кто бы и что [не] выбрал, я специально вынес в отдельный пункт. Стартапы следуют моде, для упомянутых компаний важнее эффективность хранения и обработки информации, потому что именно в таких масштабах эта эффективность имеет прямые следствия для бизнеса.
Именно поэтому скорее выбор стартапов как раз менее осознан и более подвержен нетехническим факторам вроде «команда знакома». Гиганты же вынуждены искать способы оптимизации хранения и обработки данных, не ограничивают себя в выборе технологий. Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL. С MySQL на MariaDB — да. На MongoDB — да. Это не значит, что PostgreSQL чем-то хуже для этих проектов. Не хуже, но видимо и не [достаточно] лучше.
Тезис о том, что кто бы и что [не] выбрал, я специально вынес в отдельный пункт. Стартапы следуют моде, для упомянутых компаний важнее эффективность хранения и обработки информации, потому что именно в таких масштабах эта эффективность имеет прямые следствия для бизнеса.
Именно поэтому скорее выбор стартапов как раз менее осознан и более подвержен нетехническим факторам вроде «команда знакома». Гиганты же вынуждены искать способы оптимизации хранения и обработки данных, не ограничивают себя в выборе технологий. Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL. С MySQL на MariaDB — да. На MongoDB — да. Это не значит, что PostgreSQL чем-то хуже для этих проектов. Не хуже, но видимо и не [достаточно] лучше.
Избыточное обобщение приводит к обратному эффекту — люди говорят одно, Вы спорите с чем-то другим, в результате кто с кем спорит и зачем, что самое главное, непонятно :-)
Стартапы — да, наверно самая неосознанная в выборе (хотя все ли?) категория. Но у крупного бизнеса свои заморочки. Смена платформы, особенно, если это смена или переобучение решающей части технических специалистов, в то время как само применение технологии уже проникло на множество взаимосвязанных уровней — может быть неприемлема (хоть в силу дороговизны процесса, хоть в силу религиозных убеждений ядра команды, что тоже нельзя исключать). Радикальная перетряска в этом вопросе скорее ожидаема, если перед бизнесом начинает маячить вопрос убытков и/или банкротства (наверно это мощный мотиватор для поиска альтернатив коммерческим СУБД), но это уже совсем другая история, редко касающаяся гигантов и монополистов в некоторой сфере. Никто ведь не утверждает, что MySQL абсолютно бесполезен. А вот что будет прибыльней для компании уровня Facebook — MySQL или Postgres, мы вряд ли когда-либо узнаем, поскольку при наличии одного, у нас нет аналогичной компании для сравнения.
При этом мы можем наблюдать, что Postgres так же прекрасно используется в нагрузках/масштабах уровня фейсбука/твиттера (например, Instagram, Skype), но не можем сравнить — выгоднее/эффективнее это или нет.
«утверждение [...] хорошо чем-то подтверждать»
Ну вот например один из источников, из которого в своё время почерпнул я: https://www.insight-it.ru/highload/2010/arkhitektura-facebook/
Да, время идёт, это уже далёкий 2010, судя по URL.
> мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
«Мне не известен» ≠ «нет в природе».
Повторюсь — для гигантов это недостаточно корректная постановка вопроса, когда много внутренних проектов и сервисов, и у каждого своя технология.
http://habrahabr.ru/post/26289/ — новый сервис в Yahoo — это пример или не пример?
http://habrahabr.ru/post/269463/#comment_8626975 — Рамблер, вот даже в теме отметился, интернет-гигант или не гигант?
http://www.nixp.ru/news/12845.html — Яндекс вот понемногу Постгрес вместо Оракла внедряет — Яндексу «тесновато». Сложно сказать, как бы он чувствовал себя в рамках MySQL, но определённо пару лет назад интернет-гигант сделал выбор не в его пользу.
Так что, это скорее вопрос неосведомлённости, а не отсутствия факта + сложность перехода на фоне того, что MySQL, удачно инкорпорировав высококлассную стороннюю разработку — уверенно занял нишу. Насколько его применение «на самом деле» было оправдано и нужен ли был сам MySQL как оболочка над InnoDB, это уже вопрос догадок и допущений, на который лучше отвечать со ссылкой на первоисточники из соответствующих компаний, не полагаясь, однако, на их полную объективность.
> не [достаточно] лучше
В общем, я именно об этом: «не ремонтируй то, что не поломано»
Стартапы — да, наверно самая неосознанная в выборе (хотя все ли?) категория. Но у крупного бизнеса свои заморочки. Смена платформы, особенно, если это смена или переобучение решающей части технических специалистов, в то время как само применение технологии уже проникло на множество взаимосвязанных уровней — может быть неприемлема (хоть в силу дороговизны процесса, хоть в силу религиозных убеждений ядра команды, что тоже нельзя исключать). Радикальная перетряска в этом вопросе скорее ожидаема, если перед бизнесом начинает маячить вопрос убытков и/или банкротства (наверно это мощный мотиватор для поиска альтернатив коммерческим СУБД), но это уже совсем другая история, редко касающаяся гигантов и монополистов в некоторой сфере. Никто ведь не утверждает, что MySQL абсолютно бесполезен. А вот что будет прибыльней для компании уровня Facebook — MySQL или Postgres, мы вряд ли когда-либо узнаем, поскольку при наличии одного, у нас нет аналогичной компании для сравнения.
При этом мы можем наблюдать, что Postgres так же прекрасно используется в нагрузках/масштабах уровня фейсбука/твиттера (например, Instagram, Skype), но не можем сравнить — выгоднее/эффективнее это или нет.
«утверждение [...] хорошо чем-то подтверждать»
Ну вот например один из источников, из которого в своё время почерпнул я: https://www.insight-it.ru/highload/2010/arkhitektura-facebook/
Да, время идёт, это уже далёкий 2010, судя по URL.
> мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
«Мне не известен» ≠ «нет в природе».
Повторюсь — для гигантов это недостаточно корректная постановка вопроса, когда много внутренних проектов и сервисов, и у каждого своя технология.
http://habrahabr.ru/post/26289/ — новый сервис в Yahoo — это пример или не пример?
http://habrahabr.ru/post/269463/#comment_8626975 — Рамблер, вот даже в теме отметился, интернет-гигант или не гигант?
http://www.nixp.ru/news/12845.html — Яндекс вот понемногу Постгрес вместо Оракла внедряет — Яндексу «тесновато». Сложно сказать, как бы он чувствовал себя в рамках MySQL, но определённо пару лет назад интернет-гигант сделал выбор не в его пользу.
Так что, это скорее вопрос неосведомлённости, а не отсутствия факта + сложность перехода на фоне того, что MySQL, удачно инкорпорировав высококлассную стороннюю разработку — уверенно занял нишу. Насколько его применение «на самом деле» было оправдано и нужен ли был сам MySQL как оболочка над InnoDB, это уже вопрос догадок и допущений, на который лучше отвечать со ссылкой на первоисточники из соответствующих компаний, не полагаясь, однако, на их полную объективность.
> не [достаточно] лучше
В общем, я именно об этом: «не ремонтируй то, что не поломано»
Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQLИ это не означает, что их никогда не было.
Вообще мигрировать с MySQL на MySQL-подобную СУБД проще, чем на PG если не использовалась более-менее нормальная ORM, которая позволит абстрагироваться от проблемы с разными запросами к разным СУБД. А выбор стэка технологий зависит не от «компании», а от людей работающих в ней. Кто сказал, что в крупных компаниях люди делают только правильные выборы? Почему вы считаете, что в крупных компаниях такого результата можно было достингуть только с этим стэком технологий и с другими стэками они никогда не достигли бы таких результатов?
Вообще, если быть уж совсем честным, то всё это всего лишь инструменты и не маловажный фактор тут — на сколько хорошо команда умеет пользоваться этим инструментом. И нельзя делить инструменты на хорошие и плохие, есть только более (или менее) подходящие инструменты для решения какого-то типа/круга задач.
И пусть не получается всю логику всегда хранить в приложении, а СУБД использовать только как хранилище когда эта СУБД может очень хорошо помочь оптимизировать приложение. Допустим вы храните всю логику в приложении, потом натыкаетесь на проблему производительности вашего решения, потом осознаёте, что если переложите эту часть логики на СУБД, то выиграете в скорости и потреблении ресурсов — тогда перестанете думать, что перекладывание логики на СУБД — это какой-то грех. После этого вы просто будете думать как сделать управление логикой на стороне СУБД более удобной, гибкой и не причиняющей боль.
На мой взгляд, MySQL проигрывает PG по ряду причин:
- В PG раньше появилась возможность масштабирования «из коробки».
- RETURNING, как в MySQL без него живут? Ещё я сталивался с проблемами в MySQL, если там PK это не автоинкрементируемый Integer, а UUID, было это, правда, давно.
- WITH — очень хороший помощник в оптимизации запросов к БД, которого нет в MySQL.
- PLSQL — отличный инструмент, которого нет в MySQL, даже нет ничего похожего.
- Функциональные индексы.
- Больше типов данных и можно подключать новые через плагины.
- Не больно делать ALTER TABLE.
>> И нельзя делить инструменты на хорошие и плохие
Это что за новость? Бывают хорошие, а бывают плохие. Еще бывают устаревшие. Я про любые инструменты, а не только в сфере ИТ.
Это что за новость? Бывают хорошие, а бывают плохие. Еще бывают устаревшие. Я про любые инструменты, а не только в сфере ИТ.
Может плохие инструменты и есть, но я таких не встречал. Зато встречал инструменты использованные не к месту, в этом случае такой инструмент действительно можно считать плохим, но не объективно, а только в применении к конкретной задаче. Повторюсь ещё раз, объективно плохих инструментов я не встречал, так чтобы они вообще ни на что не годились. И если инструмент устарел — это ещё не делает его плохим, он просто старый.
> И это не означает, что их никогда не было.
Так я ж нигде не говорил, что их никогда не было, откуда вы все это берёте? Но я люблю на факты опираться. Вот список «гигантов» на MySQL я привёл. И это я не очень старался, там можно ещё отакенный список привести. А с PostgreSQL мы тоже обсудили. Skype, TripAdvisor, Instagram. Ну пусть будет Яндекс и Авито, хотя отечественный IT он весьма эм, самобытный.
И вот для этого факта есть наверняка какие-то объяснения, да? А вот тут начинается полный разброд, каждый придумывает какие-то свои весьма витиеватые объяснения. Мне, как я говорил, это не особо интересно. Я больше по фактической части. Всё, что я утверждаю — это то, что записывать MySQL в «legacy» несколько рановато, как бы этого кому-то не хотелось.
Так я ж нигде не говорил, что их никогда не было, откуда вы все это берёте? Но я люблю на факты опираться. Вот список «гигантов» на MySQL я привёл. И это я не очень старался, там можно ещё отакенный список привести. А с PostgreSQL мы тоже обсудили. Skype, TripAdvisor, Instagram. Ну пусть будет Яндекс и Авито, хотя отечественный IT он весьма эм, самобытный.
И вот для этого факта есть наверняка какие-то объяснения, да? А вот тут начинается полный разброд, каждый придумывает какие-то свои весьма витиеватые объяснения. Мне, как я говорил, это не особо интересно. Я больше по фактической части. Всё, что я утверждаю — это то, что записывать MySQL в «legacy» несколько рановато, как бы этого кому-то не хотелось.
хотя отечественный IT он весьма эм, самобытный.А если бы они использовали MySQL, вы бы не считали отечественный IT самобытным?
записывать MySQL в «legacy» несколько рановатоНикто его в legacy записывать не собирается, хотя у него много своих причуд и багов (о них писали выше, некоторые баги/причуды исторические и с ними надо просто смириться), и для высоконагруженного проекта я бы его не выбрал.
Нет, он самобытный в любом случае. Есть же VK в конце концов. И про производительность я хочу написать отдельный пост, просто не хочу мешать всё в одном.
Но главное, что многие в комментариях не понимают: я не пишу это всё, чтобы убедить кого-то в переходе на MySQL или чтобы доказать какое-либо превосходство MySQL над PostgreSQL. Друзья, прочитайте ещё раз хотя бы заголовки, а ещё лучше сами статьи. Они совсем о другом, как мне кажется. Более того, я считаю, что PostgreSQL — отличная СУБД. Я мало о ней знаю, но практически всё, что знаю, мне нравится :) Но и статьи, опять же, не о том.
Но главное, что многие в комментариях не понимают: я не пишу это всё, чтобы убедить кого-то в переходе на MySQL или чтобы доказать какое-либо превосходство MySQL над PostgreSQL. Друзья, прочитайте ещё раз хотя бы заголовки, а ещё лучше сами статьи. Они совсем о другом, как мне кажется. Более того, я считаю, что PostgreSQL — отличная СУБД. Я мало о ней знаю, но практически всё, что знаю, мне нравится :) Но и статьи, опять же, не о том.
| Кто-то говорит, что не используют JOIN-ы. Но источник никто не указывает.
Их есть у меня. FaceBook: http://www.infoq.com/presentations/Facebook-Software-Stack — c 9-ой минуты: 'How do we use MySQL? MySQL used primarily as <key, value> storage… That's interesting: we don't do any joins in production' и так далее. И это при том, что они этот MySQL закостомизировали под себя вусмерть.
Их есть у меня. FaceBook: http://www.infoq.com/presentations/Facebook-Software-Stack — c 9-ой минуты: 'How do we use MySQL? MySQL used primarily as <key, value> storage… That's interesting: we don't do any joins in production' и так далее. И это при том, что они этот MySQL закостомизировали под себя вусмерть.
Спасибо, теперь хотя бы источник есть. Презентации 7.5 лет, многое наверняка изменилось. Хотя и там часто используются слова primarily и mostly. Но, как я написал в статье, в наиболее нагруженных и распределённых сервисах key-value — единственная работающая модель независимо от СУБД.
Кроме primarily и mostly там чётко сказано: no joins in production. Ну то есть они там люди широких взглядов и где-то, когда никто не видит, запершись в туалете можно открыть ноут и заняться join-ами, но вот на людях, в продакшне — это, конечно, недопустимо. :D
А вообще это упоминалось много где, с пояснением, что если сильно приспичило и без этого совсем никак, то всё нужное грузится в память, а потом join делается «руками».
Угу, например могли наконец выкинуть mySQL и перейти на какой-нибуть Redis, потому что я не понимаю, зачем в таком подходе sql вообще.
В Stack Overflow/Exchange/..., как я понимаю, никаких key-value на уровне BD нет, т.к они cначала иссползовали ORM от MS а потом вообще нафигачили свой явно не для того, что бы только по какому-то global id select-ы делать, а потом в памяти «join». Биржи вон тоже покупают дорогущие оракловские/ms сервера DB зачем-то.
В любом случае исспользование MySQL в виде key-value — это ну ни разу не аргумент чего бы то ни было.
Да, вдогонку: «длинный список использующих MySQL компаний ничего не значит» еще и потому, что они… не исспользуют MySQL. Почему-то неизменно оказывается, что у этих гигантов свой собственный MySQL с сами знаете кем и чем, который полностью переработан командой из кучи людей, внезапно состоящей из ex-программистов оного MySQL вплоть до главных, ключевых разработчиков. Ну ок, они перепилили MySQL, затюнили его под какие-то узкие задачи… А нам с того какая радость? В обосновании технического решения так и говорить: наймём Видениуса, он там пошаманит и всё полетит или что?
А вообще это упоминалось много где, с пояснением, что если сильно приспичило и без этого совсем никак, то всё нужное грузится в память, а потом join делается «руками».
Презентации 7.5 лет, многое наверняка изменилось.
Угу, например могли наконец выкинуть mySQL и перейти на какой-нибуть Redis, потому что я не понимаю, зачем в таком подходе sql вообще.
Но, как я написал в статье, в наиболее нагруженных и распределённых сервисах key-value — единственная работающая модель независимо от СУБД.
В Stack Overflow/Exchange/..., как я понимаю, никаких key-value на уровне BD нет, т.к они cначала иссползовали ORM от MS а потом вообще нафигачили свой явно не для того, что бы только по какому-то global id select-ы делать, а потом в памяти «join». Биржи вон тоже покупают дорогущие оракловские/ms сервера DB зачем-то.
В любом случае исспользование MySQL в виде key-value — это ну ни разу не аргумент чего бы то ни было.
Да, вдогонку: «длинный список использующих MySQL компаний ничего не значит» еще и потому, что они… не исспользуют MySQL. Почему-то неизменно оказывается, что у этих гигантов свой собственный MySQL с сами знаете кем и чем, который полностью переработан командой из кучи людей, внезапно состоящей из ex-программистов оного MySQL вплоть до главных, ключевых разработчиков. Ну ок, они перепилили MySQL, затюнили его под какие-то узкие задачи… А нам с того какая радость? В обосновании технического решения так и говорить: наймём Видениуса, он там пошаманит и всё полетит или что?
Мы вот, к примеру, используем джойны на посгресе (хайлоад) и ничего страшного не происходит.
есть мастер, на него только запись, у него несколько read-only физических репликаций. Соответственно на чтение идет балансировка на эти реплики. Я не вижу проблем исползьовать джойны. Если наши x серверов не будут справляться, добавим еще, но пока что справляются с большим запасом
Я уверен, что на авито тоже полным-полно джойнов, там ведь сложные фильтры всякие.
есть мастер, на него только запись, у него несколько read-only физических репликаций. Соответственно на чтение идет балансировка на эти реплики. Я не вижу проблем исползьовать джойны. Если наши x серверов не будут справляться, добавим еще, но пока что справляются с большим запасом
Я уверен, что на авито тоже полным-полно джойнов, там ведь сложные фильтры всякие.
Ну вот сообществу PostgreSQL очень хочется верить, что MySQL используется исключительно без JOIN-ов. Пока нашли подтверждение про Facebook семилетней давности. Но в Facebook шарды, по крайней мере для статусов пользователей. Что и с чем там JOIN-ить?
Послушайте, ну это же не серьёзно, это уже «спор без аргументов, спор на темперамент». После представленых ссылок это уже ВАМ нужно доказывать, что за прошедшее время что-то в FB радикально изменилось и изменилось в сторону того, что MySQL используется не как тупо key-value коллекция а действительно как сервер баз данных, а кроме «веры» я аргументов не вижу.
Видео датировано 2009 г. Как у вас какие-то значения типа «презентации 7.5 лет» получаются? А вообще я же сказал, что таких подтверждений много. Две минуты гугления и вот вам посвежее, 2010-го годa, что, если без альтернативной арифметики, — видео пятилетней давности, это не там и много и я не слышал о каких-то грандиозных кардинальных переменах(если вы слышали — дайте, пожалуйста, ссылки).
http://www.infoq.com/presentations/Scale-at-Facebook, 30+ минута, «The way as we use MySQL: it used primarily as a bit store...joins, query optimization — we don't think about any of those… We use it(MySQL) as a key-value storage.… Every my SQL database has one table, I'm simplifying, which basically has two columns: id and data. That's exectly what it is». Куда уж яснее-то?
Что и с чем там JOIN-ить?Вы не могли бы уточнить свою точку зрения: в FB исспользуют join(но не признаются) или всё-таки не исспользуют(join «не нужен»)
Видео датировано 2009 г. Как у вас какие-то значения типа «презентации 7.5 лет» получаются? А вообще я же сказал, что таких подтверждений много. Две минуты гугления и вот вам посвежее, 2010-го годa, что, если без альтернативной арифметики, — видео пятилетней давности, это не там и много и я не слышал о каких-то грандиозных кардинальных переменах(если вы слышали — дайте, пожалуйста, ссылки).
http://www.infoq.com/presentations/Scale-at-Facebook, 30+ минута, «The way as we use MySQL: it used primarily as a bit store...joins, query optimization — we don't think about any of those… We use it(MySQL) as a key-value storage.… Every my SQL database has one table, I'm simplifying, which basically has two columns: id and data. That's exectly what it is». Куда уж яснее-то?
Прочитайте внимательно: я нигде не утверждаю, что в FB используются JOIN-ы. Более того, я абсолютно уверен, что в самом нагруженном сервисе FB (том, что отвечает за выдачу статусов пользователей) исключительно key-value нагрузка.
Но обобщать один сервис в одной компании на десятки крупнейших компаний с сотнями внутренних сервисов — это глупо, особенно без доказательств. Я понимаю, очень хочется и припекает. Но нет.
А видео с конференции QCon SF 2008, и ему 7 лет (мне показалось, что она в мае была, а не в ноябре).
Но обобщать один сервис в одной компании на десятки крупнейших компаний с сотнями внутренних сервисов — это глупо, особенно без доказательств. Я понимаю, очень хочется и припекает. Но нет.
А видео с конференции QCon SF 2008, и ему 7 лет (мне показалось, что она в мае была, а не в ноябре).
я абсолютно уверенАга, а вот «даже если бы это было так», «никто не предоставил ссылок» — это кто-то другой писал. Ок.
исключительно key-value нагрузка.
И, следовательно, пример «а вот в FB» — негодный. ЧТД
Припекает — это как раз про то, как из флагманского аргумента FaceBook превратился в «это давно и неправда», «один серсвис» в какой-то там компании(да какой-то NoName практически!), а какие-то другие — стали «крупнейшими с сотнями внутренних сервисов » и то, что это вообще не аргумент и нельзя же обощать, потому что это раньше было можно, а теперь — нельзя. «Но нет»
Хотя на самом деле-то всё наоборот, бремя доказательств лежит сами знаете на ком, поэтому после примера с FB это вам надо доказывать, что в «десятках крупных компания», MySQL всё-таки как сервер DB используется, а не в стиле «это у нас типа такой noSQL, только не говорите никому».
Хочу оставить, пусть и запоздалый, но комментарий про то как соотносится PostgreSQL и EnterpriseDB. Сотрудники EnterpriseDB, имеют, хоть и существенное влияние на развитие PostgreSQL, но отнюдь не решающее. Посмотрите на страницу с перечислением разработчиков, сотрудников EnterpriseDB там много, но далеко не большинство. А главное – сообщество PostgreSQL и инфраструктура разработки никоем образом не интегрирована в EnterpriseDB. Менеджмент EnterpriseDB не может волевым решением закоммитить ту или иную фичу в PostgreSQL. Решения, продвигаемые сотрудниками EnterpiseDB в PostgreSQL, зачастую подвергаются критике, пересматриваются, отвергаются. Т.е. PostgreSQL реально обладает независимым сообществом. А коммерческий форк может сделать кто угодно, лицензия этого не запрещает, сообщество этого не осуждает.
Спасибо за комментарий. Но я по-прежнему не вижу большой разницы, Как в PostgreSQL, так и в MySQL есть полностью свободный и бесплатный проект, а есть закрытый и платный с дополнительным функционалом, который нужен в основном в крупных/промышленных/enterprise проектах. Причём даже набор этих дополнительных функций весьма схож. Что неудивительно, потому что среди топ-менеджеров EnterpriseDB есть несколько людей из бывшего топ-менеджемента MySQL/Sun/Oracle. То есть, сама идея EnterpriseDB вполне могла срисовываться с MySQL Enterprise.
Что касается сообщества, то практически весь функционал из MySQL Enterprise был реализован сообществом в MariaDB и Percona. Я сам приложил руку к разработке threadpool для Percona Server и могу утверждать, что эта бесплатная и свободная реализация лучше, чем вариант из MySQL Enterprise. Что однако не означает, что MySQL Enterprise не нужен. Просто глупо вешать ярлыки, совершенно не разбираясь в том, о чём речь.
Что касается сообщества, то практически весь функционал из MySQL Enterprise был реализован сообществом в MariaDB и Percona. Я сам приложил руку к разработке threadpool для Percona Server и могу утверждать, что эта бесплатная и свободная реализация лучше, чем вариант из MySQL Enterprise. Что однако не означает, что MySQL Enterprise не нужен. Просто глупо вешать ярлыки, совершенно не разбираясь в том, о чём речь.
Я здесь и не пишу про разницу, и не сравниваю. Для того, чтобы сравнивать, мне нужно было бы знать, что сейчас происходит в разработке MySQL, а я этого не знаю. Я просто посчитал нужным описать ситуацию про PostgreSQL. Дело в том, что про PostgreSQL существует миф, что он якобы «бесплатная, урезанная версия EnterpriseDB». Миф этот, насколько я смог объяснить, в корне не соответствует действительности. Поэтому, мне кажется, будет лучше детальнее объяснить ситуацию, которая сложилась в разработке MySQL. Рассказать как соотносятся между собой MySQL, MariaDB и Percona, какая в этих проектах модель управления, кто разработчики, как принимаются решения и т.д.
Хорошо, давайте так. Правильно я понимаю, что к тому, что я написал в статье, возражений нет? Я всегда открыт к конструктивным замечаниям. Если что-то неверно или неточно, я обязательно исправлю.
Заявки на то, что можно было бы рассказать ещё, тоже принимаются, но в отдельном окошке :) Невозможно охватить всё сразу.
Заявки на то, что можно было бы рассказать ещё, тоже принимаются, но в отдельном окошке :) Невозможно охватить всё сразу.
Правильно я понимаю, что к тому, что я написал в статье, возражений нет?
Я бы сказал, что у меня недостаточно знаний, чтобы судить о том верно то, что написано в статье или нет. Тема явно не раскрыта. Могу задать пару уточняющих вопросов.
1. Правильно ли я понимаю, что на текущий момент только Oracle имеет право создавать закрытые коммерческие форки MySQL, такие как MySQL Enterprise?
2. Что стало с темой, которая вызвала брожение умов в 2012 году? Ведь именно с этого момента и пошло «MySQL – проприетарщина».
1. Правильно ли я понимаю, что на текущий момент только Oracle имеет право создавать закрытые коммерческие форки MySQL, такие как MySQL Enterprise?
Да, лицензия GPL, под которой распространяется MySQL не допускает смену лицензии, в том числе на проприетарную. Поэтому закрытых форков нет. Oracle, как владелец копирайта, лицензию может менять по своему усмотрению.
BSD лицензия, под которой распространяется PostgreSQL, допускает смену лицензии. Поэтому много проприетарных форков.
2. Что стало с темой, которая вызвала брожение умов в 2012 году? Ведь именно с этого момента и пошло «MySQL – проприетарщина».
Думаю, «MySQL — проприетарщина» пошло гораздо раньше, с 2007-го года , когда появился MySQL Enterprise.
Тем не менее, по поводу закрытых багов и закрытых тесткейсов, поясняю: любая уязвимость с точки зрения безопасности, видна только сообщившему и Oracle, но не всем желающим. Oracle включает в уязвимости любой баг, приводящий к падению сервера в неотладочной сборке сервера. Соответствующие регрессионные тесты тоже скрываются, потому что это сделало бы остальные ограничения бессмысленными. Исправления же (т.е. сам код) естественно всегда доступны всем. Это политика Oracle, схожую политику применяет Redhat. Здесь они подробно объясняют причины. Redhat Linux проприетарщиной тоже никто не называет.
Это в достаточной степени раскрывает тему?
Вот видите, разница между EnterpriseDB и MySQL Enterprise довольно большая, если мы всё-таки сравниваем PostgreSQL именно с MySQL, а не MariaDB или Percona. Я бы это отразил в статье.
Я до сих пор не очень понял отличие между EnterpriseDB и MySQL Enterprise в контексте разговоров о проприетарности MySQL. Но по просьбам включаю абзац из предыдущего комментария в статью.
По-моему, мы отличие уже достаточно чётко выделили. Переформулирую, чтобы было понятнее.
1. EnterpriseDB делает свой коммерческий форк на общих условиях, также как это может делать любая другая компания. Oracle делает MySQL Enterprise, пользуясь своими эксклюзивными правами на MySQL.
2. Как мы выяснили, часть инфраструктуры разработки MySQL – закрыта, в PostgreSQL вся инфраструктура разработки открыта.
3. Весь процесс разработки PostgreSQL – открыт и принадлежит сообществу, включая принятие ключевых решение. В случае с MySQL (если мы говорим именно о MySQL, а не о MariaDB и Percona) – всё в руках Oracle.
Поэтому если искать аналогию, то лучше её проводить между PostgreSQL и MariaDB. А MySQL – это нечто среднее между PostgreSQL и EnterpriseDB: исходики открыты, но процесс разработки закрыт и коммерческая компания имеет эксклюзивные права на продукт.
1. EnterpriseDB делает свой коммерческий форк на общих условиях, также как это может делать любая другая компания. Oracle делает MySQL Enterprise, пользуясь своими эксклюзивными правами на MySQL.
2. Как мы выяснили, часть инфраструктуры разработки MySQL – закрыта, в PostgreSQL вся инфраструктура разработки открыта.
3. Весь процесс разработки PostgreSQL – открыт и принадлежит сообществу, включая принятие ключевых решение. В случае с MySQL (если мы говорим именно о MySQL, а не о MariaDB и Percona) – всё в руках Oracle.
Поэтому если искать аналогию, то лучше её проводить между PostgreSQL и MariaDB. А MySQL – это нечто среднее между PostgreSQL и EnterpriseDB: исходики открыты, но процесс разработки закрыт и коммерческая компания имеет эксклюзивные права на продукт.
То есть, логика следующая:
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
2. В MySQL есть закрытые баги в багтрекере. А в PostgreSQL багтрекера нет совсем. Поэтому PostgreSQL «открытый», а MySQL «проприетарный»
3. В PostgreSQL все решения принимает сравнительно небольшая группа людей. Вот решили, что не нужен им багтрекер, и нет его. Решили, что не будет встроенной логической репликации, и нет её. Решили, что не нужны хинты в оптимайзере, и нет их. Но конечно же, «процесс разработки открыт и принадлежит сообществу». Эти мантры сколько не повторяй, реальностью они не станут.
А коммерческая компания не только имеет эксклюзивные права на продукт, но и вкладывает в разработку эксклюзивные коммерческие средства. Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем. Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет, потому что лицензия BSD к этому не располагает, так как все результаты инвестиций окажутся в чьём-то проприетарном форке.
Парни, вы там в Postgres Professional молодцы со всех сторон, но с таким однобоким восприятием реальности я боюсь, что вы долго не проживёте. Религиозные секты долго не живут.
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
2. В MySQL есть закрытые баги в багтрекере. А в PostgreSQL багтрекера нет совсем. Поэтому PostgreSQL «открытый», а MySQL «проприетарный»
3. В PostgreSQL все решения принимает сравнительно небольшая группа людей. Вот решили, что не нужен им багтрекер, и нет его. Решили, что не будет встроенной логической репликации, и нет её. Решили, что не нужны хинты в оптимайзере, и нет их. Но конечно же, «процесс разработки открыт и принадлежит сообществу». Эти мантры сколько не повторяй, реальностью они не станут.
А коммерческая компания не только имеет эксклюзивные права на продукт, но и вкладывает в разработку эксклюзивные коммерческие средства. Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем. Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет, потому что лицензия BSD к этому не располагает, так как все результаты инвестиций окажутся в чьём-то проприетарном форке.
Парни, вы там в Postgres Professional молодцы со всех сторон, но с таким однобоким восприятием реальности я боюсь, что вы долго не проживёте. Религиозные секты долго не живут.
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
Такого я не писал и не имел ввиду. Я утверждаю, что MySQL – не является продуктом сообщества, он является open source продуктом компании Oracle. Это отличает MySQL от PostgreSQL, также как и от MariaDB. Если бы этого отличия не было, то и MariaDB была бы, в значительной степени, не нужна.
2. В MySQL есть закрытые баги в багтрекере. А в PostgreSQL багтрекера нет совсем. Поэтому PostgreSQL «открытый», а MySQL «проприетарный»
Да, в PostgreSQL нет багтрекера, подробнее об этом ниже. Но это не значит, что баги не ведутся совсем. Баги сейчас ведутся в отдельном mailing list. И этот mailing list открыт и достуен всем. И потом речь не только о багах, но и тестах. Все тесты в PostgreSQL также открыты, в отличие от MySQL.
3. В PostgreSQL все решения принимает сравнительно небольшая группа людей.
Одни решения принимает сравнительно небольшая группа людей, другие – сравнительно большая. И это, пожалуй, очень обширная тема.
Вот решили, что не нужен им багтрекер, и нет его.
Такого решения никто не принимал, в настоящее время понимание того, что багтрекер нужен есть. Решение по поводу того, какой это будет багтрекер и каким должен быть процесс перехода на него, ещё не принято.
Решили, что не будет встроенной логической репликации, и нет её.
Такого решения тоже никто не принимал. На текущий момент реализации логической репликации для PostgreSQL не достигли достаточного качества, чтобы их включили в ядро.
Решили, что не нужны хинты в оптимайзере, и нет их.
Да, так и есть. Безусловно, это спорное решение. Все продукты проходят чере спорные решения. Но это не значит, что они не могут быть со временем пересмотрены.
Но конечно же, «процесс разработки открыт и принадлежит сообществу». Эти мантры сколько не повторяй, реальностью они не станут.
Да, он открыт принадлежит сообществу. Это не мантра, это так есть, в этом может убедиться любой желающий, у которого есть интернет. Достаточно следить за mailing list'ами, git'ом, wiki и т.д. Вы же не отрицаете, что разработка MariaDB принадлежит сообществу? Вопрос может быть в том, что это, может быть, не самый лучший и эффективный в мире подход к разработке ПО. Но вы могли заметить, что этого вопроса я нигде не касался.
Вот вы сейчас привели негативные примеры того, как это может мешать PostgreSQL принимать определённые решения. Процесс достижения консенсуса в сообществе может быть слишком долгим и медленным, по сравнению с волевыми решениями, которые принимаются в компаниях с жёсткой иерархической структурой. Но даже негативный пример подтверждает, что решения принимаются всё-таки сообществом.
А коммерческая компания не только имеет эксклюзивные права на продукт, но и вкладывает в разработку эксклюзивные коммерческие средства. Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем. Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет, потому что лицензия BSD к этому не располагает, так как все результаты инвестиций окажутся в чьём-то проприетарном форке.
Я не очень понимаю, что вы здесь пытаетесь доказать? Вы пытаетесь оспорить, что в PostgreSQL процесс разработки открыт и принадлежит сообществу, или пытаетесь доказать, что это плохо? Второго вопроса, как я уже написал, я предпочёл бы не касаться, во всяком случае, в рамках данной дискуссии.
Парни, вы там в Postgres Professional молодцы со всех сторон, но с таким однобоким восприятием реальности я боюсь, что вы долго не проживёте. Религиозные секты долго не живут.
В данной ситуации, с конструктивной дискуссии свернули именно вы…
Я пытаюсь объяснить очевидную вещь: принадлежность разработки сообществу определяется желанием разработчиков слушать это самое сообщество. А не наличием/отсутствием копирайта, лицензией, тесткейсами и прочим.
У меня лично есть много претензий к взаимодействию Oracle с сообществом. Это потому, что я взаимодействовал с Oracle не раз в качестве этого самого «сообщества». Но я вижу огромные изменения к лучшему за последние пару лет. А вот вы лично что знаете на эту тему, чтобы делать выводы космического масштаба и космической же глупости?
MariaDB вы упорно приводите в пример образцового open source проекта. А про MariaDB Enterprise вы ничего не слышали? Или вот почему сравнивать нужно обязательно PostgreSQL с MySQL. А кто выбирает, что с чем можно и нужно сравнивать? А вот если мы сравним MariaDB с EnterpriseDB? Где разработка будет более открытой? И где можно посмотреть список уязвимостей EnterpriseDB? А нужно ли объяснять, почему его нигде нет?
По поводу багтрекера, вот что мне говорили на этот счёт люди из PostgreSQL сообщества (те, которые без религиозных заморочек): «да, разработкой управляют старпёры, которым очень трудно объяснить необходимость багтрекера». И я рад, что понимание есть. Багтрекера вот только нет, правильно?
И да, сотрудников вашей компании и сообщество PostgreSQL в целом я не раз замечал в совершенно необоснованных утверждениях при очень слабом представлении о предмете. Упорство в отстаивании этих утверждений мне напоминает религиозную секту. Одна из целей этих статей — вернуть вас к реальности.
Но я не желаю вашей компании ничего плохого. Я даже пошутил, когда говорил, что долго вы не проживёте. Проживёте конечно, просто повзрослеете. Когда-нибудь сладкий дурман инвесторских денег рассеется и выяснится, что разработка софта и чтение лекций в университетах — это очень романтично, но денег не приносит. И умные люди посоветуют, что для построения устойчивой бизнес-модели нужны подписки, а не одноразовые договоры. А дальше выяснится, что для удержания клиентов в рамках подписки нужно добавлять какие-то уникальные предложения, которых больше ни у кого нет. Единственное, что в open source бизнесе можно придумать — это проприетарные расширения или форки. А потом придут другие люди с большими деньгами и серьёным промышленным применением PostgreSQL, которые попросят не публиковать уязвимости. И ваш гордый ответ «А у нас, знаете ли, всё принадлежит сообществу!» им не понравится. И придётся вылезти из детских штанишек, перестать кричать «MySQL — проприетарщина!» и всё у вас будет хо-ро-шо.
У меня лично есть много претензий к взаимодействию Oracle с сообществом. Это потому, что я взаимодействовал с Oracle не раз в качестве этого самого «сообщества». Но я вижу огромные изменения к лучшему за последние пару лет. А вот вы лично что знаете на эту тему, чтобы делать выводы космического масштаба и космической же глупости?
MariaDB вы упорно приводите в пример образцового open source проекта. А про MariaDB Enterprise вы ничего не слышали? Или вот почему сравнивать нужно обязательно PostgreSQL с MySQL. А кто выбирает, что с чем можно и нужно сравнивать? А вот если мы сравним MariaDB с EnterpriseDB? Где разработка будет более открытой? И где можно посмотреть список уязвимостей EnterpriseDB? А нужно ли объяснять, почему его нигде нет?
По поводу багтрекера, вот что мне говорили на этот счёт люди из PostgreSQL сообщества (те, которые без религиозных заморочек): «да, разработкой управляют старпёры, которым очень трудно объяснить необходимость багтрекера». И я рад, что понимание есть. Багтрекера вот только нет, правильно?
И да, сотрудников вашей компании и сообщество PostgreSQL в целом я не раз замечал в совершенно необоснованных утверждениях при очень слабом представлении о предмете. Упорство в отстаивании этих утверждений мне напоминает религиозную секту. Одна из целей этих статей — вернуть вас к реальности.
Но я не желаю вашей компании ничего плохого. Я даже пошутил, когда говорил, что долго вы не проживёте. Проживёте конечно, просто повзрослеете. Когда-нибудь сладкий дурман инвесторских денег рассеется и выяснится, что разработка софта и чтение лекций в университетах — это очень романтично, но денег не приносит. И умные люди посоветуют, что для построения устойчивой бизнес-модели нужны подписки, а не одноразовые договоры. А дальше выяснится, что для удержания клиентов в рамках подписки нужно добавлять какие-то уникальные предложения, которых больше ни у кого нет. Единственное, что в open source бизнесе можно придумать — это проприетарные расширения или форки. А потом придут другие люди с большими деньгами и серьёным промышленным применением PostgreSQL, которые попросят не публиковать уязвимости. И ваш гордый ответ «А у нас, знаете ли, всё принадлежит сообществу!» им не понравится. И придётся вылезти из детских штанишек, перестать кричать «MySQL — проприетарщина!» и всё у вас будет хо-ро-шо.
О, какие бездны открываются!
Не стесняйтесь, напишите уж статью «Как правильно критиковать PostgreSQL» по мотивам своих же комментариев. Уверен, оценят.
Хамство, как логический итог дискуссии с вашей стороны. Ок.
Не стесняйтесь, напишите уж статью «Как правильно критиковать PostgreSQL» по мотивам своих же комментариев. Уверен, оценят.
долго не проживёте. Религиозные секты долго не живут… сотрудников вашей компании и сообщество PostgreSQL в целом я не раз замечал в совершенно необоснованных утверждениях при очень слабом представлении о предмете… мне напоминает религиозную секту… придётся вылезти из детских штанишек...
Хамство, как логический итог дискуссии с вашей стороны. Ок.
О, боевая пехота подтянулась. То есть, когда вот вы лично хамили мне, а я старался избегать любой критики PostgreSQL, всё было нормально. Когда я начал критиковать PostgreSQL, естественно начались вопли «а нас-то за что? Хамство!»
Вы где пропадали-то всё это время? На мои вопросы в посте про репликацию не желаете ответить? Ни единого уточнения, и ни единого ответа от сообщества PostgreSQL пока не последовало.
Вы где пропадали-то всё это время? На мои вопросы в посте про репликацию не желаете ответить? Ни единого уточнения, и ни единого ответа от сообщества PostgreSQL пока не последовало.
Мне еще раз цитату выше из вас привести (могу и дополнить, кстати)? Где там критика PostgreSQL?
Я бы понял, если бы у вас, как говорят, «пукан забомбил» в мою сторону, но человек с вами спокойно и вежливо беседовал, в ответ вы обозвали его и все сообщество PostgreSQL сектой, обвинили в некомпетентности, да еще стали поучать на бизнес-темы.
Я бы понял, если бы у вас, как говорят, «пукан забомбил» в мою сторону, но человек с вами спокойно и вежливо беседовал, в ответ вы обозвали его и все сообщество PostgreSQL сектой, обвинили в некомпетентности, да еще стали поучать на бизнес-темы.
Как я и предсказывал, компания Postgres Pro выпустила свой проприетарный Postgres Pro Enterprise. Добавил упоминание в статье.
Да, мы завели проприетарный форк. И сделали это на общих правах, также как это мог бы сделать любой Вася Пупкин. Преимуществоство наше здесь только в знаниях и опыте, а не каких либо правах. В этом и заключается отличие от MySQL, которое я хотел подчеркнуть.
А зачем? Какая-то концепция есть? Продавать будете? В чем планируется принципиальное отличие от Postgres Pro и, например, EnterpriseDB?
Ну это не про PostgreSQL vs MySQL, а про BSD vs GPL. И этому спору в обед сто лет. Точно такие же споры велись лет 15 назад про FreeBSD vs Linux. «Самая либеральная лицензия», «принадлежит сообществу», «кто угодно может сделать проприетарный форк» и далее по списку.
BSD даёт больше прав потребителям кода, GPL даёт больше прав авторам. Я за большие права для авторов. А всех желающих поспорить отправляю к Столлману.
BSD даёт больше прав потребителям кода, GPL даёт больше прав авторам. Я за большие права для авторов. А всех желающих поспорить отправляю к Столлману.
Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем.
Главное препятствие, имхо, для PostgreSQL — это его некая элитарность в плане администрирования, а не модели разработки и копирайты.
Объясните кто-нибудь, откуда там элитарность? Что постгрес действительно сложнее поднять, чем mysql?
Поднять — нет. Это даже я могу ) Создать хотя бы одного пользователя с правом удаленного доступа и базу под него — уже сложнее.
Ставил когда-то mysql на windows и postgres на linux. Установка mysql сводилась к «далее», а pg ставился из реп. Но mysql требовался только локальный доступ, а pg нужен был доступ извне (пришлось повозиться с pg_hba).
Главное препятствие, имхо, для PostgreSQL — это его некая элитарность в плане администрирования, а не модели разработки и копирайты.
У меня в планах ещё две статьи, где в том числе и эту тему буду разбирать. И возможно ещё одна, заключительная, с подведением неутешительных итогов культурного обмена. Пока слишком занят.
Банкет стихийно продолжается, я смотрю.
Да, постгрес свободнее mysql, потому что лицензия BSD свободнее GPL. Компания Postgres Professional существует, а MySQL Professional вряд ли возможна.
Про багтрекер и реплицкацию уже объяснили ниже, чтоврете заблуждаетесь.
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
Да, постгрес свободнее mysql, потому что лицензия BSD свободнее GPL. Компания Postgres Professional существует, а MySQL Professional вряд ли возможна.
2...— ваш фирменный стиль передергивания. Какое отношение багтрекер имеет к открытости в лицензионном смысле?
3. В PostgreSQL все решения принимает сравнительно небольшая группа людейА в mysql монетку подкидывают или голосование проводят среди пользователей?
Про багтрекер и реплицкацию уже объяснили ниже, что
Решили, что не нужны хинты в оптимайзере, и нет ихДа, тут аргументированный консенсус. Если в mysql на неделе семь пятниц, то это проблемы mysql.
Которые позволяют MySQL оставаться лидирующей базой данных для вебДа? А мужики-то не знают. Оказывается, только благодаря деньгам оракл mysql на каждом хостинге оказалась. Не иначе и фейсбук подкуплен ораклом.
Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет...практика говорит об обратном. Если вы не считаете средства сравнимыми (вложенные теми же EnterpiseDB и Oracle), поделитесь данными.
Да? А мужики-то не знают. Оказывается, только благодаря деньгам оракл mysql на каждом хостинге оказалась. Не иначе и фейсбук подкуплен ораклом.
Ну так-то это правда, что после покупки Сана Ораклом у MySQL внутренние команды были существенно увеличены, причем девелопмента именно опенсорса. Стало существенно больше фокуса на качество. С другой стороны патчи, которые скажем приходили со стороны сообщества, я видел мало, хотя они были.
p.s. я коллега kaamos, ушел правда позднее
Не корми тролля. Он здесь не для того, чтобы что-то там узнать. Он здесь, чтобы посильнее всех в грязи извалять. Ты разве не видишь?
Ну так-то это правда, что после покупки Сана Ораклом у MySQL внутренние команды были существенно увеличены
Не сомневаюсь, просто, мне помнится, популярным mysql стал задолго до этого.
Я бы даже сказал, что после покупки Сана Ораклом mysql стал менее популярным в качестве СУБД по умолчанию для новых проектов. По ощущениям, так же никак не заметно, что в Оракл (да и в сообществе в целом) заинтересованы в том, чтобы на mysql мигрировали с других «взрослых» РСУБД. Как-то «реклама» идёт в ключе: «мы сделали новую фичу (или починили старый баг) и теперь вам нет нужды выбирать что-то другое».
Оракл заинтересован, чтобы MySQL оставался СУБД #1 для web. В такой позиции есть как минусы (в других нишах он не заинтересован), так и плюсы (эту нишу он просто так не отдаст, и будет вкладывать туда столько ресурсов, сколько нужно для сохранения статус-кво).
А по поводу миграций, те люди, которые могут рассказать о каких-то реальных историях с клиентами, в том числе и о миграциях, связаны всякими договорами о неразглашениях. Сами же клиенты, по крайней мере большие компании, по разным причинам тоже стараются не разглашать такие вещи. Я вот сам такую историю недавно услышал про Яндекс. Но не хочу пересказывать, чтобы никого не подводить.
Редкие исключения бывают. Вот например Uber рассказывает о внедрении MySQL параллельно к существующей инфраструктуре на PostgreSQL. Это не совсем «миграция», но тоже показательная вещь
Редкие исключения бывают. Вот например Uber рассказывает о внедрении MySQL параллельно к существующей инфраструктуре на PostgreSQL. Это не совсем «миграция», но тоже показательная вещь
Я бы сказал, что не MySQL стал менее популярен, а классические базы данных стали активно заменяться на NoSQL, in-memory key-value storage решения, там где возможности РСУБД не нужны (ну или получаются решения «из пушки по воробьям»).
При оракле MySql стал двигаться в нужном направлении: strict mode по дефолту, избавление от myisam в системных таблицах, всякие оконные функции и т.д. начинают появляться, т.е. Oracle пытается развивать mysql, это факт, и сливать его не будет.
Ну а так да, популярным мускуль стал примерно во времена mysql 3.23, где из функциональности был только адъ
Ну а так да, популярным мускуль стал примерно во времена mysql 3.23, где из функциональности был только адъ
Я тут подучил теорию немношк.
Во времена MySQL 3.23 в PostgreSQL не было репликации вообще ни в каком виде (ни встроенной, ни внешней), не было FTS вообще ни в каком виде, вакуум нужно было запускать строго вручную, не было контрольных сумм, не было UPSERT, не было ни единой компании, которая предлагала бы коммерческую поддержку. Это так, для справки.
Во времена MySQL 3.23 в PostgreSQL не было репликации вообще ни в каком виде (ни встроенной, ни внешней), не было FTS вообще ни в каком виде, вакуум нужно было запускать строго вручную, не было контрольных сумм, не было UPSERT, не было ни единой компании, которая предлагала бы коммерческую поддержку. Это так, для справки.
Обновил раздел о соответствии стандартам. Оказывается, бывают случаи, где MySQL лучше поддерживает стандарт SQL, чем PostgreSQL. Теперь есть ссылка на соответствующую статью.
Обновил текст ссылкой на свежую серьёзную проблему с кодировками в PostgreSQL.
Проблема проявляется только на системах, где некорректно работает локаль (strxfrm возвращает некорректный результат). Сторого говоря, можно поспорить с тем, что это проблема PostgreSQL. Тем не менее, исправление было закоммичено через 2 дня после репорта.
С точки зрения пользователя, естественно это проблема в PostgreSQL. Рад, что исправление было закоммичено через 2 дня. Что я, как пользователь, должен сделать, чтобы получить исправленную версию?
Пользователь может предпринять одно из трёх действий, чтобы справиться с проблемой:
1) Обновиться до следующего минорного релиза (выйдет в ближайшие дни).
2) Если нет возможности ждать выхода минорного релиза, то самому собрать ветку REL9_5_STABLE.
3) Починить локаль ОС или сменить ОС или сменить локаль.
1) Обновиться до следующего минорного релиза (выйдет в ближайшие дни).
2) Если нет возможности ждать выхода минорного релиза, то самому собрать ветку REL9_5_STABLE.
3) Починить локаль ОС или сменить ОС или сменить локаль.
Спасибо. Краткое резюме для того, чтобы у меня и других была полная картина происшествия:
Всё верно?
- проблема выражается в неверных возвращаемых данных с определёнными локалями на определённых распространённых версиях дистрибутивов, в которых есть ошибка в strxfrm() в glibc;
- проблема появилась в ветке 9.5, первый стабильный релиз которой вышел 7 января 2016г.;
- проблема была обнаружена только 21 марта 2016г.;
- исправление было внесено в исходный текст 23 марта;
- исправление заключается в запрете оптимизации abbreviated keys для всех не-C локалей
- исправление будет выпущено 31 марта
- тем, кто не может ждать 31 марта, рекомендуется пересобрать и обновить PostgreSQL самостоятельно, либо сменить дистрибутив, либо отказаться от использования не-C локалей.
Всё верно?
Кстати, мне в связи с этим багом стало любопытно, кто и как занимается QA для Postgres. В смысле, есть ли выделенная компания, команда, человек, которые занимаются исключительно тестированием, составлением регрессионных тестов, проверкой покрытия, и т.д.? Я не говорю, что все это плохо делается, но определённые вопросы этот баг поднимает. Можете ответить? Спасибо.
Sign up to leave a comment.
Памятка евангелиста PostgreSQL: критикуем MySQL ещё грамотнее