Со времени предыдущей публикации дорогая редакция получила большое количество отзывов. Большинство из них были позитивными, что несомненно укрепляет веру дорогой редакции в человечество. Поступило и несколько серьёзных дополнений в виде критических замечаний о MySQL, о которых я либо забыл, либо никогда не слышал. Что и привело к созданию второй части, которая на самом деле является дополнением к первой и изначально не входила в мои планы.
Итак, продолжаем разбор типичных заблуждений о MySQL в рамках культурного обмена и осеннего обострения. Для начала несколько критических отзывов о первой части.
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
Иногда добавляют, что слышали это только про Facebook/Twitter, а про остальные не в курсе. Кто-то говорит, что не используют JOIN-ы. Но источник никто не указывает.
Во-первых, даже если бы это было так, это бы ничего не меняло. Этот краткий и далеко не полный список компаний я привёл только для того, чтобы показать: нравится это кому-то или нет, но MySQL — самая популярная СУБД в крупнейших веб-компаниях, поэтому legacy технологией её можно называть только живя в какой-то своей параллельной реальности.
Во-вторых, нужно понимать, что речь идёт о полутора десятке огромных компаний с десятками и сотнями внутренних сервисов, в каждом из которых свои структуры и объёмы данных, требования по времени отклика, распределение по чтению/записи и т.д. Не в каждом из этих сервисов используется MySQL, но утверждать, что в каждом случае MySQL используется исключительно в качестве key-value хранилища — как минимум наивно.
Проще всего с Wikipedia — исходный код MediaWiki открыт, каждый может посмотреть на типы запросов самостоятельно. К тому же сотрудники Wikipedia рассказывают об инфраструктуре подробнее, чем представители других компаний.
Возвращаясь к Facebook, какие-то наиболее нагруженные сервисы несомненно работают как key-value. Просто потому, что данные шардированы по тысячам серверов, а перед СУБД стоит key-value кэш, что несколько ограничивает применение агрегации, JOIN-ов и т.д. Но сервисов у Facebook много, и требования к ним разные. Здесь довольно свежее описание используемых в Facebook технологий для хранения данных. Если вы найдёте там подтверждение тезиса об исключительно key-value характере использовании MySQL — дайте мне знать.
«Длинный список использующих MySQL компаний ничего не значит, потому что сейчас бы они MySQL не выбрали»
Никаких обоснований, естественно, не приводится, но я попробую сам. В этом была бы своя логика, если бы речь шла о статичных компаниях, которые не растут, где не появляются новые сервисы и новые задачи по хранению и обработке данных. Или о небольших компаниях, где ограничены ресурсы, а значит лучшая СУБД — это та, с которой «знакома команда». Возвращаясь к пресловутому Facebook, ни то ни другое к нему не относится. Там нет никаких «религиозных» предубеждений, разные технологии используются исходя из конкретных технических задач. Бывает и так, что разрабатываются новые технологии, потому что ни одна из существующих не подходит под требования. Примеры: Cassandra, Presto, Scuba.
Если пытаться обобщить причины, по которым компании выбирают и продолжают выбирать MySQL, то я не открою Америку, если скажу, что MySQL используют как надёжное и масштабируемое хранилище для OLTP нагрузок (с key-value как частный случай). Я старательно избегаю критики PostgreSQL, поэтому и здесь многозначительно промолчу — будет отдельная публикация.
А если кто-то говорит, что существует волшебная СУБД на все случаи жизни, купите ему леденец.
«MyISAM на самом деле актуален, потому что ...»
Кто-то говорит, что «бытовые» (кстати что это?) CMS используют MyISAM. Кто-то говорит, что системные таблицы до сих пор в MyISAM (и это отчасти верно даже для 5.7, хотя были надежды, что это исправят). Кто-то использует MyISAM как хранилище для временных / append-only данных вроде логов.
Я могу только повторить сам себя: MyISAM это действительно legacy в полном смысле этого слова. Ограничения всем известны, код не развивается, и вряд ли даже поддерживается, и есть полноценная замена. Если кто-то где-то ещё находит ей применение — это прекрасно, но я бы всё-таки посоветовал посмотреть на InnoDB. Особенно в 5.7, где производительность в сравнении с MyISAM была одним из приоритетов. Просто скажите
«А вот есть такой доклад и такая статья, где доказывают, что MySQL — это путь в никуда»
Я знаю, спасибо. Обзор репликации в целом и доклада/статьи в частности должен был выйти вместо данной публикации, но у меня меньше времени, чем хотелось бы. Всё будет, как обещал.
И пара новых мифов, которые добавили в комментариях.
«В MySQL проприетарщина!»
Сказал это тот самый человек, который якобы никогда никаких мифов о MySQL не придумывает и не распространяет. MySQL — это бесплатный проект под свободной лицензией. А речь судя по всему о MySQL Enterprise. Я вижу практически прямое соответствие между MySQL Enterprise и продуктами EnterpriseDB. Но «проприетарным» от этого PostgreSQL никто не называет.
«MySQL не нужен, потому что <смешной пример из интернета>»
Обычно идёт ссылка на эту статью, которая, наверное, составляет самое серьёзное дополнение из всех прочитанных комментариев к предыдущей статье. Сама статья, на мой взгляд, представляет из себя пример грамотной критики MySQL без «евангелистских» выводов типа «MySQL — путь в никуда», «MySQL не нужен», «очевидно ущербная СУБД» и прочего выдавания желаемого за действительное. Человек перечисляет примеры странного или неинтуитивного поведения. Половина из них основана на одном простом факте: в MySQL есть неявное приведение типов, которое распространяется не только на операторы, но и на функции. Все примеры с LEAST() из упомянутой статьи эксплуатируют этот единственный факт. Туда же относится популярный пример с SELECT 0 = 'Sean'.
Что может выглядеть странно для человека, который чаще имеет дело со строгой типизацией (для меня, например, выглядит странно), но абсолютно естественно для программистов на JavaScript, PHP, Perl и прочих языков из мира web. Для этих языков можно привести много похожих примеров, и это никого особо не удивляет.
По остальным примерам из упомянутой статьи:
— примеры с ENUM: да, странное, хоть и документированное поведение. Но вообще есть гораздо более серьёзные причины не использовать ENUM, которые относятся к любой СУБД.
— примеры с UNION и INNER JOIN — да, с парсером куча проблем, и здесь никаких возражений. О планах переписать парсер в MySQL я слышу уже много лет, и работа наконец началась, что не может не радовать.
— пример с bug #27877: печально известный нюанс с правилами сортировки для немецкого языка и кучей проблем с совместимостью и апгрейдами. Но решение для этой проблемы существует уже 3 года как в основном MySQL, а в MariaDB и Percona Server решение появилось ещё раньше.
Подводя итог, я не вижу в таких вещах поводов для типичных выводов, которые из них делают. Если кто-то считает, что в других СУБД подобных вещей нет, то у меня плохие новости. Раз мы здесь разговариваем в контексте PostgreSQL, можете поискать по ключевым словам «postgresql gotchas», там попадаются забавные вещи.
Если попытаться это всё обобщить и сформулировать грамотно, то я бы сказал так. В MySQL соответствие SQL стандартам никогда не было приоритетом, и общее соответствие ниже, чем во многих других СУБД, включая PostgreSQL, где соответствие стандартам является одним из главных приоритетов. Но любят MySQL не за это, и об этом позже.
Заключение
Я всё ещё собираюсь написать отдельные публикации по репликации и сравнению MySQL с PostgreSQL с точки зрения MySQL пользователя. Но перед этим хотелось бы закрыть тему критики MySQL со стороны PostgreSQL сообщества. Это важно потому, что такие публикации ожидаемо вызовут шквал комментариев в стиле «нет коммьюнити и делит на ноль втихую!». Чтобы не отвечать много раз, удобнее собрать все ответы в одном месте. Спасибо всем за комментарии, надеюсь, ничего не упустил.
Комментарии (119)
zBit
25.10.2015 18:57-2Может я чего-то не понимаю, но как, даже в языке с динамической типизцией, 0 == 'Sean' >> true? Как это должно работать под капотом, чтобы получилось true?
PHPvar_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
defuz
26.10.2015 01:36+4Не путайте динамическую и не строгую (утиную) типизацию. В Python например типизация тоже динамическая, но она строгая.
mayorovp
26.10.2015 06:16+4Не путайте нестрогую типизацию с утиной.
В том же Python типизация строгая — но это не мешает ей быть утиной. К примеру, библиотечная функция select.select не спрашивает типы объектов, а принимает любые где определен методfileno().
rednaxi
25.10.2015 19:17-1По поводу того, что MySQL используют как key value.
На новом нашем проекте ребята все-таки уговорили меня использовать postgres вместо MySQL, но как ни странно мы postgres тоже используем как key value, потому что sphinx все равно быстрее.
Так что история про key value никак не может быть аргументом для любой РСУБД, потому что все равно найдется специализированный инструмент, который будет работать быстрее.
По поводу MYISAM кстати, я сам не сталкивался потому что давно на сфинкс перешел, но читал что MYISAM может быть интересен своими патченными версиями с интересными индексами, например индексом для координат и гео поиска (сферическая система координат и все такое). Вроде там есть еще какие то ситуативные индексы, которые могут быть интересны. До недавнего времени еще был поднотекстовый поиск, но сейчас уже не актуально.
kaamos
25.10.2015 19:50Spatial indexes для InnoDB появились в 5.7. Что в общем было последним существенным аргументом в пользу MyISAM, да и то в не самых распространённых случаях.
IncorrecTSW
25.10.2015 20:22А что слышно про Aria в MariaDB?
kaamos
25.10.2015 21:27Вот здесь всё написано: mariadb.com/kb/en/mariadb/aria-faq
Но я бы не возлагал особых надежд на версию 2.0 — скорее всего она никогда не случится.
thatsme
26.10.2015 19:00+1Просто скажите наркотикам 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.
kaamos
26.10.2015 19:14-1Я это повторял уже, но видимо придётся ещё не раз. В статьях речь идёт об использовании MyISAM для пользовательских данных. И этого действительно не нужно делать.
Bug #49744 — это совсем из другой оперы. И да, я бы хотел пояснения как по поводу неконсистентности I_S.PROCESSLIST, так и по его связи с багом.
Системные таблицы, относящиеся к репликации уже давно в InnoDB: dev.mysql.com/doc/refman/5.6/en/slave-logs-status.html О каких конкретно проблемах речь?thatsme
26.10.2015 23:03+2Ок. Специально поставил версию 5.6.26 MySQL-a, и да Вы правы, таблицы связанные с репликацией перенесены в InnoDB.
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 вполне положительные. Жаль в продуктив так быстро её не установить. Посмотрим, потестируем…kaamos
26.10.2015 23:14+1А вот что в 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)
thatsme
26.10.2015 23:35Ну 5.7 пока ещё до продуктива совсем далеко… Тут до миграции на 5.6 ещё руки не дошли :/
300 БД по ~180ГБ разнесённых территориально, за один день не мигрируешь. Один план ППР на эти работы пробить, — на 1 год постареть.
Nastradamus
27.10.2015 00:03-1Я уже писал в комментариях к предыдущей статье: с mysql на mysql народ мигрирует годами, в то время как у постгреса всё довольно просто.
nikolaikopernik
27.10.2015 12:08+18.4 -> 9.1 просто как матан
Nastradamus
27.10.2015 12:43Я перекатывался, нормально. Правда, с помощью Slony. Кажется были только проблемы с postgis расширением. На базах, где не было постгиса, разрабы даже не заметили что что-то изменилось )
datacompboy
27.10.2015 13:41У меня синтакс егоги на бинарные строки пошли из-за смены дефолта.
Исправил быстро, конечно.
Lol4t0
25.10.2015 22:17+12А что на счет «Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL потому что она включена в LAMP по уомочанию, а так им вообще пофигу какая будет SQL, потому что разницы они не заметят»?
varanio
25.10.2015 22:53+4Ну а все-таки, что есть такого в MySQL, чего нет в postgres? Хотелось бы конкретики. Из-за чего википедия и т.д. сейчас выбрала бы mysql?
khim
26.10.2015 03:59Потому что на простых запросах MySQL требует меньше ресурсов.
Смотреть в поисковике: «нити», «потоки». Там будет много шума, но в сухом остатке: MySQL на простых запросах тратит меньше ресурсов, на сложных запросах — наоборот. Но ведь не секрет, что почти любой проект начинается с простой модели, которая постепенно усложняется :-)
К тому моменту когда проект дорастает до масштабов когда, может быть, и выгоднее было бы использовать PostgreSQL — он уже плотно «завязан» на MySQL и переделывать его никто не будет…varanio
26.10.2015 07:40+2> Потому что на простых запросах MySQL требует меньше ресурсов.
сильно сомневаюсьkhim
26.10.2015 09:49-6А вы не сомневайтесь, вы проверьте. Создайте базу на виртуалке со, скажем, 1GiB памяти (минимальная доступная сейчас виртуалка… не так давно 256M было), положите туда несколько пару миллионов записей (а сколько их у вас в базе будет если вы стартап?) и посмотрите как отработает тысяч 100 запросов, пущеннах в 100 потоков.
Только не нужно рассказывать мне про то, что я PostgreSQL «готовить не умею»: это не так важно, в стартапе из трёх человек его тоже «некому готовить», никто с default'а никакие кнопки двигать не будет.datacompboy
26.10.2015 12:40+3Вот как раз при «пущенных в 100 потоков» еще недавно мускул вставал в позу «да пошли вы все».
khim
26.10.2015 13:57-1Я боюсь что вы что-то пропустили. Либо у вас запросы требовали чего-то достаточно сложного, либо транзакции, либо ещё чего. Потому что описанный сценарий — это то, что AdWords использовал больше десяти лит (до миграции на F1). И нагрузки там был, мягко скажем, немаленькие.
datacompboy
26.10.2015 14:07+2я погулял по вот этим граблям: www.percona.com/blog/2014/01/23/percona-server-improve-scalability-percona-thread-pool
Причем еще в 11м. Возможно, есть позы и условия когда всё лучше, но я тогда уходил сперва на физическое разнесение реплик через прозрачные репликаторы, а потом просто на слоника.
kaamos
26.10.2015 09:03-1Можно конкретику, но потом :) Думаю, что причины, по которым википедия выбрала бы mysql сейчас не сильно отличаются от изначальных причин много лет назад.
zBit
26.10.2015 09:32+4А с чего вы взяли, что википедия сейчас бы выбрала MySQL?
kaamos
26.10.2015 09:48С того, что если бы были какие-то очевидные плюсы от использования других СУБД, википедия бы давно переехала. Это не так сложно, как кажется. Та же MediaWiki умеет работать с PostgreSQL в качестве бэкенда. И в функциональном смысле естественно PostgreSQL содержит всё, что нужно википедии и гораздо больше. Разница в эффективности.
zBit
26.10.2015 10:15+7Мы использовали PG на не маленьком проекте. Проблемы с производительностью были, но все они решались оптимизацией запросов и индексов. Кстати, в плане оптимизации запросов (WITH, например) у PG больше возможностей, да и в плане оптимизации индексов (функциональные индексы, например) — тоже всё лучше, чем в MySQL. Я не уверен, что в MySQL появились функциональные индесы. Или появились?
Лично мои ощущения после перехода с MySQL на PG — ощущение того, что раньше я пользовался какой-то неполноценной СУБД…nikolaikopernik
26.10.2015 13:48-1А автовакуум в PG вас не напрягает? И постоянно пухнущие индексы?
zBit
26.10.2015 13:55+1Это надо делать крайне редко. А если вы делаете мало UPDATE и DELETE, то, скорее всего, можно вообще без автовакуума обойтись. Проблем с пухнущими индексами не испытывали.
nikolaikopernik
26.10.2015 14:02+1крайне редко? Да вы не работали с PG на большом проекте, если не настраивали кол-во потоков автовакуума и его scale factors.
zBit
26.10.2015 14:44+1Может и были проблемы, но решал их не я, а кто-то другой из нашей команды. И я не писал, что работал над большим проектом :) «не маленький» !== «большой» :)
varanio
26.10.2015 15:03+1Автовакуум напрягает, пока его нормально не настроишь. После чего перестаёт напрягать
kaamos
26.10.2015 19:34Нет, ну с ощущениями спорить невозможно. К тому же, я понимаю, что пишу в блоге PostgreSQL, а не MySQL, поэтому готов ко всяким эмоциональным вещам :)
Но я не об этом пишу. У меня вообще нет в целях кого-то «переубедить», «защитить MySQL» и прочего евангелизма. И даже цели собрать всю критику MySQL у меня нет. Вот, например, утверждение «в MySQL нет подключаемых типов данных» я в коллекцию не вношу — это правда и сформулировано технически корректно, потому для меня здесь нечего обсуждать. Цель статей — отсеять очевидный шлак в критике MySQL из сообщества PostgreSQL. Которого гораздо больше, чем технически корректных утверждений. Только и всего.
baldr
26.10.2015 16:33Я сам скачивал и поднимал дамп википедии на PostgreSQL. Не все таблицы, правда, но основные, со статьями.
Производительность не сравнивал, но возможность этого есть.
Вот тут есть схема для постгреса. Уровнем выше — для других баз тоже. Возможно, они не так хорошо поддерживаются, поскольку мне приходилось подправлять их руками для своих нужд, но декларировать «невозможность» не стоит. И вполне возможно что оценки ведутся.
Таким образом перейти на Postgres технически проблем нет, но есть какие-то другие причины. Возможно просто потому что работает и все устраивает. В таком случае ЧТД.
DmitryKoterov
26.10.2015 03:28+4Про недостатки enum, которые якобы относятся к любой СУБД, имхо неправду написали. В Постгресе замечательные енумы, они очень помогают, никаких проблем (в том числе теоретических) с ними не замечено.
MilkyWay
26.10.2015 03:55-1Каким образом? Чем это лучше enum в бизнес логике приложения?
BlessMaster
29.10.2015 15:01Логика базы и бизнес-логика приложения — «это разные люди».
Это особенно заметно когда одно приложение может работать с несколькими базами, а в одну базу пускают несколько существенно разных приложений и живых пользователей.MilkyWay
29.10.2015 18:20Я о том что енам в базе данных это не гибко. Например вы храните статус о доставке: 0 — не доставлено, 1 — доставлено. Спустя полгода заказчик просит добавить еще один статус «доставлено на склад». Что вы будете делать? Добавлять поля? Пересобирать енам?
mayorovp
29.10.2015 18:40+3Я буду переписывать всю логику, которая была завязана на два конкретных статуса. На фоне этого «пересборка энама» будет меньшей из проблем…
BlessMaster
29.10.2015 20:08Если честно, как-то так сложилось, что я изначально его не использую, благо в Postgres есть широкий выбор альтернатив, например hstore + contstraint на значение. Но конкретно бизнес-логика приложения и логика базы — это всё-таки очень разные вещи. В конкретном приложении может быть значительно меньше опций (а точнее в бизнес-роли), чем в самой базе.
Разным приложениям и ролям может быть доступно разное подмножество статусов. Разница именно в этом. Причём о некоторых деталях хранения в базе приложению вообще знать не обязательно. База точно так же может прятаться за интерфейсом из хранимок и вьюшек, как и серверное ПО за внешнее API, что позволяет некоторую гибкость (как всегда ценой некоторого усложнения). Доводилось сталкиваться примерами, когда вся база была спрятана за хранимками. Сам я предпочитаю «абстрагироваться» в отдельных случаях, вроде хранения журналов бизнес-транзакций и конфиденциальной информации — как одна из контр-мер против ошибки в приложении или sql-инъекции на непривелигированном аккаунте.
Задача базы — хранение данных, желательно в целостном виде :-) Подключение клиента с несоответствующей версией с ошибкой в логике сохранения данных или, хуже того, зоопарк клиентов (совсем ужас — зоопарк разработчиков) — это проблема, если сама база не контролирует вопрос. Это особенно болезненная тема в СУБД, поощряющих нестрогое обращение с данными и не предоставляющих инструменты контроля целостности, вроде Mongo. В результате приложения превращаются в «китайскую вермишель» if-ов на все варианты сохранения документов, но проблему это не решает. В общем, грустная история, поскольку этот нестрогий подход очень импонирует начинающим разработчикам, не желающим «возиться со схемой данных» — гремучая смесь.
varanio
26.10.2015 07:41-1проблемы, к сожалению, замечены: не добавить значение enum внутри транзакции
VolCh
29.10.2015 15:22Теоретические недостатки, которые не могут быть не замечены:
— повторение енумов в каждом столбце, его использующего (создавать отдельный тип из енумов — уже другая история)
— сложность получения списка допустимых значений.
jreznot
26.10.2015 07:08+5Из ваших заметок пока видится только один посыл: не критикуйте MySQL. Лучше бы побольше писали про настоящие недостатки, на которые нужно смотреть при сравнении с Postgres.
kaamos
26.10.2015 09:00+2Да ладно. Критикуйте на здоровье, только давайте делать это грамотно — вот весь смысл заметок. Потому что вести какие-то осмысленные разговоры трудно с критикой в стиле «нет комьюнити, транзакций и далее по списку».
justmara
26.10.2015 10:26+7Если честно — фиговенькая попытка. Убедительных доводов «в защиту» в статье не особо увидел (ну правда, хватит уже тыкать мне в лицо этим списком компаний), а вот в унылые вялые оправдания статья скатилась бодренько. "Ну даа, есть проблема… ну даа, печально известный баг… нуда..."
Итоговое впечатление "всё равно его не брошу, потому что он хороший". А я не выберу MySQL, как хранилище данных, какие бы критерии у проекта ни были — потому что вижу, что потенциального геморроя можно словить на порядок больше, чем… А даже преимуществ-то не вижу. Что, первичная простота развёртывания? Смешно.zBit
26.10.2015 12:30+5И я раньше натыкался на статьи о том как решать ту или иную проблему в MySQL. Потом удивлялся почему об этих проблемах не пишут про PG, подумал, что мало где используется, хреновое сообщество или люди просто не хотят делиться наработками. А поработав с пол годика с PG понял, что таких проблем там просто нет, поэтому о них никто и не пишет.
Дело было года 3-4 назад, вспомнить с какими проблемами конкретно я сталкивался не получается :( Но помню точно, что их не было при работе с PG.
baldr
26.10.2015 16:38+1По-моему это и не было защитой. Вы уверены что вы читали обе статьи?
Автор признает ошибки, но пытается донести мысль, что аргументы, которые приводятся обычно — не совсем честные аргументы и лишь только приводят к тому что никто внятно не может объяснить почему именно в его проекте не нужно выбирать MySQL, а нужен именно Postgres: «потому что вижу, что потенциального геморроя можно словить на порядок больше». Потенциальный геморрой с постгресом тоже можно найти. просто сейчас тренд — «ругаешь MySQL — ты крутой и современный. Защищаешь — ты олдфаг».
Можете сразу ответить на вопрос — в чем бы в вашем существующем проекте вы бы получили проблемы на MySQL?VolCh
26.10.2015 23:13+1Убил двое суток на задачу (упрощенно): заджойнить три (пускай даже две) таблицы (сущность и «лог» операций с ней) так, чтобы запись результирующего запроса состояла из записи сущности и последней (сортировка через ORDER BY по нескольким полям, первичный ключ обычный автоинкремент, в данной задаче можно считать его случайным) с фильтрацией по одному из полей «лога». Удалось добиться перемножения двух таблиц только путем добавления поля «номер» в «лог» и предварительного его заполнения. Иначе на полумиллионе сущностей и более двадцати миллионах «логов» за полчаса результата не дожидался.
kaamos
26.10.2015 18:43+1Ну так я ещё даже не начинал ни защищать MySQL, ни критиковать PostgreSQL. Я вообще о другом говорю.
Romulka
26.10.2015 11:06+3what-postgresql-has-over-other-open-source-sql-databases
www.compose.io/articles/what-postgresql-has-over-other-open-source-sql-databases
Nastradamus
26.10.2015 11:44+6Приятно, что сподвиг автора на новую статью своими комментариями. :) жду статью про репликацию. Очень хотелось бы видеть способы борьбы с подводными камнями.
Кстати, лично я не видел людей, кто поработав с постгресом полгода, решил перекатиться на MySQL. У нас в компании даже mysql-dba считает что мускуль не нужен в новых проектах. Речь о Рамблере, если что :)
Nastradamus
26.10.2015 11:54+7А можно еще немножко вбросить? )
На недавней конференции, Илья Космодемьянский заметил одну интересную вещь: MySQL никто не рассматривает как альтернативу Oracle, в отличие от PostgreSQL.zBit
26.10.2015 12:26+5Может потому, что у PG на порядки больше общего с Oracle, чем у MySQL? :)
CertainMan
26.10.2015 13:01+3Я бы даже сказал, что у PG на порядки больше общего с Oracle, чем с MySQL :)
CertainMan
26.10.2015 13:17+8Из личных наблюдений.
Из Postgres на Oracle и из Oracle на Postgres люди мигрируют без особого дискомфорта.
Про направление MySQL -> PG уже не раз говорили выше.
PG -> MySQL… Лично знаю пару человек, которым при переходе на другую работу пришлось пересесть с PG на MySQL. Цитировать высказывания не буду, ибо забанят, но скажу, что оба переживают такую перемену весьма болезненно.
kaamos
26.10.2015 18:45И тут бы очень пригодились ссылки на источники о желающих перейти туда или сюда. Были?
Nastradamus
26.10.2015 19:553-го ноября в офисе mail.ru будет конференция на тему перехода с Oracle на PostgreSQL. Там будет доклад от Банк Москвы, например.
kaamos
26.10.2015 20:04Я про это утверждение: «MySQL никто не рассматривает как альтернативу Oracle, в отличие от PostgreSQL». Я не против, пусть так (хотя и контрпримеры встречаются). Но интересно, на чём это основано. Если на личных ощущениях — это одно. Если на каких-то исследованиях, было бы интересно почитать.
Nastradamus
26.10.2015 20:18+1Это было на этой конференции:
www.youtube.com/watch?v=jGOkSerUPw4&feature=youtu.bekaamos
26.10.2015 20:21Мне двухчасовое видео нужно посмотреть, чтобы найти ответ на вопрос?
Nastradamus
26.10.2015 20:2312-я минута. Но лучше посмотреть полностью.
kaamos
26.10.2015 20:39На 12-й минуте я услышал «MySQL — в принципе хорошая база данных». И типичные страшилки про MyISAM впридачу. Но я не это спрашивал.
Nastradamus
26.10.2015 20:54Хорошая база данных, у которой durability с кучей оговорок. Вот что там было дальше.
Ну а о том, что никто не рессматривает — там где-то было вроде в докладе. Скорее всего, в перых 20 минутах.
У меня тоже нет времени смотреть этот доклад заново весь.
nikolaikopernik
26.10.2015 14:10+1Работал и с тем и с другим довольно плотно.
Везде свои плюсы и минусы.
В MySQL напрягали очень долгие DDL команды на больших таблицах (до версии 5.5, хз как сейчас). В PG напрягает архитектура UPDATE=DELETE+INSERT, отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы).galaxy
26.10.2015 16:13отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы)
А расскажите, если плотно работали, что за проблемы с автовакуумом? Мое впечатление: с появлением демона автовакуума — включил и забыл.nikolaikopernik
26.10.2015 17:45+1Проблема тут скорее архитектурная. Добрые молодцы в PostgreSQL придумали версионность через неизменение старых картежей, а разгребать последствия предлагают пользователю через костыль — автовакуум. Почему нельзя было скрыть механизм чистки старых кортежей? хз
если таблицы у вас до 10к строк и вялое изменение данных — ок, из коробки автовакуум работает.
Но если размер больше или нагрузка выше — автовакуум может висеть минутами, блокируя полный доступ к таблице. Если много транспортных таблиц — то самого кол-ва потоков автовакуума может не хватать (пока 3 дефолтных чистят 3 таблицы — еще 6 уже забились) Причем это сложно отловить — в коде выполняется очень простые SQL — все должно «летать». Но периодически система «подвисает». Идем в базу — select * from db_activity — а там висят… «богатыри»… молотят.varanio
26.10.2015 18:27+1На pgday рекомендовали иметь график, сколько автовакуумов работает в какой момент времени. Если часто бывает ситуация, когда все автовакуумы работают по максимуму (например, 10 из 10), значит надо увеличить их количество.
Ну и вообще, обычно их ставят агрессивнее, чем по дефолтуnikolaikopernik
27.10.2015 10:04+1это все я знаю, но это уже следствие такой архитектуры, это все уже мануалы аля «FAQ как обойти наш костыль»
я как-то лично спрашивал того же Илью Космодемьянского, упоминавшегося выше, зачем такой механизм с мертвыми кортежами, ведь от него только одна головная боль с этими автовакуумами — он просто пожал плечами — «мол, такая архитектура»
nikolaikopernik
27.10.2015 10:13+1а еще настроенный автовакуум слетает, когда изменяется нагрузка на БД. Настроил ты его на один показатель, таблицы выроста в 10 раз — и все, он уже не будет справляться — его постоянно нужно отслеживать и крутить — я считаю это проблемой. В том же MySQL один раз выставили на большой объем данных — и забыли. Так что, у каждого свои тараканы под кроватью.
galaxy
26.10.2015 20:18+2Проблема тут скорее архитектурная. Добрые молодцы в PostgreSQL придумали версионность через неизменение старых картежей
Нет, проблема принципиальная, связанная с механизмом транзакций: если в момент апдейта в системе присутствуют какие-либо еще транзакции, то БД обязана тем или иным способом сохранять обе версии данных. В оракле (и в mysql InnoDB) тоже есть UNDO логи, которые как-то там чистятся.
Почему нельзя было скрыть механизм чистки старых кортежей?
Он, можно сказать, и скрыт: при низкой нагрузке вам ничего делать не надо. А при высокой, уж извините, в любой СУБД что-нибудь где-нибудь вспухнет рано или поздно, и приходится разбираться и настраивать. За это DBA денюжку и получают.
Хотя согласен, что могли бы сделать сам демон малость поумнее, чтобы он подстраивался под нагрузку.
Может и ведутся какие-то в этом направлении. Я вот припоминаю, сколько раньше надо было телодвижений сделать для настройки стендбая (архивирование логов, перенос, удаление ненужных, отдельная история со switchover), — упростили же.Nastradamus
26.10.2015 23:48Ох, не знаю как сделать его по-умнее… Ведь тяжело понять сколько иопсов у нас еще может выдержать диск. Может нужно как-то отталкиваться от busy rate: если думать, что загреженный диск — это 50% busy.? Предположим, мы решили проблему с вычислением busy rate в разных ОС. Остаётся другая проблема: постгрес не знает какого типа носители находятся под базой (hdd, ssd) и какой процент busy нужно считать «плохим». Уверен, это как-то можно решить для конкретной ОС, но код будет не портабельным.
Вы мне дали пищу для исследований.galaxy
27.10.2015 00:33А вы разработчик PG?
Nastradamus
27.10.2015 01:10Нет, но есть планы написать пару модулей. Пришлось много покопаться в постгресе, когда писал патч, добавляющий одну функцию в pgbouncer (и pgbouncer я не разрабатываю, просто запилил функцию).
varanio
27.10.2015 10:12тут проблема в том, что дефолтные настройки пг рассчитаны на самый-самый минимум всего. Если бы они рассчитывали на некий средний сервер в вакууме, то было бы лучше
nikolaikopernik
27.10.2015 10:09+2В оракле (и в mysql InnoDB) тоже есть UNDO логи, которые как-то там чистятся.
Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали и сделали эту чистку максимально производительно. Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции. Везде всегда говорят — настраивайте автовакуум агрессивнее, но что может быть агрессивнее, чем чистить сразу за собой?varanio
27.10.2015 10:18-1тогда вставки / апдейты будут слишком медленные
nikolaikopernik
27.10.2015 10:22вы это говорите как знающий человек? или просто так?
varanio
27.10.2015 11:07+1А что тут знать?
Демоны автовакуума усердно работают в несколько потоков — значит им есть что делать. Если это будет происходить непосредственно при удалении или апдейте, то время затрачиваемое автовакуумами распределится по конкретным комитам, значит эти комиты будут работать дольше. Кроме того, оптом наверняка дешевле.
VolCh
27.10.2015 11:58+4Но время выполнения транзакций будет более предсказуемым. Оно будет больше зависеть от того, что делает сама транзакция, чем от того, что делали другие транзакции. Анализ затыков базы будет куда проще, легко будет оптимизировать запросы по общему времени выполнения (включая время очистки псоле себя).
galaxy
27.10.2015 14:19Это вы применительно к какому случаю?
В подходе PG как раз поведение более простое и предсказуемое: не надо лезть в UNDO сегменты, не надо ничего восстанавливать.VolCh
27.10.2015 14:47Исходим из требования, что в базе должны быть только данные закоммиченных транзакций и данные ещё незавершенных (не важно коммитом или ролбэком). Исходим из требования, что нам важнее более предсказуемое время выполнения, чем как можно более быстрый ответ. Какой ещё разумный способ, кроме как чистки самой транзакцией, можно предложить?
Увы, но для такого поведения нужно либо неограниченное дисковое пространство, либо какой-то сборщик мусора, который сложно представить, не мешающим выполняемым сейчас транзакциям, если база должна быть доступна постоянно.galaxy
27.10.2015 16:57Исходим из требования, что нам важнее более предсказуемое время выполнения, чем как можно более быстрый ответ.
Не понимаю, откуда возьмется «более предсказуемое время выполнения». Подход постгреса требует меньше работы в каждой транзакции и меньше времени. Если вы про то, что в бекграунде какое-нибудь тормозилово (типа вакуума) может этому помешать, то оно везде может по бесчисленному множеству причин (если у вас не RTOS, конечно).
Какой ещё разумный способ, кроме как чистки самой транзакцией, можно предложить?
Ну не может она сама в общем случае почистить. И в оракле с мускулем не чистит.
Увы, но для такого поведения нужно либо неограниченное дисковое пространство, либо какой-то сборщик мусора, который сложно представить, не мешающим выполняемым сейчас транзакциям, если база должна быть доступна постоянно
Почему сложно? Если сборщик мусора удаляет ненужные записи, на логическом уровне он мешать же не будет (блокировок нет)? Остается вопрос распределения по времени физической нагрузки, тут да, пока не все шоколадно, но, по-моему, принципиальных препятствий нет.
Кстати, в PG чистка идет НЕ ТОЛЬКО в процессе автоваккума. В процессе доступа к страницам (в последующих транзакциях) тоже: momjian.us/main/writings/pgsql/mvcc.pdf
Так что подход комбинированный.
galaxy
27.10.2015 14:16-1Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали
А я не уверен. В mysql так обычно: в одном месте они подумали (как автор приводил пример с теми же float'ами), а в трех других или не думали, или уж лучше бы не думали.
Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции
Я не спец в транзакционных движках, но выше основную мысль до вас пытался донести. При коммите КАКОЙ транзакции и чего чистить? Если в базе идут одновременно много транзакций, то до тех пор пока не закончатся все те, что пересеклись по времени с данной транзакцией, нельзя в общем случае ничего чистить. И это только одна (но принципиальная) проблема. Добавьте сюда особенности записи WAL, репликацию и прочую внутреннюю кухню.nikolaikopernik
27.10.2015 15:16При коммите КАКОЙ транзакции и чего чистить? Если в базе идут одновременно много транзакций, то до тех пор пока не закончатся все те, что пересеклись по времени с данной транзакцией, нельзя в общем случае ничего чистить.
вы говорите как гуманитарий. Транзакция X изменила строку с А на В. Транзакция Х коммитится. С этого момента ресурс А для новых транзакция не нужен (и для старых тоже, исключая если что SERIALIZABLE изоляцию), в худшем случае ждем завершения текущих транзакций и удаляем А.galaxy
27.10.2015 17:04+1Падаю все ниже и ниже. Был евангелистом постгреса, теперь вот гуманитарий уже. Скоро медицинские диагнозы пойдут.
для старых тоже, исключая если что SERIALIZABLE изоляцию
Какая мелочь, право! Может вообще забить на эти уровни изоляции?
И кстати, каждый отдельный запрос внутри себя работает как минимум на уровне REPEATABLE READ (он ведь не должен видеть записи, появившиеся в процессе его работы).
в худшем случае ждем завершения текущих транзакций и удаляем А
Кто ждать должен? Транзакция Х? А СУБД в целом так и делает, это и есть автовакуум. Или вы предлагаете вешать условный триггер на коммит каждой транзакции и кусочно удалять все, что ее существование блокировало? Не лучше ли с точки зрения производительности удалять все сразу и в фоне?
Почитайте еще коммент выше, кстати: habrahabr.ru/post/269463/#comment_8629905
Постгрес не только в процессе автовакуума умеет чистить.
BlessMaster
29.10.2015 15:54+2Автовакуум не просто так по дефолту не самый агрессивный.
— в разные время суток/дни недели нагрузка может быть сильно разная, можно процедуры вакуума настроить в соответствии: потерпеть распухание днём/в будни и агрессивно почистить ночью/в выходные (вплоть до vacuum full, если ожидается период простоя), но даже отстающий в пиках нагрузки автовакуум будет «нагонять» в периоды спада активности.
— транзакции нужно заканчивать как можно быстрее — это важнее, чем «чистить за собой», поскольку увязание транзакций в блокировках может на корню убить производительность и базы, и приложения в пики нагрузки.
С Postgres нужно понять сначала одну существенную вещь: это НЕ та СУБД, что «настроил и забыл». Postgres — это набор инструментов, граничащий с понятием «фреймворк» в языках программирования. С этого момента наступает просветление и понимание как с ним работать и раскрываются горизонты возможностей. А комплект дефолтных настроек нужен только для одного — убедиться, что демон стартует ;-)
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары. Когда про какие-то возможности говорят «здесь это не нужно», в контексте MySQL или Postgres имеют в виду очень разные вещи. В MySQL ориентируются на одно, в Postgres — на другое. Если совсем уже вульгарно: кому-то мыльница, кому-то — профессиональная камера. (На самом деле не хочу сказать, что MySQL — это конкретно «мыльница» — всё-таки за прошедшие годы таки много сделано и определённые фичи — таки круты, а нишу «мыльниц» прочно заняла Mongo; MySQL — это сейчас скорее «крепкий середнячок»).VolCh
29.10.2015 20:03+1Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары.
Одно из следствий подхода том, что из-за того, что даже в средних не-Ит компаниях выделенного администратора БД обычно нет, есть разработчики приложений и есть системные администраторы, и никто из них не хочет брать на себя ответственность за переход на Postgres в инициативном порядке.Ни разработчики, не системные администраторы не мотивированы на то, чтобы становиться профессионалами в администрировании Postgres, с гораздо более крутой кривой вхождения, чем у MySQL. Мне как разработчику Postgres нравится, но вот администрировать его, наслушавшись ужасов в холиварах, мне как-то совсем не хочется.BlessMaster
29.10.2015 20:49Наслушавшись сказок на ночь (по вкусу — насмотревшись ужастиков) — можно дойти до того, что без света не спится ;-)
Честно сказать, не вижу проблемы в детальном знании одного из неотъемлемых инструментов разработки. Не боги горшки обжигают. Если разработчика не смущает изучение языка и среды разработки, тестирование и профилирование кода приложения, почему его должно смущать оное в отношении активно используемого хранилища данных? Причём это вполне касается и MySQL/Mongo/(далее по списку) — в MySQL что-ли настраивать и профилировать нечего? Такое же хранилище, с теми же фундаментальными компромиссами «диск/память/процессор». ИМХО, системного администратора это касается куда в меньшей мере, чем самого разработчика, решающего, что, где и как в базе.
А крутой DBA — это уже для крупных команд и проектов, где пошло расслоение по классам фронтендщиков, и он в не меньшей степени разработчик, поскольку его мнение а-ля «вот здесь всё переделываем, а транзакцию с блокировками организовываем по такому-то сценарию, а вот здесь добавляем скрипт обслуживания данных, иначе через неделю всё загнётся» — прямое руководство к действию и смене планов, как и мнение СЕОшника, или специалиста по UX.
Понятно, что узкий специалист будет лучше разбираться в вопросе, на котором специализируется, но если уж команда не может себе позволить узкого специалиста и всё зависит от «инициативы снизу» (со стороны абсолютно не заинтересованного временного сотрудника), а не целесообразности для бизнеса… ну, что я могу сказать, так тоже бывает — сплошь и рядом. Всякое встречается, как от недостаточности, так и от избытка инициативы.
Ну и как всегда: «самая короткая дорога та, которую знаешь» и «работает — не трожь». Хотя хороший навигатор не помешал бы.
youROCK
26.10.2015 23:45+1Вообще говоря, в MySQL InnoDB операция update это точно такой же delete+insert, и хоть там нет необходимости делать vacuum, там тоже есть похожие проблемы с purge thread и необходимостью делать optimize table, если purge thread не успевает спуржить все записи при интенсивном потоке update/delete. Об этом, кстати, в статье ни слова сказано не было, а жаль.
kaamos
27.10.2015 00:17В какой статье? Моя же вроде совсем не о том, да и хаб неподходящий. Кстати, update=delete+insert только для secondary key, primary key обновляется «по-месту».
Stas911
28.10.2015 22:08А подскажите, вроде как IBM Netezza изначально отпочковалась от Postgre. Вопрос — насколько SQL схожи остались? Нужно потестировать простенькие запросы, но доступа к Netezza нет.
BlessMaster
29.10.2015 16:25Впору выпускать памятку «как не надо критиковать неправильно критикующих» )))
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
«Но, если начать копать, то выясняется, что MySQL там з_а_ч_а_с_т_у_ю используется как key-value хранилище».
Я, конечно, понимаю, что взаимоисключающие параграфы разных источников сковались в одну болванку, но всё же, лучше от этого не становится, это больше похоже на борьбу с ветряными мельницами (от которой сами же вроде пытаетесь отговорить), тем более, что следом сами же подтверждаете мой тезис про Facebook и Twitter: «ибо специфика у них такая».
Сам по себе тезис: «Длинный список использующих MySQL компаний ничего не значит» вполне верен в контексте того, что он не доказывает, что эти конторы, имея опыт использования MySQL не выбрали бы тогда или теперь другую СУБД, не обязательно Postgres (и это никак не проверить — «история не любит сослагательное наклонение»), а тем более в контексте «есть много разных сервисов, для каждого — что-то своё». То есть сама постановка вопроса бессмысленна без всех этих уточнений.
В то же время этот длинный список вполне можно интерпретировать и в духе «даже с MySQL можно жить и зарабатывать» (список потенциальных набросов можно долго продолжать, но я надеюсь идея понятна).
Длинный список компаний использующих некоторую СУБД на самом деле задаёт не верхний предел «это лучшая в совокупности характеристик СУБД», а нижний «это не фундаментальный фактор риска для бизнеса — другие достигали успеха, а естественный отбор не убивает тех, кто эту СУБД выбрал, за стабильностью платформы внимательно следят и вкладываются многие, рынок труда изобилует специалистами по данной технологии». Бизнес, на самом деле, интересуют немного другие вещи, чем те, о которых могли бы спорить технические специалисты.kaamos
29.10.2015 17:32Да, приходится обобщать много сообщений в одно, детали при этом теряются, уж извините. Но утверждение со словом «зачастую» в общем тоже бы хорошо чем-то подтверждать.
Тезис о том, что кто бы и что [не] выбрал, я специально вынес в отдельный пункт. Стартапы следуют моде, для упомянутых компаний важнее эффективность хранения и обработки информации, потому что именно в таких масштабах эта эффективность имеет прямые следствия для бизнеса.
Именно поэтому скорее выбор стартапов как раз менее осознан и более подвержен нетехническим факторам вроде «команда знакома». Гиганты же вынуждены искать способы оптимизации хранения и обработки данных, не ограничивают себя в выборе технологий. Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL. С MySQL на MariaDB — да. На MongoDB — да. Это не значит, что PostgreSQL чем-то хуже для этих проектов. Не хуже, но видимо и не [достаточно] лучше.BlessMaster
29.10.2015 19:24+1Избыточное обобщение приводит к обратному эффекту — люди говорят одно, Вы спорите с чем-то другим, в результате кто с кем спорит и зачем, что самое главное, непонятно :-)
Стартапы — да, наверно самая неосознанная в выборе (хотя все ли?) категория. Но у крупного бизнеса свои заморочки. Смена платформы, особенно, если это смена или переобучение решающей части технических специалистов, в то время как само применение технологии уже проникло на множество взаимосвязанных уровней — может быть неприемлема (хоть в силу дороговизны процесса, хоть в силу религиозных убеждений ядра команды, что тоже нельзя исключать). Радикальная перетряска в этом вопросе скорее ожидаема, если перед бизнесом начинает маячить вопрос убытков и/или банкротства (наверно это мощный мотиватор для поиска альтернатив коммерческим СУБД), но это уже совсем другая история, редко касающаяся гигантов и монополистов в некоторой сфере. Никто ведь не утверждает, что 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, это уже вопрос догадок и допущений, на который лучше отвечать со ссылкой на первоисточники из соответствующих компаний, не полагаясь, однако, на их полную объективность.
> не [достаточно] лучше
В общем, я именно об этом: «не ремонтируй то, что не поломано»kaamos
29.10.2015 19:42Ну, считайте, что про «не поломано» эти статьи и есть, если вам так больше нравится ;)
zBit
30.10.2015 11:26Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
И это не означает, что их никогда не было.
Вообще мигрировать с MySQL на MySQL-подобную СУБД проще, чем на PG если не использовалась более-менее нормальная ORM, которая позволит абстрагироваться от проблемы с разными запросами к разным СУБД. А выбор стэка технологий зависит не от «компании», а от людей работающих в ней. Кто сказал, что в крупных компаниях люди делают только правильные выборы? Почему вы считаете, что в крупных компаниях такого результата можно было достингуть только с этим стэком технологий и с другими стэками они никогда не достигли бы таких результатов?
Вообще, если быть уж совсем честным, то всё это всего лишь инструменты и не маловажный фактор тут — на сколько хорошо команда умеет пользоваться этим инструментом. И нельзя делить инструменты на хорошие и плохие, есть только более (или менее) подходящие инструменты для решения какого-то типа/круга задач.
И пусть не получается всю логику всегда хранить в приложении, а СУБД использовать только как хранилище когда эта СУБД может очень хорошо помочь оптимизировать приложение. Допустим вы храните всю логику в приложении, потом натыкаетесь на проблему производительности вашего решения, потом осознаёте, что если переложите эту часть логики на СУБД, то выиграете в скорости и потреблении ресурсов — тогда перестанете думать, что перекладывание логики на СУБД — это какой-то грех. После этого вы просто будете думать как сделать управление логикой на стороне СУБД более удобной, гибкой и не причиняющей боль.
На мой взгляд, MySQL проигрывает PG по ряду причин:- В PG раньше появилась возможность масштабирования «из коробки».
- RETURNING, как в MySQL без него живут? Ещё я сталивался с проблемами в MySQL, если там PK это не автоинкрементируемый Integer, а UUID, было это, правда, давно.
- WITH — очень хороший помощник в оптимизации запросов к БД, которого нет в MySQL.
- PLSQL — отличный инструмент, которого нет в MySQL, даже нет ничего похожего.
- Функциональные индексы.
- Больше типов данных и можно подключать новые через плагины.
- Не больно делать ALTER TABLE.
AlexBin
30.10.2015 11:54+1>> И нельзя делить инструменты на хорошие и плохие
Это что за новость? Бывают хорошие, а бывают плохие. Еще бывают устаревшие. Я про любые инструменты, а не только в сфере ИТ.zBit
30.10.2015 16:00Может плохие инструменты и есть, но я таких не встречал. Зато встречал инструменты использованные не к месту, в этом случае такой инструмент действительно можно считать плохим, но не объективно, а только в применении к конкретной задаче. Повторюсь ещё раз, объективно плохих инструментов я не встречал, так чтобы они вообще ни на что не годились. И если инструмент устарел — это ещё не делает его плохим, он просто старый.
AlexBin
30.10.2015 16:17Я и написал, что есть плохие, хорошие и устаревшие. Если инструмент не успевает за конкурентами или технологиями, он устаревает.
kaamos
30.10.2015 14:55+1> И это не означает, что их никогда не было.
Так я ж нигде не говорил, что их никогда не было, откуда вы все это берёте? Но я люблю на факты опираться. Вот список «гигантов» на MySQL я привёл. И это я не очень старался, там можно ещё отакенный список привести. А с PostgreSQL мы тоже обсудили. Skype, TripAdvisor, Instagram. Ну пусть будет Яндекс и Авито, хотя отечественный IT он весьма эм, самобытный.
И вот для этого факта есть наверняка какие-то объяснения, да? А вот тут начинается полный разброд, каждый придумывает какие-то свои весьма витиеватые объяснения. Мне, как я говорил, это не особо интересно. Я больше по фактической части. Всё, что я утверждаю — это то, что записывать MySQL в «legacy» несколько рановато, как бы этого кому-то не хотелось.zBit
30.10.2015 15:57-1хотя отечественный IT он весьма эм, самобытный.
А если бы они использовали MySQL, вы бы не считали отечественный IT самобытным?
записывать MySQL в «legacy» несколько рановато
Никто его в legacy записывать не собирается, хотя у него много своих причуд и багов (о них писали выше, некоторые баги/причуды исторические и с ними надо просто смириться), и для высоконагруженного проекта я бы его не выбрал.kaamos
30.10.2015 21:24+1Нет, он самобытный в любом случае. Есть же VK в конце концов. И про производительность я хочу написать отдельный пост, просто не хочу мешать всё в одном.
Но главное, что многие в комментариях не понимают: я не пишу это всё, чтобы убедить кого-то в переходе на MySQL или чтобы доказать какое-либо превосходство MySQL над PostgreSQL. Друзья, прочитайте ещё раз хотя бы заголовки, а ещё лучше сами статьи. Они совсем о другом, как мне кажется. Более того, я считаю, что PostgreSQL — отличная СУБД. Я мало о ней знаю, но практически всё, что знаю, мне нравится :) Но и статьи, опять же, не о том.
zBit
30.10.2015 16:12kaamos
30.10.2015 21:30Нет, мы не будем в это углубляться. Списки клиентов Oracle/MariaDB/Percona легко найти. Но мериться списками клиентов я считаю пустой тратой времени и электричества.
zBit
30.10.2015 21:40Я, собственно, и написал, что это ни о чём не говорит :)
/zanudamode onЛовко вы поставил в один ряд Oracle/MariaDB/Percona :D
datacompboy
Javascript:
0 == 'Sean'
false
kaamos
Я не эксперт в JavaScript, но подозреваю, что там своих gotchas с приведением типов хватает.
datacompboy
Да, но в данном конкретном случае упоминание JavaScript неправильно.
p.s.: в php/perl — да, это true.
kaamos
Хорошо, подправил :)
akalend
для этого в РНР и придумали оператор строгого сопоставления ===
0 === 'Sean'
false
lany
Да ладно, в JavaScript своего веселья хватает:
Транзитивность? Не, не слышал. Таких примеров много.
(disclaimer: мне-таки нравится JavaScript).